Drops de testes – A anatomia de um teste automatizado

Estamos fazendo uma série de artigos sobre testes do básico ao avançado com posts todas as terças, você pode ver todos os posts clicando aqui ou ver o post anterior clicando aqui.

Neste post vamos falar sobre como é a estrutura básica de um teste automatizado.

Se não está muito claro para você, recomendo fortemente que você leia o post anterior Drops de testes – Você conhece o conceito A A A?

Onde ficam os testes?

Se você leu o artigo anterior viu que nós temos um exemplo de código de testes que valida um resultado obtido pela execução de um método. Veja abaixo:

[Test] public void DeveRetornarOModeloDoCarroEsperado() { //Arrange var minhaClasse = new MinhaClasse();

//Act
var resultado = minhaClasse.ObterCarro();

//Assert
Assert.AreEqual("Corsa", resultado);

}

Mas onde este código fica dentro do projeto? Em qual namespace? Em qual classe?

Bem, são boas perguntas!
Os testes automatizados, por convenção, residem em uma nova classe com o mesmo nome da classe que irá testar, adicionado do sufixo Testes (ou Tests se você for escrever seu código em inglês). No código acima, por exemplo, estamos testando o método ObterCarro() da classe MinhaClasse. Logo este código de teste automatizado deve residir um nova classe chamada MinhaClasseTestes.

A escolha de onde criar esta nova classe é um pouco mais discutível e vai variar do framework que você estiver trabalhando. No mundo .NET, criamos um novo projeto com o mesmo nome do projeto atual também com o sufixo testes.

Então, se neste caso o nome do nosso projeto, onde escrevemos a classe MinhaClasse, é Carros, o nosso projeto de testes, por convenção, se chamará Carros.Testes.

Este código é um teste?

Você deve ter notado algumas diferenças entre o código padrão que escrevemos no dia a dia para validar uma regra de negócio e o código que escrevemos para um teste, apesar de ambos serem declarados como um método.

Os métodos que funcionam como testes automatizados não emitem retorno e são normalmente void ou Task quando estamos lidando com programação assíncrona. Estes nomes podem ser um pouco diferentes dependendo do framework que você estiver trabalhando, mas tenha em mente que o método de teste não emite um retorno.

Uma diferença bem evidente é o atributo [Test]
Esta anotação na linha anterior ao método de teste fará com que os executores de testes (você já pode ter ouvido falar em test runners) percebam este código, interprete e execute como um teste. Sem este atributo o código existirá, será compilado, mas não executado.

Em alguns frameworks esta anotação poderá mudar de nome e é importante que você cheque na documentação do framework qual é o padrão. No caso de xUnit por exemplo, temos o [Fact], Visual Studio Test temos o [TestMethod].

Você possui outras opção além do [Test] como o [TestCase] mas por hora vamos ver apenas o atributo [Test]

Nomeando um teste

O nome do método de teste deve ser o mais explicativo possível, informando qual é o cenário que está sendo testado, suas condições e resultados esperados. Não se intimide pelo tamanho do nome do testes, ele pode ficar grande algumas vezes, mas quanto mais explicativo, melhor.
Se você possui, por exemplo, um método ObterProdutos que ao receber um parâmetro retorna verdadeiro se possuir produtos disponíveis, o nome do teste poderia ser o seguinte: ObterProdutosDeveRetornarVerdadeiroSePossuiProdutosDisponíveis()

Asserções nos testes

É a asserção que irá validar se a execução da regra de negócio obteve o resultado esperado ou não. É uma boa pratica manter apenas uma asserção por teste automatizado, na maioria dos cenários.

Mantendo apenas uma asserção o teste irá passar ou falhar por um motivo único. Seu teste ficará mais conciso, com a responsabilidade fazer apenas uma validação da sua regra de negócio.

No exemplo citado no inicio deste post, a asserção checa se o resultado obtido é igual a um valor esperado. Caso seja diferente o teste irá falhar.

Nos próximos posts veremos outros tipos de asserção.

—

Por hoje é isso! Ficou claro? Qualquer dúvida deixem nos comentários!

O post Drops de testes – A anatomia de um teste automatizado apareceu primeiro em High5Devs.