Marco preferido de pruebas de unidades Python

Question

Hasta ahora he estado usando el módulo unittest incorporado (pyUnit) para probar unidades de código Python. Sin embargo, para casos simples, parece exagerado. Siendo un derivado de xUnit, parece un poco pesado para la naturaleza dinámica de Python, donde esperaría escribir menos para lograr los mismos efectos. Por otro lado, está incorporado, te hace escribir tus pruebas de una manera organizada, y se prueba por tiempo.

Las principales alternativas que he visto en línea son:

• py.test
• nose

¿Cuál de los marcos es lo que prefiere, y por qué?

---

actualización 10.12.2011: con la reciente incorporación de la prueba de auto-descubrimiento y muchas nuevas características en unittest (en Python 2.7 y 3.2), en mi humilde opinión tiene menos sentido usar una biblioteca externa.

---

En cuanto doctest: Yo no lo considero un marco pruebas unitarias per se. Definitivamente no lo usaría para escribir un gran conjunto de pruebas para una aplicación considerable. doctest es más adecuado para asegurarse de que los ejemplos que proporciona en la documentación funcionen. Tiene su lugar para esta necesidad, pero no es un competidor para unittest, py.test y otros frameworks.

Answer 1

nose no es realmente un marco de pruebas de unidad. Es un corredor de prueba y uno excelente en eso. Puede ejecutar pruebas creadas usando unittest, py.test o doctest.

Mi preferencia para el marco de pruebas unitarias es el módulo estándar unittest (también conocido como pyUnit). Es similar a otros marcos xUnit y es fácil de relacionar para personas sin antecedentes de python. También hay un soporte bastante bueno para él en Eclipse/PyDev

En py.test, encuentro que varios niveles de configuración/desmantelamiento son muy confusos. También encuentro que conduce a pruebas unitarias altamente desestructuradas y difíciles de leer.

doctest está bien para cosas simples, pero me parece que es muy limitante y realmente no escala para código complejo y altamente interactivo.

Answer 2

Siempre hay doctest si desea mantener las pruebas de su unidad cerca del código.

HTH

Answer 3

Acabo de utilizar el estándar unittest. No estoy seguro de cómo escribir pruebas tan efectivamente con otro estilo, tal vez cada prueba en una función, pero ¿cómo manejarías la configuración/desmontaje?

Answer 4

El unittest.TestCase es una clase. Siéntase libre de subclasificarlo con sus propias funciones complementarias que le permiten "escribir menos para lograr los mismos efectos".

Answer 5

Una de las mejores características de nose es su sistema de complementos: por ejemplo, el plugin de cobertura le muestra qué parte de su código está cubierto por unittests.Después de escribir muchas pruebas unitarias, a menudo es sorprendente ver cuánto de su código no está cubierto ...

Answer 6

nose2 ha reemplazado la nariz y admite parameterized tests lo que significa que puede ejecutar las mismas aserciones con diferentes parámetros. Esto le permite cubrir más escenarios con mucho menos código.

Answer 7

Estoy de acuerdo en que una de las mejores características de la nariz es su sistema de complemento. Por ejemplo, comencé a aprender Python cuando se lanzó Google App Engine y había un complemento de Nose para admitir GAE casi de inmediato. Así que Nose con sus complementos me ayudó a comenzar a hacer un desarrollo basado en pruebas con una nueva plataforma como GAE desde el principio. El plugin de cobertura estaba allí cuando yo también estaba preparado para eso.

Answer 8

Interesante que nadie ha respondido aún para defender py.test. En el testing-in-python mailing list es bastante popular, p. este hilo reciente "why do you use py.test?". La mayoría de las respuestas comunes incluyen:

• fácil de apoyo para la prueba distribuido
• arquitectura plugin bien
• afirmaciones más fácil (solo assert x == 42, sin assertEqual())
• funcargs (desde 2.3 o 2.4 llamados accesorios, algo diferente a lo otros marcos de prueba llame a los accesorios)

Answer 9

Creo que es una cuestión de elección realmente. He utilizado todos los principales marcos de prueba, se trata de cuál crees que hace el trabajo con menos codificación. Dicho esto, prefiero el doctest también.

Pero desde entonces he descubierto a Pytest y no he mirado hacia atrás alguna vez. Todavía uso doctest algunas veces pero prefiero usar pytest en nuevos proyectos.

Answer 10

Inicialmente comenzamos nuestro marco de automatización usando unittest y nosetest. Subclasificamos todas nuestras clases de prueba de unittest ya que unittest ofrece una gran sintaxis para las aserciones. Para la ejecución real de las pruebas, utilizamos nose, que era bastante bueno en términos de informes y especificando qué pruebas necesitaban ejecutarse. La lógica de generación de prueba también fue bastante buena: usar el método de rendimiento fue fácil de usar. El único problema con la generación de la prueba de nariz es que la clase de prueba no puede heredar de unittest, entonces la generación de prueba falla. Solo las afirmaciones de la nariz se pueden usar aquí.

Tuvimos problemas graves con la nariz cuando queríamos paralelizar las ejecuciones de prueba. Los informes extremadamente confusos resultaron cuando las pruebas se ejecutaron en paralelo. Además, si está creando ciertos recursos en los métodos de configuración, también la paralelización falla con errores extraños. Parecía muy complejo usar la nariz para paralelizar las carreras de prueba: probamos casi todo. Entonces, finalmente, uno de los miembros de nuestro equipo acude a py.test. En muy poco tiempo, pudo realizar los cambios necesarios en un conjunto de 30 pruebas para ejecutarlas en paralelo. Comenzó la carrera y para su sorpresa la carrera pasó en un récord de 15 minutos de los 75 minutos previos que solía tomar. Pudo ejecutar las 30 pruebas en paralelo con éxito con la menor cantidad de esfuerzo y molestias. La sintaxis también fue simple y los informes fueron excelentes, el informe del marco de la nariz fue muy superior.

Así que yo diría que la combinación ganadora es py.test con unittest.