On 5/22/10, lasizoillo lasizoi...@gmail.com wrote:
El día 22 de mayo de 2010 05:44, Ivette Maria Suarez Muñoz
immu...@estudiantes.uci.cu escribió:
Hola tengo que hacer pruebas al codigo y no se en python si existe algun
modulo o algo que me lo haga mas facil, si alguien sabe algo de esto le
estare muy agradecida si me responden
Lo primero que debería explicar qué es lo que se prueba (system under
test aka SUT) y qué es lo que pretende con las pruebas . Mientras no
haga eso, sospecho que la respuesta será un poco difícil, porque de
hecho hay múltiples respuestas . Para darse cuenta solo hay que
echarle un vistazo a la taxonomía [1]_ ;o)
Yo empezaría por hacer pruebas funcionales con nosetests o docutils.
Personalmente no me gusta nose . Yo uso dutest, que es una combinación
mejorada y simple de unittest + doctest ... pero para gustos se han
hecho los colores ;o)
El primero alguna vez lo he integrado con tests de cobertura.
No es necesario nose para hacer análisis de cobertura . Se puede usar
coverage.py
{{{
#!sh
$ coverage.py cualquier_cosa_hecha_en_py
}}}
C. Titus Brown estaba confeccionando un paquete (SomePackage @ GitHub)
de ejemplo que ilustraba las buenas prácticas para organizar los
módulos y artefactos de pruebas , sobre todo con el fin de hacer algo
más o menos así
{{{
#!sh
$ coverage.py setup.py test
}}}
Pero
también te digo que con un 100% de cobertura se pueden tener caminos
que no estan comprobados (y que sean erroneos).
http://somethingaboutorange.com/mrl/projects/nose/0.11.3/plugins/cover.html
No es del todo así, y sí es del todo así . coverage.py tiene soporte
para branch coverage. De esta forma se puede confiar más en el reporte
de coverage ;o)
Existen también algunas herramientas de QA para python que te puede
ayudar a encontrar errores (uso de variables no declaradas, ...) sin
necesitar de programar una batería de tests. También valen para
quejarse de que el código sea feucho.
* pylint (http://www.logilab.org/857) lento como un dolor y tan
quisquilloso como tengas la paciencia de configurarlo.
* pyflakes (http://divmod.org/trac/wiki/DivmodPyflakes) rapido como un
demonio, pero no tan exhaustivo.
Análisis estático de código . Ver sección en [1]_
Repetir, repetir, repetir. Cuando tires para atrás un desarrollo y te
lo den modificado sería interesante hacer la regresión de todos los
tests y revisar el código midificado. Control de versiones para ver
los cambios de los entregables y si has automatizado la batería de
tests volverlos a pasar. Buildout, buildbot, hudson, ... scripts de
python
Bitten ;o)
pueden ayudarte mucho para volver a ejecutar los tests y evitar
que un arreglo estropee una cosa que antes funcionaba.
+1 . Para más detalles acerca de la filosofía, buscar en Google :
Martin Fowler Continuous Integration
Así en general no se me ocurren más herramientas. Igual entrando en
detalles concretos aparecen más ideas.
testing-in-pyt...@idyll.org
;o)
.. [1] PythonTestingToolsTaxonomy - Cheesecake - Trac
(http://pycheesecake.org/wiki/PythonTestingToolsTaxonomy)
--
Regards,
Olemis.
Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/
Featured article:
___
Python-es mailing list
Python-es@python.org
http://mail.python.org/mailman/listinfo/python-es
FAQ: http://python-es-faq.wikidot.com/
