Les stratégies de test font partie de l’arsenal standard du développeur qui se respecte. Durant cette session non technique (mais avec un peu de code pour illustrer), Guillaume Saint Etienne revient sur les enjeux des tests et sur les bonnes pratiques, avant d’entrer dans le vif du sujet : les TDD (Test Driven Developement) et les BDD (Behavior Driven Developement).

Commençons par un point très important sur lequel a insisté l’orateur. Il ne faut pas confondre les BDD avec les tests d’IHM ; ça n’a rien à voir. Contrairement à ce que beaucoup pensent, BDD n’est pas synonyme de Selenium. Ce qu’on cherche à tester, c’est le logiciel. On veut qu’il soit conforme aux attentes du client. On vérifie qu’il respecte des normes et qu’il soit de qualité. On ne teste donc pas seulement les interfaces.

Les développeurs ont pris l’habitude de découper leurs applications en couches et en services. Mais où doivent aller les tests dans une telle architecture ? Bonne question sur laquelle on se casse parfois les dents. En outre, tester un service n’est pas toujours simple, notamment lorsqu’il possède de nombreuses dépendances. Ce qu’on doit tester, c’est le comportement. Il faut revenir au concept de la boite noire. Bien entendu, pour comprendre le comportement du logiciel, il faut connaitre le comportement de chaque partie.

La tâche est dure mais on peut s’inspirer d’un principe unique : restons simple. .. Pour les tests, la simplicité se traduit par l’isolation. Simplifier c’est isoler. Il faut tester une seule chose à la fois. Un test ne contient qu’un seul assert. D’une manière générale, l’orateur nous invite même à faire du SOLID. Si on n’est pas SOLID alors on n’est pas Agile.

Pour illustrer sa présentation, Guillaume nous a montré comment programmer une petite calculette en .Net à l’aide des TDD. Il écrit d’abord les tests puis s’en sert durant son développement. Au départ, son test NUnit est rouge mais il devient vert lorsque le code est fini. C’est magique à voir. On remarque qu’il fait attention à la présentation de ses tests et, notamment, qu’il utilise le format AAA (Arrange Act Assert). Toutefois, cela reste du chinois pour qui n’est pas de la partie.

L’idéal serait de pouvoir écrire les tests en langage humain, avec des vrais mots. Et c’est justement ce que permet la lib SpecFlow que Guillaume nous a ensuite montrée. AAA devient alors GWT (Given When Then). On utilise du simple texte en langage agnostique (pas nécessairement en anglais, ça peut être du français, allemand, etc.) pour décrire et vérifier un comportement attendu. Pour peu que le cahier des charges soit bien rédigé, avec le bon formalisme, les développeurs peuvent (presque) alors se contenter de recopier les spécifications, ce qui facilite les échanges avec le client.

Cette pratique offre de nombreux avantages, comme de permettre à des collègues d’écrire des scénarios de test sans forcément connaitre le langage de programmation.

ROTI* : 5/5

Pour aller plus loin, notons que les TDD (largement présentés sur Developpez.com) et les BDD partagent un certain nombre de bonnes pratiques. Des méthodes comme 3T (Tests en Trois Temps) s’en inspirent : tests lisibles, avec un périmètre contrôlé, simples et inspirés des spécifications. Qui plus est, 3T ne laissent pas les développeurs seuls et perdus devant leurs écrans mais, au contraire, les accompagne. D’ailleurs Guillaume Saint Etienne prévoie de coécrire prochainement un article sur le sujet.

Quelques articles à propos de 3T (Tests en Trois Temps) que je vous invite à lire :

• Initiation aux tests avec 3T
• Miniroman humoristique d’une équipe utilisant 3T
• 3T en 5 minutes chrono

(*) Un ROTI est une notation personnelle, qui change en fonction des attentes de chacun. D’une personne à l’autre, les impressions peuvent changer du tout au tout.