La partie fondamentale des tests unitaires est la construction
des cas de test individuels. Un cas de test répond à une seule
question à propos du code qu’il teste.
Un cas de test doit pouvoir :
être exécuté complètement seul, sans entrée humaine. Les tests
unitaires sont une question d’automatisation.
déterminer lui-même si la fonction qu’il teste passe ou échoue
au test, sans interprétation humaine du résultat.
être exécuté de manière isolée, séparée de tout autre cas de
test (même concernant la même fonction). Chaque cas de test est une
île.
Sachant cela, construisons notre premier cas de test. Nous avons
la spécification suivante :
toRoman doit retourner la représentation
en chiffres romains de tous les entiers entre 1
et 3999.
Pour écrire un cas de test, commencez par dériver de la
classe TestCase du module unittest. Cette classe fournit de
nombreuses méthodes utiles que vous pouvez utiliser dans vos cas
de test pour tester de conditions spécifiques.
Voici un liste de paires entier/romains que j’ai vérifié manuellement. Elle comprend les dix plus petits
nombres, le plus grand nombre, chaque nombre représenté par un
seul caractère en chiffres romains et un échantillon aléatoire d’autres
nombres valides. Le but d’un test unitaire n’est pas de tester
toutes les entrées possibles, mais d’en tester un échantillon
représentatif.
Chaque test individuel est sa propre méthode, qui ne doit
prendre aucun paramètre et ne retourner aucune valeur. Si la
méthode sort normalement sans déclencher d’exception, le test on
considère que le test est passé, si la méthode déclenche une
exception, on considère que le test a échoué.
Ici, nous appelons la véritable fonction
toRoman (pour l’instant la fonction n’a pas encore
été écrite, mais quand elle le sera, c’est cette ligne qui
l’appellera). Remarquez que nous avons maintenant défini
l’interface de la fonction toRoman : elle
doit prendre un entier en paramètre (le nombre à convertir) et
renvoyer une chaîne (les chiffres romains). Si l’interface est
différente de ça, on considère que le test a échoué.
Remarquez également que nous ne tentons d’intercepter aucune
exception quand nous appelons toRoman. C’est intentionnel. toRoman
ne devrait pas
déclencher d’exception lorsque nous l’appelons avec des paramètres
d’entrée valides et ces valeurs sont toutes valides. Si
toRoman déclenche une exception, on considère que le test a échoué.
En supposant que la fonction toRoman a
été définie correctement, appelée correctement, qu’elle s’est
terminée avec succès et qu’elle a retourné une valeur, la dernière
étape et de vérifier qu’elle a retourné la
bonne valeur. C’est une question courante et
la classe TestCase fournit une méthode,
assertEqual, pour vérifier si deux valeurs
sont égales. Si le résultat retourné par
toRoman (result) ne
correspond pas à la valeur connue que nous attendions
(numeral), assertEqual
déclenche une exception et le test échoue. Si les deux valeurs
sont égales, assertEqual ne fera rien. Si
chaque valeur retourné par toRoman correspond
à la valeur connue que nous attendons,
assertEqual ne déclenchera jamais
d’exception, donc testToRomanKnownValues se
terminera finalement normalement, ce qui signifie que
toRoman a passé ce test.