setup - Python-doctest vs. unittest

unit test en python (11)

Ambos son valiosos Uso ambos doctest y 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 desordenarán demasiado tu documentación, por lo que terminarás con docstrings inutilizables o pruebas incompletas.

Para probar realmente 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.

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.

¿Qué condiciones usarías cada uno?

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.

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

Utilizo unittest como marco de prueba de unidades, lo que significa que me 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 obsoletos que confunden el mantenimiento del código.

Otra ventaja de doctesting es que te aseguras de que tu código haga lo que tu 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. :-)

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 demasiado el código.

Trabajo como bioinformática, y la mayor parte del código que escribo es 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 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 tienes que pasar tu 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 investigadores que no son informáticos.

Usar ambos es una opción válida y bastante simple. El módulo más doctest proporciona los métodos DoctTestSuite y DocFileSuite que crean un conjunto de pruebas compatible con la unidad desde 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 más doctorales 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.

Yo uso unittest casi exclusivamente.

De vez en cuando, coloco algunas cosas en un docstring que Doctest puede usar.

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 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.

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

Doctest algunas veces puede llevar a resultados incorrectos. 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()

********************************************************************** 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 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.

Si recién está empezando con la idea de las pruebas unitarias, empezarí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 una prueba de unidad 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.