Rossi Oddet
Rossi Oddet Développeur | Formateur IT

Formation Tests Unitaires à Nantes du 12 au 13 février

Formation Tests Unitaires à Nantes du 12 au 13 février

J’ai eu l’occasion de donner une formation sur les tests unitaires. Il s’agit d’une formation qui permet une initiation aux tests unitaires à l’aide des outils :

  • TDD (Test Driven Development)
  • Pair Programming
  • JUnit
  • Mockito

Après une introduction générale aux tests et un premier TP d’initiation à JUnit, nous nous sommes lancés dans la réalisation d’un jeu de tennis en appliquant la méthode TDD et en étant organisé en “Pair Programming” (Programmation en binôme).

En tant que formateur et observateur, j’ai pu prendre quelques notes sur la perception qu’ont eu les étudiants à propos des tests.

Temps de chauffe dans le Pair Programming

Le Pair Programming consiste à travailler à deux sur une seule machine. Les deux développeurs incarnent en alternance deux rôles :

  • celui de conducteur : le développeur a ses mains sur le clavier, il écrit le code.
  • celui d’observateur : le développeur fait des suggestions sur ce qui doit être écrit.

Il s’agit d’un moment d’échange où deux développeurs coécrivent un code commun.

Lors de la première séance du Pair Programming, j’ai constaté une difficulté de la part de l’observateur à maintenir son attention. Par contre, un observateur qui sort du rôle de conducteur a une implication bien plus élevée.

Un Pair Programming efficace doit donc probablement allier deux éléments pour être une expérience agréable :

  • Un changement de rôle fréquent. Dans les travaux pratiques, j’ai eu l’occasion de tester plusieurs durées. Si à 1h d’intervalle, la plupart des observateurs perdaient leurs attentions, à 15 min, les développeurs avaient l’impression de casser leurs dynamiques de création. Pour ce groupe, la durée idéale se trouvait autour de la demi-heure.
  • Un temps de chauffe à prendre en compte. Je pense qu’au début d’une séance de pair programming, il est intéressant d’avoir une fréquence de l’alternance des rôles plus élevée et que l’on peut baisser raisonnablement cette fréquence par la suite en fonction de l’expérience des développeurs.

Infinitest1 et la vue JUnit

Les travaux pratiques étaient réalisés principalement avec Eclipse et le plugin Infinitest.

Infinitest permet d’exécuter de façon automatique tous les tests unitaires d’un projet à chaque sauvegarde de fichier. L’intérêt est d’avoir un retour rapide sur l’insertion d’une régression éventuelle lors d’une modification de code.

Si les étudiants ont adoré Infinitest, ils ont cependant regretté que la vue JUnit d’Eclipse ne soit pas mise à jour automatiquement.

En effet, le parti pris d’Infinitest est plutôt d’épingler les erreurs directement dans la classe de test.

Infinitest a manqué à un étudiant qui voulait l’utiliser avec Netbeans (seuls Eclipse et Intellij sont supportés).

Eclipse le cauchemar d’un étudiant

Un étudiant a versé une petite larme (j’exagère :)), lorsqu’il a compris que nous allions utiliser Eclipse dans le cadre de ce cours. Il s’agit d’un utilisateur quotidien de Visual Studio qui développe principalement en C#.

Difficile de trouver de bons arguments pour le rassurer, il faut avouer que Microsoft fait du très bon travail dans le développement de Visual Studio et cela depuis bien des années.

Le papier et le stylo, l’arme absolue pour penser sa conception

Les participants étaient des étudiants complètement immergés dans ce monde qui se dématérialise avec l’informatique. Un étudiant du groupe avouait, par exemple, n’avoir jamais de stylo car il faisait tout avec son ordinateur.

Pourtant, durant la séance de TDD, à l’étape du refactoring, j’ai vu plusieurs groupes prendre un papier et un stylo pour poser leurs réflexions. Ecrire, dessiner, visualiser restent toujours des outils de réflexion et de communication très efficaces.

Le dark mode, la nouvelle vision du développeur ?

Les participants au cours utilisent principalement deux IDEs pour écrire du code Java : Eclipse & Netbeans. Sur plusieurs machines, quelques soient l’IDE, j’ai noté une préférence pour le dark mode (l’utilisation d’un fond de couleur sombre, gris foncé par exemple).

A titre personnel, je trouve que le dark mode d’Eclipse n’est pas très agréable. Est-ce mon habitude d’Intellij ? Quoi qu’il en soit, les participants ont apprécié ce code couleur en vogue en ce moment sur beaucoup d’outils.

Le bilan

Les participants évoluent dans des environnements techniques très différents : C++/QT, Java EE, .Net, Front-end, … Il était donc, en tant que formateur, intéressant de noter si j’avais pu communiquer efficacement la vision que j’ai des tests. Nous avons fait le point, voici ce qui l’en ressort :

  • Tests Unitaires : l’importance des tests unitaires est acquise. Ils ont bien vu l’intérêt notamment lors de l’écriture de l’algorithme du jeu de tennis. A chaque fois, qu’ils introduisaient une régression dans leurs codes, ils voyaient exactement quel cas d’utilisation était impacté et la correction se retrouvait facilitée.

  • TDD : les avis sont mitigés. Les participants ne pensent pas que ces principes soient applicables dans leurs entreprises respectives. Si le principe d’écrire le test avant d’écrire l’implémentation est quelque chose qu’ils trouvent intéressants, TDD au sens stricte ne leurs semblent pas réalistes.

  • Pair Programming : les participants ont apprécié l’expérience. Ils ont trouvé du bon dans les échanges. Ils pensent tous que le Pair Programming est particulièrement pertinent pour faire de l’apprentissage, une montée en compétence.

  • JUnit : les étudiants ont aimé la facilité de mise en oeuvre notamment avec l’utilisation des annotations JUnit 4.

  • Mockito : si son intérêt a été difficile à percevoir au début du cours, les participants l’ont trouvé intéressant. Ils pensent qu’ils leurs faut encore plus de pratiques pour encore mieux prendre la mesure de sa puissance.

Les participants, même s’ils sont à présent conscient de l’intérêt des tests unitaires, ont exprimé des doutes sur la possibilité de les mettre en place immédiatement dans leurs entreprises. Je compte donc enrichir la formation Tests Unitaires de Dev Institut avec une séance de refactoring et tests unitaires sur une grosse application legacy. Cela permettra aux futurs formés d’avoir un ensemble de patterns permettant de tester du code expérimenté (pour ne pas dire vieux).

Ressources

comments powered by Disqus