¿Reutilización del código en pruebas unitarias?

Question

Sigo escuchando a la gente decir que las pruebas deberían ser simples, fáciles de mantener y directas, pero ¿qué sucede con la reutilización del código en las pruebas unitarias?

Tomemos por ejemplo:

def test_some_1():
    ...some code

def test_some_2():
    ...code repeated from test_some_1

¿No sería mejor encapsular el código repetido de las dos pruebas en una función que contenga las afirmaciones necesarias?

He discutido con algunos programadores sobre esto y no están de acuerdo, dijeron que las pruebas deberían ser tontas, que la reutilización del código no es buena aquí.La razón de esto es porque no está muy claro en la consola de Django dónde falló realmente la aserción, porque la aserción estaba en la función, aunque no estoy de acuerdo porque usarlo con nose te daría el nombre de la prueba y el rastreo, aunque Los chicos volvieron a no estar de acuerdo, afirmando que se podía invocar una prueba individualmente sin nariz (y por lo tanto no se podían ver todos esos detalles).

¿Qué piensan ustedes?

• ¿Es bueno utilizar la reutilización del código en pruebas unitarias?
• Si se puede/debe utilizar la reutilización, ¿cómo superar el otro problema relacionado con la localización de las afirmaciones?

Answer 1

Los factores más importantes para la calidad del código, como la claridad y la legibilidad, también lo son para el código de prueba.Si la repetición del código facilita la lectura, debe hacerlo independientemente de si lo que está escribiendo es un código de prueba y viceversa.

Por ejemplo, en un paquete que escribí, tenía una función:

def _test_vector(self, a, b, c):
    # test the function with parameter values a, b, c
    # several asserts here to verify output of function tested

Eso permitió escribir todos los vectores de prueba como:

def test_vector1(self):
    self._test_vector(a=42, b=5, c="blah)

Eso, en mi opinión, mejora la claridad, porque las pruebas individuales solo incluyen la información específica de esa prueba.

Identificar afirmaciones siempre debería ser fácil.Incluso unittest le dará un rastreo, y si su configuración de prueba no apunta a una afirmación en particular, le resultará difícil depurar cualquier falla de prueba y definitivamente deberá cambiar a algo sensato.

Answer 2

Como dijeron sus compañeros, debe escribir sus pruebas tontas.Hay varias razones para esto, la más importante es que desea evitar la lógica compleja en las pruebas.Si escribe sus pruebas "SMART", tienden a contener la misma lógica o similar, ya que el código está intentando probar.Esto significa que usted corre el riesgo de cometer el mismo error en ambos lugares y se perderá los insectos que desea encontrar.

Otra razón es que desea que su examen actúe como documentación del código que está intentando probar.Si la prueba tiene una ruta de ejecución compleja a través de muchas funciones y lógica, no será tan fácil de entender.En el mejor de los mundos, vería cómo se pretende que el código de producción funcione simplemente haciendo un vistazo a la prueba.