Testes de Integração

Os testes que escrevemos até agora verificam se unidades do software funcionam separadamente. Ou seja, testamos o comportamento dela sem se preocupar com o comportamento das outras classes, graças aos Mocks.

Se quisermos um teste que se pareça com o mundo real, é necessário escrever o que chamamos de teste de sistema, que é idêntico ao executado pelo usuário e executa tarefas como inicializar o browser, clicar em links, submeter formulários, e etc. No entanto, muitas vezes queremos testar não só uma classe, mas também não o sistema todo; queremos testar a integração entre um componente e um sistema externo/outro componente. Esse tipo de teste, que garante a integração entre 2 ou mais componentes da aplicação, é conhecido por teste de integração.

Nos testes de unidade, nossas classes são testadas isoladamente. Essas unidades devem ser integradas para verificar se o comportamento está de acordo com os requisitos quando são usadas em conjunto.

O quadro abaixo mostra as diferenças entre Testes de Unidade e Integração

Testes de Unidade	Testes de Integração
Resultado depende apenas de código	Resultado depende de sistemas externos
Fácil de escrever e verificar	A escrita e configuração dos testes pode ser complicado
Uma única classe/unidade é testada	Um ou mais componentes são testados
Todas as dependências são “mocks”	Não há uso de mocks (com exceção de componentes não usados)
O teste verifica apenas a implementação do código	O teste verifica a implementação do componentes individualmente e seu comportamento quando usado em conjunto
Uso de Junit e frameworks de mock	Containers reais, bancos de dados reais e frameworks para testes integrados (DBUnit)
Geralmente usado por desenvolvedores	Usado pelo QA, Help Desk, etc.
Falha sempre indica uma regressão (caso o requisito não tenha mudado)	Falha pode indicar que o código continua correto, mas que o ambiente mudou.
São rápidos	Podem durar horas

Mesmo que os módulos estejam funcionando individualmente, defeitos podem surgir por vários motivos.

Um componente feito por um desenvolvedor pode ter uma lógica diferente dos componentes feitos por outros desenvolvedores; erro com as interfaces de persistência pode causar perca de dados ou quebra de integridade; interface com itens de hardware, geralmente feito com simuladores/emuladores pode estar errada ao ser executado em ambiente de produção.