13.4. Tester la réussite

13.4. Tester la réussite

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.

Exemple 13.2. `testToRomanKnownValues`


class KnownValues(unittest.TestCase):                           
    knownValues = ( (1, 'I'),
                    (2, 'II'),
                    (3, 'III'),
                    (4, 'IV'),
                    (5, 'V'),
                    (6, 'VI'),
                    (7, 'VII'),
                    (8, 'VIII'),
                    (9, 'IX'),
                    (10, 'X'),
                    (50, 'L'),
                    (100, 'C'),
                    (500, 'D'),
                    (1000, 'M'),
                    (31, 'XXXI'),
                    (148, 'CXLVIII'),
                    (294, 'CCXCIV'),
                    (312, 'CCCXII'),
                    (421, 'CDXXI'),
                    (528, 'DXXVIII'),
                    (621, 'DCXXI'),
                    (782, 'DCCLXXXII'),
                    (870, 'DCCCLXX'),
                    (941, 'CMXLI'),
                    (1043, 'MXLIII'),
                    (1110, 'MCX'),
                    (1226, 'MCCXXVI'),
                    (1301, 'MCCCI'),
                    (1485, 'MCDLXXXV'),
                    (1509, 'MDIX'),
                    (1607, 'MDCVII'),
                    (1754, 'MDCCLIV'),
                    (1832, 'MDCCCXXXII'),
                    (1993, 'MCMXCIII'),
                    (2074, 'MMLXXIV'),
                    (2152, 'MMCLII'),
                    (2212, 'MMCCXII'),
                    (2343, 'MMCCCXLIII'),
                    (2499, 'MMCDXCIX'),
                    (2574, 'MMDLXXIV'),
                    (2646, 'MMDCXLVI'),
                    (2723, 'MMDCCXXIII'),
                    (2892, 'MMDCCCXCII'),
                    (2975, 'MMCMLXXV'),
                    (3051, 'MMMLI'),
                    (3185, 'MMMCLXXXV'),
                    (3250, 'MMMCCL'),
                    (3313, 'MMMCCCXIII'),
                    (3408, 'MMMCDVIII'),
                    (3501, 'MMMDI'),
                    (3610, 'MMMDCX'),
                    (3743, 'MMMDCCXLIII'),
                    (3844, 'MMMDCCCXLIV'),
                    (3888, 'MMMDCCCLXXXVIII'),
                    (3940, 'MMMCMXL'),
                    (3999, 'MMMCMXCIX'))                        

    def testToRomanKnownValues(self):                           
        """toRoman should give known result with known input"""
        for integer, numeral in self.knownValues:              
            result = roman.toRoman(integer)                      
            self.assertEqual(numeral, result)

	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.