themetest

Des études empiriques le prouvent le développement piloté par les tests (TDD pour les intimes) améliore notablement la qualité des logiciels. Cet article écrit par Nachiappan Nagappan (de chez Microsoft), E. Michael Maximilien (IBM), Thirumalesh Bhat (Microsoft), and Laurie Williams (North Carolina State University), et publié dans le journal Emperical Software Engineering Volume 13, Number 3.
L'article présente les résultats de quatre équipes variées(3 de Microsoft, 1 d'IBM) dans un contexte professionnel qui ont mis en œuvre les pratiques du TDD et ont observé une réduction du nombre de bugs par 1000 lignes de code de 40% à 90% pour une surcharge de développement de 15% à 35%.
Cette étude confirme les retours d'Allianz lors de l'Agile Tour 2008 qui annonçait une surcharge de développement de 15% à 20%.
Alors en attendant que mon patron m'offre une licence JUnitMax je vais aller écrire mes tests.

Dans le cadre du CARA, nous organisons un Coding Dojo à Grenoble.
Mais qu'est ce donc que cela: il s'agit d'un lieu d'entrainement (d'où le terme de dojo) pour pouvoir étudier, tester et apprendre des techniques et des langages de code. Fini la prise de risque sur un projet, venez vous entrainer dans un lieu sûr, sans risque, entouré des meilleurs professionnels de la région (c'est à dire vous ;o) ).
Attention il ne s'agit pas d'une formation 'classique' avec un professeur et des élèves attentifs, ici tout le monde participe et tout le monde s'enrichit !!!

• Vous rêvez d'apprendre Ruby sous Linux mais vous codez votre projet en C#.
• Si vous parlez de langage fonctionnel à votre chef de projet il va vous regarder avec des yeux comme des soucoupes.
• Si TDD vous évoque T'es Dans la Déprime sur un projet en cycle en V.
• Si vous voulez vivre des sensations eXtrem Programming.

Bref, si ces phrases vous interpellent c'est qu'il est temps de venir nous rejoindre.

Les informations et l'inscription se passent ici.

Il y a un plus d'un an je participais à l'aventure Mon Service Public et je réalisais avec quelques uns le kit d'intégration SSO pour l'administration française selon les protocoles de la Liberty Alliance.
Aujourd'hui notre code passe enfin en production :o)
Quelques liens qui en parlent :
Le site Mon Service Public
Le Sénat
Monde Public.

Un sacré projet qui nous a permis de valider pas mal de concepts et d'affiner les procédures de développement chez Orange Labs. Alalala la constructon d'artefacts multi-JDK sous Maven2, fut un poème ;o)
Bon week-end

Vendredi soir j'ai pu participer à mon premier DOJO de code grâce à deux étudiants brésiliens d'Alfredo Goldman : Hugo et Mariana.
Mais qu'est ce qu'un dojo de code me direz vous ?
Ironiquement c'est un concept français qui revient dans nos contrées. En effet le premier dojo fut créé à Paris (il est d'ailleurs toujours en activité) par Laurent Bossavit.
Vendredi soir, nous étions donc une petite dizaine dans une salle de l'Ensimag encore allumée en ce mois de vacances. Pour commencer le sujet proposé était une introduction à Ruby et au Test Driven Developpement (via rspec).
L'audience était consistuée à la fois de membres du laboratoire qui nous accueillait ainsi que de quelques développeurs que j'oserai qualifier de professionnels ;o).
Une bonne ambiance qui nous a fait ainsi entrer dans le monde Ruby. C'était en tout cas un réel plaisir d'apprendre ainsi.
Alfredo j'attends avec impatience les supports et les liens afin qu'on puisse remettre cela à la rentrée.

Les aller-retours permanents entre le code et la documentation sont pour moi une perte de temps et d'énergie (Muda selon Lean). D'ailleurs c'est pour cette raison qu'XP préconise de réduire au maximum la documentation et de la faire au plus près du code.
Qui n'a pas utilisé le retro-engineering des outils UML pour produire les diagrammes nécessaires plutôt que de les maintenir au fur et à mesure du développement ?
D'où l'idée qui coniste à produire automatiquement la documentation à partir du code, ainsi on aurait une documentation continue et toujours en adéquation avec le code. C'est d'ailleurs ce que propose Paul Duvall dans son dernier article "Automation for the people: Pushbutton documentation".
Dans le même esprit j'avais déjà expérimenté UMLGraph mais cela restait laborieux. L'outil Apiviz semble un pas en avant vers la bonne solution. J'espère le tester rapidement ;o)
Bon week-end.

Ce modèle pour caractériser l'acquisition des connaissances (essentielle dans la capitalisation d'une équipe Agile) semble avoir le vent en poupe dernièrement dans le monde informatique.
Andy Hunt célèbre pour son The Pragmatic Programmer: From Journeyman to Master explique sa vision dans l'interview suivante :

Pour plus d'informations :

• Le site de l'interview


• Pragmatic Thinking and Learning: Refactor Your "Wetware"

Je travaille actuellement avec Jackrabbit. J'utilise spring-modules ce qui me permet de facilement instancier mon repository. Cependant comment avoir un repository pour mes tests unitaires. Grâce à ce post j'ai un respository de test tout simple.
Voici donc les éléments clefs de mon fichier de configuration :

<FileSystem
class="org.apache.jackrabbit.core.fs.mem.MemoryFileSystem">
<param name="path" value="${rep.home}/repository" />
</FileSystem>

et

<PersistenceManager
class="org.apache.jackrabbit.core.persistence.mem.InMemPersistenceManager">
<param name="persistent" value="false" />
</PersistenceManager>

et voilà :)

Une petite vidéo intéressante où l'on donne des trucs et astuces pour faire accepter à sa direction de prendre en compte la qualité :

Comment tester une application J2EE 1.3 (et oui :-(( ) hors conteneur. Heureusement que l'on trouve pas mal de projets sympathiques sur le web :

• Je conseille fortement Mock Javamail pour tester l'envoi et la réception de mail, il est très très simple d'utilisation et facilite grandement la vie.


• L'implémentation FileSystem de JNDI permet d'avoir un espace de nommage très facilement.


• Enfin pour la partie plus J2EE j'ai utilisé Mockrunner même si les factories ne sont pas compatibles JNDI et qu'il faille ajouter une instance d'ObjectFactory.
  Sans oublié les classes de tests de base que fournit Spring et qui sont un plaisir notamment pour les DAOs).

Si on couple tout cela à EasyMock on est capable de faire du TDD correctement.

Un petit séminaire que j'ai contribué à animer m'a encore une fois convaincu que le Test Driven Development est la voie à suivre pour un code de qualité et un confort de développement inégalable.
Je profite de ce petit mot pour chanter les louanges d'Hudson qui est un outil formidable combiné avec Maven2 et les plugins Violations et Findbugs qui fournissent ce qui manque à Maven et son site: un historique de l'état du code.