Le test d'intégration doit-il être inclus dans l'intégration continue (CI)?

Supposons que nous développons une application Web et que Hudson effectue des tâches typiques telles que la compilation, les tests unitaires et l'analyse de code statique.

Mais la partie la plus délicate est: Hudson déploie et démarre le serveur d'applications pour effectuer des tests d'intégration , une fois les travaux précédents effectués.

Cela signifie des choses difficiles, telles que la connexion à la base de données, la connexion à une application tierce, l'écoute du port de socket, les variables d'environnement, la gestion des échecs de démarrage du serveur, etc. Pire, les tests d'intégration peuvent facilement casser le test d'intégration.

Pensez-vous que le test d'intégration devrait être inclus dans la poursuite de l'intégration (CI)? Peut-il être manuel? Ou simplifier le test d'intégration?

le nom d' intégration continue en dit long. Quel meilleur endroit pour faire des tests d'intégration que là où vous intégrez déjà?
Bien sûr, cela ne devrait pas être le seul endroit où ces tests ont lieu, lors du développement, vous devez vous assurer de ne pas casser les choses après tout, pas seulement que vos changements fonctionnent de manière isolée.
En fin de compte, il est de la responsabilité de chaque membre de l'équipe que les choses ne se cassent pas.

Pensez-vous que le test d'intégration devrait être inclus dans la poursuite de l'intégration (CI)?

Si vous avez des tests d'intégration qui réussissent et que vous n'avez pas besoin que quelqu'un se tienne là et appuie sur des boutons, alors oui - vous devez les ajouter au système CI.

Mais, comme les tests d'intégration peuvent prendre très longtemps à s'exécuter, vous devez limiter leur fréquence d'exécution. Ils peuvent être exécutés pendant une nuit, lorsque le serveur CI est inactif.

Pour répondre d'abord à votre question: oui, ils font définitivement partie de l'intégration continue si vous me le demandez. Mais je pense que nous devons clarifier ce que sont les tests d'intégration.

Martin Fowler parlait de la livraison continue comme d'un moyen d'automatiser le processus de construction complet pour un déploiement rapide. Cela nécessite que les développeurs obtiennent une rétroaction rapide fournie par le processus d'intégration continue. Il définit donc les étapes de la construction :

1. une construction de commit
2. tests approfondis
3. déploiement

La construction de la validation ne devrait pas prendre plus de 10 minutes, déclare-t-il, en raison des commentaires rapides des développeurs.

Voici comment je vois les choses: dans la première étape, récupérez le dernier commit et construisez-le. Si cela réussit, vous exécutez vos tests unitaires pour savoir si vos classes / groupes de classes fonctionnent comme prévu et prévu.

Lorsque cela réussit, vous accédez à la partie test d'intégration. Ici, vous testez l'interaction des unités testées avec succès. Cela implique d'alimenter les unités en entrée et de surveiller leur état / interaction / sortie. N'oubliez pas que nous sommes toujours dans la version commit, nous voulons donc que cela soit aussi rapide. Les interactions avec le système de fichiers, une base de données, les homologues du réseau et autres doivent donc être stoppées pour une exécution rapide. Martin Fowler fait également allusion à l'utilisation de bases de données en mémoire si vous en avez besoin, juste pour que l'exécution soit rapide sur le serveur CI.

Après vous être assuré que les unités fonctionnent et interagissent selon les besoins, vous souhaitez généralement vous renseigner sur la couverture des tests (simplement tester un petit sous-système n'est généralement pas suffisant) et rendre les artefacts testés disponibles pour les tests fonctionnels / QA / déploiement ( lire: tests approfondis) si vous pensez que vos tests couvrent suffisamment votre programme. À ce moment-là, vous provisionnez un environnement de test qui reflète l'environnement de production que vous ciblez et exécutez des tests qui impliquent une vraie base de données, de vrais fichiers, de vrais pairs du réseau, etc.

Au final, les tests d'intégration concernent les changements de code. Vous voulez vous assurer que les modifications que vous avez apportées ne cassent pas le système actuel, ce qui signifie qu'elles s'intègrent bien. Pour savoir s'ils le sont, vous devez vous assurer qu'ils se comportent correctement en eux-mêmes, puis s'ils interagissent correctement avec leurs dépendances et s'ils ont été testés. Vous pouvez avoir confiance en votre système après avoir passé tous ces tests.

Si des étapes ultérieures rencontrent des problèmes avec votre programme (comme lorsque votre base de données renvoie une certaine valeur, votre connexion réseau s'arrêtera), vous devriez essayer d'obtenir ces tests dans les tests d'intégration. La build de validation est probablement plus rapide que QA;)