PDF de programación - Programación Orientada a Objetos - JUnit

Programación Orientada a Objetos
Programación Orientada a Objetos

JUnit
JUnit

Eduardo Mosqueira Rey
Eduardo Mosqueira Rey

LIDIA
LIDIA
Laboratorio de Investigación y
Laboratorio de Investigación y
desarrollo en Inteligencia Artificial
desarrollo en Inteligencia Artificial

Departamento de Computación
Departamento de Computación
Universidade da Coruña, España
Universidade da Coruña, España

Índice
Índice

Introducción
Introducción

1.
1.
2. Tipos de tests
2. Tipos de tests
3. Desarrollo dirigido por los tests
3. Desarrollo dirigido por los tests
4. Herramientas de tests (JUnit)
4. Herramientas de tests (JUnit)
5. Herramientas de cobertura
5. Herramientas de cobertura

© Eduardo Mosqueira Rey Departamento de Computación Universidade da Coruña

2

Introducción
Introducción

El 9 de septiembre de 1947

Grace Hopper incluyó la

siguiente anotación en un libro

de log después de que se

detectara un fallo de

funcionamiento en uno de los

primeros ordenadores

electromecánicos (Mark II)

debido a un bicho que se había

introducido en un relé

Esta anotación está hoy en día
expuesta en el Museo Nacional

de Historia Americana

Aunque está demostrado que

el termino ya se usaba con

anterioridad

© Eduardo Mosqueira Rey Departamento de Computación Universidade da Coruña

3

Tipos de tests
Tipos de tests

El ámbito de los tests funcionales es todo

el sistema, tratan de comprobar que se

cumplen los requisitos funcionales

incluidos en la especificación

El ámbito de los tests de integración es la
interacción entre distintos componentes
de una aplicación. En especial cuando
estos componentes son externos (p. ej.

una base de datos)

El ámbito de los tests de unidad es el

interior de una clase dada

© Eduardo Mosqueira Rey Departamento de Computación Universidade da Coruña

4

Desarrollo dirigido por los
Desarrollo dirigido por los

tests
tests

Desarrollo dirigido por los tests (Test-Driven Development
Desarrollo dirigido por los tests (Test-Driven Development

o TDD)
o TDD)
– Se encuadra dentro de las metodologías ágiles.
– Se encuadra dentro de las metodologías ágiles.
– Básicamente lo que viene a decir es que las pruebas deben
– Básicamente lo que viene a decir es que las pruebas deben

desarrollarse ANTES que el módulo que deben probar
desarrollarse ANTES que el módulo que deben probar

– Esquema tradicional de funcionamiento del TDD
– Esquema tradicional de funcionamiento del TDD
– Esquema tradicional de funcionamiento del TDD
– Esquema tradicional de funcionamiento del TDD

• Escribir el esqueleto de la clase que queremos crear (poner las
• Escribir el esqueleto de la clase que queremos crear (poner las

funciones pero no el cuerpo)
funciones pero no el cuerpo)

• Generar los casos de prueba para esas funciones y comprobar que
• Generar los casos de prueba para esas funciones y comprobar que

fallan
fallan

• Escribir el código de las funciones
• Escribir el código de las funciones
• Volver a ejecutar los tests, si todo funciona es que el código es
• Volver a ejecutar los tests, si todo funciona es que el código es
correcto (si los tests son adecuados), sino habrá que ver que ha
correcto (si los tests son adecuados), sino habrá que ver que ha
fallado
fallado

• Aunque el código es correcto puede refactorizarse (cambiar su
• Aunque el código es correcto puede refactorizarse (cambiar su

estructura interna) para conseguir un código más eficaz y
estructura interna) para conseguir un código más eficaz y
adecuado.
adecuado.

© Eduardo Mosqueira Rey Departamento de Computación Universidade da Coruña

5

Desarrollo dirigido por los
Desarrollo dirigido por los

tests
tests

• Ventajas del TDD
• Ventajas del TDD

– Los casos de prueba representan los requisitos que esperamos
– Los casos de prueba representan los requisitos que esperamos
que cumpla nuestra aplicación, por lo que al escribirlos también
que cumpla nuestra aplicación, por lo que al escribirlos también
documentamos nuestro sistema
documentamos nuestro sistema

– Tener que desarrollar primero el código de prueba significa que
– Tener que desarrollar primero el código de prueba significa que

tenemos que ver a nuestro módulo desde el punto de vista del
tenemos que ver a nuestro módulo desde el punto de vista del
tenemos que ver a nuestro módulo desde el punto de vista del
tenemos que ver a nuestro módulo desde el punto de vista del
cliente que va a usarlo. Esto nos hace centrarnos más en la
cliente que va a usarlo. Esto nos hace centrarnos más en la
interfaz que debería tener el módulo y no en su implementación
interfaz que debería tener el módulo y no en su implementación
(la interfaz debería determinar la implementación y no al revés)
(la interfaz debería determinar la implementación y no al revés)

– Es fácil comprobar si el código desarrollado es correcto,
– Es fácil comprobar si el código desarrollado es correcto,

simplemente hay que pasar los casos de prueba. De esta forma
simplemente hay que pasar los casos de prueba. De esta forma
se reducen los tiempos de depuración de errores
se reducen los tiempos de depuración de errores

– Si automatizamos los casos de prueba es fácil comprobar si
– Si automatizamos los casos de prueba es fácil comprobar si

nuestra aplicación sigue siendo correcta después de una
nuestra aplicación sigue siendo correcta después de una
refactorización (cambios en la estructura interna). Esto nos
refactorización (cambios en la estructura interna). Esto nos
permite perder el miedo a realizar modificaciones en el código
permite perder el miedo a realizar modificaciones en el código

© Eduardo Mosqueira Rey Departamento de Computación Universidade da Coruña

6

Herramientas de test (JUnit)
Herramientas de test (JUnit)

• JUnit
• JUnit

– JUnit es una librería Java de código abierto que facilita la
– JUnit es una librería Java de código abierto que facilita la

realización de pruebas de unidad (aunque también se usa para
realización de pruebas de unidad (aunque también se usa para
correr pruebas de integración o funcionales)
correr pruebas de integración o funcionales)

– Básicamente facilita la construcción de tests y su ejecución
– Básicamente facilita la construcción de tests y su ejecución

conjunta
conjunta
conjunta
conjunta

– Antes de JUnit las pruebas de unidad se reducían a incluir un
– Antes de JUnit las pruebas de unidad se reducían a incluir un
main en cada clase que permitiera probar su ejecución (poco
main en cada clase que permitiera probar su ejecución (poco
cómodo y poco flexible)
cómodo y poco flexible)

– NetBeans integra la librería JUnit de forma que es muy sencillo
– NetBeans integra la librería JUnit de forma que es muy sencillo
crear un test para una clase determinada. Además permite crear
crear un test para una clase determinada. Además permite crear
tests en el formato del JUnit v3.8.1, así como en la nueva
tests en el formato del JUnit v3.8.1, así como en la nueva
versión v4.0 basada en anotaciones. Incluso es posible mezclar
versión v4.0 basada en anotaciones. Incluso es posible mezclar
ambos tipos de tests
ambos tipos de tests

– Mas información en: http://junit.org y en
– Mas información en: http://junit.org y en

http://junit.netbeans.org/
http://junit.netbeans.org/

© Eduardo Mosqueira Rey Departamento de Computación Universidade da Coruña

7

Herramientas de test (JUnit)
Herramientas de test (JUnit)

• Ejemplo
• Ejemplo

– Nos encargan realizar una rutina que calcule si un
– Nos encargan realizar una rutina que calcule si un

año determinado es bisiesto o no
año determinado es bisiesto o no

– Especificaciones:
– Especificaciones:
– Especificaciones:
– Especificaciones:

• Un año es bisiesto si es divisible por cuatro lo que provoca
• Un año es bisiesto si es divisible por cuatro lo que provoca

que uno de cada cuatro años sea bisiesto
que uno de cada cuatro años sea bisiesto

• Para un mayor ajuste los años divisibles por 100 no serán
• Para un mayor ajuste los años divisibles por 100 no serán

bisiestos, de tal forma que cada 100 años habrá un año que
bisiestos, de tal forma que cada 100 años habrá un año que
debería ser bisiesto y no lo es
debería ser bisiesto y no lo es

• Sin embargo si el año es divisible por 400 sí que es bisiesto,
• Sin embargo si el año es divisible por 400 sí que es bisiesto,
así cada 400 años habrá un año que no debería ser bisiesto
así cada 400 años habrá un año que no debería ser bisiesto
pero sí que lo es
pero sí que lo es

© Eduardo Mosqueira Rey Departamento de Computación Universidade da Coruña

8

Herramientas de test (JUnit)
Herramientas de test (JUnit)

El primer paso según el TDD sería
crear el tests. Sin embargo, vamos a
crear una versión trivial del código

para aprovecharnos de las
capacidades de NetBeans de

autogeneración de tests.

De todas formas el código creado

debe siempre FALLAR el test

9

Herramientas de test (JUnit)
Herramientas de test (JUnit)

Le decimos a NetBeans que cree un

test JUnit para esta clase.

También le indicamos que vamos a
crear tests siguiendo la versión 4 de

JUnit.

10

Herramientas de test (JUnit)
Herramientas de test (JUnit)

Los tests se generan preferentemente en
un subdirectorio separado de los fuentes
(aunque lógicamente se sitúan dentro del

mismo paquete)

Podemos elegir sobre que métodos

queremos hacer las pruebas

(generalmente serán los métodos públicos
(generalmente serán los métodos públicos

de la clase)

Los métodos de inicialización son

procedimientos que se ejecutan siempre
antes de hacer ningún test (p. ej. leer un

recurso de disco)

Los métodos de finalización realizan la
operación contraria, se ejecuta al final de
hacer los tests para liberar los recursos

comprometidos

Default Method Bodies crea tests por

defecto cuyo resultado es un fallo

© Eduardo