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.

test Filed under Planeta | Comment (0)