Leonardo Peron5 min de leitura
Integração é a parte de um projeto de software em que metade do sistema pertence a outra empresa. Isso muda o que "testar" significa: não existe suíte que prove o conjunto, porque metade dele você não controla e não pode derrubar para experimentar. O que existe são três camadas de prova, e o erro caro é achar que a primeira cobre a terceira.
O que dá para provar sem o outro lado
Muita coisa, e é a camada mais barata. Com um duplo — um serviço falso no lugar do fornecedor — dá para exercitar tudo que é seu: o mapeamento campo a campo contra o de-para escrito; a idempotência, mandando o mesmo evento duas vezes em paralelo; o que a integração faz quando o outro lado demora ou devolve um corpo inesperado; a classificação entre falha temporária e permanente, que decide se a fila enche; e o freio de ritmo, baixando o próprio teto para um valor absurdo para ver se o lote termina lento em vez de falhar.
O limite dessa camada é o que a torna perigosa: o duplo responde como você acredita que o fornecedor responde. Confirma o seu entendimento, não o comportamento real. Gravar respostas verdadeiras e reproduzi-las melhora bastante — e continua congelando o dia em que você gravou.
O que só a homologação do outro lado prova
Autenticação de verdade, o formato exato do que chega, os códigos de erro que existem mesmo, o campo que a documentação não menciona e o que acontece quando o registro já existe lá dentro. Nada disso se descobre lendo manual — e a diferença entre documentação que descreve o erro e documentação que só descreve o caminho feliz é o que mais mexe no prazo de uma integração.
Falta verificar se essa homologação se parece com produção. Cinco sintomas de ambiente que engana:
Base vazia. Sem cadastro, sem histórico, sem conflito: tudo passa porque nada colide.
Validação mais frouxa. Aceita o que produção recusa, e o defeito aparece na primeira carga real.
Versão diferente. A instalação de produção pode estar atrás — ou à frente — do que a homologação roda.
Sem limite de requisições. O teto só existe em produção, e o 429 chega como surpresa no pico.
Compartilhada e reiniciada. Outros clientes escrevem ali, e a base é zerada em intervalos que ninguém avisa.
Nenhum deles impede o uso do ambiente. Todos mudam o que ele prova, e a diferença precisa estar escrita.
A pergunta que decide o cronograma
Antes de qualquer estimativa: existe homologação do outro lado, quem libera o acesso, e quanto tempo isso leva?
Sem ambiente separado, cada tentativa acontece em produção — cada pedido de mentira é um pedido de verdade que alguém cancela, cada nota é uma nota, cada cadastro sujo fica lá. O ritmo cai não pelo desenvolvimento, mas porque toda tentativa exige combinação prévia com quem opera e limpeza depois.
E o acesso costuma ficar fora do plano: quando o outro lado exige registro de aplicação, aprovação ou credencial de terceiro, o trâmite não consome trabalho do time e bloqueia a entrega no fim.
Massa de teste que não é o caso feliz
Testar com três pedidos redondos prova que o caminho existe, e nada além disso. O que quebra integração é a exceção que a operação conhece e ninguém escreveu.
A massa útil vem da produção, anonimizada e escolhida para conter o que incomoda: o cliente sem documento, o nome com apóstrofo e sessenta caracteres, o pedido com duas centenas de itens, o valor negativo do estorno, o cadastro criado em 2014 com uma convenção que não existe mais, o código com espaço no fim. Some os registros que já vêm duplicados de origem — eles obrigam a decidir quem é o dono do cadastro antes da subida.
O exercício que mais rende é pegar um dia inteiro de produção e reproduzi-lo num ambiente separado, comparando o resultado com o que aconteceu de verdade naquele dia. É o método da reconciliação aplicado antes de existir o que reconciliar: o que não bater é especificação faltando.
O que só aparece em produção
Três coisas resistem a qualquer ambiente de teste: volume real, concorrência real e a intermitência do outro lado — inclusive a janela de manutenção que o fornecedor não avisa. É por isso que o plano para quando a API cai precisa estar pronto antes da subida, e por que a instrumentação sobe junto com a integração, não no mês seguinte.
O que reduz o risco não é testar mais: é subir de um jeito que permita voltar. Rodar em modo silencioso primeiro, calculando tudo sem gravar no destino e comparando com o processo atual. Depois abrir por recorte — uma filial, uma família de produtos, um canal — e só então ampliar volume, com um interruptor que desliga sem precisar de deploy. É a lógica de rodar dois sistemas em paralelo aplicada a uma ponte.
O roteiro que decide se dá para subir
Seis provas, na ordem em que ficam caras:
- O mesmo evento, duas cópias em paralelo: um registro só no destino.
- Destino derrubado de propósito, cinco eventos gerados, destino de volta: os cinco entram sozinhos, uma vez cada.
- Um evento com defeito permanente: para de tentar, fica visível, e alguém é avisado.
- Um dia de produção reproduzido: o que não bater vira lista de decisão.
- A credencial invalidada no meio de um lote: renova e continua, sem entulhar a fila.
- O interruptor acionado com carga andando: para limpo, e o que estava na metade não fica na metade.
Quem passa nos seis tem o que subir. Quem não conseguiu executar o segundo porque não há onde derrubar nada já recebeu a resposta mais importante — e ela é sobre o ambiente, não sobre o código.