Trabalhando com TDD em projetos .NET

O Test-Driven Development é uma prática onde desenvolve-se um projeto ou parte dele pensando, primeiramente, em testes. O próprio nome traduzido já é uma auto-explicação, Desenvolvimento Dirigido por Testes. Tal prática tornou-se popular e, consequentemente, muito utilizada devido a garantia de funcionamento e qualidade de itens de desenvolvimento entregues.

Neste contexto, surge algumas perguntas, tais como:

Qual a vantagem em desenvolver assim?

  • Maior cobertura de testes no código

Qual a diferença entre utilizar TDD e criar os testes após o desenvolvimento?

A qualidade final de um código está com base nos testes criados. A diferença entre a maneira que cria-se os testes está no retorno de feedback do teste para o desenvolvedor.

Se um programador começa a criar os testes primeiro, ele recebe feedback constantemente, pois o mesmo consegue dividir seu trabalho em pequenas tarefas. Onde o mesmo consegue ter os seguintes passos:

  • Escrever um teste

A cada teste escrito ele recebe um feedback. E, com isso, fica fácil de alterar o código feito.

Quando o programador desenvolve primeiro e depois, ao final, cria os testes, ele não recebeu nenhum feedback. E ao criar os testes, caso tenha que realizar alguma alteração, a mesma pode ser complexa e trabalhosa e levar um tempo maior para ser feita, custando cara.

Isso irá diminuir minha produtividade?

Onde pratica-se o TDD, obviamente o desenvolvedor irá gastar um maior tempo criando testes, mas não significa ser menos ou mais produtivo.

Tal tempo gasto, é gasto de maneira inteligente. Pois os testes criados, irão perdurar até o fim do projeto/código, ou seja, irá durar por muito tempo. E, além isso, podem ser executados a qualquer momento e quantas vezes for necessário, visando a garantia do código feito.

Também, ao criar/pensar em testes primeiro, facilita as modificações no código que for preciso, como citado acima.

Como funciona o TDD?

TDD é uma técnica de desenvolvimento baseado em um ciclo, independente da linguagem de programação, composto por passos que são:

  1. Criar um cenário de teste baseado em uma regra de negócio

Basicamente, é o que está apresentado na imagem abaixo:

Ciclo do TDD

Hands-on

Regra de negócio

Antes de tudo, é preciso ler e entender qual é a regra de negócio que será solicitada. Sendo assim, tem-se:

Dado itens de produtos, é necessário permitir o cadastro de tais itens. Onde cada produto terá as seguintes informações com seus respectivos tipos:

- Nome [string]
- Código do produto [string]
- Descrição [string]
- Valor de custo [decimal]
- Valor de venda [decimal]

Deve-se considerar as seguintes regras, ao realizar o cadastro de algum item:

- Os campos obrigatórios serão: ‘Nome’, ‘Código do produto’ e ‘Valor de custo’
- O campo ‘Valor de custo’ deve ser maior do que zero
- A quantidade de caracteres do campo ‘Nome’ deve ser inferior a 100
- A quantidade de caracteres do campo ‘Descrição’ deve ser inferior a 500
- O campo ‘Código do produto’ deverá conter, exatamente, 6 caracteres
- O ‘Valor de venda’ será calculado automaticamente, onde constituirá do ‘Valor de custo’ + 15% de seu valor

Cenário de teste

Dado a regra de negócio acima, necessita-se criar os cenários de teste. No caso, cria-se apenas um como demonstrativo, sendo ele:

Deve-se testar um produto válido, onde apresenta-se um item composto pelos seguintes dados:

- Nome: Notebook Acer
- Código: 849071
- Valor de custo: R$ 1.843,25

Deve-se validar todos os campos, de acordo com as regras, onde o resultado deverá ser sucesso.

Construção do teste

Com o cenário de teste já definido, pode-se criar os testes via código, como é exibido abaixo:

Teste unitário da funcionalidade de cadastro de produto

Analisando o código, nota-se o seguinte:

  • Para que um produto exista é necessário informar o nome, código e valor de custo do mesmo. Com isso, tais campos são cobrados no construtor da classe e a mesma não deve permitir ser instanciada sem tais campos, atendendo a primeira regra de validação.

Execução do teste

Após o teste já estar desenvolvido, pode-se executá-lo. Como ainda não tem-se nenhum código criado, o teste não será executado e irá dar erro de compilação.

Erro ao tentar executar o teste

Escrita do código

Após analisar o teste criado, deve-se desenvolver o código que irá atendê-lo, ou seja, criar a classe Produto com todos os atributos esperados.

Classe produto

Refatoração do código escrito

Como o código desenvolvido está atendendo perfeitamente as regras de negócio, não será necessário refatorá-lo. Apenas se houver alguma mudança na própria regra.

Execução novamente do teste

Por fim, ao executar o teste novamente, nota-se que o mesmo irá ter um resultado de sucesso.

Resultado de sucesso do teste executado

Conclusão

Seguindo tais práticas, garante-se que o código desenvolvido sempre estará coberto por uma certa quantidade de testes. Onde, a cada alteração do código pode-se assegurar que o mesmo estará em funcionamento.

É válido, também, considerar que os teste não são imutáveis. Pois as regras de negócio podem sofrer alterações.

Bachelor in Computer Science, MBA in Software Architecture and .NET Developer.

Bachelor in Computer Science, MBA in Software Architecture and .NET Developer.