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

Meus amigos e eu temos lutado para classificar exatamente o que é um teste de integração.

Agora, no meu caminho de casa, eu acabei de perceber, que toda vez que tento dar um exemplo do mundo real de um teste de integração, acaba sendo um teste de aceitação, ou seja. algo que uma pessoa de negócios diria em voz alta que especifica o que o sistema deve entregar.

Eu verifiquei a documentação do Ruby on Rails para a classificação desses tipos de teste, e agora isso me impressionou completamente.

Você pode me dar uma breve descrição acadêmica de um teste de integração com um exemplo do mundo real?

No momento, gosto desta afirmação: "Não é importante como você chama, mas o que ela faz", feita por Gojko Adzic neste artigo .

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

Muitas pessoas têm opiniões diferentes, dependendo de qual é o seu papel.

Para os testadores, uma metodologia de teste geral 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 de sistemas
• teste de aceitação (todos os tipos / níveis)
• teste de aceitação funcional
• teste de aceitação de usuário
• teste de aceitação de produção

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

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

O livro que o programador pragmático diz:

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

Olhando para essas diferentes fontes e colocando algumas de minhas próprias experiências e opiniões, 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 nas aulas pelos programadores para mostrar a correção no nível do código. Eles devem ser rápidos e não dependem de outras partes do sistema que você não pretende testar
  • Teste de aceitação funcional : o cenário de caso de uso de teste está em um conjunto de dados limitado (especialmente criado) feito pelo departamento de teste para mostrar que todo cenário especificado funciona como especificado.
  • Teste de aceitação do usuário : teste de cenário de caso de uso na produção, como dados feitos por representantes dos usuários para fazê-los aceitar formalmente o aplicativo
  • Teste de integração : teste os caminhos de comunicação entre diferentes partes do módulo, realizados 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 faz"

Espero que isto ajude.

26-10-2016 Editar: Recentemente, uma introdução muito boa foi feita nos testes de unidade do YouTube versus testes de integração - Musings do MPJ - FunFunFunction # 55

teste de integração, acaba sendo um teste de aceitação

Obviamente.

Esses dois são quase a mesma coisa. Mas existem 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 de canto? Os casos de teste tendem a ser técnicos, escritos por designers e codificadores.

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

Pessoalmente, gosto de pensar em um teste de integração como 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 do usuário real. Você testa funcionalidade específica quando o sistema está totalmente montado e é como deveria ser quando implantado.

Em minha (admito) pouca experiência, entendi que a palavra integração pode realmente criar mal-entendidos: realmente, é 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:

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

Na definição do teste de integração, por externo eu quis dizer sistemas que estão fora do meu alcance de desenvolvimento : não posso mudar imediatamente o modo como eles se comportam, por qualquer motivo. Pode 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 testando a aceitação, finjo coisas: estou trabalhando em algo diferente, trabalhando nas especificações do sistema, não na capacidade de colaborar com entidades externas.

Esta é realmente uma visão mais restrita em comparação com o que KeesDijk descreveu anteriormente, no entanto, suponho que os projetos em que 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) estão funcionando juntos, conforme projetado.

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

• interação correta entre alguns componentes. Exemplo: ao pressionar o botão Iniciar, o motor dá partida e a hélice atinge a velocidade de rotação esperada (a aeronave ainda permanece no chão)
• interação correta com componentes externos. Exemplo: verifique se o rádio incorporado pode se comunicar com um rádio estacionário (aeronave ainda em terra)
• interação correta entre todos os componentes envolvidos, para que o sistema como um todo funcione conforme o esperado. Exemplo: uma equipe de pilotos e engenheiros de teste inicia o avião e voa com ele (todos usam pára-quedas ...).

O teste de integração soluciona um problema técnico , a saber, 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 à finalidade. Eles são, em princípio, realizados 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: ensaie 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 um teste de unidade, mas são realizados pelo usuário (por exemplo, tente os plugues elétricos com o equipamento da empresa).
• o sistema funciona em uma situação de negócios quase real. Exemplo: faça um voo de teste vazio entre dois destinos reais, com pilotos recém-treinados da companhia aérea para verificar se o consumo de combustível é o prometido.

O teste de aceitação aborda mais uma questão de responsabilidade . No relacionamento cliente / fornecedor, pode ser uma responsabilidade contratual (conformidade com todos os requisitos). Mas, em qualquer caso, também é responsabilidade da organização que os utiliza garantir que suas tarefas possam ser executadas com o sistema e evitar prudentemente qualquer problema imprevisto (por exemplo, essa empresa de ferrovias que descobriu durante os testes de aceitação que eles precisavam reduzir algumas delas porque os novos vagões eram 5 cm grandes demais - não é brincadeira!).

Conclusões: Os testes de integração e aceitação sã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 é do que verificar a conexão e a correção do fluxo de dados entre dois ou mais módulos.

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

Uma definição prática de um teste de integração é: Qualquer teste que exija interação com algo fora de 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 a verificação mínima desse 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ê está se movendo em direção ao espaço do sistema / de ponta a ponta.

Os testes de unidade são capazes de testar toda a lógica dentro dos limites do seu processo e podem fazê-lo facilmente precisamente devido à falta de dependências no "mundo externo" lento / frágil / complexo.

Embora existam testes de integração, essa definição não cobre (por isso a chamei de definição prática ), acho que são muito menos comuns / úteis.

NB: Estritamente falando, sim, essa definição também abrangeria testes de sistema / de ponta a ponta. Na minha filosofia, eles são uma forma de teste de integração "extremo", por isso os nomes enfatizam outro aspecto. Na outra direção, um teste de unidade pode ser considerado um teste de integração de zero componentes, ou seja, todos os testes podem ser considerados em algum lugar do espectro de integração, integrando entre 0-n componentes :-)