____ksjdf

Eu compartilho da opinião de Jimmy Bogard, que diz que os nomes dos testes precisam descrever o que e o porque, a partir da perspectiva do usuário, onde o desenvolver possa ler o nome do teste e claramente entender o comportamento que é esperado.

Um teste unitário nada mais é que um método em uma classe, e tanto em C# como Java, existem convenções de nomenclatura de métodos.

Em C#, nome de métodos são declarados utilizando Pascal Case:

·········10········20········30········40········50········60········70········80········90········100·······110·······120·······130·······140·······150
1.
[TestMethod]
2.
public void ProductShouldHaveAtLeastOneCategory()
3.
{
4.
//Test implementation.
5.
}
Já em Java, convencionou-se escrever métodos utilizando Camel Case:

·········10········20········30········40········50········60········70········80········90········100·······110·······120·······130·······140·······150
1.
@Test
2.
public void productShouldHaveAtLeastOneCategory() {
3.
//Test implementation.
4.
}
Muitas vezes, o nome desses testes (métodos) ficam um tanto longos, como os exemplos acima. Dessa forma, a legibilidade não é muito boa.

Seguindo um dos conselhos de Neal Ford, em sua apresentação 10 Ways to Improve Your Code, você pode deixar de lado as convenções de nomenclatura da linguagem em favor da legilidade dos nomes dos seus testes. Escreva o nome do teste como se fosse uma frase, nada de letras maiúsculas para cada palavra, e use “_” (underscore) para separar as palavras.

Veja como fica o exemplo acima em C#:

·········10········20········30········40········50········60········70········80········90········100·······110·······120·······130·······140·······150
1.
[TestMethod]
2.
public void Product_should_have_at_least_one_category()
3.
{
4.
//Test implementation.
5.
}
E agora em Java: