O que é um teste de integração exatamente?

No momento, eu gosto desta declaração: "Não é importante o que você chama, mas o que faz" feito por Gojko Adzic em este artigo .

Você realmente precisa especificar com as pessoas falando sobre os testes o que você pretende testar.

Existem muitas pessoas que têm opiniões diferentes, dependendo do papel delas.

Para os testadores, uma metodologia de teste aceita na Holanda é TMap . O TMap faz a seguinte distinção.

• teste de unidade
• teste de integração de unidades
• teste do sistema
• teste de integração do sistema
• teste de aceitação (todos os tipos / níveis)
• teste de aceitação funcional
• teste de aceitação do usuário
• teste de aceitação de produção

Eles têm tipos mais específicos de testes que podem ser realizados nos testes mencionados acima. Veja esta palavra doc para uma visão geral.

A Wikipédia também tem uma boa visão geral .

O livro do programador pragmático diz:

• um teste de unidade é um teste que exercita um módulo
Testes de integração
• mostram que as partes principais de um sistema funcionam bem juntas

Olhando para essas diferentes fontes e colocando algumas de minhas próprias experiências e opiniões, eu começaria fazendo distinções em três categorias

• quem faz o teste em geral
• o que é testado

• qual é o objetivo do teste

  • Teste de unidade : teste a lógica em classes por programadores para mostrar a correção do nível de código. Eles devem ser rápidos e não depender de outras partes do sistema que você não pretende testar
  • Teste de aceitação funcional : teste o cenário de caso de uso em um conjunto de dados limitado (especialmente criado) feito pelo departamento de teste para mostrar que cada cenário especificado funciona conforme especificado.
  • Teste de aceitação do usuário : teste cenários de casos de uso em produção, como dados feitos por representantes dos usuários para aceitá-los formalmente.
  • Teste de integração : teste os caminhos de comunicação entre as diferentes partes do módulo feitas pelo departamento de teste ou pelos desenvolvedores para mostrar que todos os módulos funcionam corretamente juntos.

Minha lista acima é apenas um começo e uma sugestão, mas eu realmente penso: "Não é importante o que você chama, mas o que ela faz"

Espero que isso ajude.

26-10-2016 Edit: Recentemente, uma introdução muito legal foi feita no YouTube Testes de unidade vs. testes de integração - MPJ's Musings - FunFunFunction # 55

integration test, it turns out to be an acceptance test

Obviamente.

Estes dois são quase a mesma coisa. Mas há algumas dimensões ligeiramente diferentes para a definição de teste.

Integração == o sistema como um todo.

Aceitação == o sistema como um todo.

A única diferença - e isso é sutil - é a definição dos casos de teste.

Integração == casos de teste para testar a profundidade e o grau de integração. Funciona para todos os casos de borda e casos de canto? Casos de teste tendem a ser técnicos, escritos por designers e codificadores.

Aceitação == casos de teste para exercer apenas 80% do conjunto de recursos com foco no usuário final. Nem todos os casos de borda e canto. Os casos de teste tendem a ser não técnicos, escritos por usuários finais.

Pessoalmente, gosto de pensar em um teste de integração a partir de um teste de recurso quando todos os componentes do sistema são reais , sem objetos simulados.

Um repositório real, um banco de dados real, uma interface de usuário real. Você testa uma funcionalidade específica quando o sistema está totalmente montado e é como deveria estar quando implantado.

Em minha (eu admito) pouca experiência, eu entendi que a palavra integração pode realmente criar mal-entendidos: na verdade, é difícil encontrar algo completamente isolado em um sistema, alguns elementos precisarão de alguma integração com certeza.

Assim, me acostumei a fazer as seguintes distinções:

• eu uso teste de unidade para identificar documentar e enfatizar todos os comportamentos a classe que estou testando é responsável realizar.
• Estou fazendo testes de integração sempre que eu tenho um componente (talvez mais de um) no meu sistema, que é tendo alguma conversa com outro sistema " externo ". (continuou abaixo ...)
• eu implemento um teste de aceitação para definir, documentar e sublinhar um certo fluxo de trabalho que é esperado pelo sistema.

Na definição de teste de integração, por externo eu quis dizer sistema que está fora do meu intervalo de desenvolvimento : não posso mudar imediatamente a maneira como eles se comportam, por qualquer motivo. Poderia ser uma biblioteca, um componente do sistema que não pode ser alterado (ou seja, é compartilhado com outros projetos da empresa), um dbms, etc. Para esses testes, preciso configurar algo muito semelhante ao ambiente real do sistema. funcionará em: um sistema externo deve ser inicializado e definido para um determinado estado; dados realistas devem ser registrados no banco de dados; etc.

Em vez disso, quando estou fazendo testes de aceitação, eu falsifico coisas: estou trabalhando em algo diferente, estou trabalhando nas especificações do sistema, não em sua capacidade de colaborar com entidades.

Este é realmente um ponto de vista mais restrito comparado ao que KeesDijk descreveu anteriormente, no entanto, suponho que os projetos nos quais trabalhei até agora eram pequenos o suficiente para me permitir esse nível de simplificação.

Um teste de integração verifica se os componentes de um sistema complexo (por exemplo, software, aeronave, usina de energia) estão funcionando em conjunto, conforme projetado.

Vamos imaginar que estamos falando de uma aeronave (com software é mais abstrato e difícil de fazer a diferença). Os testes de integração incluem verificar:

• interação correta entre alguns componentes. Exemplo: ao pressionar o botão de partida, o motor começa e a hélice atinge a velocidade de rotação esperada (a aeronave ainda permanece no solo)
• interacção correcta com componentes externos. Exemplo: verifique se o rádio incorporado pode se comunicar com um rádio estacionário (aeronave ainda no solo)
• interação correta entre todos os componentes envolvidos, de modo que o sistema como um todo funcione conforme o esperado. Exemplo: uma equipe de pilotos e engenheiros de teste começa o avião e voa com ele (todos usam paraquedas ...).

O teste de integração aborda um problema técnico , ou seja, que o sistema funciona apesar de sua subdivisão em componentes. No software os componentes podem ser casos de uso, módulos, funções, interfaces, bibliotecas, etc ...

O teste de aceitação verifica se o produto é adequado ao objetivo. Eles são, em princípio, executados pelo cliente. Tomando a analogia da aeronave, eles incluem a verificação de que:

• cenários de negócios previstos levam ao resultado esperado em uma situação quase real. Exemplo: ensaiar um embarque com passageiros de teste para verificar se a equipe pode monitorar o embarque conforme o esperado com os procedimentos operacionais. Alguns cenários podem ser tão simples que parecem com o teste de unidade, mas são executados pelo usuário (por exemplo, tente os plugues elétricos com o equipamento das empresas).
• o sistema funciona em uma situação de negócios quase real. Exemplo: faça um vôo de teste vazio entre dois destinos reais, com pilotos recém treinados da companhia aérea para verificar se o consumo de combustível está conforme o prometido.

O teste de aceitação aborda mais uma questão de responsabilidade . Numa relação cliente / fornecedor, pode ser uma responsabilidade contratual (cumprimento de todos os requisitos). Mas, em qualquer caso, também é responsabilidade da organização utilizadora garantir que suas tarefas possam ser executadas com o sistema e evitar de maneira prudente qualquer problema imprevisto (por exemplo, como a empresa ferroviária que descobriu durante os testes de aceitação ter que encurtar alguns cais porque os novos vagões eram 5 cm muito grandes - não é brincadeira!).

Conclusões: Os testes de integração e aceitação estão sobrepostos. Ambos pretendem mostrar que o sistema como um todo funciona. No entanto, o "todo" pode ser maior para o cliente (porque o próprio sistema pode fazer parte de um sistema organizacional maior) e mais técnico para o integrador de sistemas:

O teste de integração nada mais é que verificar a conexão e a correção do fluxo de dados entre dois ou mais módulos.

Por exemplo: Quando compomos um e-mail (um módulo) e o enviamos para um ID de usuário válido (segundo módulo), o teste de integração é para verificar se o e-mail enviado está nos itens enviados.

Uma definição prática de um teste de integração é: Qualquer teste que requeira interação com algo fora do processo.

Por exemplo:

• O sistema de arquivos
• A rede
• Um banco de dados
• Uma API externa

Existe um tipo de contrato entre o seu processo e o mundo externo e, minimamente, verifica se o contrato deve ser o objetivo de um teste de integração. isto é, não deve fazer mais do que verificar o contrato. Se isso acontecer, você estará se movendo em direção ao sistema / espaço de ponta a ponta.

Testes de unidade são capazes de testar toda a lógica dentro do seu limite de processo, e eles podem fazê-lo facilmente precisamente por causa da falta de dependências no "mundo externo" lento / frágil / complexo.

Embora existam testes de integração que esta definição não cobre (daí porque eu a chamei de uma definição prática ) eu acho que eles são muito menos comuns / úteis.

N.B. Estritamente falando, sim, essa definição também cobriria os testes do sistema / ponta a ponta. Na minha filosofia, eles são uma forma de teste de integração "extremo", daí porque seus nomes enfatizam outro aspecto. Na outra direção, um teste unitário pode ser considerado um teste de integração de zero componentes, ou seja, Todos os testes podem ser considerados em algum lugar no espectro de integração, integrando entre 0-n componentes :-)