Rex E2E

REX un an de testing E2E

• EBIA ALLIANCE = XEBIA + XEBIALABS + THIGA + UX REPUBLIC

XL Release

2

• Un outil de release management • Un mélange entre Jenkins et Trello


3

• Début au studio en mars 2013 • V1 en septembre 2013 • Online trial en janvier 2014

Quelques dates et chiffres

• 32 sprints de deux semaines • 4000+ commits • 21 000+ lignes de Java • 8 000+ lignes de JavaScript • 8 000+ lignes de Html/Less


4

• Approche ATDD dès le début • ATDD : Acceptance test driven development

Le Test sur XL Release

• 400+ tests E2E • 1000+ TU Java • 900+ TU JS

E2E Unit


5

• CasperJS • Basé sur PhantomJS

Choix du framework E2E en 2013

• ZombieJS • Émule un navigateur web en JS

• Karma + Angular Scenario • Prévu pour AngularJS • Permet de tester sur des vrais navigateurs


6

Javascript ou bien ?

CoffeeScript !• Parce que c’est plus facile à lire • Parce que c’est plus facile à écrire • Parce que c’est plus simple pour faire des

classes


7

• Interactions minimalistes • Assertions CSS

Comment tester en E2E ?


8

• Mocker le backend ? • Ou bien tester aussi le backend ?

Et le backend ?

• Pour XL Release : approche ATDD • -> On teste aussi le backend


9

Au début un script d’insertion de données

Oui, mais alors les données ?

• Très rapidement, cela devient une gageure • Les tests dépendent entre eux • Il est impossible de lancer un seul test • Les merges des données de tests :(


10

Insertion des données locale à chaque test :

Oui, mais alors les données ?

Suppression automatique à la fin du test

Via une API de fixtures dédiée


11

• Au début : c’est très rapide • Et puis ça devient lent… 15 secondes par

test

Et ça va vite ?

• Comment aller plus vite : • Ne faire que de la navigation in-page :

pas de rafraîchissement complet • Utiliser Chrome : c’est plus rapide que

PhantomJS !


12

Demo time !


13

• Cauchemar de maintenance :

Quand les tests se compliquent


14

• À l’utilisation :

Le pattern “Page object”


15

Implémenter un “Page object”


16

Le “Page object” +BDD +Rend les tests plus lisibles +Permet de séparer le test métier de son

implémentation dans la page HTML +Facilite la factorisation des interactions et

des assertions

- Ne produit pas d’erreurs plus faciles à lire


17

• Formulaires

Les features qui se testent bien


18

• Monitoring temps réel

Les features plus difficiles à tester


19

• Dates

Les features plus difficiles à tester


20

• Le Drag & Drop

Les features très dures à tester


21

• Deployit/XL Deploy, Jenkins, Jira • Mocké avec un NodeJS + Express

• LDAP • Mocké avec NodeJS + LdapJS

-> Node Fake API lancé pendant les tests

Et les dépendances externes ?


22

La triche• Comment “hi-jacker” certains services

AngularJS pendant les tests :


23

Protractor ?• Fin 2013 : • Angular Scenario stagne • Protractor devient l’outil recommandé • Tous nos tests (300+) sont écrits pour

Karma / Angular Scenario • Que faire ?


24

Angular Scenario VS Protractor

• Angular Scenario est simple : il pilote une application AngularJS dans une IFrame via JQuery

• Protractor est basé sur WebDriverJS, lui même basé sur Selenium : il pilote le navigateur via le driver Selenium


25

Angular Scenario VS Protractor

• Très rapide • Simpliste

• Plus lent • Plus riche : • Permet le D&D • Permet les

captures d’écran


26

Protractor comment le vendre ?• Notre PO réussit à vendre le passage à

Protractor pour un nouveau besoin : • Générer automatiquement les captures

d’écran de la documentation !


27

Protractor : les difficultés• Protractor n’aimait pas trop CoffeeScript

au début • Protractor tourne dans NodeJS : un niveau

d’asynchronisme en plus • Lenteurs :

• Pour le même test : • 3/4 secondes avec Angular Scenario • 7/10 secondes avec Protractor


28

Protractor : comment y passer ?• S’appuyer sur le “page object” • Ré-implémenter nos pages objects pour

Protractor • Ré-utiliser les tests

• Ré-implémenter le mécanisme de fixtures en Node

• Make it work !


29

Demo time !


30

Captures d’écran automatisées


31

Captures d’écran automatisées


32

Captures d’écran automatisées• Interroger les dimensions de chaque

composant via JQuery • Calculer le rectangle englobant • Capturer toute la page avec Protractor • Demander à Image Magick de retailler

l’image en fonction des dimensions


33

Captures d’écran automatisées• Au final ? +Un jeu de données stable : des captures

qui suivent les évolutions du produit +Des captures avec des dates à jour!

- Nécessite de refaire une vérification manuelle sur les captures.

- Race condition sur le cropping à résoudre !


34

Notre avis sur Protractor+ Projet assez actif et réceptif aux PRs ~ Beaucoup plus réaliste : ne permet pas de

prendre des raccourcis : clic sur un élément invisible

~ Asynchronisme avec Angular JS - Déboggage assez difficile :

• Trop verbeux ou pas assez: parfois pas d’affichage du sélecteur CSS en erreur

- Performances


35

Le testing E2E+ Efficace

• Permet de tester les cas nominaux d’une User story

+ Assez stable aux changements dans l’interface

- Sensible aux problèmes de concurrence : • Attention aux “Heisentests” !


36

Le testing E2E- Coûteux en temps de build :

• > 20 minutes pour 400 tests • Ne tester que les cas nominaux, les cas

particuliers sont à tester unitairement !


37

Questions

?

Merci!

Software

Rex E2E