Ejemplos java y C/linux

Tutoriales

Enlaces

Licencia

Creative Commons License
Esta obra está bajo una licencia de Creative Commons.
Para reconocer la autoría debes poner el enlace https://old.chuidiang.org

JUnit en maven y en eclipse

Ahora que conocemos la librería JUnit y sabemos hacer test con ella, veremos que casi todos los IDE y las herramientas de compilado permiten integrar en ellas test automáticos de prueba. En este tutorial vamos a ver cómo se pueden hacer esos test desde eclipse o como integrar esos test con una herramienta como maven.

Empezaremos viendo como podemos crear los test de JUnit en eclipse y las opciones que nos da el wizard de eclipse a la hora de crear la clase de test. También como ejecutar estos test desde eclipse.

Luego, teniendo en cuenta la importancia de ejecutar estos test con frecuencia, veremos cómo es aconsejable usar además del IDE (eclipse en este caso) alguna herramienta como maven que ejecuta todos los test cada vez que compilamos el proyecto. Esto lleva también a la necesidad de alguna herramienta de integración continua, de esas que todas las noches y de forma automática compila nuestro proyecto, sin ninguna intervención nuestra.

Crear test de JUnit en eclipse

Supongamos que en eclipse ya tenemos montado nuestro proyecto con las clases Suma.java y Resta.java del tutorial de JUnit. En el directorio donde queramos crear el test, damos al botón derecho del ratón para obtener el menú y elegimos new -> JUnit test case. Si no hemos hecho todavía ningún test, eclipse nos preguntará la versión de JUnit que deseamos usar. Elegimos la que más nos guste y obtenemos la siguiente ventana

Hay varias cosas que podemos rellenar.

Una vez relleno todo, pulsamos next y obtenemos la siguiente ventana

Al haber puesto la clase que queremos testear en el paso anterior, nos aparece aquí la clase con todos sus métodos. Podemos marcar aquellos de los que prevemos hacer test. Pulsamos Finish y veremos que se genera la siguiente clase de test

package com.chuidiang.ejemplos.junit38;

import junit.framework.TestCase;

public class TestDeSuma extends TestCase {
   protected void setUp() throws Exception {
      super.setUp();
   }

   protected void tearDown() throws Exception {
      super.tearDown();
   }

   public final void testGetSuma() {
      fail("Not yet implemented"); // TODO
   }

   public final void testIncrementa() {
      fail("Not yet implemented"); // TODO
   }
}

Vemos que se han creado los métodos setUp() y tearDown(), según habíamos marcado. No se ha generado constructor, ya que no lo habíamos marcado. Y se han generado un método de test para cada uno de los métodos de nuestra clase Suma que habíamos marcado. Estos métodos llaman a fail(), que es un método de la clase padre TestCase que provoca un fallo en el test. El fallo, obviamente, es que el test todavía no está implementado.

Con esto, podemos símplemente rellenar el código de los métodos de test. Lo hacemos de acuerdo al ejemplo anterior de JUnit y obtenemos la clase TestSuma.java.

Una vez hecho, para ejecutar el test desde eclipse, seleccionamos la clase y con el botón derecho del ratón, sacamos el menú y elegimos Run as -> JUnit test. Puesto que la clase Suma.java está hecha mal a posta para que falle, obtendremos la siguiente ventana de resultado de test

En esta ventana podemos elegir otros test que tengamos disponibles en el combo superior, donde aparece el nombre de la clase TestSuma, y pulsar luego el botón Run, situado a la derecha, para ejecutar el test elegido.

JUnit y maven

Como mencionamos en la introducción de test automáticos, es muy importante ejecutar los test automáticos con mucha frecuencia, especialmente mientras estamos modificando código que ya funcionaba para añadirle alguna nueva funcionalidad o corregir algún error. Sólo con eclipse no conseguimos esto, ya que somos nosotros manualmente los que debemos ejecutar los test cada vez. Por ello, son interesantes herramientas como maven.

No vamos a entrar aquí en detalles sobre maven, para ello sigue el enlace anterior. De momento, baste decir que maven es una herramienta de línea de comandos que permite crear de forma automática una estructura de directorios para un proyecto java. Una vez creada, tendremos directorios src/main/java para nuestros fuentes java y src/test/java para nuestros Test de JUnit. En el directorio principal del proyecto, maven crea un fichero pom.xml en el que se pone información del proyecto, como nombre del mismo, autor, ... y otras cosas tan interesantes como qué jars externos necesitamos para nuestro proyecto. La estructura que crea maven es como la de la imagen

Por defecto, ese fichero pom.xml indica que necesitamos JUnit 3.8.1 para hacer los test. Podemos cambiar la versión si lo deseamos. Aquí tienes el fichero pom.xml del ejemplo de JUnit, que he hecho con maven.

<project xmlns="http://maven.apache.org/POM/4.0.0"
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   xsi:schemaLocation=
      "http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
   <modelVersion>4.0.0</modelVersion>
   <groupId>com.chuidiang.ejemplos</groupId>
   <artifactId>ejemplo-junit</artifactId>
   <packaging>jar</packaging>
   <version>1.0-SNAPSHOT</version>
   <name>ejemplo-junit</name>
   <url>http://www.chuidiang.com</url>
   <dependencies>
      <dependency>
         <groupId>junit</groupId>
         <artifactId>junit</artifactId>
         <version>3.8.1</version>
         <scope>test</scope>
      </dependency>
   </dependencies>
</project>

Una vez que hacemos nuestras clases Suma.java y Resta.java en el directorio src/main/java y que hacemos nuestras clases de Test en el directorio src/test/java, con maven tenemos una ventaja importante. Cada vez que le decimos a maven que compile nuestro proyecto, maven se encargará de ejecutar todos los test (todas las clases en src/test/java que empiecen por Test***). Gracias a ello, no hay posibilidad de despieste. Sólo podemos conseguir el jar de nuestro proyecto si compila y todos los test pasan correctamente.

El comando para compilar con maven es algo así como mvn install. Esta sería la salida de ese comando cuando todo compila correctamente, pero falla un test.

Vemos que indica que el método testGetSuma() de la clase TestSuma ha fallado y por ello, al final da un BUILD FAILURE y no genera el jar de la aplicación.

Otras herramientas de este estilo, como ant, permiten que se las configure para ejecutar también los test en cada compilado. En el caso de ant, no lo hace por defecto, pero se puede poner en el fichero build.xml, que es el fichero donde se indica qué cosas se debe hacer para compilar el proyecto.

Integración continua

Con maven todavía tenemos un pequeño problema. Sólo pasa los test si le damos a compilar. Desgraciadamente, aunque usemos maven para gestionar el proyecto, normalmente trabajaremos con un IDE como eclipse y compilaremos con él, no en maven. Por ello, todavía no tenemos garantizado que los test se pasen con frecuencia.

En parte pasa solucionar esto, salen las llamadas herramientas de integración continua, como Cruise Control, Continuum o Hudson. Una vez instaladas estas herramientas y configuradas para tener en cuenta nuestros proyectos, lo que suelen hacer es compilar por la noche nuestro proyecto desde cero. Si nuestro proyecto es maven y la herramienta de integración continua está configurada para usar maven para compilar (suele ser lo habitual), ese compilado nocturno también pasará los test.

A la mañana siguiente, cuando lleguemos a trabajar, tendremos un correo enviado por esta herramienta indicando si el compilado ha ido bien o si ha habido algún fallo, así como un enlace a la web de la herramienta en el que podremos ver los detalles del fallo.

Gracias a estas herramientas, todas las noches, sistemáticamente, se compila y prueba el código generado a lo largo del día, por lo que cualquier metedura de pata en el mismo, no pasa mucho tiempo inadvertida. No es lo mismo darse cuenta que hace un mes metí la pata en un sitio, que darse cuenta que ayer metí la pata en un sitio. Tendré "más fresco" lo de ayer y me resultará más fácil de corregir.

Pasemos ahora a ver qué cosas son difíciles de testear y algunos truquillos de cómo testearlas.

Estadísticas y comentarios

Numero de visitas desde el 4 Feb 2007:

Aviso Legal