Tests de régression de disposition de site Web en utilisant docker-console

Vous est-il déjà arrivé de regarder un site web et de ne pas être sûr si une police que vous avez utilisée était de 12 pt ou de 13 pt ? Ou peut-être avez-vous continué à regarder une image, en vous demandant si elle avait été légèrement déplacée vers la gauche auparavant ? Si la disposition est une priorité sur votre site web, il est peut-être temps de penser à automatiser le test de cet aspect de votre projet. VisualCeption est une solution remarquable pour exactement ce cas d'utilisation. Chez Droptica, nous l'utilisons beaucoup pour nous assurer que les sites web corporatifs que nous construisons pour nos clients conservent la qualité originale tout au long des itérations de développement ultérieures.

Dans cet article, nous allons vous montrer comment lancer cet add-on sur un projet construit en utilisant le docker-console. Comme dans nos articles précédents, nos exemples seront basés sur le projet que vous connaissez déjà de nos articles précédents.

Comment cela fonctionne-t-il ?

Lors du premier lancement, VisualCeption fait une capture d'écran "référence" d'un site web donné ou d'une liste d'éléments spécifiés dans le test. Ensuite, à chaque exécution ultérieure du texte, VC prend de nouvelles captures d'écran (actuelles) et les compare aux versions précédentes - c'est pourquoi la première exécution se termine toujours par un score positif, car il n'y a pas de fichiers de base avec lesquels il pourrait comparer l'état actuel de la page. Cette comparaison donne une valeur en pourcentage exprimant les différences entre les deux images et un fichier spécifiant où se trouvent les changements. Pour l'instant, tout cela peut sembler un peu flou, mais j'espère qu'à la fin de l'article, tout sera clair. Alors, sans plus tarder, passons à la configuration.

Nouveau suite de test

Comme ce type de tests est exécuté plutôt lentement, nous pensons qu'il est approprié de créer une nouvelle suite de tests afin de ne pas ralentir les tests restants et de maintenir un meilleur contrôle sur tous. Pour ce faire, ouvrez le terminal (dans le dossier du projet) et tapez :

dcon codecept generate:suite visual

Après avoir exécuté cette commande, les fichiers nécessaires pour le lancement des tests de la nouvelle suite seront automatiquement générés dans notre projet. Nous aurons probablement besoin de changer les autorisations et le propriétaire car les fichiers de base seront générés.

Installation

Lorsque vous suivez le lien vers le projet (https://github.com/Codeception/VisualCeption) vous verrez qu'il est nécessaire d'ajouter VisualCeption à composer.json ; cependant, si vous utilisez le docker-console, vous pouvez passer ce pas en toute sécurité. Assurez-vous que vous avez Imagick installé sur votre ordinateur (https://www.imagemagick.org/script/index.php) - il est utilisé pour comparer les captures d'écran. Il est maintenant temps de débloquer le module dans visual.suite.yml. Il faut également ajouter Webdriver (car il est utilisé pour automatiser les navigateur), donc à la fin, votre fichier de configuration devrait ressembler à celui présenté ci-dessous:

Vous pouvez définir les paramètres suivants dans la configuration de VisualCeption :

• referenceImageDir - VisualCeption stocke les captures d'écran précédentes pour pouvoir comparer l'état actuel de la page. Par défaut, il crée un nouveau dossier nommé 'VisualCeption' dans tests/_data.
• currentImageDir - à chaque exécution ultérieure du test, VC crée de nouvelles captures d'écran qui sont comparées à celles de référence, par défaut elles sont situées dans tests/_output/debug/visual/
• maximumDeviation - lors de la comparaison de deux captures d'écran, VC calcule une différence en pourcentage entre les images. Ce paramètre spécifie combien de différence est acceptable et ne donnera pas lieu à une erreur. Par défaut, il est défini à 0, ce qui signifie même le moindre changement provoquera une erreur.
• saveCurrentImageIfFailure - si cette valeur est définie sur true, en cas d'échec du test, l'état actuel de l'écran sera enregistré dans un fichier avec le préfixe "actuel".
• report - par défaut, cette option est définie sur false, mais dès que vous l'activez, toute défaillance générerera un rapport HTML trouvé dans tests/_output/vcresult.html. Nous vous montrerons à quoi il ressemble plus tard.
• module - ce paramètre détermine quel module est responsable de l'interaction avec le navigateur. Par défaut, il s'agit de WebDriver.
• fullScreenShot (par défaut : false) capture d'écran pleine page pour Chrome et Firefox.
• templateFile - chemin absolu ou relatif depuis le répertoire du module vers le modèle de rapport, par défaut "/report/template.php".

Chrome vs Firefox

Comme vous avez pu le voir auparavant, lors de l'exécution des tests en utilisant WebDriver, nous avons toujours utilisé Chrome ; cependant, dans ce cas, les auteurs de VisualCeption recommandent d'utiliser Firefox.

Nous suivrons cette recommandation pour vous montrer comment utiliser Firefox dans vos tests. De plus, cette configuration mettra en évidence toutes les capacités de ce module, mais vous êtes bien sûr libre d'expérimenter avec d'autres versions de Selenium et divers navigateurs.

Si vous voulez utiliser Firefox comme navigateur par défaut pour votre projet, vous devez apporter quelques modifications à la configuration de votre environnement. Tout d'abord, allez dans le dossier docker_console et trouvez dc_settings.py, où vous devez changer l'image Selenium par celle utilisée pour les tests.

 La ligne 'selenium_image': ('selenium/standalone-chrome', None), doit être remplacée par 'selenium_image': ('selenium/standalone-firefox:2.53.1', None). Nous écrirons plus sur la configuration d'un projet pour être en mesure d'utiliser plusieurs images Selenium dans un prochain article.

Maintenant que nous avons une image de Selenium avec Firefox configurée et prête, nous devons également changer le navigateur dans les fichiers de configuration des suites de tests utilisant Webdriver. Dans notre cas, il s'agit de visual.suite.yml et js_capable.suite.yml

Dans ce cas, vos tests seront exécutés en utilisant Firefox. Après ce changement, vous devez vous assurer que les tests écrits auparavant fonctionnent toujours correctement, car il peut s'avérer que le code de test nécessite également quelques correctifs - heureusement, tout s'est bien passé dans notre projet exemple et nous n'avons pas eu à corriger quoi que ce soit ici.

Si, vous voulez toujours utiliser Chrome pour vos tests et prendre une capture d'écran de toute la page. Vous pouvez utiliser l'option fullScreenShot dans la configuration de ce module ou pour chaque test, définir dynamiquement la hauteur de la page (cela fonctionne avec le docker, où la taille physique de l'écran ne nous limite pas).

Utilisation dans les tests

L'utilisation de ce module dans les tests est très simple car son fonctionnement est principalement basé sur deux fonctions supplémentaires :

•  seeVisualChanges, qui renvoie une erreur si aucune différence n'est trouvée sur la page et
•  dontSeeVisualChanges, qui renvoie une erreur s'il y a des différences visibles sur la page.

Ces deux fonctions peuvent être utilisées avec différents paramètres pour mieux déterminer ce que nous voulons vérifier sur une page donnée.

C'est pourquoi pour vérifier la page pour les changements visibles sur l'écran de l'utilisateur, nous allons écrire un test similaire à celui-ci :

 public function page(VisualTester $I) {
 	$I->wantTo('Test - compare homepage');
 	$I->amOnPage('/');
 	$I->dontSeeVisualChanges("homepage");
 }

Dans ce test, le paramètre "homepage" sera un nom unique pour la capture d'écran prise dans ce fichier, grâce à quoi VisualCeption saura quelles deux fichiers il doit comparer. Après avoir exécuté le test, nous obtiendrons une capture d'écran similaire à celle présentée ci-dessous :

Si vous voulez prendre une capture d'écran de toute la page, le test devrait ressembler à celui-ci :

 public function page(VisualTester $I) {
 	$I->wantTo('Test - compare homepage');
 	$I->amOnPage('/');
 	$I->dontSeeVisualChanges("homepage");
 }

Ce que nous avons fait ici, c'est ajouter un deuxième paramètre, un sélecteur CSS "#page", qui est un conteneur avec tout le contenu de la page. Les différences dans la zone à comparer seront facilement visibles dès que vous vérifierez la capture d'écran prise cette fois-ci.

Grâce à cette méthode, nous pouvons également suivre les changements dans les éléments plus petits de la page, comme l'en-tête ou le pied de page.

Une autre possibilité offerte par VisualCeption est d'exclure les éléments que nous ne voulons pas suivre sur la page. C'est une fonction très utile si par exemple vous voulez vérifier la disposition d'une page qui affiche une image sélectionnée au hasard, qui sera différente à chaque fois que la page est rechargée. C'est pourquoi si le test ressemble à celui ci-dessous, la capture d'écran ne contiendra pas la boîte de connexion.
 

public function notFullPage(VisualTester $I) {
 	$I->wantTo('Test - compare homepage not full page');
 	$I->amOnPage('/');
 	$I->dontSeeVisualChanges("homepage-not-all", "#page", "#block-user-login");
 }

Le dernier paramètre que nous pouvons ajouter au test est sa sensibilité aux changements sur la page - sa valeur par défaut a déjà été définie dans le fichier de configuration. Ici, nous pouvons augmenter ou diminuer le pourcentage de différences sur la page qui donnera lieu à une erreur lors de l'exécution de notre test. Un tel changement pourrait être utile si nous voulons vérifier le site pour des changements, mais l'une des pages contient un petit élément variable qui fait partie d'un ensemble plus grand et nous ne voulons pas l'exclure du test. Un exemple d'un tel élément peut être un compteur de visites - il affichera une valeur différente à chaque fois, mais cela ne signifie pas qu'il doit être exclu. Le test ci-dessous ne renverra une erreur que si les changements englobent plus de 5% de la page. 

public function deviation(VisualTester $I) {
 	$I->wantTo('Test - compare homepage deviation');
 	$I->amOnPage('/');
 	$I->dontSeeVisualChanges("homepage-deviation", "#page", "#block-user-login", 5);
 }

Rapports

Maintenant, lorsque nous avons déjà écrit plusieurs tests pour vérifier les changements de disposition sur la page principale, nous pouvons passer à leur première exécution, afin que les captures d'écran de référence soient prises. Les tests doivent être exécutés exactement comme les autres, en utilisant "dcon test", ou si vous êtes seulement intéressé par cette série, utilisez "dcon test visual" à la place.

Après la prise des captures d'écran de référence, vous pouvez changer quelque chose sur votre site web pour voir si vos tests fonctionnent. Pour mon exemple, je vais changer le titre de la page et relancer le test. Les trois premiers tests ont échoué, mais le quatrième n'a pas donné d'erreurs, malgré le changement de titre. C'est parce que nous avons écrasé la sensibilité du test - le pourcentage de changement était trop petit pour déclencher une erreur.

Bien sûr, vous pouvez vérifier quels types de tests ont entraîné quelles erreurs dans le fichier "raport.html", exactement comme avec d'autres tests. Il contient des informations sur tous les tests qui ont échoué, ainsi que le pourcentage de différence entre les pages comparées.

Avec de tels tests, ces informations peuvent ne pas être suffisantes. C'est pourquoi il y a un autre fichier à votre disposition - vcresult.html - contenant trois images sous le nom de chaque test échoué. La première image présente les différences trouvées lors de la comparaison, en marquant les pixels différant en rouge. Les deux images suivantes présentent un résultat attendu et actuel. 

Fichiers de projet

Vous pouvez exécuter les exemples décrits dans cet article en les téléchargeant à partir du dépôt du projet et en changeant la branche pour visualception.
Depôt du projet :
https://github.com/DropticaExamples/docker-console-project-example 
Dump de base de données :
https://www.dropbox.com/s/r0o3u9gjp3dccd4/database.sql.tar.gz?dl=0 
Fichiers de projet :
https://www.dropbox.com/s/hl506wciwj60fds/files.tar.gz?dl=0

Résumé

J'espère que cet article vous a donné envie d'essayer VisualCeption pour automatiser les tests de vos projets. Ce module est vraiment utile, surtout si votre projet est très sensible à tous les changements dans la mise en page. Après tout, il est bien connu qu'un humain qui vérifie la page peut avoir une mauvaise journée et passer à côté d'un petit changement apparemment insignifiant. Les tests automatisés suivront chaque modification au pixel près ; cependant, lors de la mise en œuvre de ces tests, vous devez garder à l'esprit qu'ils sont nettement plus lents (par rapport à d'autres types de tests) et qu'ils consomment beaucoup de mémoire.

Si vous avez aimé les tests Codeception, suivez notre blog, car ce n'est pas le dernier article sur ce sujet.