Rien de prévu mardi prochain ? Rejoignez nous pour la première de la marmite, LA soirée récurrente des duchesses ! J’aurais l’occasion d’animer avec Brice Dutheuil, commiter Mockito, un Hands-On sur la mise en place de tests avec Mockito et comme il y en a pour tous les gouts chez les duchesses, on a également prévu en parallèle un open-space pour échanger sur les sujets qui vous intéressent !

Qu’est-ce qu’un open space ? C’est un peu comme un barCamp à part que les sujets sont présentés au début et que l’on ne traite que les sujets les plus populaires pendant un temps limité. Le but essentiel est de partager et de débattre. Tous les sujets autour de Java et de l’IT sont les bienvenus. Pour vous donner des idées, voici quelques pistes possibles :

• une problématique technique que vous avez rencontrée
• un super outil qui a changé votre vie de développeur
• votre sujet de veille préféré
• ou une problématique relationnelle (ex: comment travailler avec une personne au caractère difficile ?).

Pour vous inscrire a l’Hands-On ou a l’open-space

Plus d’infos

On a vu dans la première partie que l’on pouvait faire facilement du data-driven testing et que la syntaxe en bloc apportait beaucoup en lisibilité. Les blocs expect/where que l’on a vu sont les plus adéquats lors de cas de tests simples, où l’on peut facilement exprimer le stimulus et son résultat, typiquement monojbetA.maMethode()==monResultat. Dans le cas où l’on se retrouve face à des tests un peu plus compliqués, l’utilisation de la structure given/when/then est alors préférable. Cet article n’a pas pour vocation de comparer les fonctionnalités des trois frameworks, juste de présenter spock et de comparer la syntaxe des trois frameworks dans le cas de tests ‘classiques’.
Read more »

Au cours de mes tribulations, je suis tombée sur un nouveau framework de test : Spock, basé sur Groovy & JUnit.  Il est facile à prendre en main et est beaucoup moins verbeux que certains autres framework de tests même quand on ne maitrîse pas Groovy. Les tests sont structurés à l’aide de blocs  given/when/then et setup/expect/where ce qui permet d’améliorer la lisibilité et l’écriture. Ce framework est à suivre, il est rapidement pris en main mais il manque encore certaines fonctionnalités avancées. Cet article est le premier d’une série de trois, il permettra de comparer spock à d’autres frameworks similaires.
Read more »

Qui n’a jamais attendu de nombreuses minutes pour builder un projet ? Et qui n’en a jamais profité pour aller boire un café/regarder twitter/… ? Parce que l’on teste fréquemment, il est important d’essayer d’optimiser et de réduire la durée d’exécution des tests.  Tester souvent ne veux pas dire attendre souvent ! Il est donc primordial d’essayer de réduire cette durée en jouant sur différents paramètres. Comment obtenir le résultat des tests le plus rapidement possible ?

Ce qui suit est tiré de la conférence de David Gageot [ @dgageot / http://javabien.net ] à SoftShake 2010.

Sur une vingtaine de personnes présentes dans la salle, les durées de build vont de quelques minutes à plusieurs heures. David présente brièvement quelques frameworks comme Infinitest et JUnitMax. Ce sont des plugins pour IDE Java qui permettent de lancer les tests unitaires en continu et de manière intelligente, c’est à dire uniquement ceux impactés par le code modifié.
La première idée lorsque l’on cherche à optimiser cette durée d’exécution, c’est de vouloir déléguer le problème. C’est faire  tourner les tests sur des serveurs distribués qui permettront d’exécuter les tests en tâches de fond. C’est une mauvaise idée, les serveurs coûtent chers et on peut se retrouver submerger. Il existe des méthodes plus simples pour réduire cette durée.

Le KISS ( Keep It Simple, Stupid ) est également applicable lorsque l’on crée des tests. Chercher à optimises ses tests peut améliorer votre produit : ce qui est simple à tester sera simple à coder et à utiliser. Ce qui est compliqué n’en vaut surement pas la peine. Read more »

Le test unitaire est un test qui provoque l’exécution d’une partie du code et qui l’analyse.  Il permet de garantir que le code exécuté fonctionne correctement. Il se doit donc d’être automatisé et répétable. Pour cela, cela nécessite fréquemment le besoin d’isoler le test unitaire des systèmes extérieurs (base de données, appels web-service distants).

Pour ce faire, il existe plusieurs méthodes, l’utilisation de bouchon (‘stub’) ou de simulacre (‘mock’). L’article de référence est un article de Martin Fowler « Les simulacres ne sont pas des bouchons« . Pour résumer, une méthode bouchonnée est appelée sur un objet bouchon réel, centré sur le système testé. Il ne peut jamais faire échouer le test. On regarde l’état de l’objet final à la fin du test et non les étapes qui ont permis d’obtenir cet état. C’est un test basé sur des états. Read more »

EasyMock est un framework de test qui peut dérouter dans un premier abord. Une fois qu’on a compris comment l’utiliser, on tombe sur un certain nombre d’erreurs qui reviennent très souvent et qui ne sont pas souvent explicites. Même si EasyMock 3.0 a clarifié un certain nombre d’erreurs, cet article (fait sous la 2.5.2) servira de pense-bête à ceux qui débutent avec ce framework. Read more »

J’ai participé hier à la deuxième édition du kawa barcamp. Un bar camp c’est une rencontre ouverte autour de thèmes choisis par les participants. Nous étions hier une trentaine de personnes réunis pendant environ 3 heures. Après un bref tour de table où nous nous sommes présentés (nom + prénom + 3 mots clés), 8 personnes ont inscrits des thèmes d’ateliers sur un tableau. Nous devions choisir parmis 2 sujets au choix : Read more »

« java.lang.IllegalStateException: 1 matchers expected, 2 recorded » est une exception bien connue du développeur utilisant EasyMock. Elle veut tout simplement dire que lorsque l’on utilise un matcher (genre eq,anyObject …) il faut en utiliser pour tous les paramètres de la méthode, j’y reviendrai plus en détail dans un prochain article. Ainsi :

expect(maMethode("XYZ","BZT")).andReturn("XXX")
// est correct tout comme :
expect(maMethode((String)anyObject(),eq("BZT"))).andReturn("XXX")
// mais pas :
expect(maMethode((String)anyObject(),"BZT")).andReturn("XXX")

Sauf que mon erreur du jour, c’est que cette expression arrive sur la méthode :
« expect(formatServiceMock.scale(eq(BigDecimal.valueOf(10)))).andReturn(c) » qui elle est correcte a première vue.

Read more »

Lundi  12 avril avait lieu dans les locaux de Xebia une présentation sur « les applications Java et la production » animée par Cyrille Le Clerc. Cette formation de  deux heures était très intéressante, si le sujet vous intéresse et que vous êtes sur Paris, ils en refont une le lundi 26 avril http://training.xebia.fr/soiree-les-applications-java-et-la-production.
Cinq pôles principaux ont été abordés :  les bonnes pratiques autour du déploiement, la supervision et le monitoring, la gestion des logs, la question de la robustesse et les bonnes pratiques organisationnelles. Seul le déploiement sera abordé dans cet article, la suite suivra !
Cyrille Le Clerc est architecte EE depuis 11 ans, dont 6 ans passé chez IBM Global Services et un peu plus de 3 ans chez Xebia.

Read more »