Je vous souhaite une bonne année 2011. Je me rends compte que nous sommes mi-janvier et pas un article à se mettre sous la dent. Je travaille beaucoup en ce moment sur l’eXpress-Board. Le week-end passé j’ai ajouté l’authentification OpenId avec Google, Yahoo! et nous avons travaillé sur la partie profil. Il y a encore pas mal de travail pour aller vers ce que j’ai envie de faire, mais ça marche bien. Je travaille aussi en ce moment dans une équipe de développement pour un client dans la Banque. Les journées sont donc bien remplies. L’eXpress-Board est un vrai succès avec 31 annonces en 2011, plus de 170 profils, et plus de 89 recruteurs intéressés par le projet.
Soirée David Gageot
Mardi dernier le Paris JUG avait invité David Gageot, responsable technique d’Algodeal pour nous parler des tests. Soirée très intéressante et très pragmatique. Pourquoi accélérer les tests unitaires et donc le temps pour construire globalement son logiciel ? Il cite le cas d’une équipe qui avait un build de 12 heures. Petit à petit, ce nightly build n’était lancé que toutes les 30 heures… Un build quotidien qui dure plus de 30 heures… cherchez le problème.
Lorsqu’il devient héroïque ou compliqué de construire, déployer et tester votre logiciel, il y a un souci. Cela veut dire que vous acceptez d’attendre 2 ou 3 jours avant de savoir si votre dernière modification fonctionne. Ajoutez à cela le fait que vous êtes 6 ou 7 développeurs, et vous l’avez compris, nous sommes en plein Chaos. Imaginez un médecin qui vous donne un médicament et qui revient 30 heures plus tard pour vérifier si tout va bien…
David parle de « Continuous Testing« . Les tests doivent tourner presque en permanence. Pour cela il nous montre Infinitest. Ce plugin Eclipse permet de lancer les tests unitaires en tâche de fond dès lors que vous modifiez une classe. L’outil est assez intelligent pour n’exécuter que les tests en rapport avec la class Java sur laquelle vous travaillez. Il montre aussi MoreUnit qui est un plugin Eclipse pour faciliter la navigation entre les tests et le code.
Pour accélérer les tests David présente 3 stratégies :
– le tricheur
– le paresseux
– le brave
Le tricheur achètera une machine plus puissante. Il essayera de faire tourner plusieurs agents sur plusieurs machines, ou il essayera de ne pas faire tourner toute la compilation. Surefire 2.7.1 permet de faire tourner des tests unitaires dans plusieurs Threads. Avec Maven 3 il est possible de compiler son projet en parallèle lorsque vous avez plusieurs modules… Mais ces solutions ne s’attaquent pas au coeur du problème. Avec maven 3 vous pouvez par exemple lancer ceci :
mvn -T1 clean install --> 5mn
mvn -T4 clean install --> 3mn
Le paresseux va chercher le moindre effort. Il va par exemple effacer les tests unitaires qui ne servent à rien. Et c’est une très bonne chose. Il va aussi effacer le vieux code qui n’est plus utilisé. Vous pouvez aussi remplacer des tests d’intégration avec Oracle par des tests in-memory avec H2 ou HSQLDB. David cite Apache Comons VFS pour remplacer des tests avec accès réseaux par exemple.
Le brave enfin va vraiment s’attaquer à ce qui fait ralentir votre système. Premier conseil de David : ne testez pas les règles métiers de votre application via des tests d’intégration. Cela rajoute une couche d’infrastructure entre ce qui test et ce qui est testé. Ne prenez pas Selenium pour valider les règles métiers de votre application. Il est plus simple, plus rapide et plus efficace de prévoir des tests unitaires sur la partie purement métier. Le reste ne doit être que de l’infrastructure.
Pour optimiser son build, David recommande de s’attaquer aux 10 tests les plus lents dans votre compilation. Essayez de les repenser pour qu’ils ne testent que ce qui est indispensable. Utilisez aussi Mockito pour bouchonner les parties les plus lentes de l’application. Si vous faites un test d’intégration, vous n’avez pas forcément besoin d’une base de données en mémoire. Il suffit de moquer les DAO pour valider le métier. Pas l’accès à la base. C’est un travail qui demande de la pratique mais qui est très intéressant.
David termine en nous recommandant de garder une approche simple. Non Ajax n’est pas une bonne approche à systématiser. Le coût est-il supérieur au gain attendu ? Je partage son idée de KISS (Keep it simple and stupid) et sa démarche qui est de faire toujours simple et efficace. Le dernier billet du Touilleur Express sur la complexité a reçu 2200 visites en quelques semaines, ce qui est énorme.
Après le buffet offert par Objectif Informatique, David a présenté ses outils préféres comme InfinitTest, MoreUnit et des techniques avancées avec JUnit 4. J’ai découvert par exemple les annotations @Theory et @DataPoints ainsi que @Rule. Il parle aussi de FEST (Fluent Interface) qui permet de rendre plus clair l’écriture des tests unitaires. JUnit 4 propose Hamcrest qui est déjà très bien, mais FEST est l’outil favori de David.
Rendez-vous le 28 février pour l’anniversaire du Paris JUG
Les slides de présentation de David sont sur le site du Paris JUG à cette adresse si vous souhaitez les parcourir. Le prochain RDV du Paris JUG c’est le lundi 28 février à la Cité Internationale Universitaire. Pour l’occasion nous avons trouvé une grande salle de 500 places avec Antonio. Il y aura de part et d’autre de cette salle un espace pour les exposants, pour les partenaires du Paris JUG. Le thème de la soirée sera « Sifflet en travaillant » avec le témoignage de plusieurs développeurs sur leur métier. Comment pouvons-nous travailler et continuer à s’amuser ? A exercer notre métier avec passion ? Si vous souhaitez venir partager votre expérience vous pouvez proposer un sujet via la page « Call for Paper« . L’équipe délibère et rendra publique le programme mi-février.
En attendant, je vous souhaite une bonne année 2011 !
Autres articles
– Cédric Vidal a publié un résumé plus précis sur le blog de Proxiad.
Si on s’amusait a faire la liste des outils ou fwk qu’il faut connaitre pour être un « bon » dev JEE…hum…et après on se demande pourquoi Java a une réputation de complexité…
@smicky : il ne « faut » pas « absolument » connaître tous les outils cités dans cet article.
Par contre lorsque l’on a le niveau « test first » de david ben on est obligé d’avoir des outils appropriés qui nous facilitent le travail quotidien.
Il n’y a pas d’obligation, tout dépend du niveau de rigueur que l’on s’impose. Dans beaucoup de softs le niveau de qualité requis n’est pas celui atteint par David.
Pour finir David a posé un problème initial : éviter la dérive sur le temps de test/build. Il a proposé plusieurs approches dont une quasi extrême.
Notre travail (tous langages confondus) c’est d’être suffisamment critique pour savoir ce qui sera pertinent (ou pas) dans les contextes de nos projets.