[Python-es] sobre pruebas de caja blanca

Dom Mayo 23 06:31:17 CEST 2010

On 5/22/10, lasizoillo <lasizoillo en gmail.com> wrote:
> El día 22 de mayo de 2010 05:44, Ivette Maria Suarez Muñoz
> <immunoz en 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-python en 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/