¿Hay algún valor en escribir una prueba unitaria que sea un subconjunto de otra prueba?

14

Para dar un ejemplo ligeramente artificial, digamos que quiero probar que una función devuelve dos números y que el primero es más pequeño que el segundo:

def test_length():
    result = my_function()
    assert len(result) == 2

def test_order()
    a, b = my_function()
    assert a < b

Aquí, si test_length falla, entonces test_order también fallará. ¿Es una buena práctica escribir test_length o omitirlo?

EDITAR: tenga en cuenta que en esta situación, ambas pruebas son en su mayoría independientes entre sí, cada una se puede ejecutar de forma aislada, o se podrían ejecutar en orden inverso, esto no importa. Así que ninguna de estas preguntas anteriores

es un duplicado del anterior.

    
pregunta Mihai 12.01.2015 - 16:24
fuente

4 respuestas

28

Puede haber valor, pero esto es un poco de olor. O tus pruebas no están bien aisladas (ya que test_order realmente prueba dos cosas) o estás siendo demasiado dogmático en tus pruebas (haciendo que dos pruebas prueben la misma cosa lógica).

En el ejemplo, fusionaría las dos pruebas juntas. Sí, significa que tienes múltiples afirmaciones. Demasiado. Todavía estás probando una sola cosa: el resultado de la función. A veces, en el mundo real, eso significa hacer dos comprobaciones.

    
respondido por el Telastyn 12.01.2015 - 16:34
fuente
5

Sus pruebas deben ser explícitas. No se deduce completamente que si se produce un error en text_length, test_order falla.

No estoy seguro de cómo va en Python que has publicado, pero si len(result) es 3, el primero fallará, pero el segundo puede pasar (y si no está en Python, entonces en idiomas como JavaScript, sin duda ).

Como usted dijo, quiere probar que la función devuelve dos números y que están en orden. Dos pruebas es.

    
respondido por el Madara Uchiha 12.01.2015 - 16:34
fuente
2

El único valor de test_length aquí es que, si todo pasa, su presencia indica que se ha probado la "longitud".

Por lo tanto, es realmente innecesario tener estas dos pruebas. Mantenga solo test_order , pero considere cambiarle el nombre a test_length_and_order .

Por cierto, me parece un poco torpe el uso de nombres que comienzan con test . Soy un firme defensor de los nombres de las pruebas que realmente describen la condición que usted está afirmando.

    
respondido por el Dawood ibn Kareem 12.01.2015 - 20:41
fuente
1

Dejaré estas pruebas separadas si así es como han evolucionado para ser. Sí, es probable que test_order falle cuando test_length lo haga, pero definitivamente sabes por qué.

También estoy de acuerdo en que si test_order apareciera primero y usted encontró un error comprobable fue que posiblemente el resultado no fue dos valores, agregar ese cheque como assert y cambiar el nombre de la prueba a test_length_and_order tiene sentido .

Si también tuviera que verificar que los tipos de valores devueltos fueran enteros, lo incluiría en esta prueba de resultados "omnibus".

Pero tenga en cuenta que ahora tiene una batería de pruebas para el resultado de my_function() . Si hay múltiples contextos (o, más probablemente, múltiples parámetros) para probar esto, ahora puede ser una subrutina para probar todos los resultados de my_function() .

Sin embargo, cuando escribo pruebas unitarias, normalmente pruebo los casos de borde y los malos por separado de la buena entrada y la salida normal (en parte porque la mayoría de mis pruebas de "unidad" son a menudo mini pruebas de integración) y, a menudo, con varias afirmaciones, que solo se dividen en pruebas separadas si fallan en formas en las que encuentro que quiero más información sin depurar.

Por lo tanto, probablemente comenzaría con sus pruebas separadas y expandiría de test_length a test_length_and_types y dejaría a test_order por separado, asumiendo que este último se considera "procesamiento normal".

    
respondido por el Mark Hurd 15.01.2015 - 02:21
fuente

Lea otras preguntas en las etiquetas