Meu pipeline de CI/CD funcionou por 3 meses — Depois eu li os logs

Ver checkmarks verdes traz uma sensação boa. Todo pull request passou. Todo deploy funcionou.

Então, um usuário relatou uma funcionalidade quebrada. Ela estava quebrada há semanas.

Abri os logs do pipeline. Nossos builds bem-sucedidos mentiram para nós.

Nosso processo parecia perfeito:

  • Linting
  • Testes unitários
  • Testes de integração
  • Build
  • Deploy

Cada etapa teve uma taxa de sucesso de 100% por meses.

O botão de exportação não fazia nada ao ser clicado. Nenhum erro aparecia. Eu rastreei o problema até uma alteração de 11 semanas atrás. O pipeline passou. O code review foi aprovado. A funcionalidade estava quebrada desde o início.

O problema não era o nosso código. Era o nosso código de teste.

Nossos testes de integração estavam usando mocks para tudo. Nós mockamos o serviço de exportação inteiro. O teste verificava o mock em vez do código real. O mock sempre retornava um status de sucesso.

Caímos na armadilha do excesso de mocks:

  • Testes unitários: Mockamos tudo para isolar a unidade. Isso é aceitável.
  • Testes de integração: Mockamos tudo para ganhar velocidade. Isso é um erro.
  • Testes E2E: Perderam esse fluxo específico.

Nossos testes de integração eram apenas testes unitários caros. Eles verificavam se nossos mocks funcionavam. Eles não verificavam se o nosso código funcionava.

Fiz três mudanças para corrigir isso:

  1. Limite os mocks aos testes unitários. Testes de integração devem acessar bancos de dados, APIs e sistemas de arquivos reais. Se um teste for lento, não o esconda com um mock. Use essa lentidão como um sinal para otimizar.

  2. Adicione testes de contrato. Eles garantem que seus mocks correspondam ao comportamento real do serviço. Se um mock retornar dados que um serviço real não retornaria, o teste de contrato falhará.

  3. Monitore a cobertura real. Paramos de olhar apenas para as taxas de aprovação simples. Passamos a olhar para o que os testes realmente exercitavam. Nossos números de cobertura caíram de 94% para 67%. Esta foi a métrica mais honesta que tivemos.

Um pipeline verde não significa que seu código funciona. Significa que seus testes passaram. São coisas diferentes.

Os bugs mais perigosos são aqueles que o seu pipeline diz estarem bem.

Faça a si mesmo estas perguntas:

  • Meus testes estão pegando bugs ou apenas confirmando mocks?
  • Meus testes de integração realmente integram?
  • Se eu remover todos os mocks, quantos testes ainda passam?
  • Estou medindo cobertura ou confiança?

Um pipeline que nunca falha não é confiável. Ele não foi testado.

Fonte: https://dev.to/kollittle/my-cicd-pipeline-passed-for-3-months-then-i-read-the-logs-4mbj