desenvolvedor - software

Testes: qual a melhor abordagem para a sua aplicação?

Rafael Amaral

Hoje é dia de conversar sobre o trabalho em tecnologia. Gostaria de tratar sobre os diferentes tipos de testes automatizados que podemos criar para nossas aplicações, além de sugerir um modo de interpretar a conhecida pirâmide de testes de Mike Cohn.

A interpretação não deve ser feita como uma cartilha do que deve ser feito em Q&A (Quality Assurance), mas sim como uma orientação que pode nos trazer mais entendimento sobre os processos de teste.

Inicialmente, devemos lembrar que criamos testes automatizados, basicamente, para  descobrir, com antecedência, possíveis erros na nossa aplicação que antes tomaríamos conhecimento apenas por testes manuais. Imagine que a alteração de uma função específica no nosso projeto interfira em outras funções que acabam quebrando algum comportamento esperado da aplicação. Quanto tempo demoraríamos para descobrir o erro? E se este erro fosse para produção e um cliente tomasse conhecimento dele antes do time técnico?

Esta situação toca em um dos princípios fundamentais para um teste de qualidade. Segundo o modelo de Cohn, eles devem ser automatizados para nos dar insights sobre falhas com maior rapidez do que teríamos com o uso direto do aplicativo. Este ponto está presente na pirâmide de Cohn, representado pela seta à direita e orienta a escolha pelos testes unitários como primeira escolha para o desenvolvimento dos testes gerais da aplicação.

A escolha dos testes unitários se deve à rapidez no desenvolvimento, aplicação e manutenção do código. Os testes unitários, como podemos imaginar, testam a unidade do código, uma função isolada de todo o resto da aplicação. Se existe uma função de soma, por exemplo, onde ao se receber dois números que retorna a soma deles, como resultado o teste vai conferir apenas se ao receber os números 2 e 1, por exemplo, a função retorna 3 independentemente do modo como este código se relaciona com o restante da aplicação.

É importante ressaltar que os desenvolvedores podem incidir em erro ao seguir a pirâmide de Mike Cohn como uma norma definitiva.

Este modelo é uma heurística, ou seja, uma escolha mais fácil e rápida que desenvolvedores chegaram ao elaborar estratégias para testes e que ignora grande parte da informação sobre os casos particulares no geral (CICILIA, 2020). A pirâmide não é uma receita de bolo para a estratégia de testes que iremos criar e devemos estudá-la aprendendo os princípios que orientam Mike Cohn nas escolhas e não tentando aplicar o modelo sem nenhuma crítica.

Um ponto que devemos analisar com maior criticidade, por exemplo, é a recomendação de se realizar testes unitários em maior número (o tamanho dos segmentos do triângulo indicam também o volume de testes daquele tipo que é recomendado). Partindo da ideia de que estes testes devem ser usados pela praticidade do uso de um modo geral, muitos desenvolvedores, na intenção de alcançar uma cobertura de 100% de testes em toda a aplicação, acabam criando testes em partes do código que não necessitam de testes como getters e setters normais (VOCKE, 2018). Como resultado, temos apenas um grande número de testes que não nos dão informações relevantes sobre a qualidade da aplicação, que devem sempre passar por manutenção, pois, caso contrário, teremos uma série de erros nos testes ou falsos positivos que acabam diminuindo a credibilidade que temos na estratégia adotada para os testes.

Subindo mais um nível na pirâmide, temos os testes de serviço ou integração. Ao contrário dos unitários, eles testam como as funções se inter-relacionam e também como elas se relacionam com serviços externos, como banco de dados ou APIs de terceiros.

O modelo de Cohn recomenda que estes testes estejam em menor quantidade do que os testes unitários, por demorarem mais para serem criados, executados e mantidos. Além disso, a restrição também se deve ao fato de estes testes serem mais integrados. Neste caso, precisamos entender que o isolamento da função tem a qualidade de evitar qualquer conflito que não tenha relação direta com o código. Se, por algum motivo, o banco de dados estiver fora do ar, por exemplo, quebraria testes de integração que não estivessem usando mocks e stubs (modos de substituir respostas de funções que não podem ser executadas nos testes, isolando assim o comportamento do conjunto a ser testado) mesmo que o código estivesse correto.

A escolha pelo isolamento tem o benefício de evitar que qualquer outro fator prejudique o resultado dos testes, mas deve ser utilizado com ressalvas, uma vez que não se testa o comportamento real da aplicação que poderia nos revelar outros tipos de erros que ficam ocultos utilizando-se apenas testes isolados. Pensando nisso, alguns autores sugerem outros modelos concorrentes à pirâmide de testes, tal qual o modelo de troféu que dá prioridade aos testes de integração por considerarem que em certas aplicações, como microsserviços, os maiores riscos estão principalmente nas integrações (CICÍLIA, 2020).

Por último, temos os testes de UI, ou end to end, que, pelo fato de utilizarem um browser e terem processos de instalação e desenvolvimento mais lentos, são os últimos testes recomendados por Cohn. Seguindo este modelo, deveríamos primeiro tentar resolver os problemas com testes unitários, depois de integração e, por fim, recorrer aos testes de UI. Mesmo considerando os pontos negativos deste tipo de teste, devemos lembrar que ele realiza o teste mais próximo do uso da aplicação real e que, dependendo dos nossos objetivos, uma abordagem que utiliza mais testes end to end pode evitar certos riscos que corremos ao utilizarmos apenas testes isolados.

Hoje vimos os três tipos principais de teste e pudemos observar como a abordagem para a construção dos testes deve levar vários fatores em conta, como otimização, qualidade e os diferentes riscos que corremos deixando completamente de lado testes com integrações reais. Vale lembrar que existem vários outros tipos de testes, como os de mutação, chaos ou testes de contrato.

Saiba onde nos encontrar

O blog não é nosso canal exclusivo de relacionamento. Você pode encontrar mais do conteúdo caprichado que nosso time de Social Media prepara também em outras redes!

Confira tudo que preparamos para você e nos acompanhe no Instagram, Facebook, LinkedIn, Twitter e TikTok.

Rafael Amaral

Mineiro, ex-filósofo, programador em tempo quase integral que, de vez em quando, frequenta a academia para escutar disco music.