Tech Talk aboud integration tests running on containers

Slides.md

theme
techtalk

<script src="https://unpkg.com/[email protected]/dist/mermaid.min.js"></script> <script>mermaid.initialize({startOnLoad:true});</script>

Containers e Qualidade

Uma abordagem para testes de integração

---

Apresentador

Andre Silva Desenvolvedor Vertical Canais

---

Time

---

Roteiro 🛣️

1. Dificuldades
2. Solução Inicial
3. Obstáculos
4. Solução Atual

---

Dificuldades

Nossa metodologia de testes de integração tinha diversas carências.

A mudança para Kubernetes acarretaria outras mais.

---

Cenário inicial

---

Testes somente "ao vivo"

(erro-tardio 🏷️)

Testes de comportamento [automatizados] somente durante a publicação em Sandbox/Produção.

• Erros tardios
• Janelas de Deploy

---

Indisponibilidades de terceiros indisp

• falso negativo.

Se algum componente estiver temporariamente indisponível, não é possível fazer deploy com segurança pois os testes não poderão ser executados.

---

Erros afetam clientes erro-cliente

(Kubernetes)

Uma vez a aplicação publicada, a aplicação já está servindo requisições.

Não encontramos maneiras de rodar os testes:

• Antes de que os pods antigos sejam apagados,
• Testando contra os novos pods
• E antes que o tráfego seja redirecionado para os novos pods

---

Dados de Teste dados-teste

(API Transacional)

• Loja que não liquida pagamentos
• Dependência de PinPad (dados EMV, senha)

---

Cenários pontuais exceções

Usando APIs de produção e/ou sandbox é difícil de validar alguns cenários bastante específicos mas que fazem parte do conjunto de comportamentos esperados ou conhecidos das APIs relacionadas.

Exemplos:

• Timeout da API relacionada
• Erros 401/403/404/500, etc
• Casos que quase nunca acontecem

---

Poluição lixo

• Nas nossas bases
• Nas APIs/bases relacionadas

---

Validação da integração de contratos contratos

A aplicação chamou as APIs relacionadas da forma como deveria?"

• Olhar nos logs
• Risco de regressão

---

Conceito Inicial 👶

---

Conceito Inicial 👶

• Base exclusiva pra CI/CD (lixo)
• Versões mockadas das APIs relacionadas (lixo)
  • Comportamento controlado (indisp)
  • Cenários de teste (dados-teste, exceções)
  • Endpoint de verificação (contratos)
• Incorporar ao pipeline de build (erro-tardio, erro-cliente)

---

Obstáculos

• Custo de base exclusiva pra CI/CD
• Poluição (entre execuções, entre times)
• Desenvolvimento e manutenção de APIs mockadas
• Como implementação o "endpoint de verificação" de forma simples?
• Como "Incorporar ao pipeline"?

---

Solução Atual 💡

• Mock de Banco: Container SQL Server for Linux
  • Não pago pela "base dev"
  • Não poluo
• Mock de API: Container mock-server
  • Não tenho que programar uma API com os cenário de mock
• Incorporação ao Pipeline: Biblioteca testcontainers
  • Resolve "problema da prontidão"
  • Resolve "problema das portas"

---

testcontainers 🍒

Problema da prontidão

Como saber que o container já está pronto para receber requisições?

Sondas

• Logs
• HTTP
• TCP
• SQL

---

Fluxo Básico

graph TD; start_app[Inicia Aplicação] start_dep[Inicia Mocks] run_tests[Executa Testes] start_app --> run_tests start_dep --> run_tests run_tests --> dump_logs[Exibe logs] dump_logs --> remove_containers[Para containers] remove_containers

---

Próximos Passos

• Acelerar processo de teste (agente self-hosted?)
• Separar código comum em pacotes
• Mock de componentes proprietários (ex.: Service Bus)

---

Dúvidas?

---

Obrigado! 🏁

mock-server.com testcontainers.org