Netapsys Blog - agile

AGILE & MORE EFFICIENT : Test JUnit, EasyMock & Spring

Abderrazek CHINE — Wed, 24 Mar 2010 08:11:00 +0100

Ce billet aborde l'aspect purement technique de mise en oeuvre de l'agilité dans le développement d'applications robustes.
Il s'inscrit dans la continuité du séminaire de Netapsys sur le thème "Agile & more efficient".
Il présente les tests JUnit 4.x et EasyMock sous Spring afin de concrétiser "être agile".
EasyMock permet de simuler l'accès aux fonctionnalités des couches applicatives, par exemple la couche DAO.
Un des piliers de l'agilité est TDD (Test Driven Development).
Le TDD est une approche évolutive de réalisation de projets basés sur les tests avant même de produire du code effectif.
TDD combine le TFD (Test First development) et le refactoring afin d'arriver à affiner / définir les spécifications.
Easymock et JUnit constituent donc les briques afin de réaliser le TDD via les tests unitaires et d'intégration.
En fait, les tests unitaires sont faciles à mettre en place mais les tests d'intégration restent encore difficiles.
Et le coût de réaliser les tests d'intégration est pesant.
Et EasyMock permet la mise en place des tests sans pour autant avoir développé une ligne de code d'implémentation des couches applicatives. Tous ces aspects vont être explicités ci-dessous.

Nous démarrons avec un projet exemple simple qui permet de comprendre les notions importantes dans EasyMock.
1- Le projet exemple:

Comme notre objectif est de faire du TDD, nous allons écrire uniquement les interfaces puis enchaîner avec les tests sur des classes simulées (moquées) par EasyMock.

/***interface couche dao**/
public IContactDao{
  	void save(Contact contact) ;
}

Et celle de service:

/***interface couche service*****/
public IService{
  	void save(Contact contact) ;
      void setContactDao(IDao dao);
}

Et l'entité Contact est un POJO simple:

package fr.netapsys.easymock.entites;
 
import java.io.Serializable;
 
import fr.netapsys.easymock.common.BaseObject;
 
public class Contact implements Serializable {
	private static final long serialVersionUID = -1511337412528984583L;
	private int id;
	private String nom;
	private String prenom;
	private String mail;
	public Contact() {
		super();
	}	
 
	//Setters/getters omis		
}

Donc nous avons en place les briques techniques qui vont servir à pratiquer le TDD et favoriser les échanges avec le client.
Écrivons les tests avant de commencer les développement pur et dur des couches dao, service et web(back & front).
La classe de test est simple néanmoins consistante afin d'illustrer réellement l'apport des test mock.

2- Classe JUnit4 test

package fr.netapsys.easymock.tests;
 
import org.apache.log4j.Logger;
import org.junit.Assert;
import org.junit.Before;
import org.junit.Test;
import org.junit.runner.RunWith;
import org.springframework.test.context.ContextConfiguration;
import org.springframework.test.context.junit4.SpringJUnit4ClassRunner;
import fr.netapsys.easymock.entites.Contact;
import fr.netapsys.easymock.interfaces.*;
//**** notez cet import *****
import static org.easymock.EasyMock.*;
 
@RunWith (SpringJUnit4ClassRunner.class)
@ContextConfiguration (locations = { "classpath:spring.xml" }) 
public class TestEasyMock {
	private final Logger logger=Logger.getLogger(getClass());
	private IContactDao contactDao;
	private IContactService contactService;
	@Before public void setUp() {
		contactDao=createMock(IContactDao.class);
		contactService= createMock(IContactService.class);
	}
	@SuppressWarnings("nls")
	@Test public void testSave() {
			Contact contact=new Contact();
			//************** createMock, expect, replay, call & verify		
			expect(contactDao.save(contact)).andReturn(saveContactInDao(contact));			
			replay(contactDao);
			contactDao.save(contact);
			verify(contactDao);			
			//appel au service
			expect(contactService.save(contact)).andReturn(saveContactInService(contact));
			replay(contactService);
			Contact c=contactService.save(contact);
			logger.info(">>>>Contact retrieved by service :"+contact.toString());
			verify(contactService);
			Assert.assertTrue(  c.getNom().equals(contact.getNom()) && c.getId()==1 && c.getMail().equals("mail@mail.fr"));
	}
	@SuppressWarnings("nls")
	private Contact saveContactInDao(Contact contact) {
		Contact contact2Return=contact;
		contact.setNom("Easymock");
		contact.setPrenom("test");
		//setter id 
		contact2Return.setId(1);
		return contact2Return;
	}	
	@SuppressWarnings("nls")
	private Contact saveContactInService(Contact contact) {
		Contact contact2Return=contact;//contactDao.save(contact);
		contact2Return.setMail("mail@mail.fr");		
		return contact2Return;
	}
}

NB. Le fichier spring.xml est pour l'instant vide. Il ne contient que les déclarations des namespaces.
La seconde partie de ce billet revient sur ce fichier de configuration pour aller plus loin dans l'utilisation de l'api easymock combiné avec spring.

3- Exécutions des tests

La première capture illustre que le test JUnit répond bien:

Avec une sortie sur la console qui ressemble à:

[INFO  (TestEasyMock.java) >>>>Contact retrieved by service :fr.netapsys.easymock.entites.Contact@17050f5[
  id=1
  nom=Easymock
  prenom=test
  mail=mail@mail.fr
]]}

Easymock est utilisé par spring et le projet apache strutstestcase. Néanmoins, à mon avis, il est plus ou moins intuitif à pratiquer.
Son concurrent MOCKITO séduit par la simplicité d'emploi.
EasyMock se comporte comme un "recorder" et par conséquent nécessite généralement les étapes suivantes:

createMock, ( C'est ce que a été fait dans la méthode annotée par @Before )
expect, (C'est ce qui a été fait dans le corps de la méthode testSave)
replay, (idem)
call, (idem)
verify. (idem. A noter que cet appel peut générer une exception incompréhensible si l'ordre des étapes n'est pas respecté)

La prochaine fois, nous introduirons l'auto-injection Spring des beans de la couche service en simulant (en moquant) uniquement la couche DAO.

Retour d'expérience sur l'intégration continue

Fabian Piau — Mon, 01 Mar 2010 22:29:00 +0100

Sébastien Roul et moi-même allons co-animer une présentation sur l'intégration continue le mercredi 17 mars dans le cadre d'une rencontre Agile à Nantes.

Notre objectif ne sera pas seulement d'en présenter les concepts, nous apporterons aussi notre vision et retour d'expérience.

En effet, après plus d'un an d'utilisation chez Netapsys Atlantique, l'intégration continue s'inscrit au cœur de notre métier avec une mise en place systématique sur l'ensemble de nos projets client.

L'intérêt de cette double intervention permettra de présenter ma vision de développeur avec une utilisation quotidienne, mais aussi la vision de chef de projet avec Sébastien.

L'intégration continue n’est pas seulement l'installation d'un serveur avec quelques outils appropriés, c’est vraiment un état d'esprit qui doit vivre au sein de l'équipe...

Pour en savoir plus ou assister à la présentation, vous pouvez consulter ce billet sur le site d'Agile Nantes.

Mise à jour du 29 mars 2010 :

Cette rencontre s’est déroulée dans le cadre des rencontres agiles à Nantes dans des locaux prêtés à l’occasion par l’école SUPINFO.

Voici les slides de la présentation.

Une bonne couverture pour l'hiver

Fabian Piau — Sun, 08 Nov 2009 22:52:00 +0100

Améliorer la couverture du code avec Emma

Dans cet article, je vous présente le plug-in EclEmma (contraction d'Eclipse et d'Emma), Emma est un analyseur de code Java open-source qui détermine la couverture du code. EclEmma est bien évidemment son portage sous Eclipse.

Après l'avoir utilisé pendant quelques semaines, j'avoue me demander comment j'ai pu faire sans avant.

Installation du plug-in

Tout d'abord, l'installation. Sous Eclipse, Help -> Install New Software... -> Add site. L'adresse est http://update.eclemma.org/. Après installation, Eclipse doit être redémarré.

Utilisation

Habituellement, pour lancer vos tests unitaires, j'imagine que vous sélectionnez soit un package, soit une classe de tests ou soit un test seul, puis vous faites un clic droit, Run As -> JUnit Test

Pour lancer le(s) test(s) avec EclEmma afin de vérifier la couverture correspondante, il vous suffit de faire quasiment la même chose. Vous utilisez le nouveau menu "Coverage As" au lieu du "Run As". Notez qu'il est possible d'utiliser un bouton dans l'IHM, mais je préfère le menu.

Présentation détaillée

Voici un exemple en images pour bien voir comment cela fonctionne.

Nous souhaitons implémenter la fonctionnalité suivante: la conversion d'un texte au format HTML. Rien de bien évolué donc, mais parfait pour une présentation d'EclEmma.

Nous allons créer un premier test pour tester la gestion des accents.

Le test ne compile même pas, nous allons implémenter juste le code qu'il faut pour qu'il compile.

Après création de la classe ConvertToHtml et de sa méthode « convert », le test peut être lancé.

Sans surprise, le test ne passe pas.

Implémentons la méthode « convert ».

Maintenant, le test réussit.

Le code n'est pas parfait, nous allons faire un peu de refactoring pour l'alléger et l'améliorer.

On vérifie que le test passe toujours.

A cet instant précis, vous pouvez vous poser la question suivante : bon d'accord, je sais que le code que j'ai écrit passe le test. Mais, comment être sûr que je n'ai pas écrit trop de code, c'est-à-dire que j'ai écrit un code qui fait plus que ce que mon test lui demande...

La solution est dans EclEmma. On relance le test avec ce dernier.

Le code testé est surligné en vert. Dans mon cas, tout est complètement testé.

En plus, un tableau résumé s'affiche en bas. Le taux de couverture indiqué est de 100%.

Bon, il faut avouer que ce n'était pas trop dur avec un exemple aussi simple, mais gardez en tête l'utilité d'un tel logiciel sur une application contenant plusieurs centaines de milliers de lignes de code avec quelques milliers de tests unitaires.

Pour le tutoriel, je vais aller à l'encontre du principe TDD et modifier le code métier sans avoir préalablement écrit mon test.

Relançons le test avec EclEmma.

Le taux de couverture est « tombé» (si j'ose dire) à 95%. Ce que nous avons ajouté n'est clairement pas couvert par un test unitaire. La ligne est surlignée en rouge. EclEmma nous donne tout de suite le feedback qu'il nous faut.

Un coup d'œil au tableau résumé et je sais exactement quel est le fichier concerné. Bon là, c'est moins drôle, je n'en ai que deux, ce n'était pas trop difficile à trouver.

Sans plus attendre, nous allons ajouter le test pour tester la non-conversion d'un texte qui ne doit effectivement pas être converti.

J'ai profité de la phase de réflexion sur l'écriture de mon test unitaire pour améliorer mon code métier en supprimant le préfixe en sortie, et en le mettant en constante.

Je relance EclEmma... Je retrouve un taux de couverture à 100%, tout est bien testé, et mon code fait exactement ce que je veux qu'il fasse (pas plus, pas moins).

Encore une fois, à des fins pédagogiques (bien sûr), nous allons modifier le code métier sans avoir modifié les tests. Supposons que maintenant on utilise un suffixe de non-conversion. On relance EclEmma. Oh, les belles couleurs !

Une ligne est surlignée en jaune, elle est partiellement testée. Arrangeons le code en 2 lignes pour y voir plus clair.

Tout s'explique maintenant, on est passé dans la première partie du ET mais pas dans la seconde, car la première partie n'a pas été vérifiée.

Vous l'aurez compris, EclEmma colorise les lignes de la façon suivante :

Vert: la ligne est testée, un test (au moins) la vérifie.
Rouge: la ligne n'est pas testée, aucun test ne la vérifie, il faut donc écrire un test.
Jaune: la ligne est partiellement testée, elle contient du code testé et du code non testé. Pour voir exactement ce qui est testé, « cassez » la ligne en plusieurs morceaux comme j'ai fait précédemment.

EclEmma fournit deux pourcentages de couverture, celui sur le code de l'application par les tests (c'est celui-ci qu'il faudra le plus surveiller, c'est le plus important), mais aussi le taux de couverture sur les tests eux-mêmes. Ce dernier peut-être utile, car il permet de faire un bon nettoyage dans les tests en montrant les lignes qui ne sont jamais utilisées.

Enfin, si vous regardez les propriétés du projet, vous pouvez avoir un résumé de la couverture par type d'élément Java. Ces chiffres sont utiles pour le développeur, le chef de projet, et peuvent faire partie d'un livrable client.

La configuration par défaut d'EclEmma est très suffisante. Vous pouvez paramétrer quelques options comme la personnalisation des 3 couleurs ou bien ajouter le taux de couverture dans le package explorer (comme ci-dessous).

Conclusion

Selon moi, EclEmma (Emma plus généralement pour ceux qui ne travaillent pas sous Eclipse) fait partie de la boîte à outils indispensables à tout développeur JAVA travaillant quotidiennement avec des tests unitaires.

Il vous aidera facilement à améliorer votre taux de couverture. Autrement dit, et pour être plus réaliste, il vous montrera efficacement que vous développez plus qu'il n'en faut pour passer vos tests. Ainsi, peut-être qu'un jour, vous réussirez à atteindre un taux de couverture proche du mythique 100% (mais là... rien n'est moins sûr, car tout n'est pas testable comme on le voudrait... c'est une autre histoire... et surtout un sujet différent).

Je vous souhaite un bon test de ce logiciel sur vos tests !

Scrum et XP : Retours d'expérience

Céline Gilet — Sat, 04 Apr 2009 18:50:00 +0200

Jeudi dernier, le groupe des praticiens Agiles de Nantes proposaient deux retours d'expérience autour des méthodes Scrum et de la mise en place de l'eXtreme Programming (XP).
Nous avons aussi pu bénéficier d'un retour sur la formation ScrumMaster dispensée par Pyxis.
Petit résumé de la soirée...

Scrum est une méthode agile utilisée pour la gestion de projet. Son objectif est de proposer au client une structure réactive pour mieux répondre à ses besoins et à ses demandes d'évolution tout au long du projet. Cette réactivité passe par une amélioration de la productivité des équipes.
Pour y parvenir, Scrum propose un certain nombre de préconisations en terme d'organisation et de communication.

Au niveau organisationnel, Scrum identifie trois rôles différents :

le Directeur de Produit ("Product Owner") : il s'agit du client ou du représentant du client. C'est lui qui a la connaissance métier et qui détermine l'ordre des fonctionnalités à implémenter.
le ScrumMaster : il s'agit d'un membre de l'équipe projet. Il a en charge d'animer les daily meetings (points journaliers) et de motiver l'équipe. Un point essentiel : ce rôle n'est pas forcément assuré par le chef de projet !
et le dernier acteur, sans qui rien ne serait possible, l' Equipe : c'est elle qui réalise l'application. Il n'y a pas de notion de hiérarchie dans l'équipe. Les décisions sont prises ensemble, notamment lors des daily meetings. On parle d'une équipe en auto-gestion : chacun sait ce qui est à faire et pour quand. L'équipe partage donc cet objectif commun et c'est à elle de tout mettre en œuvre pour y arriver.

Le principe clé de Scrum est la communication. C'est en communiquant le plus possible qu'on va être capable de résoudre les problèmes ou de détecter des incompatibilités entre fonctionnalités le plus tôt possible.
Pour mettre en place une communication efficace, Scrum propose les daily meetings. Tous les acteurs du projet doivent y participer (y compris le client). L'objectif est de faire le point en toute transparence. Chaque membre de l'équipe indique :

ce qu'il a fait hier
les problèmes qu'il a résolu
ses éventuels points de blocage
ce qu'il va faire aujourd'hui

La présence du client est importante lors de ces points car cela lui permet de suivre l'état d'avancement de l'application et d'avoir connaissance des problèmes que rencontre l'équipe sur telle fonctionnalité. Une ré estimation ou un retard de livraison pour une fonctionnalité sera alors mieux compris.
Impliquer le client au quotidien et pas seulement lors des livraisons est un vrai challenge. C'est indéniablement l'élément le plus difficile à mettre en œuvre de la méthode Scrum. Sur le retour d'expérience présenté, c'est d'ailleurs l'implication du client qui a été mise de côté...

Même si Scrum est un vaste sujet, passons au deuxième thème de la soirée : l'eXtreme Programming.

L'eXtreme Programming (XP) est une autre méthode agile de conduite de projet. Comparée à Scrum, XP propose des préconisations qui sont plus orientées côté technique.
On va alors retrouver, comme principes :

une conception simple et qui évolue tout au long du projet (on ne garde que les diagrammes qui sont indispensables)
la mise en place d'une intégration continue
la mise en place de l'automatisation des tests (qui permet d'assurer les opérations de refactoring)
la généralisation du pair-programming (un développeur doit être capable d'intervenir sur l'ensemble du code de l'application)
l'application de normes de développement (ces normes doivent être connues de tous les développeurs : il est donc essentiel que les développeurs prennent part à leur définition au début du projet)

Parmi tous ces principes, le plus dur à faire accepter (notamment à la direction) est le pair-programming, qui est souvent perçu comme une perte de temps.

Scrum et XP ont une ligne directrice commune : mettre définitivement de côté les méthodes de développement dites traditionnelles qui consistaient à suivre un cahier des charges et à livrer l'application en fin de projet. Le projet doit être découpé en plusieurs cycles et une livraison doit être faite à la fin de chaque cycle : on parle de développement itératif. Les livraisons régulières (en moyenne tous les 30 jours) sont là pour obtenir des validations intermédiaires du client et pour être sûr d'être en adéquation avec le besoin.

En résumé, "pragmatisme", "souplesse" et "simplicité" doivent être les valeurs de référence tout au long du projet : les méthodes Scrum et XP sont là pour nous aider !!

Et comme promis, le retour sur la formation de ScrumMaster dispensée par Pyxis qu'a suivie Pierrick Thibault, Directeur technique chez Carra Consulting. Il s'agit d'un retour positif, aussi bien sur le contenu que sur la qualité du formateur : François Beauregard. Selon Pierrick, les présentations et les exercices pratiques permettent de prendre conscience de la nécessité d'apporter de l'agilité dans la gestion de projets.
Mais c'est à chacun de réfléchir à ce qu'il est possible d'appliquer sur un projet en fonction du client et de ses équipes : il n'y a pas de recette miracle mais une liste d'ingrédients que chacun doit combiner !

La chandeleur chez Netapsys Atlantique

Denis Sanchez — Tue, 10 Feb 2009 16:27:00 +0100

De nombreuses raisons de fêter la chandeleur chez Netapsys Atlantique.

Ce n'est pas la présentation de Jésus à toute l'équipe mais l'arrivée de Nicolas David stagiaire issu de Polytech Nantes.

Nicolas rejoint Netapsys pour terminer sa formation d'ingénieur. Son stage doit se dérouler sur une période de 5 mois.

La seconde raison, c'est la première livraison de "Easydor", l'application de gestion financière du CHU de Nantes après 2 mois de travail studieux où l'équipe nantaise a mis en place pour la première fois une gestion de projet et d'équipe avec les méthodes agiles.

Le premier bilan est très encourageant. En effet, de nombreux points ont été améliorés :

la communication
la dynamique
le partage des connaissances
la mise en place des tests et de l'intégration continue
le refactoring
les stand’up

Toutes ces bonnes nouvelles méritaient bien une petite crêpe !

Lean Management : les 7 principes

Can Atac — Fri, 25 Jul 2008 09:59:00 +0200

Dans notre étude sur les apports de la méthodologie Lean prodiguée par le couple Poppendieck et son influence sur la méthodologie Agile, nous nous trouvons face à sept principes à respecter afin d'améliorer la valeur ajoutée de la production logicielle :

l'élimination du gâchis (1)
la création de la connaissance
la construction de la qualité (5)
le report de l'engagement (2)
les livraisons rapides (3)
le respect des personnes (4)
l'amélioration du système

Reprenons quelques principes qui nous semblent avoir un lien de parenté avec les principes agiles.

Le coût des limites organisationnelles : la communication est ralentie par les barrières organisationnelles qu'une entreprise met en place. Les Poppendieck annoncent une augmentation des coûts de 25%. Cette remarque soutient la bonne pratique Agile de rapprochement physique des parties prenantes d'un projet informatique
Limiter "agressivement" la liste des points à livrer à la capacité de livraison (2). Cela se traduit par un report des engagements des parties prenantes sur le cahier des charges et le contenu des livraisons. Il s'agit de décider le plus tard possible ! Cela peut choquer au premier abord. L'idée est de figer les dates de livraison (la fin d'une itération en somme, ou d'un sprint à la sauce Scrum) et de laisser les acteurs décider du contenu des livraisons. Nous devinons les implications : coopération des acteurs, transparence sur les charges, connaissance des problèmes...
Livraison rapide : inspirée des méthodes de production 'Just-In-Time' du secteur automobile (zéro stock), les parties prenantes racourcissent les délais de livraison. Cette accélération du rythme des livraisons est un des grands principes adoptés par les méthodes agiles.
Le respect des personnes. Nous retrouvons cette valeur introduite en 2004 comme étant la cinquième dans les valeurs XP. En quoi est-il besoin de s'en préoccuper ? Sans aller étudier la théorie de la sociologie du travail, notre bon sens nous laisse deviner qu'une mise en confiance des équipes va améliorer, entre autres, la communication : meilleure connaissance des problèmes, des charges associées au développement d'une fonction mais également l'implication. Nous voyons poindre ici deux valeurs XP : communication et en second plan, le courage de prendre des risques.
La construction de la qualité : tests et retests. Aucun problème pour créer un nouveau lien vers XP...

Même si la connaissance des principes de la gestion de projet "Lean" ne bouleverse pas les praticiens des méthodes agiles, elle offre une vision plus orientée 'coût' et ouvre un champ d'étude de bonnes pratiques issues de méthodes historiques de management provenant d'autres secteurs (de chez Toyota en particulier).

Une preuve, s'il en est, que les managers en informatique ne sont pas les premiers ou les seuls au monde à penser le changement ;-)

Les Poppendieck : une source d'inspiration de la communauté Agile

Can Atac — Tue, 08 Jul 2008 14:28:00 +0200

C'est en lisant un billet récent sur le site de Martin Fowler répondant à la question "I'm thinking of using agile software development - but should I use Lean software development instead?", que je me suis mis à m'intéresser au Lean software development.

Ce papier super intéressant rappelle les influences des méthodes "Lean" issues du secteur automobile japonais sur les développements "Agile".

Un petit tour sur le site du couple Poppendieck offre au visiteur quelques principes "Lean" et invite à les comparer avec les principes derrière le Manifeste Agile.

Nous tenterons de cerner les points communs et les divergences.

A retenir, Martin Fowler et Jez Humble animeront un webinar le 28/07/08 sur la gestion des mises en production à la sauce 'Lean' autour du nouveau produit 'Cruise' de la société ThoughtWorks.

A suivre...