Bonjour,

Aujourd'hui, nous allons parler des tests unitaires avec l'outillage de Java.

Aujourd'hui, nous allons survoler l'agile et parler des TDD. En quelques mots, l'agile consiste à délivrer rapidement le maximum de valeur au client et à mettre le client, le code et l'équipe au centre des projets. Vraiment, c'est une présentation très générale. Si l'agile vous intéresse, voyez .

Tester, c'est douter

HAHAHA! A quel point c'est faux! Le cliché selon lequel on ne teste que lorsqu'on n'est pas sûr de soi ou qu'on débute a des effets redoutables! Tester, c'est garantir une application. Quand vous voyez du code dégueulasse, soit vous vous taisez en espérant que vous serez parti avant que la dette technique ne tue le projet, soit vous appliquez la boy scout rule. Mais comment garantir que vous n'avez rien cassé (ou rien de grave)? Et bien, avec les tests! Sans tests, il n'y a pas de refactoring sécurisé. Sans refactoring sécurisé, votre projet va crouler sous la dette technique, et vous allez mettre de plus en plus de temps à livrer de la qualité. Le test a d'autres fonctions: documenter, prouver le code, etc.

Tester, c'est comprendre. Si vous êtes un développeur pressé, sur un projet qui ne vous tient pas à coeur, pour une prestation dont vous n'avez que faire, et bien, ne testez pas si le coeur vous en dit. Si au contraire, vous voulez livrer de la qualité, la démarche de TDD est une théorie intéressante. Sa mise en pratique se heurte à des difficultés majeures, mais parlons pour l'instant juste de la théorie. En théorie, donc, vous codez d'abord vos tests. Ainsi, vous vous creusez la tête pour voir comment votre code doit réagir. Par exemple, vous pensez aux cas limites. Par exemple, quand vous codez une fonction qui appelle un webservice, que devez vous faire si çà ne répond pas en face? Ce n'est pas forcément le sujet d'un test unitaire, plutôt d'un test d'intégration, mais il faut se poser la question. Vous l'aurez en production, çà c'est sûr! Les notions de BDD ont alors toute leur valeur: si la MOA est capable de définir des scénarii et des critères d'acceptance, c'est vers elle que vous vous soulagez, et c'est elle qui commence le travail sur la partie fonctionnelle. Et plutôt que de pisser le code de test, vous pouvez même prendre le temps de comprendre 🙂 Des outils comme Fitnesse permettent de définir ces scénarii en code "MOA", même si le temps de montée en compétence est déjà énorme...

La pratique des TDD

Pratiquer le TDD, en théorie, c'est formidable. Dans la dure réalité des projets, le TDD fait ses preuves sur les nouveaux projets, ou sur lesquels chaque fonction a un rôle figé dans le temps. Par exemple, si vous utilisez des librairies de calcul, il y a peu de chance que leur sens change... En revanche, et nous l'avons vécu chez nos amis clients, les projets avec un très gros existant posent plusieurs questions:

  • chargement du contexte d'exécution. Par exemple, si vous avez besoin de tester l'exécution d'un ordre financier, vous allez devoir charger le produit, le deal, etc. C'est beaucoup, et c'est sûrement trop. Le pattern Factory ayant ses limites, vous devez réflechir à une autre méthode. Mockito? JSON? XML?
  • Gérer les tests existant. C'est à dire: supprimer ou changer les tests qui ne servent plus. Que faire en cas d'évolution. Est ce normal si vous passez une évolution et qu'aucun de vos tests ne passe au rouge? C'est aussi savoir si la couverture de code est suffisante. Et donc, gérer la couverture de tests
  • Savoir si, sur du code non testé, il faut prendre du temps pour inclure des tests avant un refactoring. En particulier, savoir quand est ce que la dette technique est préoccupante

 Nous n'avons pas de solution à ce niveau de généralité...

Les outils du TDD

Maven est pour cela bien pratique. Il permet d'automatiser les tests, et est le socle d'outils comme Jenkins. Jenkins est un serveur d'intégration continue. Autrement dit, il permet d'automatiser les tests, de garder une trace du nombre et de leurs résultats, et d'avoir une métrique de qualité. Parce qu'en France, on aime bien les chiffres, et donc, on mesure la qualité avec des chiffres. En tous cas, le but est de builder le projet sur un environnement séparé de celui des développeurs (idéal pour tester un fichier non commité) et d'avoir une version déployable en production rapidement. La réelle plus value du principe est là: on peut livrer (en théorie) très rapidement, les ear ou autres java archives sont prêtes à l'usage, et tout est bel et bon pour le déploiement.

Voilà, en quelques mots, comment le test permet de garantir une certaine qualité et une livraison rapide, deux bases de l'Agile

 

Comments are closed.

Set your Twitter account name in your settings to use the TwitterBar Section.