Aplicando Conceitos TDD em .NET

Alex Alves — Thu, 04 Jan 2024 18:17:26 +0000

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
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?
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
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?
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:

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

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

🔧 Mão na massa!

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:

public class ProdutoTest 
{
    [TestMethod]
    [DataRow("Notebook Acer", "849071", 1843.25)]
    public void SalvarProduto_ComDadosValidos_Sucesso(string nome, string codigo, decimal valor)
    {
        //action
        Produto produto = new Produto(nome, codigo, valor);

        //assert
        Assert.IsNotNull(produto);
        Assert.IsTrue(produto.Nome == nome);
        Assert.IsTrue(produto.Codigo == codigo);
        Assert.IsTrue(produto.ValorCusto == valor);
        Assert.IsTrue(produto.ValorCusto > 0);
        Assert.IsTrue(produto.Nome.Length <= 100);
        Assert.IsTrue(produto.Codigo.Length == 6);
        Assert.IsTrue(produto.ValorVenda == 2119.7375);
    }
}

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

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.

public class Produto 
{
    public Produto(string nome, string codigo, decimal valor) 
    {
        Nome = nome;
        Codigo = codigo;
        ValorCusto = valor;
    }

    public string Nome { get; }
    public string Codigo { get; }
    public decimal ValorCusto { get; }
    public decimal ValorVenda { get; } = ValorCusto * 1.15;
}

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.

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.

Forem: Uai Bora Tech!

Aplicando Conceitos TDD em .NET

🔧 Mão na massa!

Conclusão

Referências