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

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é.

9a53fbe79231c78c893f258af967096e?s=128

Yann Gravrand

October 18, 2015
Tweet

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
  24. None
  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