Probar Sin redesplegar, ¿es tan importante?

Tenia el blog ultimamente muy abandonado, cosas del pluriempleo jeje, a ver si poco a poco empiezo a coger ritmo otra vez, de momento una entrada sobre mi tema favorito, testing! (el titulo es para despistar a incautos).

El viernes pasado estuve en el spring2gx day, que por cierto desbordo todas las expectativas de asistencias y fue un autentico éxito (algunas opiniones sobre el evento de Alberto Vilches , Tomás Lin y Daniel Latorre). Una característica de grails que se nombro en varias ponencias y que sus usuarios parecían valorar mucho es la posibilidad de modificar un fichero y probar la aplicación sin necesidad de redesplegarla (vaya palabro :P), se comentaron algunos problemas que había con esta característica y la dificultad de que funcionará bien por ciertos bugs en tomcat y jetty. Despues de oir todo me quedo claro que se trata de una característica a la que los usuarios dan una gran importancia, lo que me pregunto yo es ¿realmente es tan importante?

No me entendáis mal, no pretendo decir que no es algo útil, es obviamente una buena característica que puede aligerar el desarrollo, pero si alguien considera esta característica como algo diferencial para su productividad es porque en su ciclo habitual de desarrollo relanza la aplicación un buen número de veces al día. ¿no será esto también parte del problema?, ¿para que necesita alguien relanzar la aplicación tantas veces?, la respuesta a esto último esta bastante clara: para probarla, es decir, para obtener feedback de que el código que esta escribiendo es correcto y seguir adelante con lo siguiente.

Un ciclo de desarrollo como este implica que a cada cambio hago varias cosas:

• Obviamente relanzar la aplicación.
• insertar los datos que me hagan falta para la prueba, si me hace falta alguno lógicamente
• Navegar por la aplicación hasta que llego a la parte que quiero probar
• Verificar manualmente que la cosa funciona como esperaba, en caso contrario vuelta a empezar.

Y esto si hablamos de un lenguaje dinámico como groovy es algo que probablemente haga aún con más frecuencia porque tampoco tengo el feedback del compilador que me asegure que mi código es sintacticamente correcto. Metidos en un ciclo como este que sea necesario redesplegar el servidor es sólo una pequeña parte del problema, en mi opinión el verdadero problema radica en que necesito una manera más rápida y más efectiva de obtener feedback de que lo que estoy escribiendo es correcto, ¿y esta claro por donde voy no?, test automáticos!.

Grails, como nos contaron los creadores de jobsket, cuenta con buen soporte para unit testing, con este soporte se pueden construir pruebas que utilizando los objetos mock que provee grails prueben toda nuestra lógica servidor sin necesidad de arrancar la aplicación y apretar botones. No conozco grails pero últimamente he estado usando stripes para algunos desarrollos web sencillitos en java y cuenta con una librería de mocks similar a la que ofrece grails. En mi caso el ciclo de desarrollo es algo así:

• Escribo un test de la funcionalidad a implementar utilizando los mocks de stripes.
• Escribo los componentes servidor (action beans, interceptores...) que necesito para que pase el test. En este paso por supuesto también escribo test de unidad para cada clase en la que me apoye (acceso a base de datos, lógica de negocio etc,etc)
• Los test pasan!. Llegados a este punto tengo todo el código servidor funcionando, puedo llevar perfectamente varias horas desarrollando mi aplicación web, he probado que todo funciona y todavía no he tenido que arrancar un servidor web, y claro tengo una red de test de regresión para minimizar el riesgo de futuros cambios.
• Me falta la vista, no he escrito ni una linea de JSP de momento, ahora arranco el servidor con tomcat o jetty (usando maven en netbeans) y voy escribiendo mi JSP para la vista, ahora puedo cambiar el JSP y simplemente haciendo F5 veo los cambios, sin reiniciar el servidor. Si estoy inspirado de regalo agrego algo de "magia" con jquery al asunto, que también puedo ir haciéndolo sin reiniciar.
• Una vez terminada la vista escribo algún test con selenium, estos me sirven para comprobar que la vista esta bien "enganchada" con el servidor y de nuevo minimizar los riesgos de cambio, en este caso sobre la vista. (todavía no me veo con soltura para escribir estos test de selenium primero, todo se andará).

Vamos que en un día normal de desarrollo no veo la necesidad de reiniciar el servidor más que unas pocas veces.

¿Y a donde quiero llegar con todo esto?

La reina de las excusas o impedimentos a la hora de hacer test automáticos es sin duda "no tengo tiempo". Sin embargo en muchas ocasiones no nos damos cuenta de que nuestro ciclo de desarrollo es lento y tedioso porque tardamos mucho en poder probar un simple cambio, con los test podemos ir obteniendo feedback continuo y agilizar el ciclo de desarrollo. Empleando un poco de tiempo inicial en aprender a hacer buenos test podemos conseguir beneficios enormes, no sólo en la evidente mejora de calidad de nuestro desarrollo sino que también podemos tener un ciclo de desarrollo más sano e ir más rápido!, o como mínimo compensar el tiempo dedicado a escribir los test, con la enorme diferencia de que en el mismo tiempo tendremos un producto mucho más robusto y que podremos cambiar con menos riesgo.

Y esto es sólo un ejemplo de como los test no son sólo devoradores de tiempo, también pueden ayudar ha acelerar el ciclo de desarrollo si los usamos correctamente. Otro ejemplo en otro contexto es la "debuger-dependencia", desarrolladores que pasan horas y horas al día con el debuger arrancado dándole a F7 para en definitiva hacer lo mismo, obtener feedback, algo que se puede hacer de forma mucho más efectiva con unos buenos test. Otro día me explayo más con lo del debuger que tiene delito el tema también jeje.

Coding Dojo

El pasado día 22 estube en el coding dojo que organizarón la gente de agilismo.es con colaboración de autentia, os cuento un poco como fue el asunto.

La idea era realizar una pequeña clase para controlar el funcionamiento de un reloj pomodoro en el tiempo que dura un pomodoro (25 minutos), se formarón dos equipos de 5 personas cada uno (yo participe en uno aunque tampoco ayude gran cosa, eso si deje los test pasando que conste! xd). El primer equipo empezo a implementar los primeros pasos y el segundo equipo, en el que estaba yo, continuamos por donde lo dejarón los primeros. No conseguimos completar todo el ejercicio pero por lo menos nos divertimos un rato, y lo mejor de todo fue la cantidad de debates interesantes que se iban produciendo.

Para terminar jose manuel beas realizo una code kata mostrando una posible solución al problema realizada por supuesto haciendo uso de TDD. La idea de las katas esta muy bien, se trata de que alguien que ha pensado y practicado el problema durante unos días hasta dar con una solución suficientemente "pulida" demuestre la solución programandola desde cero en vivo y en directo, esto es importante porque no solo se ve "la solución final" sino que se ve también el proceso de desarrollo para llegar hasta esa solución. Vamos viendo como a través de TDD se va refinando el problema y se enfatiza el papel de TDD no como una tecnica de "pruebas" sino como una tecnica de diseño.

La verdad es que fue una tarde divertida, con un monton de gente pese a lo dificil de estas fechas (estaba "petao") y como siempre Xavi Gost en su estilo habitual showman provocador nos regalo algunas perlas xd, los operadores ternarios no le gustan mucho eso quedo claro jeje, la verdad es que fue muy divertido y con un ambiente de muy buen rollo entre todos los asistentes.

Luego por supuesto terminamos con una cañitas de rigor, la verdad es que se nos hizo un poco tarde y yo me fui sobre las 11 y media y por alli se quedarón unos cuantos valientes tomando la penultima.

Da gusto que se organizen este tipo de cosas, entre las reuniones locales del grupo de madrid de agile-spain, el agile open y estas iniciativas queda claro que se esta formando una comunidad muy activa alrededor de las metodologías ágiles y sus practicas, y es un autentico placer estar siendo participe de todo esto con tantos buenos profesionales que demuestran tanta pasión por su trabajo. Lo que nos queda es seguir apoyando y colaborando en todo esto, y a todos los que tengais posibilidad de asistir a estos eventos y reuniones: ¿a que estais esperando?.