Alors qu’on commence le développement d’un nouveau jeu en ligne, j’ai décidé de reprendre les bonnes habitudes : on fait des tests unitaires ! Et pas après avoir codé, avant !

Si il y a un truc que j’ai retenu de mon expérience du Test Driven Development, c’est qu’il faut jamais arrêter. C’est dur de s’y remettre après, voir impossible sur un même projet. Sur Equideo, pris par le temps on avait décidé de ne pas en faire, et je pense qu’il y en aura jamais maintenant.

L’argument du temps revient souvent… En fait je me rend compte qu’il est surement moins important que ce qu’on pense. Les tests, au début on a l’impression que ça va nous prendre deux fois plus de temps (écrire le code, et les tests qui vont avec). Ce qui est pas loin d’être faux. Mais si on y regarde bien, de toute manière on est très souvent obligé de passer du temps à tester, de manière informel. Qui plus est, quand on accumule les fonctionnalités, il faut retester les anciens codes, vérifier qu’on a rien cassé. Avec une batterie de tests unitaires, on vérifie très simplement que tout fonctionne.

Vient le temps de la mise en production. Et c’est là qu’on apprécie le plus les tests unitaires : à chaque modification, vous pouvez vous assurer tout aussi aisément que vous n’avez rien cassé ailleurs. Au final, entre le temps gagné à ne pas tester en bricolant de manière informel, et vu le gain en confiance lors de changement sur le site en production, je pense qu’on a largement regagné le surplus d’effort initial.

Le jeu qu’on prépare se prête assez bien aux tests unitaires, donc le choix est vite vu, je pense pas que je le regretterai.

Pour ceux que ça intéresse, j’avais écrit un petit papier sur les tests unitaires.