Boas práticas de Testes Unitários: Não cometa o erro de descrever o seu teste dessa forma!

Você pode até achar que não tem muita relevância, mas eu te garanto que, após um tempo definindo seus testes dessa forma, você terá um grande problema!

Na construção de testes unitários, o padrão de nomenclatura é tão importante quanto a qualidade de escrita do código de teste. Os testes devem ter nomes claros e objetivos, especificando o que está sendo testado, como está sendo testado e qual é o resultado esperado.

Imagine que você está trabalhando em um projeto de construção de um CRUD simples, que possui poucos testes unitários, e o cenário de criação inclui testes nomeados como:

• criarProdutoSucesso
• criarProdutoErro

Acredite, eu já vi diversos projetos que têm seus testes unitários descritos dessa forma.

Digamos que, no cenário de cadastro, exista uma regra que proíbe o cadastro de produtos com o mesmo nome, e isso está sendo garantido pelo teste criarProdutoErro. Amanhã, poderá surgir outra regra para a operação de cadastro, e você terá que implementar outro teste unitário. Agora, haverá um novo requisito que não permitirá cadastrar um produto sem categoria. Seguindo a mesma lógica, o teste provavelmente será nomeado como criarProdutoSemCategoria.

Porém, essa nomenclatura pode gerar confusão. No teste, seu objetivo é garantir que nenhum novo produto seja criado sem categoria. Vamos analisar duas hipóteses:

• Falha no teste criarProdutoSemCategoria: Um desenvolvedor que não criou esse teste poderá imaginar que DEVE ser permitido criar produtos sem categoria, mas não é isso que deve acontecer. Então, ele irá modificar o código para permitir a criação de um produto sem categoria.
• Sucesso no teste criarProdutoSemCategoria: Um desenvolvedor que sabe da regra que proíbe o cadastro de um produto sem categoria, mas que não conhece o código do teste, poderá entender que existe uma falha, na qual a regra que deveria impedir o cadastro de um produto sem categoria não está funcionando.

Como você pode ver, um nome de teste unitário mal definido pode causar bastante confusão. Para evitar esses problemas, sugiro o uso de um padrão bem conhecido: [nome_metodo_ou_funcao]_[descricao_cenario]_[resultado_esperado].

Usando o mesmo exemplo anterior, em que não é possível criar um produto sem categoria, vamos refazer a nomenclatura dos testes seguindo o padrão:

• criarProduto_QuandoAcionarCriacaoDeProdutoSemCategoria_LevantarExcecao
• criarProduto_QuandoAcionarCriacaoDeProdutoDeNomeJaExistente_LevantarExcecao
• criarProduto_QuandoAcionarCriacaoDeProdutoComDadosValidos_RetornarProdutoCadastrado

Você consegue notar a diferença? Agora, em caso de falhas, o desenvolvedor, conhecendo a regra ou não, saberá o que está sendo testado e qual o resultado esperado.

Ao longo do tempo, todas as aplicações tendem a crescer em número de testes unitários, seja com novas funcionalidades ou com bugs descobertos. Já pensou o tamanho do problema que será criado ao longo do tempo pelo simples fato de não ter um padrão de nomenclatura de testes que seja claro e objetivo?!

Espero ter contribuído com você para uma melhor escrita de testes.

Até a próxima, abraços!