13.2. Présentation de romantest.py
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.
