Innovations Techniques Au Service Du Test De Recette Automatisé

Innovations techniques au service du test de recette

automatisé

Rémy SanlavilleExpert Senior en Ingénierie Logicielle Orange [email protected]

Emmanuel HugonnetArchitecture [email protected]

Hervé LourdinArchitecte Sénior / Coach agileOCTO [email protected]

Contrat de la session

• Cette session a pour objectif : – Faire l’état des lieux en terme de technologies pour les tests de

recettes automatisés depuis ces 4 dernières années

• Cette session s’adresse à :– Tous: développeurs, testeurs, maîtrise d'ouvrage: Geek et Boss

– A des personnes qui savent ce que sont les tests fonct. auto.

• A la sortie de cette session vous aurez : – Découverts de nouveaux outils

– Identifié les limites des outils actuels

– Pris connaissance des nouveaux axes d’innovation autour des tests fonctionnels automatisés

© OCTO Technology - Université du Système d’Information 2

Agenda

• Un bref rappel de la situation…• Innovations autour des tests de recette automatisés• Synthèse• Conclusion


Un bref rappel de la situation…


Les Tests

Fonctionnel

Technique

ProduitEquipe

Les Tests

Fonctionnel

Technique

ProduitEquipe

Les tests fonctionnels pour…

Tests fonctionnels automatisés

Acceptance Test Driven Development

© OCTO Technology - Université du Système d’Information 8ATDD cycle model by Jim Shore with changes suggested by GrigoriMelnick, Brian Marick, and Elisabeth Hendrickson

Innovations autour des tests de recette automatisés


Axes d’analyse


Expressivité des tests


Dites-le avec un tableau !


Utilisateur Mot de passe Message

jdoe elephant Echec !

dgray wilde1890 Echec !

dcooper d1ane4ever! Succès !

. . . . . . . . .

Par exemple…


Dites-le avec un tableau

• Historiquement le format proposé par les outils les plus avancé à ce jour

• Le format tabulaire est simple et autoportant• Il permet de formaliser la majorité des cas de tests• C’est un format idéal pour tester des fonctions dites

« sans état »

• Langages supportés : Java / Ruby / C# / Python / SmallTalk


Raconter une histoire avec un tableau


Behaviour Driven Development

• Nouvelle forme expressive des tests– Définir l’intention d’une fonctionnalité par l’exemple


Etant donnée … [ un contexte ]

Quand … [ un événement ]

Alors… [ un état attendu ]

Etant donnée … [ un contexte ]

Quand … [ un événement ]

Alors… [ un état attendu ]

Etant donné un nouvel Utilisateur BartLorsqu'il crée un compte avec un mot de passe p@ssw0rdAlors le message 'SUCCESS' apparait

Et lorsqu'il s'authentifie avec Bart / p@ssw0rdAlors le message 'Hello Bart' apparait

Etant donné un nouvel Utilisateur BartLorsqu'il crée un compte avec un mot de passe p@ssw0rdAlors le message 'SUCCESS' apparait

Et lorsqu'il s'authentifie avec Bart / p@ssw0rdAlors le message 'Hello Bart' apparait

BDD – A new Generation

• Tests d'Acceptance• Prise en compte du reste

de l'équipe• Extraction des scénarios

• Evolution syntaxique de TDD

• Orienté développeur• Tout est dans le code

Cucumber

Cucumber

Behaviour Driven Development

• Constats : – Bon formalisme pour définir des enchaînements d’évènements

(workflow)– Formalisme amenant naturellement fonctionnels & développeurs

à spécifier ensemble par l’exemple– Peine à trouver son public

• Format encore très orienté développeurs

• Cependant l’outillage tend à se rapprocher du monde des profils fonctionnels


Maintenabilité


Twist: fusion IDE et tests

• Le système de saisie des tests et l’environnement de développement du code de tests sont distincts– Le refactoring (ex : changement du nom du test) est douloureux– Aide à la réutilisation


Organisation

• Organiser les tests


Usabilité


Usabilité

• Les premiers outils (Fit / Fitnesse) sont difficiles d’accès pour les acteurs ciblés (fonctionnels / testeurs)

– Wiki sans éditeurs WYSIWYG– Contraint à apprendre le

langage wiki– Ne permet pas facilement de

documenter les tableaux de tests


Usabilité

• Toujours un wiki, mais déjà plus accessible :


Twist , vers une meilleure usabilité

• Les plus : – Un IDE dédié à l’écriture des

tests– Des facilités pour les

refactoring de tests

• Les moins : – Approche encore trop

centrée sur l’IHM• Selenium (Webapps)

• Franckenstein (Swing)


Documentation des tests



• L’ATDD prend le parti de spécifier par les tests mais peu d’outils permettent de les documenter


Exemple de GreenPepper


• Exemple de Concordion :– Format HTML

– Nécessite de travailler avec un éditeur HTML

– Toujours pas convenable pour un acteur fonctionnel


Intégration


Intégration à l’IDE


Au travers de JUnit

Intégration à la Gestion de Configuration


ProductionSprint N-1

DéveloppementSprint N

Quels Tests pour quel code ?

MétierSprint N + 1

Intégration aux forges logicielle

• Intégration dans l'outil de Build pour pouvoir exécuter les tests d'acceptance sur le poste du développeur et le serveur d'intégration continue


Rapports


Rapports

• C’est aujourd’hui une des carences majeures des outils de tests fonctionnels automatisés

• Les rapports sont quasi inexistants et demandent aux projets de les implémenter eux même en fonction des métriques qu’ils souhaitent mettre en place

• Les équipes ont besoin de rapports pour suivre leur évolution au fil du projet – couverture des exigences,

– Suivi des régressions

– …


Rapports : Historisation des tests


• L’historisation des tests joués et de leurs résultats est le seul réel rapport disponible à ce jour dans Fitnesse…

Synthèse


Synthèse


Conclusion

• On distingue deux grandes familles de tests fonctionnels qui adressent respectivement :– Les fonctionnalités sans état facilement testable par des grilles de

tests– Les fonctionnalités intégrant un workflow d’actions

• L’approche BDD se prête bien à ce type de tests

• Le nombre d’outils augmente de plus en plus

• Cependant aucun ne regroupe l’ensemble des fonctionnalités nécessaires– Fitnesse / Slim semble à ce jour le produit qui vit le plus et voit son

nombre de fonctionnalités grossir plusieurs fois par semestre !


Questions / Réponses
