Se você trabalha utilizando ou já leu algo sobre testes, talvez já tenha se deparado com algumas estruturas, termos e nomenclaturas que podem causar algumas confusões.

É comum tentar assemelhar seus testes à maneira que seu software é utilizado pelos seus usuários. Isso é uma parte muito importante do processo de confiança que você cria com o código que você desenvolve. Um pouco na linha de pensamento utilizada no BDD (Behavior Driven Development ou Desenvolvimento Guiado a Comportamento), embora seja um tópico um pouco mais abrangente.

Entender como funciona a anatomia de um teste, sabendo os pedaços envolvidos no processo e como seu teste é avaliado é parte importante nesse processo todo.

Para prosseguirmos com alguns exemplos de código, seguirei algumas estruturas propostas por frameworks pelo Jest, acredito que é uma das ferramentas que tem mais visibilidade hoje em dia. Mas existem outras no mercado que possuem estruturas semelhantes e, os fundamentos, podem ser aproveitados da mesma maneira.

Cobertura (ou coverage)

É um dos termos mais comuns e acho que é o que mais utilizamos como parâmetro para algumas decisões e resultados quando estamos escrevendo testes.

A cobertura de testes indica quais partes de seu código estão sendo executadas. Por exemplo: se temos um código de 10 linhas e uma cobertura de 50%, isso quer dizer que apenas metade das linhas desse código (ou seja, 5 linhas) estão sendo executadas ao longo dos testes.

Algumas ferramentas geram alguns relatórios visuais em HTML ou até mesmo diretamente no seu terminal, como é o caso do Jest, que oferece um report com uma tabela parecida com essa:

----------|----------|----------|----------|----------|-------------------|
File      |  % Stmts | % Branch |  % Funcs |  % Lines | Uncovered Line #s |
----------|----------|----------|----------|----------|-------------------|
All files |      100 |      100 |      100 |      100 |                   |
 data.js  |      100 |      100 |      100 |      100 |                   |
----------|----------|----------|----------|----------|-------------------|

Vale a pena darmos uma passada sobre cada uma das categorias desse relatório de cobertura.

• Arquivo (ou file): nessa coluna podemos ver todos os arquivos que foram executados ao longo dos testes escritos;
• Declarações (ou statements/stmts): indica quais os termos de declaração (como variáveis e imports) foram ou não cobertos ao executar os testes;
• Ramificações (ou branch): analisando a palavra branch temos ramo (ou "galho") como tradução em português o que faz com que essa coluna possa ser confundida com as branches do git, então vale ressaltar que são coisas diferentes. Os valores que aparecem nessa coluna não condizem com a cobertura de sua branch do git, mas sim com as ramificações de seu código. Podemos entender como ramificação qualquer trecho de código que divide a execução de nosso programas em duas ou mais partes, ou seja: trechos com blocos if/else, switch/case ou ternários; O que essa coluna relata é justamente essa questão: quantas ramificações (trechos de execuções distintas) do código escrito nos arquivos foram executadas.
• Funções (ou functions/funcs): indica se as funções (rotinas e sub-rotinas) do seu código foram executadas ao longo dos seus testes;
• Linhas (ou lines): indica quantas linhas do código estão cobertas;
• Linhas não cobertas (ou uncovered lines): ao contrário do item anterior, indica quais linhas não foram cobertas nos testes.

Agora vamos ver alguns trechos e exemplos mais práticos e entender como eles funcionam.

Suítes de teste (ou test suites)

Suítes de teste é um termo utilizado pra exemplificar um agrupamento de testes. Basicamente! :)

É comum que, no caso do Jest, isso seja confundido com os blocos de describe, que são usados para agrupar alguns testes dentro de um mesmo arquivo, mas não é o caso. Pode parecer confuso, mas o Jest considera que cada arquivo é uma suite de teste diferente.

Nesse caso, a utilização do describe é exclusivamente para realizar um agrupamento mais específico de testes relacionados, por exemplo:

describe('Calculadora', () => {
  // testes relacionados aos cálculos
});

Essa estrutura é totalmente opcional, já que é possível criar testes utilizando outras funções que veremos a seguir. Entretanto, é uma boa ferramenta para aprimorar a semântica (ou seja, o significado) de seus testes já que agrupa testes (ou outros describe) com uma descrição.

O teste em si

É o bloco onde devem ser declarados os testes que realmente serão executados e onde as asserções (que veremos a seguir) serão inseridas.

Através do Jest podem ser acessados através das funções it (que nada mais é que um apelido, ou alias para as funções test).

Dessa forma, podemos criar alguns testes como:

describe('Calculadora', () => {
  it('Soma', () => {

  });
  // ou com test
  test('Soma', () => {

  });
});

Como it e test são iguais, você pode optar pelo que achar melhor.

O que vale a pena ter em mente é que, assim como o describe, utilizar um ou outro pode trazer alguns detalhes mais semânticos pro seu código, já que as funções tem nomenclaturas diferentes.

Asserções (ou assertions)

Asserção significa afirmação. É com as asserções que iremos afirmar o comportamento esperado do nosso código. Assim como os blocos de describe e it, são funções que possuem uma nomenclatura semântica. Podemos pensar na utilização das asserções em duas partes:

• valor atual (ou de entrada/esperado);
• valor a ser comparado (ou de saída/resultado).

Com base nesses dois valores, conseguimos sempre organizar nossos testes. Vamos voltar ao exemplo da calculadora e vamos tentar implementar o teste da função de soma (não vamos realizar a função em si).

Podemos criar nosso bloco de descrição (describe) com um teste (it) para iniciar:

import calculadora from './calculadora';

describe('Calculadora', () => {
  it('Soma', () => {
    // faremos o teste aqui
  });
});

Vamos imaginar que teremos um objeto calculadora que possui o método soma, que recebe como parâmetro dois valores que serão somados. Dessa forma, acessamos a função utilizando calculadora.soma.

Com isso, podemos já criar algumas variáveis que serão responsáveis por conter nosso valor esperado e nosso resultado.

Continuando o teste:

import calculadora from './calculadora';

describe('Calculadora', () => {
  it('Soma', () => {
    // atual (a ser testado)
    const atual = calculadora.soma(1, 1);
    // resultado esperado
    const resultado = 2;

    // asserção será feita a seguir
  });
});

Já temos as variáveis com o retorno função (atual) e o resultado esperado (resultado).

Com isso podemos escrever nossa asserção. A função é iniciada com expect (pois iremos consultar e esperar que algum valor seja igual a algo que determinamos) e essa função retorna um objeto com outras funções (chamadas matchers onde verificamos valores correspondentes), como: toEqual (verifica se um valor é igual a outro), toThrow (verifica se um erro foi disparado), toBeGreaterThan (verifica se o valor é maior que outro).

Caso tenha precise, você também pode criar seus matchers customizados.

Nesse exemplo, podemos utilizar o toEqual já que vamos comparar se o valor retornado por nossa função é igual a 2.

import calculadora from './calculadora';

describe('Calculadora', () => {
  it('Soma', () => {
    // atual (a ser testado)
    const atual = calculadora.soma(1, 1);
    // resultado esperado
    const resultado = 2;

    // asserção feita
    expect(atual).toEqual(esperado);
  });
});

Poderíamos ter moldado o teste de qualquer forma, inclusive removendo as variáveis e passando os valores diretamente. Mas acho que dividindo os testes nessas etapas (entrada, saída e execução da função) é uma forma prática de entender como tudo funciona.

Sobre a semântica e a leitura dos testes que comentamos, podemos parar para fazer uma leitura sobre o teste que criamos. Ao ler o código desenvolvido, podemos ler algo como:

Descrição: calculadora
Ela: soma
Espero: que o valor atual (2) seja igual ao esperado (resultado da calculadora.soma(1, 1));

Com isso, conseguimos ver que além de nos trazer mais confiança, escrever testes que se assemelham à forma como seu software é utilizado é uma forma também de documentar seu sistema. Se seus testes estão organizados, você consegue executá-los, ler suas descrições e entender como seu sistema funciona.

Hooks

Outra estrutura que as ferramentas (como o Jest) costumam disponibilizar, são funções executadas em determinada "parte" dos seus testes. São bem úteis caso você precise ajustar/resetar alguma configuração antes, depois ou a cada teste, você consegue utilizá-las para realizar esse trabalho.

Podemos utilizar as funções:

• beforeAll: para executar algo antes de todos os testes;
• afterAll: para executar algo após todos os testes finalizarem;
• beforeEach: para executar algo antes de cada um dos testes;
• afterEach: para executar algo após cada um dos testes executarem.

Para utilizar essas funções, basta executarmos elas antes dos nossos códigos, algo como:

import calculadora from './calculadora';

describe('Calculadora', () => {
  beforeAll(() => {
    // executa algum trecho de código
    calculadora.limpa();
  });

  it('Soma', () => {
    // atual (a ser testado)
    const atual = calculadora.soma(1, 1);
    // resultado esperado
    const resultado = 2;

    // asserção feita
    expect(atual).toEqual(esperado);
  });
});

A documentação do Jest tem uns exemplos bem bacanas se quiser dar uma lida.

Arquivos

Por fim, apenas um detalhe que vale ser comentado, é comum que alguns arquivos de teste sejam escritos dentro de um diretório como __test__ ou então com o sufixo .test ou .spec (que quer dizer especificação).

E você, já trabalhou com testes? 🧪

Conhecia essas estruturas e já teve experiências com testes? Tem alguma ferramenta favorita que gosta de utilizar e quer comentar?

Espero que tenha curtido e que essas estruturas possam ajudar você a entender e organizar melhor seus testes.