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 Labsremy.sanlaville@orange-ftgroup.com

Emmanuel HugonnetArchitecture J2EESilverpeasemmanuel.hugonnet@silverpeas.com

Hervé LourdinArchitecte Sénior / Coach agileOCTO Technologyhlourdin@octo.com

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

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

Un bref rappel de la situation…

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

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

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

Axes d’analyse

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

Expressivité des tests

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

Dites-le avec un tableau !

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

Utilisateur Mot de passe Message

jdoe elephant Echec !

dgray wilde1890 Echec !

dcooper d1ane4ever! Succès !

. . . . . . . . .

Par exemple…

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

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

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

Raconter une histoire avec un tableau

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

Behaviour Driven Development

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

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

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

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

Maintenabilité

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

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

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

Organisation

• Organiser les tests

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

Usabilité

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

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

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

Usabilité

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

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

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)

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

Documentation des tests

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

Documentation des tests

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

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

Exemple de GreenPepper

Documentation des tests

• Exemple de Concordion :– Format HTML

– Nécessite de travailler avec un éditeur HTML

– Toujours pas convenable pour un acteur fonctionnel

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

Intégration

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

Intégration à l’IDE

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

Au travers de JUnit

Intégration à la Gestion de Configuration

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

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

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

Rapports

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

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

– …

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

Rapports : Historisation des tests

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

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

Synthèse

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

Synthèse

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

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 !

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

Questions / Réponses

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