Apesar de aplaudirmos o foco em testes automatizados, seguimos observando diversas organizações investindo excessivamente no que consideramos testes de integração ampla ineficazes. Como o termo teste de integração é ambíguo, adotamos a classificação ampla do verbete de Martin Fowler sobre o assunto em seu bliki. Ele indica que esse tipo de teste requer versões ativas de todas as dependências de tempo de execução. Obviamente, esse tipo de teste é caro, pois exige um ambiente de teste completo com toda a infraestrutura, dados e serviços necessários. Gerenciar as versões corretas de todas essas dependências demanda uma sobrecarga significativa de coordenação, o que tende a retardar os ciclos de lançamento. Além disso, os próprios testes geralmente são frágeis e pouco úteis. Por exemplo, determinar se a falha de um teste ocorreu devido ao código novo, incompatibilidade de versões de dependências ou ao ambiente pode exigir bastante esforço, e a mensagem de erro raramente ajuda a identificar a origem do problema. Essas críticas não significam que discordamos de testes de integração automatizados do tipo caixa preta em geral. No entanto, consideramos uma abordagem mais vantajosa aquela que equilibra a necessidade de confiança com a frequência de lançamento. Isso pode ser feito em duas etapas, validando o comportamento do sistema sob teste. Primeiro, validamos o comportamento do sistema considerando um determinado conjunto de respostas das dependências de tempo de execução. Utilizamos virtualização de serviços para criar dublês de teste para essas dependências, o que simplifica o gerenciamento de dados de teste e permite testes determinísticos. Em seguida, validamos essas premissas de ambiente com dependências reais usando testes de contrato.
