Pour l'amélioration de mes tests unitaires

J'ai une confession à faire. Malgré que j'ai toujours su la valeur et la pertinence des tests unitaires, je dois avouer que j'ai souvent écrit des tests qui laissaient à désirer. J'ai souvent négligé le principe qui stipule qu'on doit écrire les tests avant d'écrire le code. Résultat: des tests fragiles qui ne tenaient pas la route dès qu'un changement était apporté aux classes.

Début 2009, je me suis fixé l'objectif de changer tout cela! Je suis tombé dernièrement sur le livre Test Driven de Manning et la lecture des premiers chapitres m'a particulièrement aidé! Dans ceux-ci, on nous amène à écrire un petit programme en utilisant les méthodes TDD. Le principe de base? Ces trois étapes: test, code et refactor. La technique requiert passablement de discipline. Aucune nouvelle fonctionnalité ne doit être ajoutée sans qu'un test ne soit écrit avant.

D'après l'auteur Lasse Koskela, la bonne approche consiste à écrire les tests en fonction des fonctionnalités de la classe. Ça implique que l'on teste en grande majorité du temps seulement les méthodes publiques d'une classe. Le reste de la classe sera testé indirectement. Et si on se rend compte qu'on n'arrive pas à bien tester certaines méthodes privées de la classe en ne passant que par les tests aux méthodes publiques, c'est probablement le signe que ces méthodes devraient être envoyées dans une classe à part.

Une fois le test écrit, on ajoute le code pour faire réussir le test. Il faut écrire le minimum de code pour faire fonctionner le test! Il fait combattre la tentation d'écrire du code en prévision de futures fonctionnalités. Une fois que le test passe avec le minimum de code, on passe à l'étape de refactoring. On examine le code écrit jusqu'à maintenant et on corrige les code smells, ces indicateurs que quelque chose ne va pas dans le code. Duplication, méthodes trop longues, classes trop dépendantes, tout doit y passer. Et comme on a nos tests comme filet de sécurité, on n'a pas à craindre de perdre certaines fonctionnalités. Une autre chose que j'ai trouvé aussi très
révélatrice, c'est qu'on doit se rappeler que le code de test doit lui aussi passer par la moulinette du refactoring! Ce code doit lui aussi être exempt de code smell! C'est un point important pour que les tests restent pertinents et facile à faire suivre à mesure qu'on ajoute de nouvelles fonctionnalités aux classes.

Donc pour ceux qui, comme moi, pensent qu'ils peuvent s'améliorer dans la pratique du TDD, jetez un coup d'oeil au chapitre 2 de Test Driven. Il aborde les bases du TDD et donne une bonne idée des étapes en pratique.