Uma análise dos diferentes formatos de teste (“Test Shapes”)

Ao entrar na área de testes, um dos primeiros conhecimentos que se deve adquirir é sobre os diferentes níveis e tipos de teste que existem.

Uma das representações mais reconhecidas do mercado foi criada pelo International Software Testing Qualifications Board (ISTQB), que define os diferentes níveis de teste como teste de componente, teste de integração, teste de sistema e teste de aceite.

No entanto, o ISTQB não é a única entidade a desenvolver um modelo para separar esses níveis de teste.

Um dos modelos gráficos mais reconhecidos para visualizar esses diferentes níveis de teste é o modelo esquemático criado por Mike Cohn, descrito em seu livro "Succeeding with Agile" como a "Test Pyramid" (pirâmide de testes).

Pirâmide de testes

A "pirâmide de testes" de Mike Cohn é dividida em três camadas, como mostra o diagrama acima:

Testes unitários: testes aplicados à menor parte testável do código, independentemente da integração pela qual ela vai passar;

Testes de serviço (alguns autores os chamam de testes de integração): testes aplicados para verificar a integração entre as unidades;

Testes de UI (alguns autores os chamam de testes E2E): testes aplicados para verificar o comportamento do sistema ou produto como um todo.

Essa figura tem o formato de uma pirâmide porque, segundo o conceito estabelecido, o maior esforço do analista de testes deve estar no nível mais baixo da pirâmide — o nível de testes unitários —, depois no nível de testes de serviço e, por fim, no nível de testes de interface.

Mas por que nessa ordem?

De acordo com essa característica, quanto mais testes forem estabelecidos na camada mais baixa (testes unitários), mais precisos, simples e rápidos eles serão.

Mais tarde, outro autor, Martin Fowler, deduziu que, quanto mais próximo da base da pirâmide, mais rápidos e baratos serão os seus testes (algo semelhante à dedução do "shift-left", segundo a qual o analista de testes deve concentrar esforços no início do ciclo de desenvolvimento de software, e não no final).

A pirâmide de testes é uma das "formas geométricas" de testes já estabelecidas.

Pirâmide de testes invertida

Outro formato que surgiu é a "pirâmide de testes invertida", também chamada de "cone de testes" ou "casquinha de sorvete de testes" ("Test Ice Cream Cone")

Essa pirâmide invertida é, essencialmente, o formato oposto ao proposto pela pirâmide de testes. Ou seja, quando uma equipe de testes adota a "casquinha de sorvete de testes", o maior esforço é gasto na camada mais próxima da liberação para produção, em vez de ser aplicado nas camadas mais básicas.

O uso dessa pirâmide invertida dentro de uma equipe demonstra imaturidade nos conceitos ágeis, o que resulta em custos maiores e execução mais lenta das tarefas.

Troféu de testes

Outra forma geométrica (ou conjunto de formas) desenvolvida foi o "Test Trophy" (troféu de testes), de Kent C. Dodds, cuja intenção é demonstrar que, dependendo do software analisado, o esforço de testes não deve estar principalmente nos testes unitários, mas sim nos testes de integração.

Nele, "Static" pode ser uma ferramenta de análise estática, como o ESLint, usada para padronização de código, por exemplo.

Nas palavras de Kent C. Dodds:

“A pirâmide de testes se baseia na premissa de que testes de integração são caros, lentos e frágeis em comparação com testes mais focados, como os unitários. Embora isso geralmente seja verdade, há exceções. Se os meus testes de alto nível são rápidos, confiáveis e baratos de modificar, então os testes de baixo nível não são necessários.”

Em outras palavras, o autor afirma que há exceções quanto a qual camada de teste deve ser mais priorizada: a unitária ou a de integração.

Colmeia de testes

Por fim, a última forma geométrica que vale mencionar é a "Testing Honeycomb", que pode ser traduzida como "Colmeia de Testes" ou entendida como "Diamond Testing".

A "colmeia de testes" é uma representação gráfica criada pela equipe de engenharia de qualidade do Spotify.

Pode-se observar que a "colmeia de testes" traz uma proposta semelhante à do "troféu de testes", colocando mais esforço na camada de integração do que na camada de testes unitários.

Isso acontece porque o produto em que a equipe do Spotify trabalha tem forte relação com diversos outros microsserviços — um conjunto de serviços independentes integrados dentro de um escopo.

Na visão da própria equipe de qualidade do Spotify:

O microsserviço se tornou a nossa nova "unidade", e é por isso que evitamos o termo "testes unitários" para microsserviços e preferimos "Implementation Detail Tests" (testes de detalhes de implementação). Os microsserviços pegam a antiga ideia de componentes isolados e nos mostram quais devem ser as abstrações.

Conclusão

Embora diferentes autores e equipes criem várias formas geométricas para visualizar graficamente os testes, é possível identificar uma semelhança entre elas: divergem quanto a onde devem estar principalmente o esforço e o foco (unitários ou serviços), mas sempre concordam que os testes E2E devem exigir menos esforço.

Basicamente, a maior camada dos seus testes (seja de unitários, seja de serviços) vai depender do foco do produto, principalmente se ele envolve muitos microsserviços de terceiros (como o Spotify) ou não.

No entanto, os testes E2E devem sempre ter o menor esforço dentro da sua suíte de testes; caso contrário, o processo de testes será sempre mais lento e mais caro de manter.