Les tests unitaires ne sont pas qu’une bonne pratique des méthodes agiles, ils sont un véritable pré-requis à la mise en place d’un développement itératif.
Le refactoring et la modification d’une base de code existante, bien que facilités par les environnements de développement actuels, comportent un évident risque de régression, en partie couvert par les tests unitaires.

Vous trouverez ci-dessous nos 10 commandements des tests unitaires.

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 »

Comme nous l’avions vu dans notre précédent billet (« Introduction à Hibernate Search (Googling your Persistent Domain Model)« ), Hibernate Search vise à réconcilier la recherche full-text et les modèles de persistance relationnels.
Pour ce faire, Hibernate Search se base sur Apache Lucene, un moteur d’indexation et de recherche full-text standalone très puissant et permet ainsi d’utiliser ses capacités dans le cadre d’une couche de mapping Hibernate.

Ce billet présente, au travers d’un exemple simple, les capacités de recherche full-text d’Hibernate Search.
L’exemple proposé permet l’indexation et la recherche de documents auxquels sont attachés des auteurs.
Vous retrouverez l’ensemble des sources présentées dans ce billet dans le repository SVN de Xebia France.

Lire la suite de cet article »

Wicket est un framework plutôt en rupture avec les frameworks web actuels. Ici pas de fichier XML qui définit la navigation, pas de librairies de tag spécifiques, juste de la simplicité et du pragmatisme … tout pour nous plaire ! Wicket a choisi de ne pas mélanger les genres : les pages se font en plain html et le développement, à proprement parler, se fait en pur Java.

Enfonçons-nous un peu dans les mécanismes du framework. Cette semaine, étudions la gestion de la session, la validation de formulaires et l’intégration (toujours aussi simple) avec SpringFramework.

Lire la suite de cet article »

J’ai eu l’occasion courant décembre de rencontrer Emmanuel Bernard [1] pour, entre autres, une présentation d’Hibernate Search.

La vulgarisation et la généralisation de l’utilisation des moteurs de recherche ont définitivement changé les habitudes et les exigences des utilisateurs. Pourquoi la fonctionnalité de recherche d’une application de gestion ne serait-elle pas aussi simple et performante que Google ?
Difficile d’expliquer à son responsable que cela est dû à une divergence de paradigme entre l’indexation documentaire et SQL.
Hibernate Search vise à répondre à cette question, à moindre coût, en s’appuyant sur Apache Lucene afin d’offrir au travers du modèle de persistance d’Hibernate des capacités de recherche full-text.

Lire la suite de cet article »

Wicket est un framework plutôt en rupture avec les frameworks web actuels. Ici pas de fichier XML qui définit la navigation, pas de librairies de tag spécifiques, juste de la simplicité et du pragmatisme … tout pour nous plaire ! Wicket a choisi de ne pas mélanger les genres : les pages se font en plain html et le développement, à proprement parler, se fait en pur Java.

Dans le précédent billet, nous nous étions arrêtés à la mise en place d’un projet Wicket. Aujourd’hui, regardons de plus près la construction des pages et la façon d’implémenter la logique de navigation avec les formulaires et les liens.

Lire la suite de cet article »

Wicket est un framework plutôt en rupture avec les frameworks web actuels. Ici pas de fichier XML qui définit la navigation, pas de librairies de tags spécifiques, juste de la simplicité et du pragmatisme … tout pour nous plaire ! Wicket a choisi de ne pas mélanger les genres : les pages se font en pur html et le développement, à proprement parler, se fait en pur Java.

Dans cette première partie, nous verrons comment démarrer avec Wicket.

Lire la suite de 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 »

Les grands intégrateurs ont depuis longtemps institué un chemin d’évolution basé sur la gestion de projets. Les jeunes débutants, le plus souvent de formation ingénieurs, sont rapidement formés à encadrer des équipes de développeurs et à piloter les projets : la voie royale ! Ces dernières années, vue la complexité technique des nouvelles architectures, une autre voie a émergé : la filière technique. Cette dernière destinée à promouvoir les compétences techniques et d’architectures applicatives, plus en adéquation avec une formation initiale d’ingénieur. Cependant la pression économique impose que ces personnes progressent rapidement vers une spécialité, une expertise (J2EE ; Les bases de données ; La sécurité …) et en les affectant de plus en plus à des missions en parallèle (2 jours chez Untel, 1 jour sur le projet Bidule). Cette rapidité de progression pose toujours le même souci : qui développe réellement l’application ? Très souvent des stagiaires ou, dans le meilleur des cas, de très jeunes embauchés après leur formation.

Les techniques de développement demandent de plus en plus d’être polyvalent : de l’écriture de requêtes SQL à la présentation des données dans une page JSP. Cette polyvalence ne s’acquière pas en quelques années et nécessite également de rester à jour dans ses connaissances. Alors pourquoi propulser ces personnes dans d’autres fonctions ?

Intégrer dans une équipe de développement un ou plusieurs développeurs expérimentés permet deux choses :

• Accélérer les phases de codage et de validation technique et fonctionnelle : l’expérience permet de réduire le nombre d’allers retours entre ces deux étapes.
• Créer une continuité de savoir et d’intérêt entre de jeunes débutants et des profils tels que les chefs de projets voire même les architectes.

Reste à définir la notion d’expérience. Deux composantes rentrent en jeux : les années passées à exercer cette compétence, 3 à 5 ans et surtout le nombre de projets, 5 à 10. Ce dernier point est très important : confronter sa compétence à différents clients, technologies ou architectures est essentiel pour aguerrir les meilleurs développeurs !

Alors laissez les coder !

Nous l’avons constaté encore une fois, une fois de trop sans doute. L’un de nos clients s’est mis tout seul (car les responsables d’une telle situation travaillent bien dans la même entreprise que celle où officie notre interlocuteur) dans une situation perdant/perdant avec son intégrateur dans le cadre d’un projet développé au forfait. Quels sont les faits ? Nous pourrions, sans même lui laisser la parole, nommer une à une toutes les difficultés qu’il rencontre, les yeux fermés, à la manière d’un chapelet qu’on égrène.

Un Appel d’Offre a été émis à destination des principaux intégrateurs de la place car selon la Direction des Achats c’est la seule manière de mener un projet informatique (Nous vous en parlions dans un précédent billet : « Eloge de la qualité« ). C’est, selon les mêmes spécialistes reconnus pour leurs compétences informatiques, un moyen de maîtriser les coûts et les délais, de partager le risque avec l’entreprise choisie et d’avoir un moyen de pression (car bien entendu de superbes clauses de pénalités de retard ont été prévues au contrat). L’intégrateur X est choisi. Pour une grande part, parce qu’il avait une proposition alléchante et savait accepter, sans piper mot, tous les principes de ce « contrat de confiance ». Le décor est planté : une atmosphère de sérénité, une confiance réciproque, l’implication des meilleurs profils de la société X, des desiderata d’utilisateurs pris en compte …

Vous vous en doutez, cette dernière phase est ironique.

Lire la suite de cet article »