Que tipos de bugs podem realmente ser encontrados no teste de integração?

Vou dar dois exemplos:

Uma vez trivial, uma vez vi uma classe de rede que permitia definir o host e a porta e depois enviar mensagens. Teste de unidade funcionou - você poderia definir o host, você poderia definir a porta, você poderia chamar o método que enviou mensagens.

Na integração, alguém escreveu o código do cliente que usou essa classe e definiu a porta antes de definir o host. Nada funcionou, porque o método host set redefiniu a porta para um padrão.

Esse é um exemplo simples e simples que mostra que seus testes de unidade podem mostrar um comportamento correto, mas como os métodos não foram chamados da maneira esperada, falharam no tempo de execução. Você poderia argumentar que os testes unitários não estavam corretos, pois eles não testaram todas as combinações das chamadas de configuração da propriedade, mas o teste unitário é garantir que cada seção do código funcione corretamente (por exemplo, define a propriedade correta) e não como a interação entre então ocorre. (Claro, seria melhor argumentar que a classe deveria ter sido a unidade de teste aqui e que poderia ter detectado esse bug, mas mesmo assim duvido que alguém tenha repetido o teste com uma combinação diferente de configuração de propriedade).

Outro exemplo é com threading. Eu tive uma classe que funcionou perfeitamente em testes de unidade, que tem um bloqueio em um recurso compartilhado e chama um método em um objeto diferente, que como esse método é ridicularizado, retorna imediatamente. No mundo real, esse método realmente faz muito mais trabalho, cria um novo thread que aguarda o mesmo recurso compartilhado se tornar disponível e, assim, compromete todo o programa. Boa sorte em encontrar isso em testes unitários.

Testes de unidade não são o teste principal que você deve fazer. De fato, se você tivesse que ter apenas 1 camada de teste, seria um teste de integração. Os testes de unidade são uma maneira "rápida e suja" de superar os erros óbvios gerados durante o desenvolvimento e são mais uma verificação de desenvolvedor para garantir que você não fez nada estúpido (como no tempo em que escrevi uma aula de aritmética o operador de subtração .. um teste de unidade teria pego aquele corte e cole preguiça). Isso é tudo o que eles devem estar lá para, no entanto, tentando garantir a operação perfeita do sistema usando-os é equivocada.

Testes de integração são os primeiros testes em que dois ou mais componentes reais do sistema (ou seja, não escarnecidos) interagem entre si. Se você tiver testes de integração e de unidade, um teste de integração com falha é um strong indicador de que o comportamento da simulação para o Componente A não corresponde ao comportamento do Componente A real.

Especialmente em um sistema maior, é fácil criar uma desconexão entre o comportamento do componente real e o comportamento esperado codificado nos mocks e seu uso.

Depende um pouco do sistema que você está testando, mas eles podem encontrar muitas coisas que não são cobertas por bons testes de unidade sem estado.

Para mim, o mais importante é conversar com o banco de dados. Você pode ter seus testes de unidade em coisas que decidem falar com o banco de dados, e você pode ter seus testes de unidade em coisas que correm dentro do banco de dados (às vezes, com alguns truques sujos), mas você precisa de testes de integração para se certificar de que essas coisas podem todos falam uns com os outros corretamente. A interface do banco de dados / aplicativo geralmente é bastante frágil, por isso é importante ter testes sobre o máximo que você puder gerenciar.

Sistemas contendo vários componentes que se comunicam em REST ou em um barramento de mensagens se beneficiam enormemente de testes de integração para verificar se os componentes podem realmente funcionar uns com os outros da maneira que deveriam. Eles podem ter uma cobertura abrangente de testes de unidade em suas interfaces externas, mas será que a idéia da interface pública do Mungeifier para Frobnicator corresponde à interface pública que o Mungeifier realmente forneceu? Mesmo os componentes mais livremente acoplados imagináveis têm que estar de acordo com algum tipo de contrato de interface ou comunicação torna-se inteiramente impossível. Isso tudo tem que ser testado, e a única maneira de ter certeza é testá-lo de verdade.

Além disso, você pode ver o teste de desempenho como um tipo de teste de integração. Você não apenas está testando se o sistema pode executar cargas abaixo do esperado, porque você estará testando todo o sistema como montado para produção (ou deveria estar), mas também fazendo testes de integração na carga de trabalho de desempenho. Assim, o seu arnês de teste de desempenho precisa ser capaz de detectar erros comportamentais, bem como características de desempenho. Não é bom ser rápido se você estiver errado!