Visuellement correct - Tests de non régression visuels automatisés - Pycon FR 2015

Talk given @pyconfr 2015

Après avoir écrit des tests unitaires pour les parties métier de notre code, nous avons souhaité ajouter un autre niveau de vérifications automatisées : les tests de différences visuelles. Ce vieux rêve des développeurs web consiste à comparer visuellement les pages web d'une source reconnue comme fiable (baseline) avec la version que l'on s'apprête à déployer. Il est ainsi possible de vérifier l'impact des nouvelles fonctionnalités sur une nouvelle version, s'assurer de la non régression, et une fois l'impact visuel éventuel accepté, établir une nouvelle baseline pour non régression future. Cette présentation décrit des cas concrets dans lesquels ces types de vérifications présentent de l’intérêt. Nous verrons ensuite l’architecture et le workflow que nous avons adoptés afin de relever le défi, à l’aide d’une librairie python nommée dpxdt développée chez Google. Nous terminerons par un retour d’expérience sur les interactions avec notre système d’intégration continue, des pistes d'amélioration, et les limites du procédé.

Transcript

1. OFUOH OFUOH VISUELLEMENT CORRECT : TESTS DE NON RÉGRESSION VISUELS AUTOMATISÉS Yann Gravrand Pycon FR 2015 - Pau
2. ›  Net-ng - Rennes 20 pers Applications métier en Python Forte orientation web Framework web open source : www.nagare.org Présentation
3. Applications web modernes ›  Dans le web, le visuel est important ! ›  Zone de contact du produit avec l’utilisateur ›  Les temps de mise en ligne se veulent raccourcis… ›  … Sans sacrifier la qualité du rendu ›  Or la « stack » est complexe ›  Besoin de se rassurer
4. ›  Ce que les tests habituels ne « voient » pas… ›  … on le fait avec des tests « exploratoires » ›  Inconvénients du manuel Tardif ! plus de lien avec le dev Répétitif ! rébarbatif surtout si sprints courts Dépendant de l’attention aux détails de chaque personne ›  A améliorer pour ne garder que la valeur ajoutée de l’humain Comment se rassure-t-on
5. ›  Gestion de « boards » : projet, TODO list… Exemple : Net-ng/kansha
6. Exemple de régression > git log --oneline f5410c5 Fixed switch-zone position on calendar view.  
7. Exemple : impact sur tablette
8. Exemple : impact sur mobile
9. Exemple : une autre page sur tablette
10. Exemple : une autre page sur mobile AARG  !!  
11. Vous  
12. Votre  client  
13. ›  Classiquement on teste la fonctionnalité, pas tous ses effets de bord ›  Pourquoi des effets de bord visuels ? Technologie : règles et surcharges dans les CSS Comportement Responsive Problème généricité / spécificité ›  Comment faire ? Structure / bon sens / sensibilisation designers (re-use) / évaluation des risques Revue de code CSS – Pull Request Et … Pourquoi ce type de problème ?
14. ›  1) Capture d’une IHM dans un 1er état ›  2) Capture dans un 2e état ›  3) Comparaison et examen des différences Principe des tests visuels
15. ›  Pas des « tests unitaires » : Très orientés calculs métier / rouages internes et pas rendu Cas prévus par le développeur : on ne teste que ce que l’on peut imaginer… ›  Ni vraiment des « tests d’acceptance » : On teste un comportement business, des fonctionnalités Ou encore la robustesse, les performances On définit des scénarios, des exigences C’est quoi alors ces tests
16. ›  Des tests à la recherche de l’imprévu Côté systématique Cherchent « le trou dans la raquette » Rien à écrire, peu de stratégie Pas captivants Augmentent la confiance globale Orientés utilisateur final C’est quoi alors ces tests
17. ›  « Pixel perfect » Exigence client élevée ›  « Meta » Système de templates, skins, multi sites, approches meta ›  Fragiles Historique de régressions imprévisibles ›  Travail collaboratif ›  A livraisons fréquentes Pour quelles applications
18. ›  Un moyen d’investiguer Rechercher l’origine d’un bug visuel ›  Un moyen de mesurer les impacts visuels Si utilisation dans les Pull Requests L’outil est aussi…
19. github.com/bslatkin/dpxdt 1049 ★ Github ›  Mode simple : screenshot d’URL ›  Fichier de config yaml URL(s) de test, résolution à utiliser, JS à injecter… ›  dpxdt update . Crée une « baseline » : screenshots des URLs avec PhantomJS ›  dpxdt test . Compare à la « baseline » : diff avec Imagemagick Dpxdt (« Depicted »)
20. github.com/ygravrand/pyconfr2015/ex1 ›  Direct run : Installer PhantomJS, Imagemagick Créer un virtualenv et l’activer ›  Pour ne pas s’embêter avec les deps : Exemple 1 : capture simple > pip install dpxdt > dpxdt update .   > ./capture_using_docker.sh.  
21. Exemple 1 : capture simple setup: | echo dummy waitFor: url: https://twitter.com/pyconfr tests: - name: twitter_pyconfr url: https://twitter.com/pyconfr config: viewportSize: width: 1024 height: 768 - name: twitter_pyconfr_mobile url: https://twitter.com/pyconfr config: viewportSize: width: 320 height: 768 # Twitter puts a min-width on regular user agents, so emulate mobile a little bit userAgent: iPhone  
22. Exemple 1 : capture simple Desktop   Mobile  
23. github.com/ygravrand/pyconfr2015/ex2 ./capture_each_commit.sh ›  On cherche l’origine du bug graphique vu précédemment ›  Pour chaque commit, capture et diff avec le précédent ›  Techniquement Dpxdt est installé dans un container docker L’appli tourne dans un autre container docker Un script shell parcourt les commits et lance les captures Exemple 2 : capturer chaque commit
25. Exemple 2 : diff du commit incriminé Avant   Après   Diff  
26. ›  Parfois, les modifications trouvées par l’outil sont très subtiles Intérêt des diff Avant   Après   Diff  
27. ›  Parfois, les modifications trouvées par l’outil sont très subtiles Intérêt des diff
28. ›  Un client lui soumet des demandes de captures & de diff Possibilité de crawler une URL de base ›  Une IHM permet de les visualiser et les accepter Dpxdt : le serveur
29. Dpxdt : release en cours de test
30. Dpxdt : visualisation de diff
31. Dpxdt : workflow suggéré URL  1   URL  2   URL  3   CréaAon  d’une  baseline   pour  un  commit  donné   Marquage  release  «  good  »   URL  1   URL  2   URL  3   Nouvelle  capture  avec  un  autre   commit  choisi   Examen  et  acceptaAon  des  diff   Dev…  
32. Dpxdt : workflow cible avec Pull Requests URL  1   URL  2   URL  3   URL  1   URL  2   URL  3   master   Commits  sur   feature  branch   AcceptaAon  PR  :   revue  des  diff   URL  1   URL  2   URL  3   AutomaAsaAon  capture   +  diff  avec  baseline  master   Baseline  master   IntégraAon  conAnue  :   nouvelle  baseline  master  
33. Techniquement URL  1   URL  2   URL  3   URL  1   URL  2   URL  3   master   X  feature  branches   testées    indépendamment   avec  dpxdt   1  appli  dokku  par  branche   1  appli  dokku  dpxdt   Test  différé  en  nocturne   URL  1   URL  2   URL  3   Appli  master  déployée  sur  dokku   CréaAon  baseline  avec  gitlab  ci  
34. ›  Adaptations nécessaires pour de bons screenshots Idempotence nécessaire Désactiver animations, carrousels, … Désactiver ressources externes : partage réseaux sociaux, fonts, … Désactiver stats ›  Où ? Dans l’appli Avec des scripts JS exécutés par PhantomJS Retours d’expérience (1)
35. ›  Echecs techniques Plantages PhantomJS ! le système réessaye X fois Plantages serveur dpxdt ! supervisord avec redémarrage auto (ticket déposé) Retours d’expérience (2)
36. ›  Limites de l’outil de capture Pas de scénarios évolués, seulement des URLs Webkit uniquement ›  Faux positifs Demandent du temps d’analyse Disparaissent si on les traite systématiquement Retours d’expérience (3)
37. ›  Complexité Système plus ou moins complexe à mettre en place selon le degré d’automatisation souhaité N’investissez dans la solution pour les petits projets Retours d’expérience (4)
38. ›  Tests focalisés sur composants d’IHM PhantomCSS ›  Pouvoir ignorer certaines parties Ex : captcha, google maps, … IHM de création de masques ? Pistes d’amélioration
39. ›  Huddle/PhantomCSS ›  3209 ★ Github JS, CasperJS, {Phantom | Slimer}JS, Resemble.js ›  Needle 409 ★ Github Python, Selenium ›  BackstopJS 727★ Github Node, PhantomJS, CasperJS ›  BBC-News/Wraith 3235 ★ Github Ruby, {Phantom | Casper | Slimer}JS Alternatives non testées
40. ›  Continuous Delivery – Jez Humble, David Farley ›  http://pchiusano.github.io/2014-07-02/ css-is-unnecessary.html A lire
41. ›  Questions ? @ygravrand github.com/ygravrand/pyconfr2015 github.com/Net-ng/kansha Merci de votre attention