Uma pirâmide de testes mais simples: aproveitando ao máximo seus testes

Artigos da página inicial do InfoQ Uma pirâmide de testes mais simples: aproveitando ao máximo seus testes

Este item em japonês

10 de abril de 2023 10 minutos de leitura

por

Tyson felizmente

revisados ​​pela

Matt Campbell

Os desenvolvedores usam muitos rótulos diferentes para descrever seus testes automatizados (unidade, integração, aceitação, componente, serviço, ponta a ponta, UI, banco de dados, sistema, funcional ou API). Cada um desses rótulos tem um significado semântico diferente, seja descrevendo o escopo do teste, os tipos de ações que o teste realiza, o sujeito do teste ou os colaboradores do sujeito. Geralmente não concordamos sobre o significado de cada um desses rótulos, e as discussões sobre sua definição tendem a ser fúteis.

Em vez de discutir quais rótulos usar e como defini-los, achei mais útil usar um dos dois adjetivos para rotular cada teste: lento ou rápido. Esses rótulos podem ser igualmente úteis ao decidir a composição de um conjunto de testes, ao mesmo tempo que permitem aos desenvolvedores classificar os testes objetivamente, sem argumentos improdutivos.

Codifique, implante e dimensione o Java do seu jeito. O Microsoft Azure oferece suporte à sua carga de trabalho com diversas opções, esteja você trabalhando em um aplicativo Java, um servidor de aplicativos ou uma estrutura. Saber mais.

A escolha dos rótulos de teste é uma influência importante na composição de um conjunto de testes. Os desenvolvedores os utilizam para saber quando escrever um teste para um determinado comportamento, para saber que tipo de teste escrever e para avaliar o equilíbrio do conjunto de testes como um todo. Quando erramos, acabamos com um conjunto de testes que não oferece cobertura precisa ou oferece cobertura a um custo inaceitável.

Quando você deve escrever um teste para um determinado código de produção? Desenvolvedores que, como eu, praticam Extreme Programming (XP) ou Test Driven Development (TDD) costumam responder a essa pergunta com “sempre”. No entanto, nem todo trecho de código deve ser testado automaticamente. Para cada teste proposto, primeiro compare os custos de redação do teste com os benefícios.

Não estou defendendo a escrita de testes. Na verdade, para a maioria dos testes, esta é uma verificação rápida e a resposta é sim. No entanto, essa verificação é útil, especialmente se um teste for lento para ser executado, lento para ser escrito ou difícil de manter. Nestes casos, faça algumas perguntas a si mesmo.

O teste é caro devido a uma decisão de projeto? O código pode ser refatorado para acomodar melhor os testes? Seus testes são os primeiros consumidores do seu código de produção. Tornar o código mais fácil de testar geralmente facilita seu consumo, melhorando a qualidade de sua base de código.

O teste é caro devido à abordagem de teste? Uma abordagem de teste diferente tornaria esse teste mais fácil de escrever? Considere usar dublês de teste, como falsificações ou simulações, no lugar de colaboradores. Se seus testes precisarem de uma configuração complicada, extraia isso para um cenário de teste que possa ser reutilizado entre os testes.

Tenha cuidado para não abusar dos testes duplos, pois eles não proporcionam tanta confiança quanto colaboradores reais. Às vezes, essa queda na confiança compensa a facilidade de configuração, a diminuição na duração do teste ou o aumento na confiabilidade. No entanto, muita dependência de testes duplos pode acoplar seus testes à sua implementação, resultando em um conjunto de testes que fornece baixa confiança e que inibe a refatoração.

O teste é caro porque o comportamento é inerentemente difícil de testar? Nesse caso, considere a importância do recurso que você está testando. Se for um recurso crítico que envolve o processamento de pagamentos, o custo do teste pode valer a pena. Se for um caso extremo peculiar em sua lógica de exibição, você deve reconsiderar se deve ou não escrever o teste.

O teste é caro porque falha de forma imprevisível? Nesse caso, você deve removê-lo, reescrevê-lo para ser mais confiável ou separá-lo do resto do seu conjunto de testes. Para que um conjunto de testes forneça feedback útil, você deve ter certeza de que as falhas nos testes representam um comportamento indesejado. Se você achar que um teste é necessário e não pode ser previsível, mova-o para outro conjunto de testes que seja executado com menos frequência.