Test-First: a anatomia de um teste

Agora que as devidas apresentações foram feitas, você já deve estar inteirado O que o Test-Driven Development não é; O que são Testes de Unidade e até como conseguir criar seu primeiro teste. Assim sendo, acredito que é possível partirmos para conteúdos mais específicos dentro de cada assunto.

Para começar, vou apresentar o que acredito ser uma anatomia válida para um teste de unidade.

Ana….tomia ?

Uma pergunta até que comum que alguns co-workers têm feito é: como identificar se meu teste está bem construído ?

Essa pergunta é um resumo das seguintes perguntas:

  • (Até) Quantas linhas deve ter um teste de unidade ?
  • Já li que é assertion por teste. Não pode ter mais por quê ?
  • Como consigo testar se um Adapter que formata dados para JSON retorna valores fidedignos, se eu tenho √784 itens no retorno ? Fiz um assertion para cada key. Não posso ficar sem testar isso. Tem ideia melhor ?

Para conseguir mostrar visualmente como isso é possível, temos que adicionar ao nosso In-Memory Testing Toolbox a técnica de como identificar se um teste tem partes faltantes (ou excedentes).

Um Teste de Unidade – teste no geral – pode ser separado em três partes: inicialização de dados; exercitar o código de produção; e, analisar resultados. Let’s turn it visible:

    public void testSomaDoisValoresDistintos() {
        int valorA = 10;
        int valorB = 20;
        float resultado = subject.somaValores(valorA, valorB);

        assertEquals(30, resultado, 0.0);
    }

Identificando as três partes:

Inicialização de dados:

int valorA = 10;
int valorB = 20;

Exercitar o Código de Produção:

float resultado = subject.somaValores(valorA, valorB);

Analisar Resultados:

assertEquals(30, resultado, 0.0);

Acredito que essa regra sirva muito bem para você se policiar sempre ao fazer seus testes de unidade. Isso quer dizer: você não precisa fazer 1 assertion/teste; Não precisa sempre criar teste com três linhas (exceto quando estiver treinando – assunto futuro(..)).

Isso quer dizer que não tem nada errado em ter aqueles √784 (28) assertEquals no meu teste do Adapter JSON, certo?

Errrr…. errado! Teoricamente falando isso é possível, porém é importante lembrar que frameworks de testes deste século utilizam técnicas de Hotspoting (assunto p/ outro post) que permitem nós definirmos nossos próprios assertions. Já visualizou como resolver o problema do JSON?

    public void testJsonAdapterReturnsEncodedJsonString() {
        # ... inicializa seu objeto para popular dados
        assertJsonAdapterWillContainKeysValues(subject.toJson());
    }

Mesmo sendo uma forma mais compacta, ainda assim temos a inicialização do teste, o exercício do código de produção a ser testado e a validação de que aquele código está de acordo com a especificação.

Mas… porque raios está errado colocar 28 assertions dentro de um teste?

Seu Teste é uma Especificação

Como disse Richard Stallman em The Code Linux, seu código é uma receita. Vamos utilizar a analogia dele em nosso favor: sendo o Teste uma receita, ele deve possuir steps que irá definir como ele chegará ao resultado final, ou seja, o Teste é uma Especificação de como aquele comportamento exercitado pelo mesmo deverá funcionar.

  • Coloque 400ml de água dentro de uma panela e leve-a ao fogo médio;
  • Espere 5 minutos para esquentar;
  • Abra o pacote do miojo e o coloque dentro da panela;
  • Após 3 (tsc, tsc) minutos, adicione o tempero e misture bem.
  • Sirva.

Se conseguir enxergar aqueles três passos da anatomia do teste como uma receita, ficará mais fácil para lembrá-los e visualizá-los nos códigos alheios.

Como uma especificação, ao invés de precisar ler 28 linhas para entender que tudo aquilo é apenas o passo de análise de resultados, não acha mais fácil criar seu assertion customizado e resolver isso com apenas 1 linha – assertJsonAdapterWillContainKeysValues(resultado) ?

A Anatomia apontará mutações genéticas

Seguindo a Anatomia do Teste, se algum dos passos aparecerem mais de uma vez por teste, é indício de que seu teste está testando mais do que uma unidade. Ao topar com isto, você deve: extrair a duplicação e criar outro teste para aquele conteúdo duplicado. Em casos extremos, a duplicação não poderá ser removida. Isso indica ao coder de que a abstração dele caiu por terra ou ainda você está testando o comportamento errado. Será necessário repensar a solução daquele pedaço.

Concluindo

Adote a Anatomia do Teste como sua métrica para um teste conciso. Leia sobre como criar Custom Matchers/Assertions em seu framework favorito de testes. Pratique isso no seu tempo livre. Avalie e peça avaliação de seus códigos de Teste e Produção. Exponha-se à críticas. Fará muito bem.

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s