Maintenant que nous avons défini entièrement le comportement que nous attendons de nos fonctions de conversion, nous allons faire quelque chose d’un peu inattendu : nous allons écrire une suite de tests qui évalue ces fonctions et s’assure qu’elle se comporte comme nous voulons qu’elles le fassent. Vous avez bien lu, nous allons écrire du code pour tester du code que nous n’avons pas encore écrit.
C’est ce qu’on appelle des tests unitaires (unit test), puisque l’ensemble des deux fonctions de conversion peut être écrit et testé comme une unité, séparée de tout programme plus grand dont elle puisse faire partie plus tard. Python a une bibliothèque pour les tests unitaires, un module nommé tout simplement unittest.
 |
|
| unittest est inclus dans Python 2.1 et versions ultérieures. Les utilisateurs de Python 2.0 peuvent le télécharger depuis pyunit.sourceforge.net. | |
Les tests unitaires sont une partie importante d’une stratégie générale de développement centrée sur les tests. Si vous écrivez des tests unitaires, il est important de les écrire tôt (de préférence avant d’écrire le code qu’ils testent) et de les maintenir à jour au fur et à mesure que le code et les spécifications changent. Les tests unitaires ne remplacent pas les tests fonctionnels ou de système à plus haut niveau, mais ils sont important dans toutes les phases de développement :
- Avant d’écrire le code, ils obligent a préciser le détail des spécification d’une manière utile.
- Pendant l’écriture du code, ils empêchent de trop programmer. Quand tous les cas de test passent, la fonction est terminée.
- Pendant la refactorisation (refactoring) de code, ils garantissent que la nouvelle version se comporte comme l’ancienne.
- Pendant la maintenance du code, ils permettent d’être couvert si quelqu’un vient hurler que votre dernière modification fait planter leur code. («Les tests unitaires passaient à l'intégration de mon code...»)
- Lorsqu’on écrit du code en équipe, ils permettent de s’assurer que le code que vous intégrez ne va pas interférer avec celui des autres puisque vous pouvez d’abord exécuter leurs tests. J’ai vu ce genre de chose au cours de code sprints. L’équipe se partage les tâches, chacun écrit les tests unitaires pour sa tâche à partir de sa spécification puis partage ses tests avec le reste de l’équipe. De cette manière, personne ne peut s’égarer à écrire du code qui ne fonctionnera pas avec celui des autres.