Python - doctest vs. unittest [cerrado]

Estoy tratando de comenzar con las pruebas unitarias en Python y me preguntaba si alguien podría explicar las ventajas y desventajas de doctest y unittest.

¿Para qué condiciones usarías cada uno?

Ambos son valiosos. Utilizo doctest y nose tomando el lugar de unittest. Utilizo doctest para casos en los que la prueba está dando un ejemplo de uso que es realmente útil como documentación. En general, no hago estas pruebas exhaustivas, con el único objetivo de informar. Efectivamente estoy usando doctest a la inversa: no para probar que mi código es correcto según mi doctest, sino para verificar que mi documentación sea correcta según el código.

La razón es que creo que los doctest completos saturarán demasiado tu documentación, por lo que terminarás con cadenas de documentos inutilizables o pruebas incompletas.

Para probar realmente el código , el objetivo es probar a fondo cada caso, en lugar de ilustrar lo que se hace con el ejemplo, que es un objetivo diferente que creo que otros marcos cumplen mejor.

Yo uso unittest casi exclusivamente.

De vez en cuando, pondré algunas cosas en una cadena de documentos que puede ser utilizada por doctest.

El 95% de los casos de prueba son unittest.

¿Por qué? Me gusta mantener las cadenas de documentos algo más cortas y más precisas. A veces, los casos de prueba ayudan a aclarar una cadena de documentos. La mayoría de las veces, los casos de prueba de la aplicación son demasiado largos para una cadena de documentos.

Otra ventaja del doctesting es que puede asegurarse de que su código haga lo que su documentación dice que hace. Después de un tiempo, los cambios de software pueden hacer que su documentación y código hagan cosas diferentes. :-)

Trabajo como bioinformático, y la mayor parte del código que escribo son scripts de "una vez, una tarea", código que se ejecutará solo una o dos veces y que ejecutará una única tarea específica.

En esta situación, escribir grandes pruebas unitarias puede ser excesivo, y las pruebas de documentación son un compromiso útil. Son más rápidos de escribir, y dado que generalmente se incorporan al código, permiten vigilar siempre cómo debe comportarse el código, sin tener que tener otro archivo abierto. Eso es útil al escribir pequeños guiones.

Además, los doctest son útiles cuando tienes que pasar tu guión a un investigador que no sea experto en programación. A algunas personas les resulta muy difícil entender cómo se estructuran las pruebas unitarias; Por otro lado, los doctest son ejemplos simples de uso, por lo que las personas pueden simplemente copiarlos y pegarlos para ver cómo usarlos.

Entonces, para resumir mi respuesta: los doctests son útiles cuando tienes que escribir pequeños guiones, y cuando tienes que pasarlos o mostrarlos a investigadores que no son informáticos.

Si recién está comenzando con la idea de las pruebas unitarias, comenzaría doctestporque es muy fácil de usar. También, naturalmente, proporciona cierto nivel de documentación. Y para realizar pruebas más exhaustivas con doctest, puede colocar pruebas en un archivo externo para que no abarrote su documentación.

Sugeriría que unittestsi viene de un contexto de haber usado JUnit o algo similar, donde desea poder escribir pruebas unitarias en general de la misma manera que lo ha hecho en otros lugares.

Yo uso unittest exclusivamente; Creo que doctest satura demasiado el módulo principal. Esto probablemente tiene que ver con escribir pruebas exhaustivas.

Usar ambos es una opción válida y bastante simple. El doctestmódulo proporciona el DoctTestSuiteyDocFileSuite métodos que crean un conjunto de pruebas compatible con unittest a partir de un módulo o archivo, respectivamente.

Por lo tanto, uso ambos y normalmente uso doctest para pruebas simples con funciones que requieren poca o ninguna configuración (tipos simples para argumentos). De hecho, creo que algunas pruebas doctest ayudan documentar la función, en lugar de restarle valor.

Pero para casos más complicados y para un conjunto más completo de casos de prueba, utilizo unittest que proporciona más control y flexibilidad.

No uso doctest como reemplazo de unittest. Aunque se superponen un poco, los dos módulos no tienen la misma función:

• Lo uso unittestcomo un marco de prueba de unidad, lo que significa que me ayuda a determinar rápidamente el impacto de cualquier modificación en el resto del código.

• Utilizo doctestcomo garantía de que los comentarios (es decir, las cadenas de documentos) siguen siendo relevantes para la versión actual del código.

Los beneficios ampliamente documentados del desarrollo impulsado por pruebas que obtengo unittest. doctestresuelve el peligro mucho más sutil de tener comentarios desactualizados que confunden el mantenimiento del código.

Casi nunca uso doctests. Quiero que mi código sea autodocumentado, y las cadenas de documentos proporcionan la documentación al usuario. La OMI que agrega cientos de líneas de pruebas a un módulo hace que las cadenas de documentos sean mucho menos legibles. También encuentro que las pruebas unitarias son más fáciles de modificar cuando es necesario.

DoctestAlgunas veces puede conducir a un resultado incorrecto. Especialmente cuando la salida contiene secuencias de escape. Por ejemplo

def convert():
    """
    >>> convert()
    '\xe0\xa4\x95'
    """
    a = '\xe0\xa4\x95'
    return a
import doctest
doctest.testmod()

da

**********************************************************************
File "hindi.py", line 3, in __main__.convert
Failed example:
    convert()
Expected:
    'क'
Got:
    '\xe0\xa4\x95'
**********************************************************************
1 items had failures:
   1 of   1 in __main__.convert
***Test Failed*** 1 failures. 

Tampoco verifica el tipo de salida. Simplemente compara las cadenas de salida. Por ejemplo, ha hecho un tipo racional que imprime igual que un número entero si es un número entero. Entonces suponga que tiene una función que devuelve racional. Por lo tanto, un doctest no diferenciará si la salida es un número entero racional o un número entero.

Prefiero los sistemas basados ​​en descubrimiento ("nose" y "py.test", usando el primero actualmente).

doctest es bueno cuando la prueba también es buena como documentación, de lo contrario, tienden a saturar demasiado el código.