Poursuivre dans l'unittest de Python lorsqu'une assertion échoue

Question

EDIT : changement pour un meilleur exemple, et clarification de la raison pour laquelle c'est un vrai problème.

J'aimerais écrire des tests unitaires en Python qui continuent à s'exécuter lorsqu'une assertion échoue, afin de pouvoir voir plusieurs échecs dans un seul test. Par exemple :

class Car(object):
  def __init__(self, make, model):
    self.make = make
    self.model = make  # Copy and paste error: should be model.
    self.has_seats = True
    self.wheel_count = 3  # Typo: should be 4.

class CarTest(unittest.TestCase):
  def test_init(self):
    make = "Ford"
    model = "Model T"
    car = Car(make=make, model=model)
    self.assertEqual(car.make, make)
    self.assertEqual(car.model, model)  # Failure!
    self.assertTrue(car.has_seats)
    self.assertEqual(car.wheel_count, 4)  # Failure!

Ici, l'objectif du test est de s'assurer que Car's __init__ définit ses champs correctement. Je pourrais le décomposer en quatre méthodes (et c'est souvent une bonne idée), mais dans ce cas, je pense qu'il est plus lisible de le garder comme une seule méthode qui teste un seul concept ("l'objet est initialisé correctement").

Si nous supposons qu'il est préférable ici de ne pas fragmenter la méthode, j'ai alors un nouveau problème : je ne peux pas voir toutes les erreurs en même temps. Lorsque je corrige la model et ré-exécuter le test, alors l'option wheel_count erreur apparaît. Cela me ferait gagner du temps de voir les deux erreurs lorsque je lance le test pour la première fois.

À titre de comparaison, le cadre de test unitaire C++ de Google fait la distinction entre entre les cas non mortels EXPECT_* assertions et fatalité ASSERT_* les assertions :

Les assertions sont présentées par paires et testent la même chose mais ont des effets différents sur la fonction courante. Les versions ASSERT_* génèrent des échecs fatals lorsqu'elles échouent, et interrompent la fonction courante. Les versions EXPECT_* génèrent des échecs non fatals, qui n'interrompent pas la fonction courante. En général, les versions EXPECT_* sont préférées, car elles permettent de signaler plusieurs échecs dans un test. Cependant, vous devriez utiliser ASSERT_* si cela n'a pas de sens de continuer lorsque l'assertion en question échoue.

Y a-t-il un moyen d'obtenir EXPECT_* -dans le langage Python unittest ? Si ce n'est pas le cas unittest Dans ce cas, existe-t-il un autre cadre de test unitaire Python qui supporte ce comportement ?

---

Par ailleurs, j'étais curieux de savoir combien de tests réels pouvaient bénéficier d'assertions non fatales. exemples de code (édité le 2014-08-19 pour utiliser searchcode au lieu de Google Code Search, RIP). Sur 10 résultats choisis au hasard sur la première page, tous contenaient des tests qui faisaient plusieurs assertions indépendantes dans la même méthode de test. Tous bénéficieraient d'assertions non fatales.

Answer 1

Une autre façon d'avoir des assertions non fatales est de capturer l'exception d'assertion et de stocker les exceptions dans une liste. Puis d'affirmer que cette liste est vide dans le cadre du tearDown.

import unittest

class Car(object):
  def __init__(self, make, model):
    self.make = make
    self.model = make  # Copy and paste error: should be model.
    self.has_seats = True
    self.wheel_count = 3  # Typo: should be 4.

class CarTest(unittest.TestCase):
  def setUp(self):
    self.verificationErrors = []

  def tearDown(self):
    self.assertEqual([], self.verificationErrors)

  def test_init(self):
    make = "Ford"
    model = "Model T"
    car = Car(make=make, model=model)
    try: self.assertEqual(car.make, make)
    except AssertionError, e: self.verificationErrors.append(str(e))
    try: self.assertEqual(car.model, model)  # Failure!
    except AssertionError, e: self.verificationErrors.append(str(e))
    try: self.assertTrue(car.has_seats)
    except AssertionError, e: self.verificationErrors.append(str(e))
    try: self.assertEqual(car.wheel_count, 4)  # Failure!
    except AssertionError, e: self.verificationErrors.append(str(e))

if __name__ == "__main__":
    unittest.main()

Answer 2

Une option est d'asserter sur toutes les valeurs à la fois comme un tuple.

Par exemple :

class CarTest(unittest.TestCase):
  def test_init(self):
    make = "Ford"
    model = "Model T"
    car = Car(make=make, model=model)
    self.assertEqual(
            (car.make, car.model, car.has_seats, car.wheel_count),
            (make, model, True, 4))

Le résultat de ces tests serait :

======================================================================
FAIL: test_init (test.CarTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "C:\temp\py_mult_assert\test.py", line 17, in test_init
    (make, model, True, 4))
AssertionError: Tuples differ: ('Ford', 'Ford', True, 3) != ('Ford', 'Model T', True, 4)

First differing element 1:
Ford
Model T

- ('Ford', 'Ford', True, 3)
?           ^ -          ^

+ ('Ford', 'Model T', True, 4)
?           ^  ++++         ^

Cela montre que le modèle et le nombre de roues sont tous deux incorrects.

Answer 3

Ce que vous voudrez probablement faire c'est dériver unittest.TestCase puisque c'est la classe qui est lancée lorsqu'une assertion échoue. Vous devrez ré-architecturer votre TestCase à ne pas lancer (peut-être garder une liste d'échecs à la place). La ré-architecture peut causer d'autres problèmes que vous devrez résoudre. Par exemple, vous pouvez finir par avoir besoin de dériver TestSuite pour effectuer des changements en support des modifications apportées à votre TestCase .

Answer 4

Il est considéré comme un anti-modèle d'avoir plusieurs assertions dans un seul test unitaire. Un test unitaire unique est censé tester une seule chose. Peut-être testez-vous trop de choses. Envisagez de diviser ce test en plusieurs tests. De cette façon, vous pourrez nommer chaque test correctement.

Parfois, cependant, il est bon de vérifier plusieurs choses en même temps. Par exemple, lorsque vous affirmez les propriétés d'un même objet. Dans ce cas, vous vérifiez en fait si cet objet est correct. Une façon de procéder est d'écrire une méthode d'aide personnalisée qui sait comment affirmer sur cet objet. Vous pouvez écrire cette méthode de manière à montrer toutes les propriétés qui échouent ou, par exemple, à montrer l'état complet de l'objet attendu et l'état complet de l'objet réel lorsqu'une assertion échoue.

Answer 5

Faites chaque assertion dans une méthode séparée.

class MathTest(unittest.TestCase):
  def test_addition1(self):
    self.assertEqual(1 + 0, 1)

  def test_addition2(self):
    self.assertEqual(1 + 1, 3)

  def test_addition3(self):
    self.assertEqual(1 + (-1), 0)

  def test_addition4(self):
    self.assertEqaul(-1 + (-1), -1)