Archive for February, 2009

25 FebConcordion: un ejemplo

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 shopaasmvn 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.

    22 FebAgilismo en el radar

    Estaba echando un vistazo al blog de James Shore (el autor de “The Art of Agile Development”) y me he encontrado con un descubrimiento de extraordinario valor: A Better Team.

    Como podéis ver, se trata de un gráfico de tipo radar que nos explica si realmente estamos haciendo agilismo o se trata de otra cosa. Además, nos explica cuál es nuestro nivel de riesgo y nos aconseja cómo mejorar. Para los que tengáis el libro de Shore, en la página 62 está la encuesta en la que se basa este sitio (“Assess Your Agility”).

    Todo un hallazgo.

    Por cierto, el blog del autor de aBetterTeam.org (Sebastian Hermida) es también muy recomendable. La serie de “steps to a better design” están muy bien. Yo ya los he impreso y pegado en mi pared.

    22 FebAntonio Machado

    Hoy se cumple el septuagésimo aniversario de la muerte de Don Antonio Machado. Creo que le debo un pequeño y modesto homenaje…

    Joan Manuel Serrat – Cantares

    Espero seguir haciendo camino al andar

    Tags: ,

    22 FebSe busca programador capacitado y… limpio

    Hace pocos días he recibido mi último pedido de Amazon. Entre los libros recibidos se encuentra “Clean Code” de Robert C. Martin (también conocido como UncleBob). Éste no es cualquier autor, es una persona muy importante en el desarrollo del software puesto que fue quien juntó en una sala de Chicago al grupo que “parió” en Febrero de 2001 el Manifiesto Ágil.

    Una sensación de alivio me invadió mientras leía el primer capítulo donde el autor explica qué es Código Limpio para él y para otros personajes bien reconocidos del desarrollo de software, entre ellos Stroustrup, Booch, Jeffries o Cunningham; ninguno sospechoso de no haber programado suficiente en su carrera como para que su opinión no tenga valor.

    Esta sensación que comento comenzó mientras leía el prólogo de James Coplien en el que utiliza el sencillo eslógan de unos caramelos para ilustrar su visión de lo que debe ser un buen profesional del desarrollo de software. El eslógan dice “La honestidad en las pequeñas cosas no es una cosa pequeña”. Coplien explica que este eslógan no solamente nos aconseja que prestemos atención a los detalles, sino que también seamos honestos con el código, con nuestros compañeros acerca del estado de nuestro código y, sobre todo, honestos con nosotros mismos acerca de nuestro código. ¿Hemos hecho todo lo posible para “dejar el campamento más limpio que nos lo encontramos” (tal y como reza el lema de los Boy Scouts)? Coplien añade que “errar es humano, perdonar es divino” y explica que debemos airear nuestra ropa sucia y hacer visible el verdadero estado de nuestro código porque el código nunca es perfecto y un suelo limpio reduce los accidentes.

    Pero tuve una revelación cuando en el primer capítulo leí que Robert C. Martin escribía:

    Los programadores se enfrentan a una paradoja de valores básicos. Todos los desarrolladores con algunos años de experiencia saben que desordenes previos son causas de retraso. Y sin embargo todos los desarrolladores sienten que la presión les hace dejar mal algunas cosas para conseguir alcanzar las fechas de entrega. En resumen, no se toman el tiempo necesario para ir rápido.

    Los verdaderos profesionales saben que la segunda parte de la paradoja está mal. No llegarás a la fecha haciendo mal las cosas. Es más, hacer las cosas mal te retrasará instantáneamente, y te forzará a incumplir la fecha de entrega. La única manera de llegar a la fecha -la única manera de ir rápido- es mantener el código tan limpio como sea posible durante todo el tiempo.

    Y finalmente, una lágrima de alegría rodó por mi mejilla cuando leí:

    ¿No es acaso la mejora continua una parte intrínseca de la profesionalidad?

    15 FebGrupo de Wicket en español

    Para los que estéis usando o interesados en usar Apache Wicket en vuestras aplicaciones web, he encontrado un pequeño grupo de usuarios en GoogleGroups en el que podemos ir, poco a poco, creando comunidad y compartiendo experiencias.


    Tags:

    15 FebArtesanos del software, uníos

    En una lista de correo sobre artesanía del software han estado redactando un “envoltorio” sobre el Manifiesto Ágil. Este nuevo lado izquierdo, además de la originalidad del formato, creo que aporta valores un tanto olvidados, pero que algunos que aún mantenemos viva la llama de la vocación tenemos muy presentes.

    Software bien hecho sobre Software que funciona sobre Documentación exhaustiva

    Añadir valor constantemente sobre Responder ante el cambio sobre Seguimiento de un plan

    Una comunidad de profesionales sobre Individuos e interacciones sobre Procesos y herramientas

    Impresionar a nuestro cliente sobre Colaboración con el cliente sobre Negociación de contratos

    Esto es, aunque aún valoramos los elementos en el medio más que los de la derecha, nosotros valoramos por encima de ellos los que están a la izquierda.

    Quizás hay también un libro que os puedo recomendar relacionado con este tema (posiblemente sin saberlo el autor): La ética del hacker.

    Actualización:
    Olvidé añadir que este manifiesto aún no está acabado. Hay un hilo de discusión en el que personajes como Robert C. Martin (Uncle Bob) están aportando su granito.

    15 FebDocumentación ágil

    En un artículo de un blog que encontré por casualidad, da unas cuantas pistas sobre cómo “agilizar” nuestra documentación.
    1. Si un documento es más largo de 20 páginas, por favor considera repartir el contenido en más de un documento.
    2. Si puedes decir lo mismo con menos palabras, por favor hazlo. (Usa patrones, por ejemplo)
    3. Si puedes decir lo mismo sin palabras, mejor. (Usa imágenes, diagramas…)
    4. Escribe para tu audiencia, no para ti mismo. No des por supuesto que sé lo que tú sabes.
    5. Si crees que puedes expresarlo mejor hablando, grábalo y enlazas a la grabación desde el documento. Igualmente, si crees que es mejor mostrar cómo se hace con una grabación en video o un screencast, adelante.
    6. Si mientras estás trabajando encuentras algo digno de ser registrado, blogéalo o ponlo en el wiki.

    A éstas yo añadiría:

    1. Automatiza las pruebas para que sea posible entregar el informe correspondiente en cualquier momento.
    2. No tengas miedo a incluir una foto o un diagrama escaneado en un documento para un cliente (y mucho menos si es un documento de uso interno).
    3. Incluye un resumen del documento (al menos su propósito) en las propiedades del documento, así permites que se pueda indexar y realizar búsquedas.
    4. Incluye un resumen en la portada del documento, así permites que no sea necesario “bucear” en el documento para saber si es el que buscamos o no.
    5. Utiliza un repositorio para saber exactamente cuál es la última versión del documento.

    ¿Se os ocurre alguna más a vosotros?

    Tags:

    12 FebPrimera reunión Agile Spain en Alcobendas: Resumen

    Pues sí, ayer estuvimos apenas cuatro gatos (mi ex-jefe Iván Hernández, Herme García, Ricardo Roldán y yo mismo). Lógicamente no hablamos mucho sobre Agile Spain, pero sí sobre las causas de la poca capacidad de convocatoria. Bueno, creo que había que hacer la primera “release” de estas reuniones para poder “inspeccionar y adaptar” cuanto antes. Estoy seguro de que pronto podremos llegar al nivel de las reuniones de Agile Spain en Barcelona.

    Tags:

    10 FebPrimera Reunión Agile-Spain en Alcobendas

    Finalmente (es un segundo intento) nos vamos a reunir algunos miembros de la comunidad Agile Spain en Madrid. Visitad la agenda prevista y veréis que no hay más requisito que tener interés por el agilismo, Scrum, Lean, TDD, eXtreme Programming, etc. Simplemente pediros que os pongáis en contacto conmigo para no esperar mucho rato en la puerta. Pero incluso si llegáis algo tarde seréis bienvenidos. :-)

    Tags:

    10 FebNo estoy solo

    Cuando hace ya casi 8 meses que abandoné Degesys, recibí un correo de un tal Herme García que me daba ánimos y que me invitaba a tomar un café. Yo no lo conocía de nada pero resulta que sigue habitualmente este blog. Hombre, la verdad es que me sorprendió bastante. Pues bien, hoy he estado en las oficinas de Peoplecall, aquí en Alcobendas, invitado por Herme para tomar ese cafelito.

    Unas oficinas pulcrísimas y un ambiente de trabajo muy agradable. Y mis anfitriones una gente muy amable y con los que he congeniado muy bien. Me invitaron a un “nespresso” con leche muy rico: nada de esos cafés molidos que parecen “aguachirri“. Ya sabéis, la primera impresión es muy importante… :-)

    Herme se autodefinía como informático vocacional (a pesar de ser “teleco”), que defiende el aspecto artístico (yo prefiero decir artesanal) de nuestra profesión. Y efectivamente, se le ilumina la cara cuando me explica algunos problemas que durante estos años le han surgido y que quedan lejos del típico CRUD (“altas, bajas, modificaciones y listados”) al que desgraciadamente solemos empujar a los usuarios de nuestras aplicaciones. También me comentó cómo después de asistir al curso de Scrum que impartió Ángel Medinilla en Barcelona, dieron la vuelta “como un calcetín” a un proyecto y consiguieron que fuera todo un éxito. Escucharon a los usuarios y se dieron cuenta de que el enfoque “ingenieril” era inadecuado. Escucharon a los usuarios y consiguieron enfocarse hacia el éxito del proyecto.

    Lástima que Hacienda haya perdido mi declaración del año pasado y tuviera que irme tan pronto. Probablemente siguieramos charlando todavía a esta hora… :-)

    Muchas gracias, Herme. Creía que estaba solo, pero resulta que hay más “informáticos vocacionales”.