O sucesso aparente e o silêncio na fila
Durante semanas, nossa integração automatizada com o WordPress exibia um painel impecável, com todas as tarefas marcadas em verde. No entanto, nenhum post novo de fato aparecia no blog de produção, mascarando uma falha grave na pipeline.
O problema estava no estado final da tarefa: em vez de transicionar para ‘falhou’ após um erro, o post agendado voltava silenciosamente para o estado ‘agendado’. A fila de mensageria simplesmente retentava a operação em background, sem nunca disparar alertas nos painéis de monitoramento.
O TypeError escondido no json.loads()
Ao inspecionar o fluxo de dados entre as camadas internas, identificamos a causa raiz: uma chamada para json.loads() aplicada sobre um objeto que já era um dicionário Python. A camada inferior da biblioteca de transporte já havia decodificado a carga útil da API.
Essa redundância gerava um TypeError imediato no interpretador. Como cada metade do código funcionava perfeitamente quando isolada em testes unitários mockados, a incompatibilidade de tipos na fronteira entre as duas camadas passou despercebida.
Testando a costura entre as camadas
A solução definitiva não exigia mais logs ou ferramentas complexas de observabilidade, mas sim testes na costura de integração. Precisávamos garantir que a saída exata da camada de transporte fosse consumida sem suposições pela camada de publicação.
Escrevemos um teste de integração que simula o payload real retornado pelo WordPress, validando a tipagem do dicionário diretamente no ponto de contato. Com esse teste, a cadeia inteira — desde a definição do assunto e geração do artigo até a criação da ilustração em tempo real — passou a ser validada de ponta a ponta.
Confiar apenas em testes unitários que usam mocks excessivos cria uma falsa sensação de segurança. A verdadeira estabilidade de uma pipeline complexa reside na validação rigorosa dos contratos de interface entre os seus subsistemas.
Deixe um comentário