Pruebas funcionales automatizadas de una aplicación web

Hoy voy a resumir cómo automatizar las pruebas funcionales de una aplicación web utilizando:

  • Maven. Con Maven gestionamos el ciclo de vida de la construcción y las pruebas, así como las dependencias entre artefactos.
  • Cargo. Con este plugin Maven realizamos el despliegue de la aplicación web en el contenedor de nuestra elección.
  • Selenium Webdriver. Con este framework y el correspondiente plugin Maven ejecutamos las pruebas funcionales.
  • Jetty. Éste es el contenedor web de mi elección. (Podría haber sido Tomcat, Glassfish o cualquier otro).
  • JUnit. Como framework de pruebas.
  • Wicket. Éste es el framework web de mi elección.

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"?>


shopaas
shopaas
0.0.1-SNAPSHOT

4.0.0
shopaas
web
war
Web Application
0.0.1-SNAPSHOT
UI wicket para Shop As A Service

shopaas-web


src/main/resources


src/main/java

**


**/*.java





src/test/java

**


**/*.java





maven-compiler-plugin
true

1.5
1.5
true
true



org.mortbay.jetty
maven-jetty-plugin

10


8080
60000





maven-eclipse-plugin

true






org.apache.wicket
wicket
${wicket.version}


org.slf4j
slf4j-log4j12
1.4.2


log4j
log4j
1.2.14


junit
junit
4.5
test


org.mortbay.jetty
jetty
${jetty.version}
provided


org.mortbay.jetty
jetty-util
${jetty.version}
provided


org.mortbay.jetty
jetty-management
${jetty.version}
provided



6.1.14
1.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.


xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">

4.0.0

shopaas
shopaas
0.0.1-SNAPSHOT

web-integration-test
pom
Functional Tests


shopaas
web
0.0.1-SNAPSHOT
war


junit
junit
4.5
test



org.openqa.selenium.webdriver
webdriver-htmlunit
0.6.685


org.openqa.selenium.webdriver
webdriver-support
0.6.685



org.mortbay.jetty
jetty
${jetty.version}
provided


org.mortbay.jetty
jetty-util
${jetty.version}
provided


org.mortbay.jetty
jetty-management
${jetty.version}
provided






org.apache.maven.plugins
maven-compiler-plugin

1.5
1.5
true
true




testCompile





org.apache.maven.plugins
maven-surefire-plugin


integration-test

test





org.codehaus.cargo
cargo-maven2-plugin

false



shopaas
web
war

/







start
pre-integration-test

start



stop
post-integration-test

stop








jetty6x

true


6.1.14




org.codehaus.cargo
cargo-maven2-plugin


jetty6x
embedded



8080
medium









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.


org.apache.commons.logging.Log=org.apache.commons.logging.impl.SimpleLog

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.

  • Anonymous

    You helped me a lot with this example, thank you very much!