Finalmente lo conseguí y la versión 1.3.1-RC5 de Concordion ya está en el repo1 de Maven. Y ahora está sincronizado el repositorio de GoogleCode con el repo1, con lo que ya no tenemos que depender de construir manualmente un bundle y abrir una petición en JIRA, como he explicado en una entrada anterior. ¡Guau! Esto es un avance. Ahora sólo hay que hacer release con los comandos “mvn release:prepare” y “mvn release:perform” y esperar a que ocurra la sincronización…
Ya está disponible la versión 1.3.1-RC5 de Concordion. Podéis usarlo con Maven (de momento, hasta que se publique en el Repositorio Central de Maven) declarando el repositorio remoto del proyecto:
Para los que tengáis un proyecto en GoogleCode y no sepáis cómo publicarlos en el Repositorio Central de Maven, podéis echar un vistazo al wiki del proyecto Concordion donde explico (en inglés) cómo hacer una release usando maven-release-plugin. También os resultará útil ver la solicitud que hice en el JIRA pues allí he ido relatando cómo he ido resolviendo el asunto. Lo siento, todo está en inglés, pero os lo puedo resumir:
1) Usar Maven 2.0.9 (yo utilizaba el embedder y hasta que no pasé a la 2.0.9 no conseguí avanzar) 2) Usar dav:https://concordion.googlecode.com/svn/repos/releases en la sección distributionManagement del pom.xml 3) Incluir username y password en nuestro settings.xml (tenemos que ser desarrolladores del proyecto para poder hacer commit en SVN, así que también para hacer deploy con Maven)
El último paso es, depués de hacer release, crear una entrada en el JIRA solicitando la sincronización. Yo he utilizado estos valores y estoy a la espera de conocer el veredicto.
“org.concordion”,”/home/maven/repository-staging/to-ibiblio/maven-svn”,”svn”,”Jose M Beas”,”jose.m.beas@gmail.com”,,”http://concordion.googlecode.com/svn/repos/releases/”
Acabo de terminar de solicitar la publicación en el Repositorio Central de Maven de la versión 1.3.1-RC5 de Concordion. Hasta aquí nada novedoso, pero resulta que nuestro código está alojado en Google Code y no es tan fácil automatizar todo este proceso.
He utilizado maven-release-plugin para conseguir que ejecutando mvn release:prepare me haga en Subversion los siguientes cambios: 1) commit tras quitar el -SNAPSHOT de la versión y poner el número de versión 1.3.1-RC5 en el pom.xml 2) copia de esa revisión a la rama de etiquetas (tags) con el nombre adecuado (en mi caso concordion-1.3.1-RC5) 3) commit tras quitar el número de versión de la release y en mi caso dejar 1.3.1-SNAPSHOT, pero si hubiera sido la final hubiera puesto 1.3.2-SNAPSHOT, por ejemplo
Y luego, ejecutando mvn release:perform, Maven descarga el código etiquetado y ejecuta repository:create-bundle para obtener el bundle que manualmente debo subir al area de Downloads de mi proyecto.
Finalmente, con el bundle ya en un sitio público (y relacionado claramente con mi proyecto), solicito el “upload” en JIRA.
Todo el proceso lo he documentado en el wiki del proyecto (aunque, claro, está en inglés).
Espero que os ayude y si por casualidad os enteráis de cómo hacer “sync” desde GoogleCode, por favor, contadmelo porque quiero poder automatizar completamente el proceso. Yo, por mi parte, en cuanto tenga tiempo echaré un vistazo a Google Code Upload Maven Plugin.
Actualización:
He modificado el procedimiento para solicitar la publicación en el Repositorio Central de Maven para que se sincronice con un repositorio remoto (también en el SVN de GoogleCode). Más detalles en el siguiente post.
Este fin de semana he estado jugando con maven-release-plugin con el objetivo de automatizar el versionado de mi código y, bueno, el resultado ha sido un tanto agridulce porque por un lado ha sido muy sencillo pero por otro me he encontrado con un defecto de esos que cuesta encontrar, sobre todo cuando no estás seguro de lo que tienes entre manos porque ni lo has hecho tú ni está suficientemente documentado.
La parte fácil
Antes que nada, os cuento lo que yo suelo hacer con el código cada vez que termino una iteración.
Supongamos que la versión actual es la 0.0.1-SNAPSHOT.
1) Me recorro todos los pom.xml donde he puesto 0.0.1-SNAPSHOT y le quito el -SNAPSHOT. 2) Hago commit de los pom.xml que he cambiado. 3) Etiqueto esta versión del código en el repositorio (en mi caso Subversion). 4) Vuelvo a recorrer todos los pom.xml para dejar la siguiente versión: 0.0.2-SNAPSHOT. 5) Hago commit de los pom.xml.
Y eso todas las veces…
Pues bien, resulta que hay un plugin de Maven que hace todo eso por mi: maven-release-plugin.
Antes de empezar yo aconsejo también hacer mvn clean install, pero no es obligatorio. Yo es que soy un poco obsesivo con estas cosas.
Para usarlo no puedo tener ningún “commit” pendiente, de lo contrario, el plugin se quejará. Es obligatorio también proporcionar la información de dónde está nuestro repositorio, para ello debemos incluir el apartado “scm” en los pom.xml que lo requieran (según los tengamos organizados):
El plugin sustituirá en estas cadenas los valores adecuados, por eso es aconsejable revisar cómo quedan estas secciones de los pom.xml las primeras veces.
Lo primero que hay que hacer es: mvn release:prepare -DdryRun=true
Esta instrucción cubre los pasos 1, 2 y 3. La propiedad “dryRun” nos sirve para decirle al plugin si queremos o no hacer efectivos los cambios, si le damos el valor “true”, el plugin NO hará commit ni tag. También comprueba si hay dependencias con artefactos cuya versión aún es SNAPSHOT, pero esto no lo he probado, la verdad. Además, “release:prepare” ejecuta por defecto los siguientes “goals” sobre el proyecto: “clean verify”. Esto hace que se ejecuten las pruebas.
Cuando lo ejecutemos, por la consola Maven nos preguntará la versión de cada pom.xml (él no quita el “-SNAPSHOT” sino que pone la versión que nosotros le digamos). También nos pregunta cuál es el nombre con el que va a etiquetar esta versión en el repositorio de control de versiones. Y por último nos pregunta cuál es la versión que vamos a tener para trabajar después de este versionado (que suele ser la siguiente con el “-SNAPSHOT”). El plugin nos propone valores por defecto que podemos aceptar pulsando “intro”. Para cada pom.xml, la ejecución con “dryRun=true” nos dejará 3 ficheros: pom.xml.releaseBackup, pom.xml.tag y pom.xml.next, que se corresponden con el que tenemos antes de ejecutar (0.0.1-SNAPSHOT), el que se etiquetará como versión estable (0.0.1) y el que quedará en el “trunk” con la nueva versión de trabajo (0.0.2-SNAPSHOT). Pero el plugin no hará efectivos estos cambios porque le hemos dicho “dryRun=true”.
La parte difícil
Hasta aquí todo iba bien, pero el siguiente paso me dio problemas. Pero primero hay que ejecutar sin “dryRun” para que se hagan efectivos los cambios en SVN.
mvn release:clean release:prepare
release:clean sirve para limpiar los ficheros que haya podido dejar una ejecución anterior. También podemos usar releas:rollback para deshacer los cambios efectuados en SVN.
El primer obstáculo fue al usar el Maven embebido que viene con m2eclipse. Así que tuve que pasar a usar una instalación externa (concretamente la 2.0.9).
El segundo obstáculo fue al ejecutar el comando y encontrarme con el siguiente mensaje de error:
[INFO] Executing: cmd.exe /X /C "svn --non-interactive commit --file C:\Temp\maven-scm-2032301768.commit --targets C:\Temp\maven-scm-5209016095571570993-targets"[INFO] Working directory: C:\eclipseWorkspaces\MiTienda\shopaas[INFO] Tagging release with the label shopaas-0.0.1...[INFO] Executing: cmd.exe /X /C "svn --non-interactive copy --file C:\Temp\maven-scm-328141097.commit . https://shopaas.googlecode.com/svn/tags/shopaas-0.0.1"[INFO] Working directory: C:\eclipseWorkspaces\MiTienda\shopaas[INFO] ------------------------------------------------------------------------[ERROR] BUILD FAILURE[INFO] ------------------------------------------------------------------------[INFO] Unable to tag SCMProvider message:The svn tag command failed.Command output:svn: Commit failed (details follow):svn: File '/svn/tags/shopaas-0.0.1/domain/pom.xml' already exists
El caso es que hay un bug (¡cómo no!) que, para colmo, no parece estar claro si está del lado de Maven o de SVN. Parece que maven-release-plugin hace “svn copy” para crear el tag y que, a partir de la versión 1.5.1 de Subversion esto mismo ha comenzado a fallar. Así que hay que hacer manualmente la siguiente chapu:
# mvn release:prepare=> fails# svn up -r head # mvn release:prepare -Dresume
De esta manera, los ficheros en .svn que han quedado chungos se arreglan con “svn up” y luego se continúa por donde se había quedado (con -Dresume). Con Eclipse consiste en primero hacer “Team / Update” y a continuación ejecutar Maven con el goal “release:prepare” y el Parameter “resume” (al que tenemos que ponerle el valor “true” porque la configuración del launcher que propone m2eclipse no permite añadir un parámetro con nombre pero sin valor).
Llegados a este punto podemos revisar que en nuestro servidor de SVN se han creado tres nuevas revisiones con el siguiente comentario: * [maven-release-plugin] prepare release shopaas-0.0.1 * [maven-release-plugin] copy for tag shopaas-0.0.1 * [maven-release-plugin] prepare for next development iteration
Los ficheros que son cambiados tras la ejecución (los pom.xml) podemos compararlos con las correspondientes versiones anteriores. En mi ejemplo, el mismo trozo del pom.xml que muestro más arriba queda como:
Y en nuestro espacio de trabajo tenemos que la versión de los diferentes pom.xml ha quedado ahora como 0.0.2-SNAPSHOT, tal y como respondimos en su momento. También nos ha quedado un fichero release.properties con todas las versiones y trayectorias en SVN de los componentes versionados por este plugin.
Queda pendiente
Me queda aún por probar a realizar el despliegue de la nueva versión de manera automatizada. Para ello hay que usar el goal “release:perform”, que según parece ejecuta por defecto los goals “deploy site-deploy” después de obtener dicha versión desde el servidor de control de versiones.
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:
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:
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.
Todo el código fuente lo tenéis disponible en GoogleCode.
Pruebas unitarias
En Eclipse y con m2eclipse he creado el proyecto raíz con dos módulos: web (de tipo war) y web-integration-test (de tipo pom). El proyecto web lo he creado con el arquetipo “org.apache.wicket:wicket-archetype-quickstart:1.4-rc1″ y luego lo he tocado un poco.
< ?xml version="1.0" encoding="UTF-8"?>
shopaasshopaas0.0.1-SNAPSHOT4.0.0shopaaswebwarWeb Application0.0.1-SNAPSHOTUI wicket para Shop As A Serviceshopaas-websrc/main/resourcessrc/main/java****/*.javasrc/test/java****/*.javamaven-compiler-plugintrue1.51.5truetrueorg.mortbay.jettymaven-jetty-plugin10808060000maven-eclipse-plugintrueorg.apache.wicketwicket${wicket.version}org.slf4jslf4j-log4j121.4.2log4jlog4j1.2.14junitjunit4.5testorg.mortbay.jettyjetty${jetty.version}providedorg.mortbay.jettyjetty-util${jetty.version}providedorg.mortbay.jettyjetty-management${jetty.version}provided6.1.141.4-rc1
No quiero entrar en detalles sobre cómo es una aplicación Wicket, pero sí explicaré los dos detalles más importantes:
Si quiero desplegar la aplicación en Jetty no tengo más que ejecutar Maven con el “goal” jetty:run, pero esto sólo nos sirve para probar manualmente nuestra aplicación. (Por cierto, el puerto 8080 es el puerto por defecto, pero me gusta explicitar esta configuración).
Wicket proporciona la clase WicketTester, que permite probar la aplicación fuera del contenedor, mediante una simulación del mismo. De esta manera podemos hacer pruebas unitarias de todos los componentes de nuestra GUI sin necesidad de empaquetarla y desplegarla. Más adelante, en futuros artículos, tengo previsto entrar en detalle en cómo desarrollar la GUI con Wicket haciendo TDD.
package shopaas;
import junit.framework.TestCase;import org.apache.wicket.util.tester.WicketTester;
/** * Simple test using the WicketTester */public class TestHomePage extends TestCase{ private WicketTester tester;
@Override public void setUp() { tester = new WicketTester(new WicketApplication()); }
public void testRenderMyPage() { //start and render the test page tester.startPage(HomePage.class);
//assert rendered page class tester.assertRenderedPage(HomePage.class);
//assert rendered label component tester.assertLabel("message", "If you see this message wicket is properly configured and running"); }}
Esta prueba es muy simple, pero lo suficiente como para ver “por dónde van los tiros”. Como podéis comprobar, llegados a este punto podemos tener las pruebas unitarias de nuestra aplicación web completamente automatizadas y, por tanto, incluidas en nuestro sistema de integración continua sin mayor problema.
Pruebas funcionales
Pruebas funcionales o de integración son términos muy usados pero no tengo claro que todo el mundo entienda lo mismo cuando los usa. Lo que yo estoy llamando aquí pruebas funcionales o de integración son aquellas en las que pruebo el sistema desplegado (hasta donde se puede razonablemente). Pues bien, lo que voy a enseñar ahora es cómo desplegar de manera automática el war de nuestra aplicación y lanzar (automáticamente también) las pruebas.
Para esto he usado Cargo y he modificado el ciclo de vida de varios plugins (compiler, surefire y el propio cargo) para que se ejecuten en el orden adecuado. Además, he usado Selenium Webdriver para escribir y ejecutar las pruebas.
Al ejecutar (desde el proyecto raiz) Maven con el goal “integration-test”, el propio Maven estudia las dependencias entre artefactos y empaqueta el war (y ejecuta sus pruebas) antes de pasar a desplegar ese war en un Jetty 6 que se arranca y detiene solamente para ejecutar las pruebas de integración.
El único test que he incluido como prueba de concepto contiene dos tipos de prueba (una con Webdriver y otra sin él, la anotada con @Ignore).
package shopaas.web.integration.test;
import static org.junit.Assert.assertEquals;
import java.net.HttpURLConnection;import java.net.URL;
import org.junit.Before;import org.junit.Ignore;import org.junit.Test;import org.openqa.selenium.WebDriver;import org.openqa.selenium.htmlunit.HtmlUnitDriver;
public class WebappTest {
@Ignore @Test public void testCallIndexPage() throws Exception { URL url = new URL("http://localhost:8080/"); HttpURLConnection connection = (HttpURLConnection) url.openConnection(); connection.connect(); assertEquals(200, connection.getResponseCode()); }
private WebDriver driver;
@Before public void setUp() { driver = new HtmlUnitDriver(); }
@Test public void testHomepage() { driver.get("http://localhost:8080/"); assertEquals("Wicket Quickstart Archetype Homepage", driver.getTitle()); }
}
He utilizado el HtmlUnitDriver que, aunque también es una emulación de una navegador, para mi es suficiente, no me complica mi entorno y además es más rápido. Pero si quisiera utilizar Firefox, Safari o Internet Explorer, no tendría más que cambiar el driver correspondiente. Lógicamente, podemos tener la misma prueba con un driver diferente y estaremos asegurando que nuestra aplicación funciona para varios navegadores. Mmmmm, veo que he captado vuestra atención…
Problemas encontrados
Al poner todo esto en pie he estado bastante tiempo atascado porque cada vez que ejecutaba las pruebas de integración obtenía un mensaje de error en Jetty diciendo que no era capaz de arrancar la aplicación porque “No suitable Log constructor”. No entiendo de dónde sale el dichoso commons-logging, pero el caso es que poniendo el fichero commons-logging.properties en el classpath de la aplicación web (para que se empaquete en el war), todo pasó a funcionar perfectamente.
El otro inconveniente que tuve es más un detalle al que prestar atención que otra cosa. Se trata del valor del contexto que hay que poner en la configuración de Cargo, que debe coincidir con el valor usado en el URL de la aplicación en nuestras pruebas y en el fichero web.xml de la aplicación web.
Por fin he conseguido terminar la traducción del artículo “Introduction to m2eclipse” que comenté hace unas semanas. Espero que os sea de ayuda. Me gustaría también complementarlo con otro material en español que he encontrado en la red:
Bueno, parece que últimamente me estoy especializando en traducciones del inglés al español porque estoy traduciendo (con permiso de los autores) un artículo sobre el plugin m2eclipse que apareció este verano en TheServerSide. Espero que nadie que sea experto en traducciones lea las mías porque podrá sacarme los colores fácilmente.
Por cierto, el artículo lo estoy traduciendo a ratitos y surgió como consecuencia de una pregunta que hice en la lista “ecosistemas-software” (que aprovecho para recomendar) en la que encuestaba sobre las alternativas para usar Maven en Eclipse: m2eclipse y Q4E.
Cuando tenga terminada toda la traducción os lo haré saber.
Editado: He cambiado la dirección donde he publicado la traducción. Espero que si hay errores en la traducción me lo hagáis saber para corregirlos, gracias.
Aunque se supone que estoy de vacaciones… no he podido resistir el hacer un ejercicio (que publicaré en breve en este blog) sobre Refactoring. Pero quería ver cómo de buenos eran mis tests y, la verdad, no me siento cómodo con el plugin de Cobertura para Maven: quería algo más integrado con Eclipse. Para ello he estado mirando los proyectos TPTP de Eclipse y EclEmma. Ambos están basados en Emma.
Así pues, después de instalar EclEmma, probar la cobertura de mis tests JUnit ha sido muy fácil. Simplemente he seguido las instrucciones. (Ejem, he de reconocer que las seguí después de ver que me estaba calculando la cobertura ¡¡de los propios tests!!)
Para que no incluya nuestros tests en el informe de cobertura hay que:
pulsar en el menú “Run / Coverage”,
seleccionar la configuración de nuestro test,
pulsar en la pestaña “Coverage”
y desmarcar la carpeta correspondiente (en mi caso src/test/java porque uso Maven)
Como suponía, mi cobertura era del 100%.
De todos modos, no tener un plugin estable de Emma para Maven2 hace difícil el incorporarlo al proceso de integración continua (puesto que yo he optado por tenerlo todo con Maven2 y no usar Ant ni otros procesos añadidos). En cualquier caso, en cuanto pueda lo probaré a ver qué tal…
P.S. Si alguien tiene interés, incluyo el enlace a una presentación sobre EclEmma de la EclipseCon 2008 que puede aclarar cómo funciona por dentro (incluidas referencias a OSGi).
