Tests et automatisation : pourquoi et comment ? Ou comment j’ai été convaincu pour Selenium

Introduction

Aujourd’hui, j’ai eu la chance de participer à une séance de présentation et d’échanges, inter-services, autour du sujet « tests et automatisation » : vaste sujet !

La séance, proposée et animée par Laurent, était sur la forme de « forum ouvert » (« open space » pour les anglophones), un peu préparé pour guider la séance.

Une introduction, avec quelques généralités sur les tests, a permis d’introduire les termes comme JUnit, Selenium, Jenkins, Sonar, … ainsi que d’aborder très rapidement la question « pourquoi des tests ? » en évoquant : la sérénité, la non-régression, le codage plus rapide, etc …

Ensuite Laurent a proposé et présenté plusieurs sujets, auxquels les participants en ont ajouté quelques uns. Après une séance de vote (type « buy a feature »), une première session avec 2 ateliers en parallèle s’est mise en place :

• Présentation et démonstration Sonar
• Les tests, par quoi commencer ? Selenium et/ou JUnit
  et/ou Jenkins ? 

Connaissant un peu Sonar, je me suis orienté vers le 2e atelier, d’autant plus que les membres de l’équipe que j’accompagne y étaient, et que le sujet est plus d’actualité pour ma mission.

Les tests, par quoi commencer ? Selenium et/ou JUnit et/ou Jenkins ?

Pour commencer, Arnaud a pris la parole pour préciser ce que sont chacun de ces outils et leurs usages. J’ai complété son intervention avec mon expérience plus portée sur  JUnit et Jenkins. Les questions/réponses ont permis d’être assez précis en élargissant les échanges sur des notions connexes. En résumé :

• Différents niveaux de tests :
• Les tests unitaires, bas niveaux, par et pour les développeurs, déclinaisons découpées des critères d’acceptation d’une histoire
• Les tests fonctionnels, « de bout en bout », haut niveau, plus à la charge des personnes du métier, donc compréhensibles par ces acteurs fonctionnels, qui devraient être capables de les écrire eux-mêmes, si possible avant la phase de développement (objectif) (1)
• JUnit est un framework permettant de faire des tests unitaires en Java : tests écrits en Java pour tester du code Java. JUnit apporte essentiellement des méthodes permettant de comparer des résultats générés à des résultats attendus (système d’ « assertions »), et en cas de différences, de générer des erreurs explicites. Il permet d’exécuter les jeux de tests, et il peut être intégré à un IDE ou à un système d’intégration continue (2)
• Selenium est un outils permettant de « piloter » un navigateur WEB pour dérouler des scénarios sur des pages WEB, avec des actions comme : ouvrir la page à telle adresse (url), cliquer sur un bouton ou un élément, insérer du texte dans un champ, récupérer le contenu (texte) d’un élément, etc … Couplé à JUnit qui permettra, grâce aux assertions, de vérifier les résultats obtenus, l’ensemble permet de faire des tests fonctionnels haut-niveau pour des rendus d’application à interface WEB 

En allant à cet atelier, j’avais ma réponse à la question « par quoi
commencer ? » : JUnit bien sûr ! Mais les premières interventions d’Arnaud m’ont surpris, puisqu’avec son équipe, ils ne font pas de tests unitaires, mais uniquement des tests Selenium. Arnaud évoque une expérimentation non convaincante de JUnit , et un retour sur investissement rapide et important avec Selenium : tout le contraire de ma vision sur le sujet !

Les nombreux échanges qui ont suivi, sur base des questions de l’auditoire, ont permis de comprendre cette différence d’approche, et de préciser certains concepts sur lesquels nous étions finalement tous en phase, ouf ! :

• Les tests « JUnit » (tests unitaires bas niveau) et les tests « Selenium » (fonctionnels, haut niveau) sont complémentaires et surtout pas à opposer
• Les tests JUnit sont bien adaptés lorsqu’il y a algorithmie, manipulations de données, exploitation ou génération de fichiers dans des formats précis, etc … Ils permettent de tester facilement et rapidement des cas particuliers, ou des situations difficiles à produire
• Les tests Selenium quant à eux sont incontournables dès que l’on veut tester une interface WEB, sous forme de scénarios, et vérifier le fonctionnement « de bout en bout » de l’application
• Techniquement, ces outils ne sont pas compliqués à prendre en main, même s’ils nécessitent bien sûr un peu d’investissement pour être mis en place, mais il faudra surtout prévoir du temps pour l’apprentissage par l’équipe pour modifier ses pratiques, et écrire des tests, en TDD et BDD bien sûr ! L’entraide et l’accompagnement permettront d’accélerer cet apprentissage, pour écrier les « bons » tests, mais pour sa montée en compétence, l’équipe devra passer par un minimum d’expérimentations et de difficultés à résoudre et surmonter 

Après son atelier Sonar, Laurent nous a rejoint pour la fin de nos échanges. Nous avons pu alors rappeler la pyramide des tests qui met en évidence, tout de même, la nécessité d’avoir une assise importante de tests unitaires, pour pouvoir y ajouter un quantité plus modérée de tests d’intégration, et une quantité réduite de tests fonctionnels.

Nous avons également pu comprendre pourquoi Arnaud et ses équipiers ne font pas de tests unitaires : leur application est essentiellement une interface WEB en connexion directe, ou presque, avec une base de données, pour présenter les données et en insérer avec des formulaires. Dans ce cas, le code métier sur le serveur est effectivement très réduit, et avec une architecture MVC, les opportunités de mettre en palce des tests unitaires sont limitées et peu « rentables ». J’ai été confronté à cette situation récemment, j’en ai dédéuit certaines hypothèses, et aujourd’hui, j’en ai eu confirmation.

Démonstration JUnit et Selenium

La séance s’est poursuivi par un atelier collectif autour de présentations plus techniques de JUnit et Selenium, sur base de démonstration, de présentation et d'explications de codes par Joël.

Contrairement aux précédentes versions que j’avais un peu manipulées, la dernière version de Selenium est beaucoup plus évoluée et simple à manipuler (exemple : recherche semi-automatique d’éléments DOM par annotations d’attributs de classe). L’assemblage de Selenium et JUnit m’est également apparu plus évident que lors de mes précédentes approches. J’avoue avoir été convaincu par la possibilité d’un véritable retour sur investissement, comme évoqué par Arnaud !

Mes expérimentations ne tarderont pas !

J'ai également beaucoup aimé le concept de "Page Object Pattern", basé sur la factorisation du code, et son encapsulation dans du langage métier, ce qui permettra de plus facilement impliquer les fonctionnels.

Conclusion

En un mot : génial !

J’ai du partir avant la fin (bus et train), je n’ai donc pas pu participer au ROTI final, mais le mien est sans hésiter de 5 ! En quelques heures, j’ai pu partager mes expériences et mes visions sur le sujet, j’ai appris plein de trucs, j’ai mis à jour mon information sur certaines technos (notamment Selenium) et j’ai échangé avec un groupe super chouette, motivé, et ouvert, le tout sur des sujets d’actualités et super passionnant : What else ?!

Donc, un grand merci à tous et bien sûr, plus particulièrement, à Laurent, Arnaud, et Joël !

(1) NDLA : Entre ces 2 types de tests, on en trouve d’autres, à différents niveaux, comme par exemple les « tests d’intégration » 
(2) NDLA : Pour un auditeur en grande partie novice sur le sujet, et pour une première approche, le sujet des mocks n’a pas été abordé, mais il devra l’être car indispensable !