Notre quotidien de développeur consiste très souvent à modifier du code existant. Certes, nous avons parfois la chance de développer de nouveaux modules tout frais, tout neufs et le Test Driven Development est à son avantage.

Mais comment peut-on mettre en pratique le TDD sur du code déjà écrit, parfois mal pensé et non testé. Cet article va partir d’un exemple concret, une classe comme on pourrait en trouver sur tous les projets. Le but est de commencer une démarche TDD et de pousser au maximum son efficacité (mise en évidence d’un bug potentiel, ajout d’une nouvelle fonctionnalité, refactoring du code et refactoring des tests). Au final, la classe sera beaucoup plus apte à subir le changement et surtout, elle sera testée et couvrira tous les cas d’utilisation.

Lire la suite de cet article »

Le 4 Juin 1996, à 9h35 le vol 501 de la fusée Ariane 5 effectue son premier décollage. Quelques secondes plus tard, le système de guidage inertiel reçoit trop d’informations et se met hors service, car reconnu défaillant. L’ordinateur de bord est alors notifié qu’un dysfonctionnement est en cours et compromet les informations concernant la trajectoire de la fusée. Cette modification de la trajectoire entraîne l’arrachage d’un moteur d’appoint, déclenchant l’auto destruction de la fusée. Des analyses plus approfondies ont démontré que le système de guidage inertiel est lui même la cause de cet échec. Conçu à l’époque pour Ariane 4, il n’était plus nécessaire pour Ariane 5. Maintenu actif pour des raisons de commodité, ce système s’est avéré être à l’origine d’un des bugs informatiques les plus coûteux de l’histoire.

Au-delà du caractère spectaculaire de cet exemple, il est intéressant de noter que l’origine du dysfonctionnement réside dans un module développé pour une version antérieure de la fusée et devenu obsolète. Ce vestige de code, maintenu dans l’application sans être nécessaire pour son fonctionnement, est l’une des formes de ce que Ward Cunningham désigne sous le terme de dette technique.

A travers ce document, nous découvrirons en quoi la dette technique ralentit la productivité des équipes et nuit aux projets. Nous mettrons en évidence ses mécanismes sous jacents et les leviers d’actions dont nous disposons. Enfin, nous montrerons comment elle se gère au quotidien, par l’instauration de bonnes pratiques de développement et la mise en place d’outils, pour enfin aborder quelques stratégies complémentaires, mais essentielles pour venir à bout de la dette technique.

Télécharger le Livre blanc « Maîtrisez votre dette technique ».

L’évangéliste pragmatique du software craftsmanship, Robert Cecil Martin alias Uncle Bob était l’invité d’honneur de Xebia pour un atelier software craftsmanship sur le code propre (a.k.a Clean Code).

Pendant 2 jours, se sont succédés conseils pratiques, prises de conscience (« aha… »), analogies originales, discussions sur l’industrie à l’heure du repas, randori TDD, kata, coding dojo, décortication minutieuse de classes, effacement de nombreuses lignes de code inutiles et ses fameuses diversions scientifiques (de la mitochondrie au réchauffement du soleil). Tout ça saupoudré d’une expérience de 40 ans dans l’industrie logiciel aux Etats-Unis.

Instants choisis.

Lire la suite de cet article »

Ceci est une fiction. Toute ressemblance avec des personnes existant ou ayant existé serait totalement fortuite.

Palais de justice de Paris, lundi 21 mars.

Une fois n’est pas coutume, des développeurs sont assis sur le banc des accusés! Ils sont inculpés de faire perdre des millions d’euros à nos chères compagnies du CAC40 en écrivant du code voué à crouler sous son propre poids.

Mr Tedd, praticien du Test Driven Development, est aujourd’hui jugé ainsi que quelques uns de ses collègues : Mr Whatever, Mr Guru, Mrs Clickaway et Mr Testafter.

Prévoyant et confiant, il sera défendu par son avocat : Maître Darrow. Ils ont convenu ensemble de la stratégie à adopter: il faudra pointer du doigt les mauvaises habitudes souvent utilisées et mettre en avant les bonnes pratiques qu’il a appliqué tout au long des projets qui lui ont été confiés.

Lire la suite de cet article »

La testabilité est devenue un facteur à prendre en compte lors du choix d’un composant technique. Pour les EJB 3.0, il existait plusieurs manières de tester des services développés, Ejb3unit (figé depuis mi-2009) ou Arquillian (uniquement côté JBoss AS). Les EJB 3.1 offrent enfin une solution native, prête à l’emploi et simple à manipuler : l’EJB Container.

Cet article présente l’utilité de l’EJB Container et la manière de l’utiliser ; il s’appuie pour cela sur l’écriture d’un service et d’une suite de tests exécutables sur Glassfish 3 et sur JBoss 6.

Lire la suite de cet article »

Nous avons le plaisir de vous présenter notre livre blanc sur la qualité logicielle écrit par Frédéric Dubois, avec la participation de Séven Le Mesle.

Objet du désir, la qualité logicielle est régulièrement invoquée sur le mode incantatoire au démarrage d’un projet de développement logiciel.

Assurance qualité, direction qualité, responsable qualité, qualimétrie, processus unifié, modèle de maturité… nombreux sont les dispositifs visant à garantir que le résultat du développement sera source de fierté pour ceux qui l’ont conçu, de contentement pour ceux qui l’ont financé, de soulagement pour ceux qui devront le maintenir et de satisfaction pour ceux qui l’utilisent et l’exploitent.

Dans un premier temps, ce livre blanc s’attache à définir ce qu’est la qualité logicielle, et à analyser les raisons de son évanescence. Il décrit ensuite un ensemble de pratiques d’ingénierie qui, selon nous, et appliquées de façon systématique, permettent d’écrire, à moindre coût, des logiciels de très haute qualité

Nous espérons que vous prendrez plaisir à le lire.

Télécharger le Livre blanc qualité logicielle.

Quand on est en phase de développement et que l’on pratique le TDD, il est nécessaire de connaître certaines méthodes pour éviter la répétition, une fatigue des doigts évidente et ainsi améliorer son rendement.

Nous essayerons dans cet article de montrer l’ergonomie d’Eclipse et l’utilisation du clavier pour rendre plus courte et plus agréable une session TDD. Nous présenterons quelques plugins Eclipse et aussi un outil souvent négligé que sont les templates de codes.

Un pattern sera introduit pour faciliter l’utilisation des objet métiers et POJO dans les tests.

Enfin, nous présenterons le concept important du Continuous Unit Testing appliqué à l’IDE et indiquerons et comparerons les plugins Eclipse pour le mettre en œuvre.

Lire la suite de cet article »

Les tests unitaires sont largement répandus et leur utilisation est facilitée grâce à des outils matures tels que JUnit, Unitils, ou les apis de Mocking. Au contraire, la pratique des tests fonctionnels reste encore délicate. Même si des outils comme Selenium, Fitnesse, ou HttpUnit facilitent la création de tests fonctionnels, le problème majeur reste d’automatiser l’exécution des tests, qui sont fortement liés à l’environnement d’exécution de l’application (base de données, serveur, dossiers de travail, fichiers de configuration, etc.). Je vais vous présenter une manière de réaliser l’automatisation, il existe des solutions alternatives utilisant DbUnit et Cargo, dont je vous ferai part.

Ainsi, l’automatisation des tests fonctionnels doit permettre de :

1. Initialiser la base de données avec un jeu de données.
2. Construire le WAR de l’application.
3. Démarrer le serveur web et déployer l’application.
4. Exécuter les tests fonctionnels.
5. Arrêter le serveur web.

Pour réaliser cela, cet article s’appuie sur l’outil Ant, qui reste encore répandu malgré Maven. Le passage de l’un à l’autre peut s’effectuer sans avoir à tout re-développer, car j’ai implémenté principalement du code Java réutilisable.
Cet article se concentre sur l’automatisation au niveau de la base de données et du serveur web. Ainsi, la construction du WAR et l’exécution des tests fonctionnels ne seront pas abordés.

Lire la suite de cet article »

Voici la liste des billets les plus lus sur ce blog en janvier, février et mars :

Scrum ou XP ? Scrum ET XP !

Lors des Rencontres Agiles, que nous avons co-organisées en décembre dernier – et qui, soit dit en passant, ont rencontré un fort et encourageant succès -, plusieurs personnes m’ont demandé si, pour démarrer un projet agile, il était préférable de choisir eXtreme Programming (XP) ou Scrum. La réponse est simple : il faut adopter les deux !
La complémentarité de Scrum et XP est communément admise. Scrum se positionne au niveau de la gestion et de l’organisation de projet là où XP se positionne au niveau des activités de développement. C’est la raison pour laquelle ces deux approches fonctionnent si bien ensemble : elles adressent des problématiques différentes et se complètent mutuellement.

Cet article propose une présentation sommaire de Scrum et de la façon dont elle (il? non, allez, c’est plutôt une fille) s’articule avec eXtreme Programming… Bonne lecture !

Lire cet article »

L’analyse de couverture de code en Java

Il ne reste plus grand’monde pour soutenir que l’écriture de tests unitaires automatisés est une perte de temps sur un projet logiciel – la notion de dette technique entre dans les moeurs. Cette prise de conscience salutaire se heurte pourtant souvent à deux grandes catégories de difficultés :

• Le conservatisme – pour ne pas dire la stupidité – de certains chefs de projet, qui persistent à voir dans l’écriture des tests une activité contre-productive, qui servira de variable d’ajustement au moindre coup de grisou
• L’existant : quand le projet n’a pas systématisé la pratique du test dès son origine et que la multiplication des anomalies tardives le pousse à la réintroduire. Par où commencer ?

Pour le premier point, la solution passe par un effort pédagogique, ou, pour les cas désespérés, par une reconversion imposée ou un congé sabbatique.
Pour le second, il faut un peu de bon sens, et un peu d’outillage.

C’est sur le deuxième aspect qu’interviennent les outils d’analyse de couverture de code (ou « code coverage » en anglais). Dans la suite, nous verrons que ces outils ne permettent pas d’évaluer les tests unitaires d’un point de vue qualitatif, mais qu’ils peuvent en revanche apporter au bon sens un précieux appui en répondant aux questions suivantes :

• Quels sont les tests unitaires déjà en place ?
• Les tests sont-ils en phase (à jour) avec le code qu’ils testent ?
• Les fonctions critiques de l’application sont-elles couvertes par les tests ?

Lire cet article »

Un nouveau type d’architecte: l’Architecte Agile

On observe ces derniers temps de multiples débats sur le fait de savoir si une équipe agile a besoin d’un architecte en son sein, et sur la valeur ajoutée de ce dernier sur un projet agile alors que l’architecture évolue à chaque itération.
Les architectes « Tour d’Ivoire » se révèlent petit à petit être le maillon faible des projets agiles. Les responsabilités des architectes traditionnels sont distribuées ci et là au sein des équipes agiles, leur supprimant au passage des tâches qui leur étaient auparavant attribuées.
Une nouveau genre est en train d’apparaître et de sortir du lot comme le prédit la théorie de l’évolution de Charles Darwin – question d’adaptation. Le rôle d’un Architecte Agile ne doit pas susciter de questions et tout membre d’une équipe agile vous le confirmera: ce sont des équipiers qui apportent l’une des plus grandes valeurs ajoutées.

Alors qui est cet Architecte Agile ? Comment savoir si l’architecte de votre équipe est un Architecte Agile ?

Lire cet article »

Il ne reste plus grand’monde pour soutenir que l’écriture de tests unitaires automatisés est une perte de temps sur un projet logiciel – la notion de dette technique entre dans les moeurs. Cette prise de conscience salutaire se heurte pourtant souvent à deux grandes catégories de difficultés :

• Le conservatisme – pour ne pas dire la stupidité – de certains chefs de projet, qui persistent à voir dans l’écriture des tests une activité contre-productive, qui servira de variable d’ajustement au moindre coup de grisou
• L’existant : quand le projet n’a pas systématisé la pratique du test dès son origine et que la multiplication des anomalies tardives le pousse à la réintroduire. Par où commencer ?

Pour le premier point, la solution passe par un effort pédagogique, ou, pour les cas désespérés, par une reconversion imposée ou un congé sabbatique.
Pour le second, il faut un peu de bon sens, et un peu d’outillage.

C’est sur le deuxième aspect qu’interviennent les outils d’analyse de couverture de code (ou « code coverage » en anglais). Dans la suite, nous verrons que ces outils ne permettent pas d’évaluer les tests unitaires d’un point de vue qualitatif, mais qu’ils peuvent en revanche apporter au bon sens un précieux appui en répondant aux questions suivantes :

• Quels sont les tests unitaires déjà en place ?
• Les tests sont-ils en phase (à jour) avec le code qu’ils testent ?
• Les fonctions critiques de l’application sont-elles couvertes par les tests ?

Lire la suite de cet article »