Se você já é meu aluno na CAD, sabe bem o quanto bato na tecla da importância dos testes. Não importa se são unitários, de integração ou end-to-end: sem testes, não existe confiança em deploy.
Claro, opinião pessoal aqui: teste unitário é o que menos agrega valor dentro da pirâmide de testes do Martin Fowler (https://martinfowler.com/articles/practical-test-pyramid.html) . Mas não me entenda mal: eles têm seu espaço. Só que quando falamos de garantia real de testes funcionais — ou seja, validar as funcionalidades do sistema —, é no meio da pirâmide que encontramos os testes de integração.
Eles são a camada onde boa parte dos testes necessários acontece, e quando bem implementados ajudam a reduzir significativamente a quantidade de problemas após um deployment. Principalmente se esses testes já forem executados durante o desenvolvimento e na homologação, antes de chegar em produção.
E convenhamos: é justamente no deployment e pós-deployment que as bombas aparecem. Se você não tem testes confiáveis, acaba descobrindo o problema no pior momento possível — quando o usuário já está reclamando.
A importância de tornar o teste parte da conversa
Independente de você ser dev, SRE ou trabalhar com infraestrutura, precisa entender: testes não são “coisa do time de QA”. Testes são parte essencial da arquitetura de sistemas modernos e são necessários para qualquer SDLC (Software Development Lifecycle).
Quando você consegue mostrar para o desenvolvedor os benefícios de rodar testes já na fase de desenvolvimento, não apenas em momento de pipeline, o valor é imediato: mais agilidade, menor tempo para entregar funcionalidades e muito menos retrabalho.
Por onde começar? Robot Framework 🤖
Você pode escrever testes de várias formas — scripts em Bash, Java, Python… tanto faz. Mas se você ainda não tem uma plataforma de testes estruturada, minha sugestão é começar com o Robot Framework.
O Robot é um framework simples, flexível e extremamente legível. Criado inicialmente para RPA, hoje ele é amplamente usado para testes funcionais e integrações.
Alguns pontos fortes:
✅ Sintaxe simples e próxima de linguagem natural
✅ Uso de keywords reutilizáveis, que facilitam manter e organizar testes
✅ Grande ecossistema de bibliotecas (ex.: HTTP, Selenium, SSH, etc.)
✅ Fácil integração com Docker, pipelines e até ferramentas de infra-as-code
✅ Relatórios automáticos depois da execução: cada teste gera um resultado visual com tags, permitindo identificar rapidamente como está a saúde de cada microserviço. Você pode ver tanto um resumo de alto nível quanto detalhes completos — como o payload da requisição, o status esperado e a resposta HTTP que causou a falha. Isso serve como evidência concreta, essencial em times que precisam auditar ou justificar qualidade.
Exemplo de relatório – Resumo:
Exemplo de relatório – Por Tag:
Exemplo de relatório – Por use case:
Além de tudo isso, temos que considerar o fato dele ser extremamente leve fácil de começar. Você só instala as libs que precisa e já começa a brincar.
Exemplo prático: testando um /health
Aqui vai um exemplo bem simples de teste com o Robot Framework usando a lib HTTP:
*** Settings ***
Library RequestsLibrary
*** Test Cases ***
Check Health Endpoint
Create Session myapi http://localhost:8080
${response}= GET On Session myapi /health
Should Be Equal As Strings ${response.status_code} 200
Rodando esse teste, você já garante que o endpoint /health está respondendo corretamente. Fácil, direto e eficaz.
Agora, imagine expandir isso para validar payloads, autenticação, integrações entre serviços… tudo de forma clara e reutilizável.
Conclusão
Quanto mais ferramentas você dá para o desenvolvedor testar cedo, errar localmente e simular a produção, menor o número de incidentes que vão bater na sua porta.
Então, se você já é meu aluno, desculpa repetir esse mantra mais uma vez 😅. Mas se você ainda não é e quer aprender a criar ambientes modernos, resilientes e de alta qualidade, vem com a gente na Comunidade de Arquitetura Descomplicada (CaD).
Abraço, e até o próximo! 🚀
