Dans les premières étapes du développement, vous pouvez vous en tirer avec des tests manuels selon un plan de test donné. Mais avec l'avènement de l'architecture modulaire, lorsque plusieurs équipes de développement peuvent apporter des modifications en même temps, il y a une augmentation exponentielle du nombre de scripts de test. Les éloigner manuellement devient de plus en plus difficile.
Dans cet article, nous parlerons de la façon dont Virto Commerce automatise les tests de scénarios commerciaux importants.
Pourquoi tout ça?
Je vais vous donner un exemple tiré de notre expérience: une petite modification de style CSS a rendu le bouton "Ajouter le produit au panier" plus visible sur l'appareil mobile. Malheureusement, sous cette forme, il a été testé et a frappé la version. Il existe de nombreux exemples où de nouvelles fonctionnalités, des corrections et des corrections mineures rompent des scénarios commerciaux importants. Malheureusement, nous en apprenons souvent à leur sujet après les versions et auprès des clients. Pour éviter cela, il y a plus de deux ans, nous avons commencé à implémenter les tests E2E dans le cadre du processus de développement. Après cela, la plupart des erreurs ont été identifiées au stade du développement, et non sur l'environnement de combat.
E2E teste un scénario commercial du début à la fin. Le test E2E simule les actions réelles de l'utilisateur dans un vrai navigateur, tout comme le vrai utilisateur utilisera la solution.
Nous utilisons les tests E2E:
- Pour contrôler la régression
- Décrire le système
- Pour intégration dans CI / CD
Cela implique de s'assurer que tous les modules fonctionnent et fonctionnent ensemble correctement et de manière prévisible.
Les tests E2E nous permettent de couvrir des sections de l'application qui ne sont pas vérifiées par les tests unitaires et d'intégration. Cela est dû au fait que les tests unitaires et les tests d'intégration couvrent des parties individuelles de l'application et testent une partie isolée de la fonctionnalité. Même si ces pièces fonctionnent bien par elles-mêmes, vous ne pouvez pas être sûr qu'elles fonctionneront ensemble. Ainsi, la présence d'un ensemble de tests E2E au dessus de Unit et l'intégration nous permet de tester l'ensemble de la solution de la manière la plus complète.
L'écriture et l'exécution des tests E2E prennent du temps et des ressources. Google, par exemple, propose une séparation 70/20/10: 70% de tests unitaires, 20% de tests d'intégration et 10% de tests E2E. La combinaison exacte sera différente pour chaque projet, mais en général, elle devrait conserver la forme de la pyramide.
Les tests E2E ne sont pas simples et semblent à première vue coûteux à développer et à maintenir. Chez Virto Commerce, nous travaillons constamment à simplifier le développement et à réduire le coût de la prise en charge des tests E2E lorsque de nouvelles versions sont publiées. Nous espérons que nos solutions vous aideront à simplifier l'utilisation d'E2E dans vos projets.
Bonne histoire d'utilisateur - c'est le test E2E presque prêt
Vous pouvez souvent entendre que la rédaction des tests E2E prend du temps; ils sont difficiles à maintenir. Oui, c'est vrai, ils ne sont pas faciles à maintenir ainsi que la documentation. Pourquoi ne pas les intégrer au processus de développement et à la rédaction de la documentation, capturant ainsi des scénarios commerciaux.
La création d'E2E commence par une description de la user story. Avec le soin avec lequel nous préparons la description à ce stade, il sera si simple pour l'équipe de développement d'écrire un test E2E qui démontrera que tous les systèmes fonctionnent correctement lors de la mise en œuvre de ce scénario.
Un exemple de user story pour un bouton permettant d'ajouter un article au panier:
GIVEN I am signed in to the storefront AND Some product page is open (/product-name) AND my cart is empty WHEN I click to the "Add" button on the item with the following parameters: THEN I should see a dropdown menu where I can choose from 1 to 10+
qui se transforme alors en test suivant:
Après un certain temps, les rédacteurs techniques ou une nouvelle équipe de développement, au lieu de lire la documentation, peuvent utiliser les tests pour exécuter et voir les scripts implémentés dans un vrai navigateur ou enregistrer automatiquement des didacticiels vidéo.
Facile - Installer et configurer le rapporteur
En tant qu'outil de test, nous avons choisi Protractor, un système d'automatisation de test E2E open source développé spécifiquement pour les applications Web AngularJS.
Protractor est un programme Node.js construit sur WebDriverJS. Protractor fonctionne comme un intégrateur de solutions combinant des technologies puissantes telles que Node.js, Jasmine, Selenium, Mocha, Cucumber et Web.
Protractor connaît AngularJS, ce qui facilite l'écriture de tests sans passer le temps à attendre le lancement du projet AngularJS, à rafraîchir la page, etc ... L'expérience montre que le seuil d'entrée développeur est très bas.
Utilisez npm pour installer Protractor globalement:
npm install -g protractor
webdriver-manager est un utilitaire qui facilite la configuration d'une instance de Selenium Server. Serveur Selenium - sera utilisé pour transférer les commandes entre le test et l'environnement réel.
Exécutez cette commande pour installer ou télécharger:
webdriver-manager update
Et lancez:
webdriver-manager start
Cette commande démarre Selenium Server et ouvre une fenêtre pour afficher le journal. Protractor enverra des demandes à ce serveur pour contrôler le navigateur.
Le rapporteur est prêt à partir. Une description plus détaillée des étapes de base de la rédaction des tests est disponible sur le
site principal .
La bonne structure du projet
Les tests E2E sont toujours dans le même référentiel que l'application ou le thème.
Nous avons refusé d'utiliser les services de test E2E externes, car, avec une simplicité apparente, les services compliquent le lancement des tests sur la machine locale et la maintenance ultérieure. Le code et les tests sont situés à différents endroits physiques, ce qui fait que les développeurs oublient de les mettre à jour.
La recherche de code d'application et de test dans un référentiel facilite la maintenance et la maintenance du projet.
Un exemple de base peut être
trouvé ici .
Le projet crée un dossier E2E de la structure suivante, qui utilise des objets de page pour organiser les tests.
E2E/ |--cart | |--cart.pageObject.js | |--*.spec.js |--home | |--home.pageObject.js | |--*.spec.js |--conf.js
- conf.js - le fichier de configuration est à la racine
- pour chaque objet d'interface, son propre dossier est créé, dans lequel il se trouve
- fichier pageObject pour décrire les éléments de la page
- plusieurs fichiers de spécifications - où se trouvent les tests
Dans le projet, l'utilisation de:
- baseUrl - qui vous permet d'utiliser le test pour tester différents environnements
- params - qui sont utilisés pour trouver des éléments clés sur une page ou remplir des formulaires
github.com/VirtoCommerce/vc-storefront/blob/master/VirtoCommerce.Storefront.Test/e2e/conf.js#L21
github.com/VirtoCommerce/vc-storefront/blob/master/VirtoCommerce.Storefront.Test/e2e/conf.js#L29Ces paramètres peuvent ensuite être modifiés par l'administrateur informatique lors de la configuration du lancement dans Jenkins, en mode automatique pour les environnements DEV et QA.
protractor conf.js --baseUrl=https://some-url.azurewebsites.net/--params.api.endpoint=https://some-admin-url.azurewebsites.net
Optimisation de la recherche d'éléments sur la page
Le rapporteur propose des méthodes très flexibles pour trouver des éléments sur la page:
- by.binding
- by.model
- by.repeater
- by.className
- by.css
- by.select ()
- par.partialButtonText ()
- ...
Mais dans des projets récents, nous sommes arrivés au modèle selon lequel les éléments qui participent au test sont marqués d'une classe spéciale avec le préfixe rapporteur. Dans le test, ces éléments sont trouvés par byclassName.
Cela simplifie la maintenance des tests et apporte des modifications, de sorte qu'un programmeur ou des outils automatisés peuvent déterminer que l'élément qui participe au test E2E a été modifié.
Quels navigateurs testons-nous
Par défaut, tous les processus sont configurés pour exécuter des tests dans le navigateur Chrome. Comme le montre notre expérience de l'utilisation des tests E2E dans Chrome, cela nous permet d'identifier la plupart des problèmes et en même temps de ne pas compliquer la rédaction des tests.
Si vous avez besoin de tester dans plusieurs navigateurs, alors cela se fait d'une part très simplement, d'autre part il y a des difficultés avec la configuration et la présence d'erreurs dans l'implémentation de pilotes pour différents navigateurs.
Dans divers projets clients, nous avons également testé dans Firefox, Safari et IE. Les tests Firefox dupliquent en fait les résultats dans Chrome. Mais le lancement d'E2E dans Safari et IE a nécessité la configuration du système, l'ouverture des ports, la désactivation de la sécurité et la modification du registre, mais cela a permis de détecter automatiquement de nombreux problèmes d'affichage et d'incompatibilité des scripts dans l'application.
Pour ajouter des tests dans le navigateur, vous devez télécharger et installer le
WebDriver nécessaire.Et ajoutez une nouvelle section multiCapabilities dans le fichier de configuration:
exports.config = { … multiCapabilities: [ { 'browserName' : 'chrome' }, { 'browserName' : 'firefox' } ], … }
Étant donné que les applications Web modernes prennent en charge le travail avec différentes résolutions, cela doit être pris en compte lors de l'écriture des tests.
Protractor vous permet d'exécuter des tests pour différentes résolutions d'écran.
Pour ce faire, il existe une option pour définir la taille de l'écran via browser.driver.manage (). Window (). SetSize. Dans cet exemple, nous avons défini la taille de l'écran sur 1600 par 800.
exports.config = { … capabilities: { 'browserName': 'chrome' }, onPrepare: function() { browser.driver.manage().window().setSize(1600, 800)
Ou via la section multiCapabilities du fichier de configuration. Dans cet exemple, nous exécuterons des tests dans le navigateur Chrome pour trois résolutions différentes.
multiCapabilities: [ { 'browserName': 'chrome', 'chromeOptions' : { args: ['--lang=en', '--window-size=1920,1080'] }, specs: ['specs.js'] }, { 'browserName': 'chrome', 'chromeOptions' : { args: ['--lang=en', '--window-size=1680,1050'] }, specs: ['specs.js'] }, { 'browserName': 'chrome', 'chromeOptions' : { args: ['--lang=en', '--window-size=1600,900'] }, specs: ['specs.js'] }]
E2E fait partie de la documentation.
Encore une fois, E2E est un bon élément de documentation, démontrant ce qui a été fait par l'équipe de développement. Une nouvelle équipe de développement ou rédacteur technique peut exécuter les tests et regarder les scripts mis en œuvre en direct. Par conséquent, documentez comment un nouvel employé peut exécuter ces tests.
Intégration CI / CD
Tous les tests doivent être pertinents et exécutés périodiquement. Si cela n'est pas fait, vous ne devriez pas perdre de temps à écrire des tests, ils deviendront inutiles dans quelques semaines et il sera plus facile de les réécrire à partir de zéro.
Nous avons franchi une étape importante dans l'intégration des tests E2E dans CI / CD et dans l'intégration d'E2E au processus de déploiement.
L'intégration dans le CI / CD vous permet d'exécuter automatiquement des tests E2E pour les environnements DEV et QA afin de fournir des informations en retour et d'ajouter que le système reste opérationnel même après un petit changement. Et si la décision est cassée, donnez des informations quand et à quel changement cela s'est produit.
Premièrement, les tests sont lancés lorsque l'un des modules est mis à jour et que la nouvelle version pénètre dans l'environnement QA.
Deuxièmement, les tests E2E sont exécutés la nuit selon un calendrier sur les environnements DEV et QA en mode automatique.
Troisièmement, si nécessaire, les développeurs eux-mêmes peuvent exécuter les tests selon les besoins.
Sur la base des résultats du lancement, tous les participants au projet, de l'équipe de développement au client, reçoivent un e-mail avec un rapport HTML sur les résultats du test.
Il est important de noter la disponibilité obligatoire des informations sur le résultat du test à l'ensemble de l'équipe projet. Cela donne confiance à l'équipe de développement d'une part et gère les attentes des clients d'autre part. L'équipe de développement peut apporter des modifications plus rapidement, tout en réalisant que les principaux scénarios commerciaux fonctionnent. Et le client reçoit des informations sur la qualité du projet, que la plupart des problèmes sont identifiés avant la sortie. Et même si le problème est identifié par le test et que la publication est reportée, des informations apparaissent sur ce qui s'est exactement cassé et comment se déroule le processus de travail sur la correction.
Pour générer des rapports, nous utilisons la version modifiée du plugin rapporteur rapporteur-jasmine2-html (https://github.com/VirtoCommerce/protractor-jasmine2-html-reporter). Ce plugin génère un rapport HTML et insère des captures d'écran d'éléments en ligne.
L'installation est très simple:
- Installer rapporteur-jasmin2-html-reporter
- Ajout de rapporteur-jasmin2-html-reporter au projet
- Rapport de connexion sur la méthode Prepare
var HtmlScreenshotReporter = require('protractor-jasmine2-html-reporter'); var reporter = new HtmlScreenshotReporter(self.options); var name = browser.suite; self.options.reportTitle = name + '-report.html'; jasmine.getEnv().addReporter(reporter);
Améliorez constamment le processus
Travailler constamment en équipe pour réduire les coûts et augmenter la vitesse de développement et de support des tests E2E.
Former et revoir le processus de rédaction des tests. Découvrez quels nouveaux composants et services peuvent être utilisés.
Par exemple, nous envisageons une option de connexion Cucumber. Le concombre est un outil pour exécuter des tests automatisés écrits dans un langage simple.
Conclusions
Les tests E2E ne sont pas si simples et semblent à première vue coûteux à maintenir, mais ils sont très précieux car ils sont un indicateur de la santé de scénarios commerciaux importants.
De l'expérience de l'utilisation des tests E2E dans le projet Virto Commerce, nous pouvons tirer les conclusions suivantes:
- L'écriture E2E fait partie du processus de développement. Et c'est très important, car il teste le travail des processus métier et la solution dans son ensemble. Un grand nombre d'erreurs ont été détectées au stade de DEV et QA, et non sur l'environnement de combat.
- Les tests et le code doivent être dans le même référentiel et être à la disposition du développeur.
- La qualité du test E2E dépend de la description de la user story; si elle est écrite correctement, il est plus facile pour l'équipe de développement de créer un test E2E.
- Les tests E2E peuvent servir de documentation et enregistrer les scripts créés.
- Les tests E2E doivent être exécutés en continu et automatiquement sur les environnements DEV et QA. Si vous n'avez pas automatisé le lancement, vous ne devriez pas perdre de temps sur les tests, ils deviendront sans valeur dans quelques semaines.
- Les résultats des tests devraient être disponibles pour tous les participants au projet. Cela donne une image de ce qui se passe.
- Les E2E ne sont pas une solution à 100% à tous les problèmes. Suivez la règle 70/20/10: 70% tests unitaires, 20% tests d'intégration et 10% tests E2E
- Travailler constamment en équipe pour réduire les coûts et augmenter la vitesse de développement et de support des tests E2E.
Les références
www.protractortest.orgRapporteur pour AngularJS - L'écriture de tests de bout en bout n'a jamais été aussi amusantegithub.com/angular/protractor/blob/master/docs/page-objects.mdgithub.com/VirtoCommerce/vc-storefront/tree/master/VirtoCommerce.Storefront.Test/e2eDites simplement non à d'autres tests de bout en bout
testing.googleblog.com/2015/04/just-say-no-to-more-end-to-end-tests.html