martes, 20 de marzo de 2012

Pruebas unitarias con junit (II)

En el post anterior me quedé un poco corto, junit nos permite muchas más cosas. Expliqué que las pruebas unitarias deben ser independientes, ahora veremos como podemos hacer esto.

En el caso que nos ocupaba, cada prueba era autocontenida, los datos que se utilizaban formaban parte de la clase, más aún, del método de prueba. Vemos que los operadores de la operación de suma están contenidos en el código del método.

public void testAdd100 (){
int num1 = 3;
int num2 = 2;
int total = 5;
int sum = 0;

sum = Mathematica.add(num1, num2);
assertEquals(sum, total);
}

En otras ocasiones nos enfrentaremos con clases que tenemos que inicializar, bases de datos que deben estar en un determinado estado antes de realizar la prueba, y que deben estar en un determinado estado al terminar la prueba (o pruebas).

Junit nos provee con dos métodos que podemos sobreescribir

setup: se ejecuta al principio de la ejecución de la clase de pruebas, en el podemos inicializar clases, abrir conexiones, insertar datos, cargar ficheros, ...

teardown: se ejecuta después de ejecutar el último test de la clase de pruebas, en el podemos restaurar los valores según se hayan definido para el fin de la prueba.

Vamos a probar una clase que necesita configuración inicial:

public class Configuracion {

private int rowNumber;

public Configuracion (int valor){
this.rowNumber=valor;        
}

public int getRowNumber (){
return  this.rowNumber;
}

public void setRowNumber ( int valor ){
this.rowNumber=valor;
}
}


Definimos dos casos de prueba

En el primero crearemos un valor para el rowNumber, y validaremos que este valor está correctamente establecido.

En el segundo estableceremos un valor para el rowNumber, y validaremos que este valor está correctamente establecido.

Creamos la clase de prueba

public class TestConfiguracion extends TestCase{

protected Configuracion configuracion;

public void setUp (){
configuracion = new Configuracion (5);
}

public void testConfiguracion001 () {
int c= configuracion.getRowNumber();
int inicial = 5;

assertEquals(c,inicial);
}

public void testConfiguracion002 () {
int valor = 3;
configuracion.setRowNumber(valor);
int c= configuracion.getRowNumber();

assertEquals(c,valor);
}
}

Para crear la clase configuración hemos de asignar un valor, algo que hacemos en el método setUp(). Así para el primer test está establecido con el valor que fijamos en la llamada al constructor.

Algo que no mencioné, los métodos de prueba se ejecutan en orden alfabético.

En la segunda prueba, nos aseguramos que el método setRowNumber funciona adecuadamente, ya que en la anterior hemos validado que tanto el constructor como getRowNumber funcionan adecuadamente.

¿Cómo se entiende que en un blog en español haya escrito la clase que vamos a probar en ingles? Sólo para remarcar una idea, he partido de unos requerimientos y mi parte inglesa ha escrito la función que los cumple, y mi parte castellana la función que los valida. Algo bastante habitual en grandes proyectos.

Para ejecutar esta clase de test he creado un target para ant de la siguiente manera



                 








Teniendo el resultado

testConfig:

[junit] Running com.blog.TestConfiguracion
[junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 0,016 sec

No hay comentarios:

Publicar un comentario