JUnit introducción

TemariodecursoJavaSE©IñakiMartín 
23.- JUnit 1
TEMARIO DE CURSO
PROGRAMACIÓN JAVA SE
CAPÍTULO 23
JUNIT (introducción)
© Iñaki Martín
Este obra está bajo una licencia de Creative Commons Reconocimiento-NoComercial-SinObraDerivada 4.0 Internacional.

23.- JUnit 2
๏ JUnit es un paquete Java utilizado para automatizar los procesos de prueba. Mediante la creación de Tests, JUnit
permite realizar pruebas en un código desarrollado en Java
๏ Normalmente las pruebas se realizan por parte del programador, al menos en una fase inicial. Posteriormente, pueden
existir quipos de calidad de software que realicen las pruebas en coordinación con el equipo de desarrollo
๏ Existen varias razones para utilizar JUnit a la hora de hacer pruebas de código:
✓ La herramienta no tiene coste alguno, podremos descargarla directamente desde la Web oficial. Algunas
herramientas como Eclipse, traen ya incluso JUnit instalado por defecto
✓ Es una herramienta muy utilizada, por lo que no será complicado buscar documentación. Existen varios plugins
para poder utilizar con diferentes Entornos de Desarrollo Integrado(IDE).
✓ Existen también muchas herramientas de pruebas de cobertura que utilizaran como base JUnit.
✓ Los tests JUnit se pueden organizar en suites, las que contendrán ejemplares de tests, incluso podrán contener
otras suites.
✓ Los tests realizados se podrán presentar junto con el código, para validar el trabajo realizado.
Que es JUnit
Que es JUnit
JUnit tiene varias versiones, con ligeros cambios en la sintaxis de algunos de sus
métodos. Nosotros usaremos la version 5, también llamada Jupiter
Puesto que Eclipse lleva integrado JUnit, los ejemplos de este curso se realizan
en dicha plataforma. Si se desea usar alguna otra, hay que tener en cuenta que
han de descargase las librerías correspondientes e integrarlas en el proyecto

23.- JUnit 3Elementos de JUnit
Elementos de JUnit
๏ JUnit opera a través de la creación de diversas unidades de prueba (Test Units), que no son mas que métodos que
van a probar distintas funcionalidades de nuestra aplicación.
๏ Normalmente los Test Units se crean conjuntos en una Clase de Pruebas llamada Test Case. Posteriormente, pueden
incluso juntarse varias Clases de Pruebas en una Suite de Pruebas (Test Suite)
๏ Para nuestros ejemplos, vamos a hacer pruebas sobre un desarrollo que damos por creado, que consiste en dos
clases: una clase Persona con un par de atributos, y una clase GestionPersonas que tiene un array de Persona y
varias métodos (que son lo que vamos a probar en nuestros tests):
class Persona {
private String nombre;
private int edad;
public Persona(String nombre, int edad) {
super();
this.nombre = nombre;
this.edad = edad;
}
@Override
public boolean equals(Object obj) {
Persona other = (Persona) obj;
if (edad != other.edad) return false;
if (!nombre.equals(other.nombre)) return false;
return true;
}
public String getNombre() {
return nombre;
}
public void setNombre(String nombre) {
this.nombre = nombre;
}
public int getEdad() {
return edad;
}
public void setEdad(int edad) {
this.edad = edad;
}
}
public class GestionPersonas {
Persona[] arrPersonas;
public void crearArray() {
arrPersonas = new Persona[3];
arrPersonas[0] = new Persona("Pepe", 23);
arrPersonas[1] = new Persona("Ana", 11);
arrPersonas[2] = new Persona("Luis", 59);
}
public int mayorEdad() {
int mayor = arrPersonas[0].getEdad();
for (Persona p : arrPersonas) {
if (p.getEdad() > mayor) {
mayor = p.getEdad();
}
}
return mayor;
}
public Persona quienMayorEdad() {
int mayor = arrPersonas[0].getEdad();
Persona pmayor = arrPersonas[0];
for (Persona p : arrPersonas) {
if (p.getEdad() > mayor) {
mayor = p.getEdad();
pmayor = p;
}
}
return pmayor;
}
}
CUIDADO:
Si nuestras futuras
pruebas en JUnit
contemplan comparar
objetos (si son iguales
uno a otro), estos han
de tener sobrescrito su
propio método equals()
Si además han de
compararse por orden
(un elemento mayor o
menor que otro) deben
tener sobrescrito el
método compareTo()

23.- JUnit 4Test Case y Test Units
Crear Test Case y Test Units
๏ Comenzamos por crear unos Test Units sencillos.
๏ Para ello se crea un Test Case, que es simplemente una clase normal, a la que se añaden diferentes métodos, cada
uno de los cuales es un Test Unit. Veamos un ejemplo y que significa cada uno de sus componentes:
import static org.junit.jupiter.api.Assertions.assertEquals;
import org.junit.jupiter.api.Test;
public class TestMainPersona {
@Test
public void testMayorEdad() {
GestionPersonas m = new GestionPersonas();
m.crearArray();
int mayorReal = m.mayorEdad();
int mayorEsperado = 87;
assertEquals(mayorReal, mayorEsperado);
}
@Test
public void testQuienMayorEdad() {
m.crearArray();
Persona personaMayor = m.quienMayorEdad();
// Persona personaMayorEsperada = m.arrPersonas[3];
Persona personaMayorEsperada = new Persona("Luis", 59);
assertEquals(personaMayor, personaMayorEsperada);
}
}
Creamos el Test Case, que es la clase
TestMainPersona. La clase es una clase normal
(en versiones previas de JUnit debía heredar de
TestCase, ya no al usar anotaciones)
Esta anotación indica que el método que va
a continuación es una prueba. Se pueden
incluir varios métodos que hagan varias
pruebas seguidas
Dentro del método he de obtener valores de
nuestro programa y poder comprobar si son
los esperados. En nuestro caso ejecutamos
el método que nos dice cual es la edad
mayor existente
Este es el elemento más importante.
assertEquals(a,b) comprueba que a y b sean
iguales, y si no lo son, nuestro test dará error.
Hay otros métodos para hacer comprobaciones
diferentes, que se ven en páginas siguientes.
Este text debe dar error, pues la persona con
mayor edad no tiene 87, sino 59 años……
Este es otro ejemplo de otra Test Unit, en
este caso, se comprueba que el método
quienMayorDeEdad() devuelve realmente a
la persona de mayor edad…
Este test no debe dar error…

23.- JUnit 5Ejecución de pruebas de los Test Units
Ejecución de la pruebas
๏ Para ejecutar las pruebas, basta con ejecutar normalmente la clase TestMainPersona que acabamos de crear
๏ Se abre una ventana en Eclipse para JUnit que nos informa de los resultados de las pruebas:
Esta es la ventana que
muestra los resultados
Esto indica si se ha producido algún error al construir nuestras
pruebas, (no en el desarrollo que estamos probando)
Esto indica si se ha producido algún error al ejecutar
los test, esto es, si alguna prueba ha dado error
Aquí vemos uno a uno cuales han sido los resultados de los
test efectuados.
Vemos que el uno ha ido bien, marcado con
y que otro no ha ido bien, marcado con
Barra roja indica problemas en las pruebas,
alguna no ha sido satisfactoria.
๏ Si cambiamos la prueba que falla, para que no de fallos, vemos la nueva ejecución:
@Test
m.crearArray();
}

23.- JUnit 6Métodos de pruebas
Métodos de pruebas
๏ En el ejemplo anterior vimos como se usaba el método assertEquals(), para comprobar que dos elementos habían de
tener el mismo valor.
๏ No es el único método que puede usarse en pruebas, aquí mostramos algunos de los más interesantes:
DEVUELVE METODOS DESCRIPCION
void assertEquals ( val1, val2 )
Método que se verifica que los dos valores, val1 y val2, son idénticos.
Nota: Con arrays se verifica la referencia, no el contenido de éstos.
void assertTrue ( condicion1 ) Método que se verifica que condicion1 sea true
void assertFalse ( condicion1 ) Método que se verifica que condicion1 sea true
void assertNull( val1 ) Método que se verifica que val1 sea null. Si no es null, da error
void assertNotNull ( val1) Método que se verifica que val1 no sea null. Si es null, da error
void fail ( mensaje )
Método que se provoca un error, se debe incluir dentro de nuestras pruebas como una salido
directa de error, sin tener que comprobar solamente lo que nos ofrecen el resto de métodos.
El mensaje que se indica, que es opcional, se ve en la ejecución de la prueba ,cuando falla.

23.- JUnit 7Test Fixtures
Tests Fixtures
๏ Los Test Fixtures son unos nuevos métodos que podemos añadir a nuestra clase de pruebas, que se ejecutan a la vez
que nuestros métodos de pruebas, y pueden ayudarnos a mejorar éstas. Estos nuevos métodos se identifican con unas
nuevas anotaciones, veamos cuales son:
@BeforeAll - el método que marca esta anotación se ejecutará al principio, antes de todas las pruebas @Test
@AfterAll - el método que marca esta anotación se ejecutará al final, tras todas las pruebas @Test
@BeforeEach - el método que marca esta anotación se ejecutará antes de cada una de las pruebas @Test
@AfterEach - el método que marca esta anotación se ejecutará tras cada una de las pruebas @Test
๏ Estas anotaciones marcan nuevos métodos, pero… ¿ qué nombres han de tener esos nuevos métodos ?
๏ Pues pueden tener el nombre que nosotros queramos, aunque existen “estándares” de hecho para que todo el mundo los
llame igual (como los guetterts y setters), pero que realmente, no es obligatorio. Los nombres habituales son:
@BeforeAll
// cuidado, éste ha de ser static
public static void setUpBeforeClass(){
……
}
@AfterAll
// cuidado, éste ha de ser static
public static void tearDowAfterClass(){
……
}
@BeforeEach
public void setUp(){
……
}
@AfterEach
public void tearDown(){
……
}

23.- JUnit 8
๏ Vamos a cambiar nuestra aplicación para usar los Fixtures
๏ En nuestro ejemplo, vemos que cada vez que ser hacia una prueba había que llamar a crear la clase GestionPersonas, y
eso es algo que podríamos hacer tan solo una vez, así que lo añadimos en el método setUpBeforeClass(), que es el
marcado con @BeforeAll
public class TestMainPersona2 {
static GestionPersonas m;
@BeforeAll
public static void setUpBeforeClass() {
m = new GestionPersonas();
}
El objeto lo creamos dentro de setUpBeforeClass(),
pero claro, si deseamos usarlo en todos los otros
métodos @Test, hemos de declararlo como atributo
de la clase
Y como el método setUpBeforeClass() es static, el
atributo ha de ser también static….
๏ Asimismo, puede que antes de cada prueba me haya de asegurar que el array de personas esta correctamente creado,
por que por ejemplo, en alguna prueba lo haya modificado, así que vamos a a hacer es crear el array en el método
setUp(), que es el marcado con @BeforeEach, para que se realice antes de cada uno de los métodos @Test:
@BeforeEach
public void setUp() {
m.crearArray();
}
๏ Finalmente, vamos a crear nuevas pruebas, una por ejemplo, que nos modifique el array y así, veamos que las
pruebas funcionan bien por la inclusión del fixture @BeforeEach. El código completo esta en la página siguiente:
Test Fixtures

23.- JUnit 9
static GestionPersonas m;
// TEST FIXTURES ---------------------------------------
@BeforeAll
public static void setUpBeforeClass() {
m = new GestionPersonas();
}
@BeforeEach
public void setUp() {
m.crearArray();
}
// TEST UNITS ———————————————————
// ——- comprueba que ningún elemento del array es null
@Test
public void testNigunElementoEsNull() {
for (Persona p : m.arrPersonas) {
if (p == null) {
fail("ERROR: UNA PERSONA ES NULL !!!");
}
}
}
@Test
public void testQuienMayorEdad() {
m.arrPersonas[0].setEdad(10000);
Persona personaMayorCalculada = m.quienMayorEdad();
Persona personaMayorEsperada = m.arrPersonas[2];
assertEquals(personaMayorCalculada, personaMayorEsperada);
}
@Test
}
// ——- // comprueba que el array no es null
@Test
public void testExisteArray() {
assertNotNull(m.arrPersonas);
}
}
No se incluyen @AfterEach ni @AfterAll , pues no se usan, pero se codificarían igual que los @BeforeXxx correspondientes
En este método vemos el uso de fail() Cuando se produce
cierta condición de error que deseamos controlar, (en este
caso, que hay un elemento null en el array), hacemos una
llamada al método fail()
Si por alguna razón alguno de los elementos del array fuera
null, en las pruebas saldría algo como esto, que indica, al
pincha en el test que da error, en una ventana nueva llamada
FailureTrace, que error se ha dado (ver que aparece el texto
“ERROR: ES UNA PERSONA NULL)
En este método hemos modificado el array, cambiando la edad a
una de las personas. No es un ejemplo que sea de mucha utilidad,
pero sirve para ver que los siguientes test siguen funcionando,
pues el array se crea siempre antes de cada prueba, al hacerlo en
el método marcado con @BeforeEach
Se ejecuta antes de
todos los tests, y
vale para inicializar
elementos, como en
nuestro caso, crear
el objeto de la clase
GestionPersonas
Se ejecuta antes de
ejecutar cada uno de
los tests, y vale para
asegurar que los
tests empiezan
siempre con las
condiciones
deseadas, como en
nuestro caso, que
creamos siempre el
array de personas
para que sea
siempre “nuevo”
Test Fixtures

23.- JUnit 10
๏ Como ya se dijo, los Test Units se crean conjuntos en una Clase de Pruebas llamada Test Case. Y posteriormente,
pueden incluso juntarse varias Clases de Pruebas en una Suite de Pruebas (Test Suite)
๏ Una Test Suite es una clase simple, cuyo contenido puede quedar vacio por ahora, que marca dos nuevas anotaciones.
Y que solo exige que indiquemos las clases que contienen nuestros Test Case en una de ellas :
Test Fixtures
JUnit Suite
import org.junit.runner.RunWith;
import org.junit.runners.Suite;
@RunWith(Suite.class)
@Suite.SuiteClasses({ TestMainPersona.class, TestMainPersona2.class })
public class SuiteDeTodosLosTest {
}
Aquí se indican , separados por comas, los .class de las clases de test
que hemos creado anteriormente
Las dos anotaciones nuevas se incluyen tal y como se muestran en
este ejemplo
๏ También se puede invocar a que se realicen todas las pruebas de todos los Case existentes en un package, o en un
proyecto, haciendo click el package o el proyecto, y ejecutando Run -> Run as -> JUnit Test

23.- JUnit 11
๏ Puede que en un momento dado, en un plan de pruebas con muchos Test Units o Test Case, no deseemos que alguna
de ellas se realice momentáneamente. No es necesario que se comente o borre dicho Unit o Case, podemos usar la
anotación @Ignore
@Ignore
@Test
}
Test Fixtures
@Ignore
@Ignore
@Test
}

JUnit introducción

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Similar a JUnit introducción

Similar a JUnit introducción (20)

Más de Jyoc X

Más de Jyoc X (16)

Último

Último (19)

JUnit introducción