EDITAR: cambió a un mejor ejemplo y aclaró por qué esto es un problema real.
Me gustaría escribir pruebas unitarias en Python que continúen ejecutándose cuando falla una afirmación, para poder ver múltiples fallas en una sola prueba. Por ejemplo:
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!
Aquí, el propósito de la prueba es asegurarse de que Car's __init__configure sus campos correctamente. Podría dividirlo en cuatro métodos (y eso suele ser una gran idea), pero en este caso creo que es más legible mantenerlo como un método único que prueba un concepto único ("el objeto se inicializa correctamente").
Si asumimos que es mejor no dividir el método, entonces tengo un nuevo problema: no puedo ver todos los errores a la vez. Cuando soluciono el modelerror y vuelvo a ejecutar la prueba, wheel_countaparece el error. Me ahorraría tiempo ver ambos errores cuando ejecute la prueba por primera vez.
A modo de comparación, el marco de pruebas unitarias C ++ de Google distingue entreEXPECT_* afirmaciones no fatales y ASSERT_*afirmaciones fatales :
Las afirmaciones vienen en pares que prueban lo mismo pero tienen diferentes efectos en la función actual. Las versiones ASSERT_ * generan fallas fatales cuando fallan y abortan la función actual. Las versiones EXPECT_ * generan fallas no fatales, que no abortan la función actual. Por lo general, se prefieren EXPECT_ *, ya que permiten informar más de una falla en una prueba. Sin embargo, debe usar ASSERT_ * si no tiene sentido continuar cuando falla la afirmación en cuestión.
¿Hay alguna manera de obtener un EXPECT_*comportamiento similar en Python unittest? Si no está dentro unittest, ¿hay otro marco de prueba unitario de Python que admita este comportamiento?
Por cierto, tenía curiosidad acerca de cuántas pruebas de la vida real podrían beneficiarse de afirmaciones no fatales, así que miré algunos ejemplos de código (editado 2014-08-19 para usar el código de búsqueda en lugar de Google Code Search, RIP). De los 10 resultados seleccionados al azar de la primera página, todos contenían pruebas que realizaban múltiples afirmaciones independientes en el mismo método de prueba. Todos se beneficiarían de afirmaciones no fatales.