Abordagem de testes

Muitas pessoas ainda tem dificuldades em definir que tipos de teste realizar para cada objetivo e muitas vezes a galera fica presa no conceito de pirâmide de testes (unitário <-> integração <-> UI) e esquece que isso pode ser explodido em diferentes tipos de teste dependendo das necessidades do seu projeto.

Por isso hoje em dia eu prefiro adotar a definição de uma abordagem de testes ao invés de apenas ficar batendo na tecla da tão conhecida pirâmide falando de quantidade de testes por tipo ao invés de estratégia.

Depois de algumas reflexões o modelo abaixo é o que eu acredito que faz mais sentido. Repare que eu não usei alguns termos como monolito ou microserviços e sim apenas serviços, justamente para não entrar nesse mérito, que não é objetivo nesse momento.

A ideia aqui é demonstrar como você pode aplicar diferentes tipos de teste dentro dos seus projetos considerando não só o produto mas todas as integrações a que ele está submetido.

Falando num conexto mais isolado, temos testes unitários que validam o comportamento das suas funções e métodos, sem comunicação com o mundo externo com o auxílio de mocks e stubs. Além disso você vai ter testes de integração para testar o comportamento entre a sua aplicação e o banco de dados ou entre a sua aplicação e um serviço terceiro que está fora do seu controle (com o auxílio por exemplo de um fake server porque nesse nível de teste nós diminuímos ao máximo as dependências externas que possam tornar nossos testes flaky).

Saindo desse contexto mais isolado e pensando que sua aplicação vai se comunicar com outras desenvolvidas por outros times dentro da sua empresa por exemplo, temos os testes de contratos numa abordagem consumer-driven onde você vai ter o ponto A (consumer)que consome o serviço disponibilizado pelo ponto B (provider), assim conseguimos garantir que o contrato estabelecido entre esses dois pontos vai ser respeitado e que caso exista alguma quebra, tanto o provider quanto o consumer vão ser avisados de maneira automática na execução dos testes, evitando que esse problema chegue em produção.

Por último temos os testes end-to-end, e aqui não são necessariamente testes UI, a gente poder ter teste end-to-end para uma API, a regra aqui é exercitar os fluxos a que o usuário final vai estar exposto de forma a garantir que todas as peças se encaixam, e nesse momento é importante investir em um ambiente onde você efetivamente consiga simular todas as integrações. Eu sei que algumas vezes isso não é possível, principalmente quando a gente precisa integrar com serviços de terceiros que não fornecem um ambiente de sandbox estável, se esse for o caso, invista pelo menos em um simulador como o wiremock para ter um comportamento o mais próximo da realidade possível.

Dado que você adotou essa abordagem, o próximo passo vai ser utilizar esses testes no seu pipeline de entrega, o que deve ficar parecido com:

Assim você consegue distribuir esses testes por tempo de feedback colocando os mais “rápidos” no início da esteira a fim de saber rapidamente se a alteração quebrou alguma coisa antes de efetivamente fazer deploy em algum ambiente.

Esse post é basicamente o resultado de algumas reflexões que eu venho fazendo sobre a forma que testamos software e como escolhemos o que usar e quando usar.

E você, o que acha dessa abordagem?