DEV Community: gpiress

Como seguir a pirâmide de testes

gpiress — Wed, 05 Aug 2020 15:57:45 +0000

Testes automatizados estão presentes em (quase) todos os projetos atuais.
Seu uso aumenta a qualidade do produto gerado e torna os times envolvidos mais confiantes e produtivos.

Como tentativa de garantir a qualidade de um projeto, não é difícil encontrar requisitos de porcentagem de código coberto por testes e outras métricas semelhantes. Essas métricas podem acabar sendo maléficas ao código, criando a existência de testes que efetivamente não testam nada, mas que mantém a métrica acima do limite desejado.

Mas então o que devemos testar? E como?

Pirâmide de testes

A pirâmide de testes é como você deve pensar sua estratégia de testes: a base da pirâmide é composta por testes unitários, o meio por testes de integração e o topo por testes End-to-end.

A analogia da pirâmide é útil para trazer uma imagem da quantidade de testes esperada em cada uma dessas camadas. Testes unitários (a base) devem estar presentes em maior número que testes de integração, e testes de integração devem existir em maior número que testes End-to-end.

Vamos falar sobre cada um desses tipos de teste e o como utilizá-los.

Nota: é possível encontrar muitas versões diferentes dessa pirâmide, mas eu acredito que essa é a mais útil para entender os conceitos e contém o necessário para a maioria dos projetos.

Testes unitários

Testes unitários são provavelmente os mais conhecidos e mais difundidos dentre os testes automatizados. Eles testam uma unidade e são normalmente bem rápidos e auto-contidos.

O que é uma unidade?

Eu gosto de definir uma unidade a ser testada como o menor grupo lógico de código possível em sua arquitetura. Isso quer dizer que em Java isso seria uma classe, em ReactJS seria um componente, em alguns projetos NodeJS e Python seria um módulo e assim por diante. O mais importante é ser consistente com a sua definição de unidade para o projeto.

O que testar?

Por via de regra, é necessário escrever testes para toda lógica e regra de negócio contida em sua unidade. Basicamente sua unidade só existe por conta das regras de negócio que ela satisfaz, então elas devem estar bem testadas.

Sendo mais específico, eu costumo testar o contrato de uma unidade, isto é, todas as interfaces públicas que podem ser usadas por outras partes do código.

Segue um exemplo de uma classe CaseConverter que converte uma string para outro tipo de case (snake_case, camelCase):

public class CaseConverter {

    public enum Case {
        CAMEL_CASE,
        SNAKE_CASE
    }

    public String convert(final String input, final Case convertTo) {
        switch (convertTo) {
            case CAMEL_CASE:
                return convertToCamel(input);
            case SNAKE_CASE:
                return convertToSnake(input);
            default:
                return "";
        }
    }

    private String convertToCamel(final String input) {
        StringBuilder camelCaseBuilder = new StringBuilder();

        final String[] words = input.toLowerCase().split(" ");
        for (String word : words) {
            if (camelCaseBuilder.length() == 0) {
                camelCaseBuilder.append(word);
            } else {
                camelCaseBuilder.append(word.substring(0, 1).toUpperCase());
                camelCaseBuilder.append(word.substring(1));
            }
        }

        return camelCaseBuilder.toString();
    }

    private String convertToSnake(final String input) {
        StringBuilder snakeCaseBuilder = new StringBuilder();

        final String[] words = input.toLowerCase().split(" ");
        for (String word : words) {
            if (snakeCaseBuilder.length() == 0) {
                snakeCaseBuilder.append(word);
            } else {
                snakeCaseBuilder.append("_");
                snakeCaseBuilder.append(word);
            }
        }

        return snakeCaseBuilder.toString();
    }
}

O contrato dessa classe é convert(String, Case) -> String ou seja, ao chamar a única função pública convert passando como parâmetros uma String e o tipo de Case desejados, essa função retornará a String convertida.

Devemos porém criar testes que testem toda funcionalidade que oferecemos, converter para camelCase e para snake-case:

import org.junit.Test;

import static org.junit.Assert.*;

public class CaseConverterTest {

    @Test
    public void convert_should_convert_to_camel_case() {
        final String input = "SOmE teXt hERE";
        final String expected = "someTextHere";

        final CaseConverter caseConverter = new CaseConverter();
        final String actual = caseConverter.convert(input, CaseConverter.Case.CAMEL_CASE);

        assertEquals(expected, actual);
    }

    @Test
    public void convert_should_convert_to_snake_case() {
        final String input = "SOmE teXt hERE";
        final String expected = "some_text_here";

        final CaseConverter caseConverter = new CaseConverter();
        final String actual = caseConverter.convert(input, CaseConverter.Case.SNAKE_CASE);

        assertEquals(expected, actual);
    }
}

Desse modo, verificamos que nossa classe cumpre os requisitos necessários, mesmo sem invocar explicitamente cada uma de suas funções. Perceba que as funções ainda são invocadas indiretamente, mas isso não é o mais importante, seu teste agora não assume nada sobre o funcionamento interno. Apenas testa que o contrato é cumprido.

Observação 1: Algumas linguagens não possuem o conceito de funções públicas e privadas, mas ainda assim elas seguem um padrão de contrato de uso. Tente pensar qual o contrato da sua unidade antes de escrever qualquer código!

Observação 2: Java possui a anotação @VisibleForTesting disponível através de diferentes bibliotecas. Eu acredito que o uso dessa anotação é um [code smell(https://en.wikipedia.org/wiki/Code_smell) e deve ser evitado quando possível.

O que não testar: Mocks (Spies)

Frequentemente nossas classes possuem dependências, tanto outras classes definidas no mesmo repositório ou dependências externas. Exemplos comuns são classes de acesso a Banco de Dados e clientes para requisições HTTPS.

Nesses casos, a recomendação é utilizar Injeção de Dependências no construtor da classe e não testar o funcionamento dessas dependências, pois:

Se forem outras classes do seu repositório, elas serão testadas unitariamente em seus próprios testes.
Se forem dependências externas, elas devem ser testadas unitariamente pelos donos da dependência.

Em ambos os casos, as dependências devem ser testadas em testes de integração.

Para não testar e falhar com sua dependência, utiliza-se mocks, que são objetos que fingem implementar os contratos das dependências, e que a pessoa escrevendo testes tem total controle sobre o comportamento.

Lembre-se que o objetivo dos testes unitários é garantir o contrato e testar a lógica interna da unidade, nada além disso. Por isso é necessário seguir a pirâmide de testes!

Uma última dica é que seus testes unitários jamais devem fazer requisições para nada fora da sua aplicação, como por exemplo serviços web externos. Isso se deve porque não há como garantir que esses serviços externos se mantenham online o tempo todo e com a mesma interface (api). Seu teste unitário não pode falhar por conta de um serviço externo.

Testes de Integração

Testes de integração são os mais comuns de serem esquecidos na hora de escrever testes para um projeto. O objetivo dos testes de integração não é testar a lógica das unidades, mas testar como diferentes unidades interagem entre si.

Não é incomum que repositórios tenham várias unidades que juntas são responsáveis por uma finalidade. É possível que todas essas unidades passem testes unitários e mesmo assim não funcionem em conjunto. Os testes de integração garantem que as unidades são utilizáveis em conjunto.

Exemplos de testes de integração:

Em uma página com uma lista de tarefas

Página com componentes de lista de tarefas e adicionar tarefa.
TESTE: Todos os componentes são exibidos corretamente
Adicionar uma tarefa nova
TESTE: A lista de tarefas é atualizada para incluir a tarefa adicionada

Teste "vertical" de uma funcionalidade

Para uma funcionalidade de exibir um mapa com restaurantes bem avaliados na proximidade.

Front end: Página ou componente de App que mostre o mapa
Back end: Serviço que retorna restaurantes bem avaliados dado uma localização
Banco de Dados: Contém as informações de restaurantes: localização e avaliação

Iniciando o ambiente de testes
1. Inicializar o componente frontend
2. Inicializar o serviço backend
3. Inicializar o Banco de Dados com dados de teste
No front end, navegar para uma posição de teste e pedir recomendações
No front end, verificar que os restaurantes esperados foram recomendados

Nesse caso você garante que a funcionalidade funciona em um ambiente ainda controlado, que não é o que o usuário final vai seguir. Ainda que utilize um Banco de Dados de teste, existe uma garantia de qualidade.

Testes de segurança

Por exemplo para garantir que a comunicação entre um componente frontend e um componente backend seja encriptada e que nenhum dado sensível seja transmitido pela rede.

Esses testes são mais lentos que os testes unitários, pois envolvem mais partes e inicializações. E por se tratarem de integrações entre unidades, seu número deve ser bem menor que o de testes unitários.

Testes end-to-end

Testes end-to-end (de fim-a-fim ?) são os testes que simulam a jornada de um usuário no seu aplicativo. Eles devem simular exatamente o que um usuário faria para utilizar seu produto a fim de capturar erros em alguma dessas etapas.

Não é incomum encontrar repositórios com muitos testes desse tipo. Esse é o tipo de teste mais simples de justificar a existência do ponto de vista do produto, pois emula a experiência do usuário. São portanto muito importantes, pois são os testes mais próximos do que o usuário realmente vai encontrar ao utilizar o aplicativo.

Mas testes end-to-end tem alguns problemas:

Podem ser difíceis de definir -- nem sempre é simples escrever um script para seguir o fluxo exato no aplicativo e testar exatamente cada passo
São muito lentos -- por simular a experiência de usuário, normalmente precisam de todos os componentes inicializados, carregar imagens, executar requisições, etc
Baixa granularidade de erros -- mesmo quando capturam erros, muitas vezes é difícil saber a origem exata do problema já que esses testes são definidos em nível muito alto, cada passo pode envolver muitas unidades.
Podem ter custo elevado -- testes que comparam vídeos ou imagens de uso rapidamente precisam aumentar o armazenamento de dados para comparação e, se muito utilizados, podem representar um custo não negligível para o projeto.
Testes "flaky", que hora passam, hora falham -- quanto mais pra cima da pirâmide o seu teste, mais ele é afetado por questões fora do seu controle, rede interna, conexões externas, performance da máquina rodando o teste, etc. Ter muitos testes flaky pode diminuir a confiança dos times nos testes e diminuir a qualidade do código.

Por conta dos problemas associados, esses testes devem ser usados em quantidades moderadas, para os fluxos críticos do aplicativo em questão.

Exemplo de teste end-to-end

Usuário faz login no aplicativo com user "foca" e senha "123"
Usuário vê uma tela com todas suas faturas futuras: 1, 2 e 3
Usuário clica na fatura 2
Tela com mais informações sobre a fatura 2 é exibida
Usuário clica para alterar data de pagamento da fatura 2
Usuário altera data para 31/12/2021
Usuário vê alerta de data inválida

Pelo exemplo dá pra perceber que testar todos os possíveis cenários seja uma tarefa hercúlea. E é mesmo, por isso é importante garantir que os testes unitários e de integração estejam bem escritos e realmente testando a lógica do projeto.

Conclusão

Esse artigo cobriu a pirâmide de testes, descreveu a importância de cada um dos tipos de teste que a compõe, testes unitários, de integração e end-to-end. Os testes unitários devem ser os mais presentes em qualquer repositório, mas devem testar apenas a lógica de uma unidade e seu contrato. Testes de integração verificam o funcionamento de várias unidades em conjunto e os testes end-to-end testam a jornada crítica de seus usuários.

Uma proporção base pra utilizar como orientação é: a cada 100 testes unitários, 10 testes de integração e 1 teste end-to-end

Gostou? Achou útil? Discorda? Me conta :).

Quando usar TDD

gpiress — Sat, 25 Jul 2020 22:09:20 +0000

Test-Driven Development, ou Desenvolvimento Orientado a Testes em português, conhecido por sua sigla TDD é uma prática de engenharia de software que nunca foi unanimidade e que, passado o hype, tem sido mais criticada do que apoiada nos círculos mais populares.

Pelo título, dá pra perceber que eu acredito que a prática tem seu lugar e tentarei explicar meu ponto de vista nesse texto, passando por definição, pontos positivos e negativos. Esse artigo reflete minha opinião, então não é completamente imparcial, mas tentarei passar por todos os pontos que creio relevantes.

O que é TDD?

Talvez a definição não seja muito óbvia caso não seja familiar com o tema, mas Desenvolvimento Orientado a Testes quer dizer que o processo de escrita de código começa pela escrita dos testes, e somente após os testes estarem escritos (e falhando) que a implementação do código começa. Esse ciclo é chamado "Red-Green-Refactor".

A ideia é que dessa maneira, antes de começar a escrever o código, as pessoas desenvolvedoras procurem descobrir quais são as regras de negócio que o código deve satisfazer, e quais são as expectativas daquele código.

Resolvendo FizzBuzz, um exemplo de TDD em prática

Para ilustrar a ideia, segue um exemplo de solução do problema FizzBuzz. A definição do problema é, para todo inteiro n entre 1 e 100:

Se n for divisível por 3, retorne Fizz.
Se n for divisível por 5, retorne Buzz.
Se n for divisível por 3 e 5 ao mesmo tempo, retorne FizzBuzz.

Usarei Java nos exemplos mas pessoas familiarizadas com código devem entender a ideia ainda que não todos os detalhes.

Estrutura inicial:

public class FizzBuzz {

    public String fizzBuzz(final int numero) {
        return "";
    }
}

O primeiro passo é decidir a lógica de negócio e escrever nossos testes. Vamos seguir o ciclo Red-Green-Refactor, então o primeiro teste que eu vou escrever é cobrindo a primeira regra, Se n for divisível por 3, retorne Fizz.

public class FizzBuzzTest {

    @Test
    public void fizzBuzz_RetornaFizz_QuandoMultiploDe3() {
        final String esperado = "Fizz";

        final FizzBuzz fizzBuzz = new FizzBuzz();
        final String resposta = fizzBuzz.fizzBuzz(3);

        assertThat(resposta, CoreMatchers.equalTo(esperado));
    }
}

Ao rodar o teste, encontramos o esperado, o teste falha:

java.lang.AssertionError: 
Expected: "Fizz"
     but: was ""
Expected :Fizz
Actual   :

Como em nosso código sempre retornamos uma String vazia, precisamos implementar o código necessário para que esse teste passe. Atualizando a função fizzBuzz mostrada anteriormente:

public String fizzBuzz(final int numero) {
    if (numero % 3 == 0) {
        return "Fizz";
    }

    return "";
}

E agora, ao rodar o teste novamente, vemos que ele passa. O próximo passo seria fazer um teste para quando n for divisível por 5 e depois por 3 e 5. Sempre começando por um teste falhando e fazendo ele passar.

Cheque aqui o repositório desse projeto para ver como o código e seus testes ficam.

Pontos positivos

Depois de seguir o processo, podemos tecer opiniões sobre o ciclo. Primeiro vou escrever o que penso ser bom no processo.

Pró #1: Primeiro pensar na regra de negócio antes de escrever código

Ao primeiro pensar nos testes, a pessoa desenvolvendo é obrigada a pensar nas regras de negócio, em quais são os casos complicados e se compreenderam o problema. Isso é positivo pois a função do código é satisfazer as regras de negócio, então começar por elas faz sentido.

Pró #2: TDD incentiva a escrita de código testável

Por primeiro escrever os testes, o código por consequência fica organizado de uma maneira que é mais fácil de testar. Usando o mesmo problema FizzBuzz como exemplo, seria possível escrever apenas uma função:

public void resolveTudoEmUm() {
    for (int i = 1; i <= 100; i++) {
        String resultado = "";
        if (i % 3 == 0) {
            resultado += "Fizz";
        }
        if (i % 5 == 0) {
            resultado += "Buzz";
        }
        System.out.println(resultado);
    }
}

Essa função executa corretamente, mas é difícil de testar unitariamente. Lógico que nesse exemplo de problema simples é fácil de verificar manualmente, mas assim que os problemas se tornam mais complexos, os testes manuais ficam menos confiáveis.

Código sem teste é código legado, indepedente da "idade", já falei sobre isso em outro post.

TDD pode ser extremamente útil especialmente quando lidando com problemas complexos e para acostumar a escrever código mais testável.

Pontos negativos

Muito já foi escrito sobre porque não utilizar TDD e eu vou tentar cobrir os que são mais importantes na minha opinião.

Contra #1: O desenvolvimento fica mais lento

Para qualquer um que tente seguir o ciclo TDD, uma das primeiras impressões é que a técnica parece diminuir muito a velocidade de desenvolvimento, e seguir à risca pode significar muitos ciclos entre escrever um teste de cada vez e o código associado.

Eu concordo com essa crítica, mas sugiro uma mitigação: para casos óbvios de vários testes, sinta-se à vontade para escrever todos os testes de uma vez e implementar aos poucos. É muito importante manter um ciclo curto entre os testes para garantir o progresso e que nenhum caso deixe de funcionar, mas isso diminui o número de interrupções no processo.

Contra #2: TDD não é a única maneira de escrever código testável

É possível ter os pontos positivos do TDD - ter código testável e pensar na lógica primeiro - sem ter que seguir o processo do TDD que por vezes é muito baby steps e cheio de interrupções.

Esse é o principal motivo pelo qual eu não uso TDD sempre, mas ainda acho o TDD uma técnica muito útil para aumentar o conhecimento sobre como escrever código testável.

Conclusão

Usar TDD influencia positivamente o código gerado, de modo geral o resultado é mais simples de testar e garantir que as regras de negócio são cumpridas. É também muito útil para aprender como escrever código testável.

Porém é uma técnica que, caso seguida à risca, promove muitas interrupções no fluxo de desenvolvimento, o que pode ser frustrante e diminuir muito a velocidade de desenvolvimento.

Particularmente, eu acho excelente para novos serviços em que as regras de negócio não estão super definidas e também para parear com pessoas com menos experiência em escrever testes e código testável.