A maioria das respostas aqui parece abordar as práticas recomendadas de teste de unidade em geral (quando, onde, por que e o quê), em vez de realmente escrever os próprios testes (como). Como a pergunta parecia bem específica na parte "como", pensei em postar isso, tirado de uma apresentação "bolsa marrom" que fiz na minha empresa.
Testes das 5 Leis da Escrita de Womp:
1. Use nomes de métodos de teste longos e descritivos.
- Map_DefaultConstructorShouldCreateEmptyGisMap()
- ShouldAlwaysDelegateXMLCorrectlyToTheCustomHandlers()
- Dog_Object_Should_Eat_Homework_Object_When_Hungry()
2. Escreva seus testes em um estilo Arrange / Act / Assert .
- Embora essa estratégia organizacional já exista há um certo tempo e tenha muitos nomes, a introdução da sigla "AAA" recentemente foi uma ótima maneira de passar isso. Tornar todos os seus testes consistentes com o estilo AAA os torna fáceis de ler e manter.
3. Sempre forneça uma mensagem de falha com seus Asserts.
Assert.That(x == 2 && y == 2, "An incorrect number of begin/end element
processing events was raised by the XElementSerializer");
- Uma prática simples, porém gratificante, que torna óbvio em seu aplicativo runner o que falhou. Se você não fornecer uma mensagem, normalmente obterá algo como "Esperado verdadeiro, era falso" em sua saída de falha, o que o faz realmente ler o teste para descobrir o que está errado.
4. Comente o motivo do teste - qual é a premissa do negócio?
/// A layer cannot be constructed with a null gisLayer, as every function
/// in the Layer class assumes that a valid gisLayer is present.
[Test]
public void ShouldNotAllowConstructionWithANullGisLayer()
{
}
- Isso pode parecer óbvio, mas essa prática protegerá a integridade de seus testes de pessoas que não entendem a razão por trás do teste em primeiro lugar. Já vi muitos testes serem removidos ou modificados que estavam perfeitamente bem, simplesmente porque a pessoa não entendeu as suposições que o teste estava verificando.
- Se o teste for trivial ou o nome do método for suficientemente descritivo, pode ser permitido deixar o comentário desativado.
5. Cada teste deve sempre reverter o estado de qualquer recurso que toque
- Use simulações sempre que possível para evitar lidar com recursos reais.
- A limpeza deve ser feita no nível de teste. Os testes não devem depender da ordem de execução.