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.
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.
/** * 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.
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.
org.codehaus.cargo cargo-maven2-plugin false shopaas web war /
...
Bien, creo que esto es todo. Si tenéis interés y el código de ejemplo no es suficiente, no dudéis en preguntarme y trataré de ayudaros.