Python - doctest vs unittest [cerrado]

Uso unittest casi exclusivamente.

De vez en cuando, voy a poner algunas cosas en un docstring que es utilizable por doctest.

El 95% de los casos de prueba son unittest.

¿Por qué? Me gusta mantener las cuerdas un poco más cortas y más al grano. A veces, los casos de prueba ayudan a aclarar un docstring. La mayoría de las veces, los casos de prueba de la aplicación son demasiado largos para un docstring.

Otra ventaja de doctesting es que puedes asegurarte de que tu código hace 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. :-)

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 sola tarea específica.

En esta situación, escribir grandes unittests puede ser excesivo, y los doctests son un compromiso útil. Son más rápidos de escribir, y dado que generalmente se incorporan en el código, permiten mantener siempre un ojo en cómo debe comportarse el código, sin tener que tener otro archivo abierto. Eso es útil cuando escribiendo pequeños guiones.

Además, las pruebas de documentos 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 entender cómo se estructuran los unittests; por otro lado, los doctests son ejemplos simples de uso, por lo que la gente puede copiarlos y pegarlos para ver cómo usarlos.

Entonces, para resumir mi respuesta: los doctests son útiles cuando tienes que escribir pequeños scripts, y cuando tienes que pasarlos o mostrarlos a los investigadores que no son científicos de la computación.

Si acabas de empezar con la idea de las pruebas unitarias, empezaría con doctest porque es muy fácil de usar. También proporciona, naturalmente, cierto nivel de documentación. Y para pruebas más completas con doctest, puede colocar pruebas en un archivo externo para que no sature su documentación.

Sugeriría unittest si vienes de un fondo de haber usado JUnit o algo similar, donde quieres ser capaz de escribir pruebas unitarias en general de la misma manera como has estado en otra parte.

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 testsuite compatible con unittest a partir de un módulo o archivo, respectivamente.

Así que uso ambos y normalmente uso doctest para pruebas simples con funciones que requieren poca o ninguna configuración (tipos simples para argumentos). En realidad creo que algunas pruebas doctest ayudan a documentar la función, en lugar de restarle valor.

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

Utilizo unittest exclusivamente; creo que doctest estorba demasiado el módulo principal. Esto probablemente tiene que ver con escribir pruebas exhaustivas.

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 un marco de pruebas unitarias, lo que significa que me ayuda a determinar rápidamente el impacto de cualquier modificación en el resto del código.

• Utilizo doctest como garantía de que los comentarios (es decir, docstrings) siguen siendo relevantes para la versión actual del código.

Los beneficios ampliamente documentados de las pruebas desarrollo que obtengo de unittest. doctest resuelve el peligro mucho más sutil de tener comentarios obsoletos que engañan el mantenimiento del código.

Casi nunca uso pruebas médicas. Quiero que mi código se documente por sí mismo, y los docstrings proporcionan la documentación al usuario. IMO la adición de cientos de líneas de pruebas a un módulo hace que las cuerdas docstrings sean mucho menos legibles. También encuentro las pruebas unitarias más fáciles de modificar cuando es necesario.

Doctest algunas veces puede llevar al 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 comprueba el tipo de salida. Simplemente compara las cadenas de salida. Por ejemplo, ha hecho algún tipo racional que imprime como entero si es un número entero. Entonces supongamos 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.