Concordion: un ejemplo

Tiempo aproximado: 4 min.
Hace ya varios meses que estoy involucrado en el proyecto Concordion, un framework para construir y ejecutar pruebas de aceptación. Desde entonces hasta ahora el código base no ha cambiado significativamente, pero hasta ahora seguíamos sin tener un ejemplo de uso con el código fuente incluido más completo que el HolaMundo del proyecto concordion-samples. En el artículo de hoy voy a pagar esta deuda.

Concordion

Las principales características de Concordion son:

  • Las especificaciones se escriben en XHTML
  • libertad absoluta de formato, que favorece escribir las especificaciones orientadas a comprobar los comportamientos en vez de orientadas a “scripts”
  • no es necesario conocimiento técnico para poder escribir las especificaciones

  • Las especificaciones se instrumentan para ejecutar código Java sin restricciones, puesto que las fixtures son clases Java que heredan de una extensión de TestCase de JUnit (o anotada con @ConcordionRunner) y que se vinculan con las especificaciones por convenio (se llama igual que la especificación pero con el sufijo Test)
  • No hay ficheros de configuración
  • Está disponible en el Repositorio Central de Maven
  • groupId
    org.concordion

    artifactId
    concordion

    version
    1.3.0

  • Se ejecuta como cualquier test JUnit
    • el resultado de la ejecución son los mismos XHTML pero iluminando los textos instrumentados con verde si se cumple la condición, rojo si no se cumple o amarillo si se ha producido una excepción
    • también hay un plugin Maven que produce un resumen del resultado de la ejecución que recorre todos los XHTML resultantes y que mejora el que produce el plugin Surefire para los JUnit

    Proyecto de ejemplo

    He creado un proyecto en GoogleCode para, entre otras cosas, ir realizando todas estas pruebas. Anteriormente había escrito un artículo donde se trataba de ilustrar el uso de Spring y de JPA juntos. Ahora he incorporado un ejemplo que ilustra cómo pasar de una historia de usuario sobre el Mantenimiento de un Catálogo de Productos para una tienda. Esto es un poco CRUD, pero poco a poco iremos viendo cómo incluso en ese escenario podemos orientarnos al comportamiento.

    ¿Cómo descargar y probar este ejemplo?

    Para descargar este proyecto podéis seguir las instrucciones:


    svn co http://shopaas.googlecode.com/svn/trunk/shopaas shopaas

    Podéis revisar los siguientes detalles por si queréis cambiarlos.
    En shopaas/pom.xml

    …y a continuación podéis construirlo usando Maven. Para ello, ejecutad:


    cd shopaas
    mvn clean install cobertura:cobertura site

    Si todo ha ido bien, podréis comprobar que se ha generado un “site” del proyecto en la carpeta target/site.

    Desgraciadamente no he conseguido aún que queden correctamente enlazados los módulos, por lo que es necesario ir hasta la carpeta shopaas/services-acceptance-test/target/site y abrir el fichero index.html con nuestro navegador favorito para poder ver el resultado de las pruebas de aceptación (incluso el informe de cobertura de las mismas).

    Si ejecutáis la construcción del proyecto desde la linea de comandos, es posible también que tengáis un problema de falta de memoria (Error “Java Heap Space”), para evitarlo tendréis que ejecutar antes que nada “set MAVEN_OPTS=-Xmx128m”. A mi me ha dado este problema cuando lo he probado en Windows XP con un JDK 1.6.0_11, y sospecho que tiene que ver con los valores por defecto que elige la JVM en este entorno. Pero tampoco lo tengo 100% seguro.

    maven-concordion-plugin

    No sé si para el momento en el que probéis esto ya estará publicado en el Repositorio Central de Maven el plugin que permite obtener informes resumidos de Concordion. Si no fuera así, también deberéis descargar el código del maven-concordion-plugin y construirlo con mvn install.

    Cobertura

    El informe de cobertura del código (“code coverage”) ha sido algo que me ha costado especialmente puesto que el código a instrumentar no está en el mismo módulo que las pruebas, de modo que he usado una combinación de los plugins maven-antrun-plugin y build-helper-maven-plugin. Como podréis comprobar, así podemos conocer con bastante certeza si hay código que llevamos a producción para el que no tenemos ninguna prueba. Mmmm, sí que es interesante, ¿verdad?

    Automatización

    Pero lo más interesante es que está completamente automatizado. También están las pruebas de aceptación de la UI que os mostré en un artículo anterior. Por tanto, tenemos pruebas unitarias de los componentes internos, pruebas de aceptación de los servicios de aplicación (escritas en lenguaje de negocio) y pruebas de aceptación de la UI (independientes de la implementación de los servicios de aplicación, o no, esa es nuestra decisión). Con lo que sólo nos queda, en cada “release”, darnos un paseo por la aplicación por aquellos puntos críticos o para los que el coste de hacer una prueba automática sea excesivo. Pero el resultado neto es que hemos ganado en confianza y reducido el tiempo que tardamos en entregar un proyecto. En estos tiempos de crisis, eso es importante, ¿verdad?

    Recursos

    También hay disponible un tutorial de Concordion. Además, a continuación incluyo una lista de enlaces de interés:

    Feedback (o reacciones)

    Por favor, espero que me hagáis llegar vuestros comentarios cuando probéis esto. Me ayudarán mucho a mejorar este ejemplo. No tengo claro cómo organizar el código para que Maven me construya todo como es debido y eso le resta claridad al resultado final, que debería ser que el “Product Owner” o los “expertos del dominio” pudieran navegar hasta el resultado de las pruebas de aceptación y discutir tanto sobre su definición como sobre el resultado de la ejecución.

    También hay dos conjuntos de código diferentes: users y products. El primero corresponde a aquel ejemplo que hice hace ya unos meses y el segundo es el que he estado trabajando últimamente y que pretendo que me sirva como piedra de toque para ir encontrando patrones o plantillas.