O teste de integração deve ser incluído na integração contínua (IC)?

Suponha que estamos desenvolvendo um aplicativo da Web, e o Hudson faz trabalhos típicos como compilação, teste de unidade e análise de código estático.

Mas a parte complicada é: Hudson implanta e inicia o servidor de aplicativos para fazer testes de integração , uma vez executados os trabalhos anteriores.

Isso significa algumas coisas difíceis, como conexão com o banco de dados, conexão de aplicativos de terceira parte, escuta de porta de soquete, variáveis ​​de ambiente, entrega de falhas de inicialização do servidor, etc. Pior, os testes de integração podem interromper o teste de integração facilmente.

Você acha que o teste de integração deve ser incluído na integração contínua (CI)? Pode ser manualmente? Ou simplificar o teste de integração?

o nome Integração Contínua diz muito. Qual o melhor lugar para fazer testes de integração do que onde você já está se integrando?
É claro que não deve ser o único local em que esses testes ocorrem. Ao desenvolver, você deve tentar garantir que não quebra as coisas, afinal, não apenas que suas alterações funcionem isoladamente.
No final, é responsabilidade de cada membro da equipe que as coisas não quebrem, tentar culpar e definir rigidamente pessoas ou estágios aos quais os testes são restritos são contraproducentes.

Você acha que o teste de integração deve ser incluído na integração contínua (CI)?

Se você tiver testes de integração que estão passando e não exige que alguém realmente fique lá e pressione os botões, sim - você deve adicioná-los ao sistema de CI.

Porém, como os testes de integração podem demorar muito para serem executados, você deve limitar a frequência com que eles são executados. Eles podem ser executados durante uma noite, quando o servidor de IC estiver ocioso.

Para responder à sua pergunta primeiro: Sim, eles definitivamente fazem parte da Integração Contínua, se você estiver me perguntando. Mas acho que precisamos esclarecer o que são testes de integração.

Martin Fowler estava falando sobre entrega contínua como uma maneira de automatizar o processo completo de construção para implantar rapidamente. Isso requer que os desenvolvedores obtenham feedback rápido fornecido pelo processo de Integração Contínua. Então ele define os estágios pelos quais a compilação deve passar :

1. uma construção de confirmação
2. teste completo
3. desdobramento, desenvolvimento

A compilação do commit não deve demorar mais de 10 minutos, ele afirma, devido ao rápido feedback dos desenvolvedores.

Aqui está como eu vejo as coisas: Na primeira etapa, busque o commit mais recente e construa-o. Se isso for bem-sucedido, você executa seus testes de unidade para descobrir se suas turmas / grupos de turmas estão funcionando conforme definido e esperado.

Quando isso é bem-sucedido, você acessa a parte do teste de integração. Aqui você testa a interação das unidades testadas com sucesso. Isso envolve alimentar as unidades com entrada e observar seu estado / interação / saída. Lembre-se de que ainda estamos na compilação de confirmação, por isso queremos que isso seja rápido também. Portanto, as interações com o sistema de arquivos, um banco de dados, pares de rede e similares precisam ser removidas para uma execução rápida. Martin Fowler também sugere o uso de bancos de dados na memória, se necessário, apenas para manter a execução rápida no servidor de IC.

Depois de ter certeza de que as unidades estão funcionando e interagindo conforme necessário, geralmente você deseja saber sobre a cobertura do teste (testar apenas um pequeno subsistema geralmente não é suficiente) e disponibilizar os artefatos testados para teste funcional / controle de qualidade / implantação ( leia: teste completo) se você acha que os testes cobrem o suficiente do seu programa. Nesse momento, você provisiona um ambiente de teste que espelha o ambiente de produção que você está alvejando e executa testes que envolvem um banco de dados real, arquivos reais, pares de rede reais etc.

No final, os testes de integração são sobre alterações de código. Você deseja garantir que as alterações feitas não estejam quebrando o sistema atual, o que significa que elas se integram bem. Para descobrir se eles são, você precisa garantir que eles se comportem corretamente em si mesmos, se eles interagem corretamente com suas dependências e se foram testados. Você pode ficar tranqüilo e confiante em seu sistema depois de passar em todos esses testes.

Se os estágios posteriores encontrarem algum problema com o seu programa (como quando o banco de dados retorna um determinado valor, sua conexão de rede será interrompida), tente tentar esses stub nos testes de integração. A compilação de confirmação provavelmente é mais rápida que o controle de qualidade;)