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.Python - doctest vs. unittest
¿Para qué condiciones usarías cada una?
Ambos son valiosos. Utilizo tanto doctest como nose tomando el lugar de unittest. Utilizo doctest para los casos en que la prueba da un ejemplo de uso que es realmente útil como documentación. En general, no hago estas pruebas exhaustivas, con el objetivo únicamente informativo. Estoy usando efectivamente doctest en reversa: no para probar que mi código es correcto basado en mi doctest, pero para verificar que mi documentación sea correcta en base al código.
La razón es que creo que los doctests exhaustivos llenarán demasiado tu documentación, por lo que terminarás con documentos inutilizables o pruebas incompletas.
Para realmente probar el código , el objetivo es probar minuciosamente cada caso, en lugar de ilustrar lo que se hace con el ejemplo, que es un objetivo diferente que creo que se cumple mejor en otros marcos.
Utilizo unittest casi exclusivamente.
De vez en cuando, coloco algunas cosas en un docstring que Doctest puede usar.
95% de los casos de prueba son unittest.
¿Por qué? Me gusta mantener las cadenas de documentos algo más cortas y más al grano. A veces, los casos de prueba ayudan a aclarar una docstring. La mayoría de las veces, los casos de prueba de la aplicación son demasiado largos para una docstring.
Si recién está comenzando con la idea de la prueba unitaria, comenzaría con doctest porque es muy fácil de usar. También proporciona naturalmente algún nivel de documentación. Y para realizar pruebas más exhaustivas con doctest, puede colocar las pruebas en un archivo externo para que no obstruya su documentación.
Sugeriría unittest si vienes de un trasfondo de haber usado JUnit o algo similar, donde deseas poder escribir pruebas unitarias en general de la misma manera que has estado en otro lugar.
Me animaron en esta dirección ('doctest' para empezar), pero finalmente me arrepentí.Para casos de prueba no triviales, perdí el resaltado de sintaxis y la finalización automática de mi editor. Cuando las pruebas estaban en un archivo separado, ya no podía ejecutarlo directamente desde el editor; tendría que volver a cambiar el contexto al archivo fuente correspondiente cada vez. – Oddthinking
Casi nunca uso doctests. Quiero que mi código sea auto documentado, y las cadenas de documentación proporcionan la documentación al usuario. IMO agregar cientos de líneas de pruebas a un módulo hace que los documentos sean mucho menos legibles. También encuentro que las pruebas unitarias son más fáciles de modificar cuando es necesario.
Uso unittest exclusivamente; Creo que el doctest hace demasiado ruido en 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 módulo doctest proporciona los métodos DoctTestSuite y DocFileSuite que crean un conjunto de pruebas compatible con unittest desde un módulo o archivo, respectivamente.
Así que uso ambos y usualmente uso doctest para pruebas simples con funciones que requieren poca o ninguna configuración (tipos simples para argumentos). De hecho, creo que algunas pruebas más doctest ayudan a 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, uso unittest que proporciona más control y flexibilidad.
Prefiero los sistemas basados en descubrimiento ("nose" y "py.test", usando actualmente el primero).
doctest es bueno cuando la prueba también es buena como documentación, de lo contrario, tienden a saturar el código demasiado.
nariz se ve increíblemente útil; No he tenido la oportunidad de usarlo todavía, pero tengo muchas esperanzas :) –
nose es el marco de prueba más fácil de usar, IMO. Hace que escribir y ejecutar casos de prueba sea más sencillo. –
Otra ventaja de doctesting es que usted se asegura 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. :-)
+1 de mí - excelente punto – doug
Trabajo como bioinformática, y la mayor parte del código que escribo es "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 tests unitarios grandes puede ser excesivo, y los doctests son un compromiso útil. Son más rápidos de escribir, y dado que generalmente están incorporados en el código, permiten estar siempre atentos a cómo debe comportarse el código, sin tener que abrir otro archivo. Eso es útil al escribir pequeños guiones.
Además, los doctests son útiles cuando tiene que pasar su script a un investigador que no es experto en programación. A algunas personas les resulta muy difícil comprender cómo están estructuradas las pruebas unitarias; por otro lado, los doctests son ejemplos simples de uso, por lo que las personas solo pueden 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 los investigadores que no son informáticos.
"doctests son útiles cuando tienes que escribir pequeños guiones, y cuando tienes que pasarlos o mostrarlos a los investigadores que no son informáticos." Excelente punto. Hago lo mismo y los programadores que no son python siempre se sorprenden de que la documentación se pueda ejecutar. –
No uso doctest como sustituto de unittest. A pesar de que se superponen un poco, los dos módulos no tienen la misma función:
utilizo unittest como un marco de pruebas de unidad, lo que significa que ayuda a determinar rápidamente el impacto de cualquier modificación en el resto del código .
Uso doctest como garantía de que los comentarios (a saber, docstrings) siguen siendo relevantes para la versión actual del código.
Los beneficios ampliamente documentados del desarrollo impulsado por pruebas que obtengo de unittest. doctest resuelve el peligro mucho más sutil de tener comentarios desactualizados que confunden el mantenimiento del código.
Doctest veces puede dar lugar 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.
también no comprueba el tipo de la salida. Simplemente compara las cadenas de salida. Por ejemplo, ha hecho que algún tipo sea racional y se imprime igual que un entero si se trata de un número entero. Entonces supongamos que tiene una función que vuelve racional. Por lo tanto, un doctest no diferenciará si el resultado es un número entero racional o un número entero.
Puede usar cadenas de documentos en bruto ('r" "" ... "" "') para solucionar el primer problema. – icktoofay
Funciona bien en Python 3.4. Para que funcione también en Python 2.7, use ''\\ xe0 \\ xa4 \\ x95'' en su docstring. –
También encontré que los literales unicode tampoco funcionan con doctests (incluso con la línea de comentario correcta 'codificación utf-8' en la parte superior del archivo. Generalmente los doctest no son tan compatibles como las pruebas unittest, por lo que hay algunos errores que no se solucionan – RichVel
¿Por qué utilizar nose over unittest? – Sean
Hay mucho menos texto estándar, y las pruebas son mucho más simples de escribir (y leer). El bajo costo de inicio para escribir pruebas (es decir, simplemente escribir una función "test_foo()" e ir) también ayuda a combatir la tentación de hacer los bits del código interesante antes de clavar sus pruebas. – Brian
Creo que esta es una respuesta fantástica. –