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/
