Test de régression fonctionnelle avec SOAtest dans le cadre d'un processus d'intégration continue

Atteignez de la vitesse tout en protégeant votre application contre les régressions

L'intégration continue («IC») est une pratique bien comprise et (à ce stade) bien adoptée. Il s'agit d'une première étape nécessaire pour améliorer considérablement la vitesse de livraison des applications.

L'intégration continue permet aux développeurs de pousser leurs modifications dans une branche «principale» du code source, un seul développeur pouvant potentiellement pousser de nombreuses modifications vers la branche principale tout au long d'une seule journée. Pour garantir que la branche principale est impeccable, modifiable et de haute qualité, il est essentiel de tester après chaque modification, car elle sert de copie dorée du code source de l'application.

(Si vous souhaitez en savoir plus sur l'intégration continue, je recommande l'article plus ancien mais toujours intéressant de Martin Fowler ici sur l'histoire de l'intégration dans le développement de logiciels et les avantages / meilleures pratiques de CI.)

Aujourd'hui, nous allons nous concentrer sur la façon de configurer Parasoft SOAtest pour exécuter des tests de régression fonctionnelle dans le cadre d'un processus d'intégration continue. Dans cet article, je vais décrire les étapes pour configurer SOAtest avec Jenkins, une plate-forme d'automatisation populaire. Nous utiliserons l'application open source Parabank et la déploierons à l'aide de Docker pour simplifier les choses.

Comment cela fonctionnera-t-il?

Le diagramme ci-dessous explique ce que nous allons configurer dans cet article. Il est préférable de le lire de gauche à droite.

En bref, Jenkins va vérifier un dépôt de Github qui contient le projet SOAtest appelé «Parabank» qui contient des tests REST. Jenkins extraira également une image Docker appelée parasoft / parabank à partir de Docker Hub. Cette image contient non seulement Parabank, mais également Tomcat et l'environnement d'exécution Java approprié.

Jenkins exécutera ensuite une instance de cette image Parabank (appelée «conteneur»). Ensuite, Jenkins demandera à SOAtest d'exécuter les tests que nous avons extraits de Github afin que nous puissions valider notre instance Parabank.

Maintenant, ce n'est pas tout à fait dans l'esprit d'une véritable intégration continue (puisque je vous donne une application pré-construite), mais je voulais utiliser Docker pour vous éviter d'avoir à construire Parabank avec Maven et d'avoir à installer et configurez Tomcat / Java.

Un diagramme de CI plus réaliste / réel est fourni ci-dessous. Le développeur vérifie le code source dans Github. Nous voulons maintenant tester que l'application est toujours en bon état même après les modifications du développeur.

Le changement de code source dans Github déclenche une compilation dans Jenkins, et Jenkins lance une compilation automatisée de Maven (qui exécute des tests JUnit). Si tous les tests unitaires réussissent, l'application packagée (parabank.war) est déployée sur Tomcat. SOAtest commence alors à exécuter des tests fonctionnels «boîte noire».

Ce n'est qu'après la réussite des tests unitaires (pendant la construction de Maven) et la réussite des tests fonctionnels de la «boîte noire» (pendant l'exécution de SOAtest) que les modifications originales du développeur sont considérées comme bonnes.

Passons aux étapes nécessaires pour configurer le processus dans le premier diagramme!

Configurer SOAtest et Jenkins

Pré-requis :

• Une machine Windows 10 capable d'exécuter Docker (d'autres systèmes d'exploitation fonctionneront, mais certaines des commandes que je fournis dans cet article peuvent avoir une syntaxe différente). Cette machine doit avoir une connexion Internet.
• Créez un fichier localsettings.properties quelque part sur votre ordinateur. Copiez le contenu de mon exemple de fichier dans ça. Si vous avez une licence verrouillée par nœud, ajoutez-la à la ligne 5. Si vous utilisez un serveur de licences, définissez la ligne 6 sur true et ajoutez le nom d'hôte de votre serveur de licences à la ligne 3. Nous aurons besoin du chemin d'accès à ce fichier plus tard.
• Jenkins 1.651 ou plus récent installé sur la même machine
• SOAtest 9.10 ou plus récent installé et sur le PATH (afin que vous puissiez appeler soatestcli à partir de n'importe quel répertoire) de la même machine.
• Docker installé et sur le PATH de la même machine.

Étape:

1. Connectez-vous à Jenkins dans votre navigateur Web (Jenkins est généralement déployé à une URL telle que http: // : 8080 / jenkins)
   
2. Nous allons commencer par installer quelques plugins Jenkins. Sélectionnez «Gérer Jenkins» sur la gauche puis «Gérer les plugins» dans le nouveau menu qui apparaît.
   
   
3. Sous l'onglet «Disponible», sélectionnez et installez ces plugins:
   une. «Résultats de Parasoft»
   b. «Plugin Git» (version 3.30) Sélectionnez «Installer sans redémarrer» puis, sur la page d'installation, cochez la case «Redémarrer Jenkins lorsque l'installation est terminée et qu'aucune tâche n'est en cours d'exécution»
4. Revenez à l'étape 1 du menu principal de Jenkins. Sur la gauche, sélectionnez «Nouvel élément»
5. Indiquez le nom «Parabank Deploy and Test» et sélectionnez le projet «Freestyle» puis OK
6. Dans le menu de configuration qui apparaît, faites défiler jusqu'à Gestion du code source et sélectionnez Git. Ajoutez cette URL au champ URL du référentiel: https://github.com/sdebrosse/soatest-automation-example.git . Tous les autres champs peuvent conserver leurs valeurs par défaut.
7. Faites défiler vers le bas de la page et sous Construire, ajoutez une étape de construction «Exécuter la commande par lots Windows» (si vous utilisez Linux, sélectionnez «Exécuter le shell» à la place):
   
8. Copiez le contenu du script ici et collez-le dans le champ de nouvelle étape de construction. Vous devez modifier les valeurs des deux variables en haut du script pour refléter le chemin d'accès à votre propre fichier localsettings.properties et l'endroit où vous souhaitez créer un espace de travail temporaire (SOAtest créera cet espace de travail pendant le processus de test). Les commentaires dans le script expliquent ce qui se passe sur chaque ligne:
9. C'est ça. Nous sommes maintenant prêts à exécuter notre travail Jenkins! Assurez-vous de fermer d'abord toutes les instances ouvertes de SOAtest. Sélectionnez ensuite Enregistrer en bas du menu de configuration, puis cliquez sur «Créer maintenant» à gauche:
   
10. Vous pouvez cliquer sur le travail en cours à gauche, puis afficher la sortie de la console en direct:
    
    Le journal indiquera «SUCCÈS» à la fin si tout a fonctionné correctement. Cela signifie que vous avez réussi à extraire un projet de test SOAtest de Github, à déployer un conteneur Docker avec Parabank et à exécuter des tests sur cette instance Parabank. À la fin du processus, nous avons automatiquement arrêté le conteneur Parabank et supprimé notre espace de travail temporaire pour nettoyer notre environnement.Mais attendez une seconde, vous avez peut-être remarqué en regardant les journaux que nous avions des échecs de test ...Oui, quelques-uns de nos tests contre Parabank ont ​​échoué. Si nous voulons que notre build Jenkins échoue en raison d'échecs de test SOAtest, nous ajoutons l'indicateur -fail lorsque nous invoquons soatestcli. Comme ceci :soatestcli.exe -fail -data %TEMP_WORKSPACE_PATH% -resource /Parabank -config "builtin://Demo Configuration" -localsettings %LOCALSETTINGS_PATH%Si vous ouvrez le test dans l'interface utilisateur SOAtest Desktop, vous découvrirez que cela l'échec est principalement un problème de configuration des données de test/de l'environnement de test. Notre processeur de prêt a refusé un prêt qu'il aurait dû approuver.

Où allons-nous partir d'ici?

La configuration de l'environnement de test et les données de test sont les principaux obstacles à des tests automatisés fiables. Dans de futurs articles, j'explorerai comment une technologie appelée la virtualisation des services peut nous aider à garantir que nous avons toujours la configuration d'environnement exacte dont nous avons besoin pour exécuter nos tests de manière fiable à tout moment - cela nous fera passer de l'intégration continue au monde de l'intégration continue. Essai.

Par Spencer Debrosse