Innovations Techniques Au Service Du Test De Recette Automatisé

  • 2,241 views
Uploaded on

Présentation faite à l'USI 2009 sur l'état de l'art pour les tests de recette automatisés dans le monde Java.

Présentation faite à l'USI 2009 sur l'état de l'art pour les tests de recette automatisés dans le monde Java.

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
2,241
On Slideshare
0
From Embeds
0
Number of Embeds
4

Actions

Shares
Downloads
95
Comments
0
Likes
1

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 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
  • 7. Les tests fonctionnels pour… Tests fonctionnels automatisés
  • 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
  • 10. Axes d’analyse © OCTO Technology - Université du Système 10 d’Information
  • 11. Expressivité des tests © OCTO Technology - Université du Système 11 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
  • 13. Par exemple… © OCTO Technology - Université du Système 13 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
  • 15. Raconter une histoire avec un tableau © OCTO Technology - Université du Système 15 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
  • 18. Cucumber
  • 19. Cucumber
  • 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
  • 21. Maintenabilité © OCTO Technology - Université du Système 21 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
  • 23. Organisation • Organiser les tests © OCTO Technology - Université du Système 23 d’Information
  • 24. Usabilité © OCTO Technology - Université du Système 24 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
  • 28. Documentation des tests © OCTO Technology - Université du Système 28 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
  • 31. Intégration © OCTO Technology - Université du Système 31 d’Information
  • 32. Intégration à l’IDE © OCTO Technology - Université du Système 32 d’Information
  • 33. Au travers de JUnit
  • 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
  • 36. Rapports © OCTO Technology - Université du Système 36 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
  • 39. Synthèse © OCTO Technology - Université du Système 39 d’Information
  • 40. Synthèse © OCTO Technology - Université du Système 40 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
  • 42. Questions / Réponses © OCTO Technology - Université du Système 42 d’Information