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?

  • Garantia que os requisitos solicitados funcionem
  • Qualidade do código (onde o próprio código de testes traz informações sobre a qualidade do código produzido)
  • Garantia da entrega de um produto com maior qualidade

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

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
  • Implementar um pedaço da funcionalidade
  • Executar o 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?

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?

  1. Criar um cenário de teste baseado em uma regra de negócio
  2. Criar o teste baseado no cenário
  3. Executar o teste criado (irá falhar)
  4. Escrever o código até que o teste apresente sucesso
  5. Refatorar o código desenvolvido
  6. Executar o teste novamente

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

Ciclo do TDD

Hands-on

Regra de negócio

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

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

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.
  • É testado se o campo referente ao Valor de Custo é maior do que zero, atendendo a segunda regra de validação
  • É testado se o campo referente ao nome tem o número de caracteres menor ou igual a 100, atendendo a terceira regra de validação
  • É testado se o campo referente a descrição tem o número de caracteres menor ou igual a 500, caso o mesmo exista, atendendo a quarta regra
  • É testado se o campo referente ao código do produto tem o número de caracteres igual, exatamente, a 6, atendendo a quinta regra
  • É testado se o campo referente ao valor da venda é igual a 2119.7375, valor obtido pela fórmula descrita na regra de negócio, atendendo a sexta regra

Execução do teste

Erro ao tentar executar o teste

Escrita do código

Classe produto

Refatoração do código escrito

Execução novamente do teste

Resultado de sucesso do teste executado

Conclusão

É 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.