En la vida del programador hay una tarea que lleva bastante tiempo, y es la de correr tests, ya sean "unit tests" (pruebas unitarias) o "integration tests" (pruebas donde se hacen interactuar subsistemas entre sí).
Es cierto, no todos los proyectos tienen tests, pero deberían. ¡Y son un vicio! Una vez que los probaste, querés pruebas en todos los proyectos. Pero claro, a los tests hay que correrlos, y hay muchas maneras de hacerlo.
La verdad es que la estructura de los tests es siempre la misma (o casi siempre), obviamente hablando de proyectos en Python, pero la forma de correrlos, y especialmente la forma de presentar los resultados, varía mucho de un corredor de tests a otros.
A lo largo de años he probado distintos, y debo decir que ninguno cumple 100% con lo que a mi me gustaría tener en el test runner ideal. Por otro lado, seguramente alguno (como nosetests, por ejemplo), cumpla gran porcentaje de lo que quiero, es cuestión de lograr lo que falta.
Acá está la listita de las cosas que cumpliría mi test runner soñado. Propuse un proyecto en el PyCamp de este mes para laburar en esto (obviamente no escribir algo desde cero, sino lograr el objetivo con el menor esfuerzo posible).
Le puse un número a cada ítem para que sea más fácil referenciar en cualquier discusión:
-
Debería soportar que le pase un directorio (default a '.') y que descubra todo ahí y para abajo:
$ <testrunner> project/tests/ $ <testrunner>
-
Debería soportar que le pase un archivo, y que corra sólo los tests de ese archivo:
$ <testrunner> project/tests/test_stuff.py
-
Debería soportar que le pase "paths de import de Python", y que corra sólo tests de ese paquete, módulo, clase, o lo que corresponda:
$ <testrunner> project.tests $ <testrunner> project.tests.test_stuff $ <testrunner> project.tests.test_stuff.StuffTestCase $ <testrunner> project.tests.test_stuff.StuffTestCase.test_feature
-
Debería poder pasarle una regex para que corra sólo lo que re.search() encuentra en el path completo del método:
$ <testrunner> project/tests/ --search feature correría: test_feature test_feature_1 test_feature_2 no correría: test_crash $ <testrunner> project/tests/ --search feature$ correría: test_feature no correría: test_feature_1 test_feature_2 test_crash Debería poder decirle que pare de correr los tests al encontrar el primer error o falla.
Debería poder indicarle que mida los tiempos de cada test (y al final que presente un reporte con los N tests que más tardaron).
-
Debería mostrar los resultados usando los nombres de paquete/módulo/clase/método, en una jerarquía de árbol o en la misma linea:
$ <testrunner> project/tests/test_stuff.py project.tests.test_stuff StuffTestCase test_feature_1 OK test_feature_2 FAIL OtherStuffTestCase test_feature_A OK $ <testrunner> project/tests/test_stuff.py OK project.tests.test_stuff.StuffTestCase.test_feature_1 FAIL project.tests.test_stuff.StuffTestCase.test_feature_2 OK project.tests.test_stuff.OtherStuffTestCase.test_feature_ADe cualquier manera, esto no afecta el órden de ejecución de las pruebas (secuencial, aleatoria, etc), sólo es cómo mostrar los resultados.
Los OKs deberían ser verdes; ERRORs y FAILs deberían ser rojos.
Los OKs/FAILs/ERRORs para cada prueba, en el listado, deberían estar alineados verticalmente.
No debería capturar stdout/stderr.
En el reporte final (luego del listado que va mostrando al ejecutar todo), debería mostrar el path completo del test que falla (o de los tests que fallan), junto con el (los) errores, de manera que si uno copia y pega ese path, sirva para correr ese único test.
