samedi 7 février 2015

Attendre qu'une page ExtJs soit chargée avec Selenium

Moonraker

Il existe pleins de frameworks de tests d'IHM en Javascript, et notamment pour faire du test fonctionnel ou BDD. Outre cucumber-js, on trouve aussi l'excellent Yadda qui a le bon goût d'avoir une localisation en français... Et plus encore, on trouve le formidable Moonraker qui propose une solution complète clef en main: Yadda plus mocha, WebDriverJs et Chai et, cerise sur le pompon: des page objects !

Mais avec ExtJs, quand on met un splashscreen pendant le chargement et la création de la page, on a un problème: comment cliquer sur un élément seulement quand le splashscreen a disparu ?

Lire la suite...

lundi 6 février 2012

Petite synthèse sur le Behaviour Driven Development

Voici une petite synthèse de mon crû sur le BDD

  • les noms des méthodes de test doivent être des phrases en langage métier
  • les noms des méthodes de test doivent commencer par doit ou doivent (ou Should)
  • si une classe fait plus d'une chose, il faut introduire d'autres classes pour faire une partie du travail: injection de dépendance
  • si un test échoue après changement du code, soit:
    • un bug a été introduit: corriger le bug
    • le comportement attendu reste pertinent mais s'est déplacé: déplacer le test en le modifiant éventuellement
    • le comportement attendu n'est plus pertinent: supprimer le test
  • ne pas parler en terme de test mais en terme de comportement
  • rechercher la chose la plus importante (en terme de valeur métier / business value) que le système ne fait pas encore et la réaliser
  • le comportement d'une Story est un critère de validation
  • les story sont décrites comme suit:
   En tant que {X}: le bénéficiaire
   Je veux {Y}: la fonctionnalité (feature)
   Afin que {Z} : le bénéfice
  • Les stories sont détaillées sous forme de scénarios:
   Étant donné/ Given : le contexte initial
   Quand / Lorsque / When: un unique événement se produit
   Alors / Then: on vérifie qu'on obtient les résultats attendus
  • Les Given et les Then peuvent être multiples en utilisant Et / And
  • Le When est unique
  • Ces 3 parties de scénario sont codables et doivent être capitalisées / réutilisées
  • Dans les premières itérations, on y utilise des bouchons / mock qui seront supprimés au fur et à mesure

Ceci permet de répondre aux questions usuelles

  • qu'est-ce qu'un test ? une phrase décrivant le prochain prochain comportement qui vous intéresse
  • combien de tests dois-je faire ? cf. point précédent, juste pour vérifier la phrase du point précédent
  • que faire quand un test échoue ? appliquer la procédure vue plus haut

Introduction au Behaviour Driven Developement

Traduction de l'article de Dan North: http://dannorth.net/introducing-bdd... paru pour la première fois dans Better Software Magazine en mars 2006 et publié ici avec son aimable autorisation.

J'avais un problème. Quand on utilise ou qu'on enseigne les pratiques agiles telles que le développement dirigé par les tests (TDD) sur des projets dans différents environnements, on rencontre toujours la même confusion et les mêmes difficultés de compréhension. Les programmeurs veulent savoir par où commencer, ce qu'il faut tester et ce qu'il ne faut pas tester, combien de tests doivent être exécutés en une fois, ce qui lance leurs tests et comment comprendre pourquoi un test échoue.

Plus on va profondément dans TDD, plus on a l'impression que le processus d'apprentissage est moins un processus d'amélioration progressive de sa maîtrise qu'une suite de tâtonnement et d'essais/erreurs. On arrive plus fréquemment à se dire : "si seulement quelqu'un m'avait dit ça avant" que "Eureka, une porte s'est ouverte". D'où la décision qu'il doit être possible de présenter le TDD d'une façon qui va directement aux bonnes choses et évite les écueils.

Une réponse est le Behaviour Driven Development (BDD). Il a émergé des pratiques agiles établies et est conçu pour les rendre plus accessibles et efficaces pour les équipes peu aguerries à la livraison de code agile. Au fil du temps, BDD a grandi pour englober une vision plus large de l'analyse agile et du test d'acceptation (de recette) automatisé.

Lire la suite...

Qu'y a-t'il dans une histoire (une Story) ?

Le Behaviour-driven development (BDD ou développement dirigé par le comportement) est une méthodologie « extérieur-intérieur ». Il démarre à l' extérieur en identifiant les produits métiers puis pénètre dans les fonctionnalités (« features ») pour déterminer qui réalise ces produits. Chaque fonctionnalité est capturée dans une « story » qui définit la portée de cette fonctionnalité en même temps que les critères d'acceptation. Cet article est une introduction à l'approche BDD qui définit et identifie les histoires et leurs critères d'acceptation.

Ce qui suit est la traduction de l'article de Dan North : http://dannorth.net/whats-in-a-stor..., publiée ici avec son aimable autorisation.

Les termes fréquemment usités dans le domaine seront également signalés en anglais.

Introduction

La livraison de code consiste à écrire du code qui produit des résultats métiers. Cela semble évident, mais souvent des facteurs politiques ou environnementaux nous conduisent à l'oublier. Parfois, la livraison de code peut sembler ne consister qu'à réaliser des rapports optimistes permettant de s'assurer de la bonne humeur des responsables projet ou juste à simplement maintenir les gens occupés pour garantir de conserver les effectifs existant, mais c'est un autre sujet.

En général, les attendus métiers sont trop génériques pour pouvoir être utilisés directement pour écrire du code (où commencer à coder quand l'attendu est « économiser 5% de mes frais de fonctionnement »?), aussi nous avons besoin de définir des exigences à un niveau intermédiaire afin de pourvoir faire le travail.

Le Behaviour-driven development (BDD) prend le parti que vous transformez simplement et efficacement une idée d'exigence en code implémenté, testé et prêt pour la production tant que les exigences sont suffisamment spécifiques pour que tout le monde comprenne de quoi il retourne. Pour ce faire, nous avons besoin d'un moyen de décrire les exigences de telle sorte que tout le monde – les fonctionnels, les analystes, les développeurs et les testeurs – ait une compréhension commune de la portée du travail. A partir de là, ils peuvent se mettre d'accord sur une définition commune de « terminé » (« done ») et nous échappons aux pièges mentaux du découragement (« gumption traps ») du « ce n'est pas ce que j'avais demandé » et « j'ai oublié de vous dire quelque chose ».

Ceci, alors, est le rôle de l'histoire (« Story »). Elle doit être une description d'une exigence et du bénéfice métier associé assortie d'un ensemble de critères grâce auxquels on pourra s'accorder sur le fait que l'exigence est satisfaite, donc que le travail spécifié est terminé (« done »). Ceci constitue une définition plus rigoureuse que celle que l'on trouve dans d'autres méthodologies où elle est diversement décrite comme « la promesse d'un dialogue » ou « la description d'une fonctionnalité ». (Une histoire BDD peut aussi facilement décrire une exigence non fonctionnelle du moment que le travail peut être cadré, estimé et validé par tous).

Lire la suite...