jeudi 9 janvier 2014

Inventaire des frameworks Javascript

javascriptCeci n'est pas un scoop, Javascript explose. Il est loin le temps des petits bouts de code pour afficher une boîte d'alerte dans une page. Depuis, il y a eu AJAX et maintenant, il existe une multitude de framework pour faire pleins de choses. Je vais reporter ici (et tenir à jour) mes notes concernant les différents frameworks et outils Javascript au fur et à mesure de mes investigations....

Lire la suite...

dimanche 24 février 2013

Documentation de code ExtJS

sencha

Vous connaissez le site de documentation ExtJS ? Vous voulez faire la même chose pour votre code ? C'est possible grâce à JsDuck.

Pour un démarrage rapide, il suffit d'installer ruby, gem et JsDuck:

 # gem install jsduck

puis de lancer l'outil sur votre code:

 $ jsduck --output votre/docs

On peut également utiliser un fichier de configuration json pour personnaliser tout ça (option --config).

Dans votre code, il suffit d'ajouter des commentaires du type:

 /**
  * commentaire d'objet, méthode ou attribut
  ...
  */

et d'utiliser certaines annotations du type

 @param {type} nom description ....

ou

 @return {type} description

Lisez la documentation pour plus de détails

dimanche 25 novembre 2012

Publication de cucumber-json2report

Cuke

Première publication d'un afficheur de rapport web utilisant la sortie JSON de cucumber-jvm, comme alternative à cucumber-reporting:

Voir sur github, pour une description détaillée des fonctionnalités et des captures d'écran.

jeudi 28 juin 2012

Subversion et les dépôts externes

Logo subversion

Subversion offre une manière intéressante d'inclure le contenu d'un dépôt dans un autre dépôt. C'est très utile, par exemple, lorsque vous avez un dépôt avec des routine génériques que vous voulez utiliser dans plusieurs projets sans avoir à dupliquer le code commun dans chacun de ces dépôts (pour des raisons évidentes de maintenabilité).

Attention, il s'agit ici de code commun et, en aucun cas de dépendances. Il existe des outils pour gérer les dépendances dans de multiples langages (Maven, Ivy, Gradle pour Java, PEAR pour PHP ....). Ces dépendances n'ont rien à faire dans le dépôt d'un gestionnaire de code source.

Attention (bis): l'utilisation de cette fonctionnalité crée, d'une certaine manière, une dépendance à Subversion, tous les outils de gestion de source ne la possédant pas (toutefois, Git possède un mécanisme similaire...).

En utilisant la propriété svn:externals, vous pouvez indiquer à subversion de récupérer le contenu d'un dépôt externe dans un répertoire donné.

Lire la suite...

dimanche 22 avril 2012

Traduction française du manuel PHPUnit

PHP

La traduction française du manuel PHPUnit est à consulter sur le site officiel.

Ce manuel comporte, outre la mise en œuvre technique de PHPUnit, des considérations méthodologiques très intéressantes. Il aborde notamment la question des tests unitaires, du TDD, du Behaviour Driven Development, des tests fonctionnels avec Selenium et des tests de bases de données.

N'hésitez pas à me remonter les erreurs ou coquilles que vous pourriez y trouver ...

jeudi 22 mars 2012

JUnit 4 en 60 secondes

junit-logo.png

Comme l'actualité est calme, voici la traduction un peu enrichie d'un article d'introduction à JUnit 4 à consulter ici.

JUnit 4 apporte à JUnit la gestion des annotations pour les tests Java. Voyons-en quelques unes....

@Test

Permet de marquer vos tests. Vous n'avez alors plus besoin de préfixer vos cas de tests avec "test". De plus, votre classe n'a plus besoin d'hériter de la classe “TestCase”.

  @Test
  public void addition() {
     assertEquals(12, simpleMath.add(7, 5));
  }
  
  @Test
  public void subtraction() {
     assertEquals(9, simpleMath.substract(12, 3));
  }

@Before et @After

Utilisez respectivement les annotations @Before et @After pour les méthodes “setup” et “tearDown”. Ces méthodes sont exécutées respectivement avant et après chaque cas de test.

  @Before
  public void executerAvantChaqueTest() {
     simpleMath = new SimpleMath();
  }

Ici, on vient de préparer le "monde" du test.

  @After
  public void executerApresChaqueTest() {
     simpleMath = null;
  }

Et là, on nettoie une fois le test exécuté.



@BeforeClass et @AfterClass

Utiliser respectivement les annotations @BeforeClass et @AfterClass pour les méthodes “setup” et “tearDown” s'appliquant à la classe toute entière. Pnsez à ces méthodes comme étant à usage unique. Elles s'exécutent respectivement et une seule fois avant le premier cas de test et après le dernier cas de test.

  @BeforeClass
  public static void executeBeforeClass() {
     // s'exécute une unique fois 
     //avant le premier cas de tests
  }
  @AfterClass
  public static void executeAfterClass() {
     // s'exécute une unique fois pour toute
     //  après le dernier cas de tests
  }

Gestion des exceptions



Utilisez le paramètre “expected” avec l'annotation @Test pour indiquer que le cas de test s'attend à une exception. Donnez le nom de l'exception qui va être lancée.

  @Test(expected = ArithmeticException.class)
  public void divisionAvecException() {
     // division par zero
     simpleMath.divide(1, 0);
  }

@Ignore



Ajouter l'annotation @Ignore pour les cas de tests que vous voulez ignorer. Vous pouvez ajouter comme paramètre une chaîne de caractères qui indique la raison pour laquelle vous ignorez le test.

  @Ignore(“Pas prêt à fonctionner”)
  @Test
  public void multiplication() {
     assertEquals(15, simpleMath.multiply(3, 5));
  }

Timeout



Définit un délai d'expiration en millisecondes avec le paramètre “timeout”. Le test échouera si le délai est atteint.

  @Test(timeout = 1000)
  public void infinity() {
     while (true)
     ;
  }

Nouvelles affirmations

Ces nouvelles affirmations permettent de comparer des tableaux. Deux tableaux sont égaux seulement s'ils ont la même longueur et si chaque élément de l'un est égal à l'élément correspondant de l'autre.

  public static void assertEquals(Object expected, Object actual);
  public static void assertEquals(String message, Object expected, Object actual);
  @Test
  public void listEquality() {
     List expected = new ArrayList();
     expected.add(5);
     
     List actual = new ArrayList();
     actual.add(5);
     
     assertEquals(expected, actual);
  }

JUnit4Adapter

Permet d'exécuter vos tests JUnit 4 dans les lanceurs de tests JUnit 3 avec le JUnit4Adapter

  public static junit.framework.Test suite() {
     return new JUnit4TestAdapter(SimpleMathTest.class);
  }

samedi 17 mars 2012

Manuel Thucydides en français

Thucydides

Pour faire suite à ce billet et en réponse aux 42 questions que vous vous posez sûrement sur les tests fonctionnels avec Thucydides, la vie, l'univers et tout le reste, je vous propose la traduction de mon crû du manuel utilisateur de cet excellent outil qui ne nécessite même pas d'ordinateur de la taille de la terre ...

A lire ici, et là en version originale et enfin là pour les sources....

N'hésitez pas à signaler les coquilles & erreurs !

Allez, salut et encore merci pour le poisson !

PS: devinez-donc le numéro de ce billet ....

mercredi 22 février 2012

Hamcrest, tutoriel pour Java

Java

Hamcrest est une bibliothèque d'objets de correspondance ('matchers' ou contraintes ou encore prédicats) permettant de définir des règles de 'correspondance' de façon déclarative, utilisables dans d'autres frameworks. Typiquement, on l'utilisera avec des frameworks de test, des bibliothèques d'objets bouchons (mock objects) et des règles de validation d'interface utilisateur.Par exemple, au lieu d'écrire:

   assertEquals("bleu", couleur);

On écrira:

   assertThat(couleur,is("bleu"));

On note ici le gain immédiat de lisibilité (surtout en anglais)...

Hamcrest a été implémenté pour Java, PHP mais aussi C++, Objective-C, Python et Erlang. Naturellement, avec Java, on pourra gérer cette dépendance via Maven.

Une version d'Hamcrest est fournie avec JUnit. Cependant, elle date un peu et les versions plus récentes d'Hamcrest offrent un tas de nouvelles fonctionnalités, en particuliers pour travailler avec les collections. Vous pouvez utiliser la dernière version d'Hamcrest en utilisant la dépendance junit-dep à la place de junit, comme suit:

  <dependency>
      <groupId>junit</groupId>
      <artifactId>junit-dep</artifactId>
      <version>4.10</version>
      <scope>test</scope>
      <exclusions>
         <exclusion>
              <groupId>org.hamcrest</groupId>
              <artifactId>hamcrest-core</artifactId>
          </exclusion>
      </exclusions>
  </dependency>
  <dependency>
      <groupId>org.hamcrest</groupId>
      <artifactId>hamcrest-library</artifactId>
      <version>1.3.RC2</version>
  </dependency>

junit-dep est exactement la même bibliothèque que junit, exception faite que ses dépendances sont explicitement déclarées et non incluse dans le bundle.....

Notez enfin que Hamcrest n'est pas une bibliothèque de test comme JUnit ou TestNG, mais bien une bibliothèque d'objets de correspondance destinés à rendre les tests implémentés avec les bibliothèques précédentes beaucoup plus lisibles.

Ce qui suit est la traduction du tutoriel Java que l'on peut lire sur le wiki du site de Hamcrest. On pourra également lire ce billet de John Smart.

Lire la suite...

jeudi 9 février 2012

Selenium Grid pour Selenium 1 et WebDriver

selenium-grid-logo.png

La grille Selenium permet

  • de répartir la charge en distribuant les tests sur plusieurs machines (exécution parallèle)
  • de gérer de multiples environnement depuis un point central en facilitant l'exécution de tests sur une grande variété de navigateurs et d'OS
  • de réduire le temps de maintenance de la grille en permettant d'implémenter des déclencheurs personnalisés pour mettre en place une infrastructure virtuelle par exemple

Démarrage rapide

L'exemple qui suit montre comment lancer le Hub Selenium 2 et d'y enregistrer à la fois un noeud WebDriver et un ancien noeud Remote Control Selenium 1. Sera également montrée la façon d'appeler la grille en Java. Le hub et les noeuds seront lancés sur la même machine mais il est bien sûr possible de copier le selenium-server-standalone sur plusieurs machines.

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...

samedi 4 février 2012

Test d'une application Web avec Thucydides

Thucydides

L'objet de cet article, inspiré fortement par le guide utilisateur de Thucydides, et de mettre en place des tests de validation fonctionnelle sur une application Web à l'aide de Thucydides, donc, et de WebDriver/Selenium 2. Thucydides est une bibliothèques OpenSource destinée à faciliter ces tests de recette, en utilisant, soit JUnit, soit EasyB.

Lire la suite...

mardi 31 janvier 2012

php-webdriver

selenium-logo.png PHP

PHPWebDriver (https://github.com/Element-34/php-w...) est un fork de projet Facebook php-webdriver (https://github.com/facebook/php-web...) avec quelques différences:

  • distribution via PEAR
  • ajoute de la classe WebDriverWait
  • ajout de ActionChains
  • interface nettoyée pour réduire le couplage avec l'implémentation de WebDriver

Ce fork résulte de l'insatisfaction de son auteur avec les autres implémentations PHP. Pour mémoire, aucune de ces implémentations n'est officiellement soutenue par Selenium. Évidemment, c'est libre et distribué sous la licence Apache 2 (comme le reste de la suite Selenium). L'auteur offre un support commercial et une correction prioritaire des bugs (http://element34.ca/blog).

Ce qui suit est la traduction de la documentation actuellement fournie....

Lire la suite...

dimanche 29 janvier 2012

Gherkin

Cuke

Ce qui suit est la traduction de https://github.com/cucumber/cucumbe... augmenté de détails spécifiques à notre belle langue.

Gherkin est le langage parlé par Cucumber. C'est un langage spécifique au domaine (Domain Specific Language) compréhensible par les gens du métier qui vous permet de décrire le comportement d'un logiciel sans détailler comment ce comportement est implémenté.

Gherkin répond à 2 objectifs – documentation et tests automatisés. Le troisième est une fonctionnalité bonus – quand il crie en rouge, il vous parle et vous indique le code que vous devriez écrire.

La grammaire de Gherkin est définie dans l'arbre Treetop qui est une partie du code de base de Cucumber. La grammaire existe dans différentes variantes pour de nombreuses langues (40 actuellement) de telle sorte qu'on peut utiliser des mots clefs dans sa propre langue.

Lire la suite...

samedi 28 janvier 2012

Utiliser Selenium 2 avec Maven

selenium-logo.png Logo Maven

Traduction de l'article de Michael Tamm sur le blog Selenium.

Il y a plusieurs façon d'utiliser Selenium 2:

Si vous n'avez pas de code datant de Selenium 1.x, utilisez directement les nouvelles implémentations WebDriver telles que ChromeDriver, HtmlUnitDriver, FirefoxDriver ou InternetExplorerDriver qui fournissent une API agréable, légère et facile à apprendre.

Si vous avez ce type de code, vous pouvez continuer à utiliser la désormais célèbre classe DefaultSelenium ou la nouvelle WebDriverBackedSelenium qui hérite de la précédente mais utilise en interne l'une des implémentation WebDriver.

Lire la suite...