IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
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 :

  1. 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):                           1
    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'))                        2

    def testToRomanKnownValues(self):                           3
        """toRoman should give known result with known input"""
        for integer, numeral in self.knownValues:              
            result = roman.toRoman(integer)                     4 5
            self.assertEqual(numeral, result)                   6
1 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.
2 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.
3 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é.
4 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é.
5 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é.
6 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.