Weitere ähnliche Inhalte Ähnlich wie Innovations Techniques Au Service Du Test De Recette Automatisé Ähnlich wie Innovations Techniques Au Service Du Test De Recette Automatisé (20) Mehr von Emmanuel Hugonnet Mehr von Emmanuel Hugonnet (15) Innovations Techniques Au Service Du Test De Recette Automatisé1. Innovations techniques
au service du test de recette
automatisé
Emmanuel Hugonnet Hervé Lourdin
Architecture J2EE Architecte Sénior / Coach agile
Silverpeas OCTO Technology
emmanuel.hugonnet@silverpeas.com hlourdin@octo.com
Rémy Sanlaville
Expert Senior en Ingénierie Logicielle
Orange Labs
remy.sanlaville@orange-ftgroup.com
2. 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
2
d’Information
3. Agenda
• Un bref rappel de la situation…
• Innovations autour des tests de recette automatisés
• Synthèse
• Conclusion
© OCTO Technology - Université du Système
3
d’Information
4. Un bref rappel de la situation…
© OCTO Technology - Université du Système
4
d’Information
5. Les Tests
Fonctionnel
Equipe Produit
Technique
6. Les Tests
Fonctionnel
Equipe Produit
Technique
8. Acceptance Test Driven Development
ATDD cycle model by Jim Shore with changes suggested by GrigoriMelnick, Brian Marick, and Elisabeth Hendrickson
© OCTO Technology - Université du Système
8
d’Information
9. Innovations autour des tests de recette
automatisés
© OCTO Technology - Université du Système
9
d’Information
12. Dites-le avec un tableau !
Utilisateur Mot de passe Message
jdoe elephant Echec !
dgray wilde1890 Echec !
dcooper d1ane4ever! Succès !
. . . . . . . . .
© OCTO Technology - Université du Système
12
d’Information
14. 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
14
d’Information
16. Behaviour Driven Development
• Nouvelle forme expressive des tests
– Définir l’intention d’une fonctionnalité par l’exemple
Etant donné un
nouvel Utilisateu
Bart r
Etant donnée … [ un contexte
Lorsqu'il crée u
mot de passe p@
n compte avec u
n
] Alors le messag
ssw0rd
e 'SUCCESS'
apparait
Et lorsqu'il s'au
thentifie avec Ba
Quand … [ un événement ]
p@ssw0rd
Alors le messag
rt /
e 'Hello Bart' ap
parait
Alors… [ un état attendu ]
© OCTO Technology - Université du Système
16
d’Information
17. BDD – A new Generation
• Evolution syntaxique de • Tests d'Acceptance
TDD • Prise en compte du reste
• Orienté développeur de l'équipe
• Tout est dans le code • Extraction des scénarios
20. 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
20
d’Information
22. 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
22
d’Information
25. 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
25
d’Information
26. Usabilité
• Toujours un wiki, mais déjà plus accessible :
© OCTO Technology - Université du Système
26
d’Information
27. 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
27
d’Information
29. 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
© OCTO Technology - Université du Système
29
d’Information
30. 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
30
d’Information
34. Intégration à la Gestion de
Configuration
Production Développement Métier
Sprint N-1 Sprint N Sprint N + 1
Quels Tests pour quel code ?
© OCTO Technology - Université du Système
34
d’Information
35. 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
35
d’Information
37. 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
37
d’Information
38. 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…
© OCTO Technology - Université du Système
38
d’Information
41. 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
41
d’Information