miércoles, 6 de julio de 2016

Ventajas de Spock para testear en Java

Imagen de http://www.playbuzz.com/jamesk20/leonard-nimoy-versus-spock-can-you-tell-which-quotes-are-from-his-famous-star-trek-character

Introducción 

Groovy es un lenguaje de programación dinámico para la máquina virtual de Java (JVM). Esto hace que sea muy fácil de configurar para alguien con experiencia en Java.
Lo que más destaca de este lenguaje es su sintaxis (syntax sugar) que facilita mucho el desarrollo. Y además es muy fácil comenzar a programar porque lo han hecho muy amigable para la gente que viene de Java. Es casi un superconjunto de Java.

Dentro del extenso ecosistema de Groovy tenemos Spock, que es una framework para escribir test. Spock tiene como ventaja principal la legibilidad de los test. Hace que los test sean muy fácil de entender sin ni siquiera saber nada de Spock o Groovy.
Lo más interesante de Groovy y Spock para alguien que viene de Java es que podemos tener nuestro código fuente en Java y los test en Spock.



Ventajas de Spock

En este apartado se listan los que son a mi entender las mayores ventajas de Spock frente a Java.
En cada apartado hay un ejemplo de como es el código en Spock y en Java para que puedas comprobar de la forma más clara posible la diferencia entre uno y otro. En la parte izquierda de las imágenes aparece el código con groovy y spock y a la derecha el código con java y junit.
Para los ejemplos de java se ha utilizado JUnithamcrest y mockito.

Los ejemplos en Groovy fueron creados por Iván López y los escritos en Java están escritos por mí. En el siguiente repositorio puedes encontrar el código fuente:

https://github.com/kikers25/codemotion-2015-spock

El repositorio lo escribió Iván para una charla sobre Spock y lo he extendido añadiendo los test que aparecen pero en Java porque me parecía que es más fácil ver las ventajas si se ven los dos juntos.



  • Nombre de los test unitarios son cadenas
Los nombres de los test unitarios son importantes para entender que es lo que hace el código del test. En Java, el nombre del test es el nombre del método y no se pueden escribir espacios. Por lo que se tiene que utilizar algún tipo de método para que el lector sepa que hay un espacio. En mi caso suelo utilizar guiones bajos.
Con Spock esto no es necesario porque el nombre del test es una cadena. Así, podemos escribir espacios y otros caracteres que no son posible de utilizar en Java.





  • Estructura de cada test en bloques
La separación en bloques de los test escritos en Spock es lo que hace que la legibilidad del test mejore mucho.
Los bloques están basados en el lenguaje gherkin y los bloques más comunes (aunque hay más) que se utilizan en un test son given, when y then. Estos bloques inicializan los objetos a utilizar (given), ejecutan la acción a probar (when) y comprueban que el resultado es el esperado (then).




  • Inicialización de clases, listas y mapas
La inicializacion de objetos en groovy es de lo más fácil porque no necesitamos el crear un constructor con todos los métodos, si no que por defecto tiene un constructor al que puedes pasarle en modo de clave y valor todos los atributos que quieres inicializar del objeto. Personalmente utilizo mucho el patrón constructor (builder pattern) para crear objetos para mis tests. Con groovy no es necesario.
Además crear listas y mapas es muy intuitivo y fácil de leer.





  • Tablas de datos
Con diferencia esta es una de las mejores características de Spock. Añadir test que hacen lo mismo pero con diferentes valores para los parámetros de entrada y el valor de salida utilizando una tabla de datos es una gran funcionalidad. Fíjate en las diferencias en la imagen de abajo.




  • Herramienta de dobles de test completamente integrada
Utilizo jmock y mockito para crear mis dobles de pruebas para mis test. Con Spock no necesitas el buscar ninguna librería ya que viene integrada. Lo único que no me gusta es que para que una clase mockeada devuelva un valor no es necesario especificarlo a la clase. Lo que es lo mismo el framework es lenient por defecto.




  • Mensajes de error cuando un test falla
Los mensajes de error son más claro que utilizando hamcrest.




Resumen

Groovy en combinación con Spock tienen muchas ventajas a la hora de escribir test si lo comparamos con Junit, Hamcrest y Mockito.
La configuración es muy fácil, resulta fácil el empezar a programar y la legibilidad de los test es muy buena. Es el framework para testing más completo que conozco.



Extra

Si te parece interesante tanto Groovy como Spock y quieres saber más. Los enlaces que aparecen a continuación son vídeos de las charlas de Iván López y Andrés Viedma sobre Spock:

https://www.youtube.com/watch?v=RjH1bd9D2Qs 
https://www.youtube.com/watch?v=D7TjLThg95I


lunes, 27 de junio de 2016

Método iterativo e incremental

Imagen de Henrik Kniberg


Tu empresa ha externalizado la creación de una aplicación a una empresa en India y a los cuatro meses de la fecha límite entregan una primera versión.
En esa primera versión te das cuenta que tiene bastantes problemas. Como por ejemplo:
  • Los requisitos mínimos no han sido cumplidos.
  • La interfaz de usuario tenía que ser igual a otra aplicación, ya que los usuarios están acostumbrados a esta primera, y no se parece nada.
  • La aplicación no funciona con el número mínimo de usuarios concurrentes que va a tener.
  • Las funcionalidades desarrolladas hacen lo que tiene que hacer, a veces.
  • El código no tiene un mínimo de calidad

Como puedes imaginar, no vas a poder arreglar todos los problemas en solo cuatro meses y los costes en cuanto a tiempo y dinero aumentan con cada mes que no ha entregado el producto, y serán muchos meses.
Además, la gente de negocio tiene que hablar con los clientes sobre estos cambios, ya que no van a estar terminados en la fecha prometida. Lo que bajará la confianza de los clientes en la empresa.
Lo mismo pasa con la gente de marketing y la campaña que tenían pensada hacer para captar nuevos clientes, que tendrán que ser pospuestas. Con el coste adicional que supondrá este cambio.

La forma de desarrollar este producto es en cascada (waterfall) ya que todos los requisitos han sido dados al principios del desarrollo y el producto se entrega cerca de la fecha de entrega.

Imagen de https://www.adictosaltrabajo.com/tutoriales/metodos-agiles


La forma de desarrollar un producto en cascada es la más eficiente porque si los requisitos han quedado claros y no hay problemas durante el desarrollo del producto se han gastado cada céntimo en las cosas necesarias para obtener el producto.
El problema es que en los 10 años que llevo desarrollando software siempre hay "problemas". Puede ser que sea casualidad o que los problemas no son tal, si no un es algo habitual en el desarrollo de software. Personalmente me decanto por el segundo motivo.

Hay varias alternativas a este tipo de desarrollos en cascada pero voy a hablar del que conozco. Del desarrollo iterativo e incremental.

El desarrollo iterativo e incremental consiste en ir entregando versiones de tu producto que vayan entregando cada vez más valor con cada versión del producto.

Imagen de https://www.adictosaltrabajo.com/tutoriales/metodos-agiles


La ventaja de esta forma de desarrollar un producto es que si hay algo mal, como la lista que he comentado al principio, tenemos tiempo suficiente para poder solucionarlo. O lo que es lo mismo, estamos reduciendo el riesgo que es el entregar un producto al final del desarrollo sin saber si está bien.

Claro que esta forma de desarrollo tiene sus inconvenientes. El más importante es el tiempo que hay que dedicarle a verificar que vamos por el buen camino. El tiempo que dedicamos a hablar con el cliente o con la gente de negocio para comprobar que lo que estamos desarrollando encaja con lo que tenían pensado.
Otro inconveniente importante es que la forma de desarrollar cambia de forma drástica. En cada nueva versión de nuestro producto tenemos que comprobar que las nuevas funcionalidades funcionan de la forma correcta y que las funcionalidades desarrolladas en las versiones anteriores siguen funcionan. Así, con cada nueva versión que se acerca más al producto tenemos que probar muchas cosas: las funcionalidades nuevas y las antiguas.
Como puedes imaginarte llega un momento que este proceso de comprobar que todo lo desarrollo funciona de forma correcta no se puede realizar de forma manual. De forma manual quiero decir de una persona que compruebe un todo funciona.
Por lo que necesitamos algún tipo de proceso automático que nos permita comprobar que lo que hemos desarrollo funciona. Aquí es donde entra en juego los test unitarios, los test de integración y los test de aceptación.
Los test unitarios y de integración comprueban que la aplicación funciona como debe funcionar y los test de aceptación comprueba que la aplicación funciona como el usuario final quiere.

Los cambios de un proceso en cascada a un proceso iterativo e incremental son grandes. Tanto a nivel de negocio como a nivel de desarrollo. La gente de negocio tiene que ayudar a comprobar que lo que que el usuario quiere es lo que se está desarrollando (test de aceptación) y la gente de desarrollo tiene que crear test de integración y unitarios para comprobar que lo que se está creando funciona de forma correcta.
Estos cambios son grandes pero van a permitir a vuestra empresa a reducir los riesgos. Lo que va a permitir a vuestra empresa crecer reduciendo los riesgos en este crecimiento.

Personalmente las ventajas ganan a los inconvenientes en un proceso iterativo e incremental. ¿Tú qué opinas?


miércoles, 25 de mayo de 2016

Pequeño ejemplo en Python y TDD

Imagen de http://code.tutsplus.com/tutorials/beginning-test-driven-development-in-python--net-30137


Hace un tiempo leí el libro Test-Driven Development by Example de Ken Beck y me pareció un gran libro. Es una gran introducción a TDD.

Una parte del libro no entendí bien. La relacionada con un ejemplo de xUnit.
En esa parte del libro, implementa una librería para poder testear código y el ejemplo que va desarrollando está escrito en Python y no conocía el lenguaje. Creo que el lenguaje fuera Python hizo que no lo entendiera.

Así que para poder entenderlo y aprender un poco Python he escrito el código resultado de cada capítulo en un fichero mientras iba leyendo el libro. He subido los ficheros a:

https://github.com/kikers25/tddByExamplePython

Se puede comparar un fichero (con Winmerge) con otro para ver cual han sido los cambios en cada capítulo. Por ejemplo, los cambios entre el capítulos 18 y 19 serían:

Python

Espero que te resulte útil.