Aunque sólo parece haber una charla relacionada con el agilismo, creo que a alguien le puede interesar que los próximos 26 y 27 de febrero se celebran en Madrid las "Jornadas de Experiencias sobre Validación y Verificación del Software 'Sólo Pruebas 2009'".

La nueva versión de JUnit se encuentra disponible ya en sourceforge .
En las notas de la nueva versión, los autores comentan:

JUnit is designed to efficiently capture developers' intentions about their code, and quickly check their code matches those intentions. Over the last year, we've been talking about what things developers would like to say about their code that have been difficult in the past, and how we can make them easier.

Entre los cambios de esta versión, se incluye una nueva sintaxis para las aserciones. Se puede consultar más detalle sobre esto en el blog de Joe Walnes.

Javier Gutierrez nos envía un enlace a un artículo suyo que puede resultar de interés a los lectores de Agile Spain:

He publicado en mi página un pequeño artículo titulado "Generación de pruebas del sistema en programación extrema" que da algunas ideas de como integrar trabajos sobre generación de pruebas con XP. El enlace es: http://www.lsi.us.es/~javierj/publications.html

Uno de los aspectos que me ha sorprendido más gratamente de Ruby on Rails es la facilidad para hacer pruebas de una aplicación web a todos los niveles.

En el entorno J2EE no he acabado de encontrar herramientas de pruebas que cubrieran todas las necesidades del desarrollo de aplicaciones web. Para pruebas unitarias JUnit o sus competidores están muy bien, pero cuando te sales de ese terreno las cosas no están tan claras. En particular los entornos para llevar a cabo pruebas funcionales provocan que estas supongan un coste considerable.

En Rails tenemos el equivalente a JUnit+dbUnit+HttpUnit+Cactus+Jameleon y todo ello perfectamente integrado. Así da gusto :) El único pero que le pongo son los nombres que han dado a los distintos tipos de pruebas y que resultan bastante engañosos.

En esta entrada del blog comienzo explicando las pruebas que Rails denomina unitarias y que incluyen tanto a las realmente unitarias como a las pruebas de las clases de modelo Active Record. Estas últimas no son puramente unitarias, dado que dependen de que esté disponible una base de datos con determinada información en ella.

Pruebas de presistencia con Fixtures

Las primeras no tienen ningún misterio para las que hayan usado JUnit así que centrémonos en las segundas. Para ellas, Rails proporciona el sistema de Fixtures que permite definir los datos que deben estar presentes en la base de datos antes de la ejecución de la prueba. La forma de definir estos datos es mediante un fichero con formato YAML por cada clase del modelo. Todos estos ficheros se almacenan en el directorio tests/fixtures. Por ejemplo en SprintTracker los ficheros tests/fixtures/sprints.yml contiene:

Aunque parezca una afirmación absurda, el artículo Better Testing, Worse Testing razona sobre las posibles causas que provocaron en distintos casos el que un mayor número de pruebas por parte de los desarrolladores condujo a un mayor número de defectos en el código. Estos casos se explican en un artículo anterior denominado Better Testing, Worse Quality.

Pasado algún tiempo el autor llega a la conclusión de que un aumento de las pruebas de un tipo (en su caso las elaboradas por el desarrollador) pueden ser perjudiciales si conllevan un menor número de pruebas de otro tipo (en su caso pruebas de sistema o funcionales).

Es una interesante lectura. De hecho tras los primeros artículos que leí sobre pruebas en Extreme Programming también entendí que con las pruebas unitarias las pruebas de más alto nivel eran menos importantes. Sólo leyendo mucho más te das cuenta de la maliterpretación. Está claro que los que divulgan (divulgamos) los métodos ágiles tienen (tenemos) que tener cuidado de los malentendidos a los que puede darse lugar.