SlideShare una empresa de Scribd logo
1 de 9
JUnit 
JUnit 
Desarrollador 
Kent Beck, Erich Gamma, David Saff 
http://junit.sourceforge.net 
Información general 
Última versión 
estable 
4.11 [1] 
14 de noviembre de 2012; hace 1 
año 
Género 
Herramienta para Prueba 
unitaria 
Programado en Java 
Sistema operativo multiplataforma 
Plataforma Java 
Licencia Common Public License 
Idiomas inglés 
JUnit es un conjunto de bibliotecas creadas por Erich Gamma y Kent Beck que son 
utilizadas en programación para hacer pruebas unitarias de aplicaciones Java. 
JUnit es un conjunto de clases (framework) que permite realizar la ejecución de clases Java 
de manera controlada, para poder evaluar si el funcionamiento de cada uno de los métodos 
de la clase se comporta como se espera. Es decir, en función de algún valor de entrada se 
evalúa el valor de retorno esperado; si la clase cumple con la especificación, entonces JUnit 
devolverá que el método de la clase pasó exitosamente la prueba; en caso de que el valor 
esperado sea diferente al que regresó el método durante la ejecución, JUnit devolverá un 
fallo en el método correspondiente. 
JUnit es también un medio de controlar las pruebas de regresión, necesarias cuando una 
parte del código ha sido modificado y se desea ver que el nuevo código cumple con los 
requerimientos anteriores y que no se ha alterado su funcionalidad después de la nueva 
modificación. 
El propio framework incluye formas de ver los resultados (runners) que pueden ser en 
modo texto, gráfico (AWT o Swing) o como tarea en Ant.
En la actualidad las herramientas de desarrollo como NetBeans y Eclipse cuentan con plug-ins 
que permiten que la generación de las plantillas necesarias para la creación de las 
pruebas de una clase Java se realice de manera automática, facilitando al programador 
enfocarse en la prueba y el resultado esperado, y dejando a la herramienta la creación de las 
clases que permiten coordinar las pruebas. 
Índice 
 1 JUnit 4 
 2 Referencias 
 3 Véase también 
 4 Enlaces externos 
JUnit 4 
Este framework se encuentra actualmente en la versión 4.6, con grandes mejoras. He aquí 
una pequeña relación: 
 4.6 
 Incluye un nuevo Core experimental: MaxCore. Recuerda los resultados de 
ejecuciones previas. Existe un plug-in para Eclipse. 
 Incluye un método para indicar la máquina que ejecuta los tests. 
 Se pueden comparar Arrays: assertArrayEquals(new double[] {1.0, 2.0}, new 
double[] {1.0, 2.0}, 0.01); 
 Desde 4.0 se ha podido ejecutar un único método utilizando la API: 
Request.method. Ahora el filtro que implementa esta funcionalidad está expuesto 
en: Filter.matchDescription. 
Para más información: [2] 
 4.5 
 Incluye anotaciones (Java 5 annotations) en lugar de utilizar herencia: 
o @Test sustituye a la herencia de TestCase. 
o @Before y @After como sustitutos de setUp y tearDown. 
o Se añade @Ignore para deshabilitar tests. 
 Permite timeouts en los tests. 
 Configurar excepciones esperadas. 
 Ordenación, priorización, categorización y filtrado de tests. 
 Forward y backward compatibilidad. 
 Logging. 
 Más tipos de aserciones (ej: assertEquals(Object[], Object[])) 
 Se elimina la distinción entre errores (errors) y fallos (failures).
Referencias 
Véase también 
 Portal:software libre. Contenido relacionado con software libre. 
 Prueba unitaria 
Enlaces externos 
 Página principal de JUnit 
 Tutorial de JUnit de la Escuela Super
Pruebas de Aceptación 
José A. Mañas <jmanas@dit.upm.es> 
Dept. de Ingeniería de Sistemas Telemáticos 
Universidad Politécnica de Madrid 
5 de febrero, 2004 
1. Introducción 
Se dice que un programa es aceptable cuando: 
1. hace lo que debe hacer 
2. no hace lo que no debe hacer 
Un programador jamás debería entregar un programa sin haberlo probado. Quien recibe un 
programa de otro, jamás debería aceptarlo sin haberlo probado. 
A partir de la especificación de lo que se espera de un programa, se prepara una batería de 
casos de prueba. La batería que prepara el programador le permite saber cuándo ha 
terminado. La batería que prepara quien va a recibir el programa le permite saber si puede 
aceptarlo o no. 
Los casos de prueba se pueden escribir en papel y ejecutarlos disciplinadamente de forma 
manual, estrategia que solo es viable para programas pequeños. En programación 
profesional conviene automatizar las pruebas de forma que se pueden realizar muchas 
veces, tanto durante el desarrollo (hasta estar satisfechos), como durante la aceptación (para 
dar el programa por correcto, como si en el futuro hay que modificar el programa (para 
cerciorarnos de que no hemos roto nada que antes funcionaba). 
2. JUnit 
JUnit es un paquete Java para automatizar las pruebas de clases Java. 
Se puede coger de 
http://www.junit.org 
La forma más sencilla de utilizar JUnit es crear una clase pública que sea extensión de 
TestCase. En esta clase, cada prueba es un método cuyo nombre debe comenzar por 
"test...", ser público y no devolver nada (void). La clase suele incluir un constructor para 
inicializar variables privadas. Este es el patrón: 
import junit.framework.*; 
public class MisPruebas extends TestCase { 
// variables_privadas
public MisPruebas () { 
// inicialización 
} 
public void testXXX () { 
// código que debe funcionar 
} 
} 
Ejemplo sencillo: pruebas de Java 
package lprg.pruebas; 
import junit.framework.*; 
public class Tests extends TestCase { 
public Tests () { } 
public void testSumas () { 
assertEquals(4, 2+2); 
assertEquals(2, 2+0); 
assertEquals(2, 0+2); 
} 
public void testDivisiones () { 
assertEquals(1, 2/2); 
assertEquals(2, 4/2); 
assertEquals(2, 5/2); 
} 
public static void main (String[] args) { 
// ejecución por consola texto: 
// junit.textui.TestRunner.run(Tests.class); 
// ejecución en una ventana: 
junit.swingui.TestRunner.run(Tests.class); 
} 
} 
3. Funciones para probar 
JUnit incluye una serie de métodos para probar que las cosas son como esperamos. Aunque se 
remite al lector a la documentación detallada del paquete, las siguientes funciones son básicas: 
assertEquals (X 
esperado, X real) 
compara un resultado esperado con el resultado obtenido, 
determinando que la prueba pasa si son iguales, y que la prueba falla 
si son diferentes. 
Realmente el método es una colección de métodos para una amplia 
variedad de tipos X. 
assertFalse (boolean verifica que el resultado es FALSE
resultado) 
assertTrue (boolean 
resultado) 
verifica que el resultado es TRUE 
assertNull (Object 
resultado) 
verifica que el resultado es "null" 
assertNotNull (Object 
resultado) 
verifica que el resultado no es "null" 
fail 
sirve para detectar que estamos en un sitio del programa donde NO 
deberíamos estar 
Probablemente necesite la relación íntegra de métodos disponibles. 
Las pruebas positivas detectan que estamos donde queremos. Por ejemplo: 
private int n= 2; 
public void testElemental () { 
// n vale 2 
// y 2+2 = 4 
assertEquals(4, n+n); 
} 
Las pruebas negativas detectan que NO estamos donde NO queremos. Por ejemplo: 
private String nombre= "Ana"; 
public void testElemental () { 
try { 
char c= nombre.charAt(4); 
fail("debería haber saltado una Exception"); 
} catch (Exception e) { 
return; 
} 
fail("debería haber capturado una Exception"); 
} 
4. Limitaciones 
JUnit no es útil para probar interfaces de entrada salida por consola o por pantalla gráfica. 
5. Diseño de pruebas
Diseñar pruebas es un arte que ha sido objeto de estudio durante años. El alumno puede 
encontrar un estudio en la documentación adjunta. 
No obstante, las reglas básicas son sencillas: 
 hay que prever al menos una prueba para cada función del sistema 
 hay que elegir al menos un caso "normal" de datos 
 cuando los datos presentan singularidades (límites o cambio de funcionamiento por 
rango) hay que probar los datos anexos a cada límite 
Así, para probar una función que divide dos números, probaremos los casos alrededor del 
valor singular "0": 
 numerador mayor que cero, denominador mayor que cero 
 numerador mayor que cero, denominador menor que cero 
 numerador mayor que cero, denominador igual a cero 
 numerador menor que cero, denominador mayor que cero 
 numerador menor que cero, denominador menor que cero 
 numerador menor que cero, denominador igual a cero 
 numerador igual a cero, denominador mayor que cero 
 numerador igual a cero, denominador menor que cero 
 numerador igual a cero, denominador igual a cero 
6. Ejemplo 1: conjuntos 
Se adjunta SetTest.java, una batería de pruebas para comprobar que funciona correctamente la 
clase java.util.HashSet como implementación de la clase java.util.Set. 
La batería de pruebas está organizada en 6 casos de prueba cada uno centrado en una 
función de las proporcionadas por la clase. Y en cada caso de prueba se buscan los casos 
singulares 
 conjunto vacío frente a conjunto con elementos 
 miembros que ya pertenecen al conjunto frente a miembros que no pertenecen al 
conjunto 
7. Temas avanzados 
Lo dicho es suficiente para la inmensa mayoría de los casos; pero a veces se necesita controlar más 
detalles. 
7.1. setUp() 
Si nuestro fichero de pruebas incluye un método 
public void setUp () { ... } 
JUnit lo llamará antes de lanzar cada uno de los casos de prueba, testXXX.
Puede ser útil cuando todos los casos de prueba requieren la misma inicialización de 
variables privadas y no basta con hacerlo en el constructor. 
7.2. tearDown() 
Si nuestro fichero de pruebas incluye un método 
public void tearDown () { ... } 
JUnit lo llamará después de lanzar cada uno de los casos de prueba, testXXX. 
Puede ser útil para cerrar elementos abiertos durante la prueba que pudieran quedar en un 
estado lamentable. Por ejemplo: 
 ficheros 
 conexiones Internet 
 conexiones a bases de datos 
 ... 
7.3. Same 
A veces no basta probar que dos obketos son iguales con assertEqual() sino que nos interesa 
comprobar que es exactamente el mismo. Por ejemplo, si estamos probando algoritmos de 
almacenamiento y recuperación. 
Para saber si dos objetos son el mismo o no: 
assertSame (X esperado, X real); 
assertNotSame (X esperado, X real); 
8. Inglés 
Se incluye un sucinto glosario de terminología inglesa relacionada con la prueba de programas. Se 
puede encontrar un glosario más extenso en la documentación adjunta. 
acierto success 
batería de pruebas test suite 
caso de prueba test case 
fallo failure 
probar to test 
prueba test
pruebas de aceptación acceptance test suite 
repetición de pruebas regression testing 
9. Referencias 
El alumno puede encontrar prolija documentación el la dirección oficial de JUnit: 
http://www.junit.org 
En la Universidad de Rice, en Estados Unidos, han publicado un resumen de cómo hacer 
pruebas unitarias con JUnit y DrJava: 
Unit Testing with JUnit in DrJava 
Y siempre es interesante leer a Bruce Eckel: 
Thinking in Java

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Jyoc java-cap23 j unit
Jyoc java-cap23 j unitJyoc java-cap23 j unit
Jyoc java-cap23 j unit
 
Testeo unitario
Testeo unitarioTesteo unitario
Testeo unitario
 
Presentación: xUnit y Junit
Presentación: xUnit y JunitPresentación: xUnit y Junit
Presentación: xUnit y Junit
 
Unit Testing
Unit TestingUnit Testing
Unit Testing
 
Junit y Jmock
Junit y JmockJunit y Jmock
Junit y Jmock
 
Unit Testing with Mock Objects
Unit Testing with Mock ObjectsUnit Testing with Mock Objects
Unit Testing with Mock Objects
 
Introduction to unit testing
Introduction to unit testingIntroduction to unit testing
Introduction to unit testing
 
ejemplos de pruebas unitarias y de integracion
ejemplos de pruebas unitarias y de integracion ejemplos de pruebas unitarias y de integracion
ejemplos de pruebas unitarias y de integracion
 
Test unitarios
Test unitariosTest unitarios
Test unitarios
 
Pruebas unitarias
Pruebas unitariasPruebas unitarias
Pruebas unitarias
 
Pruebas Unitarias - Uso de NUnit dentro de proyectos .NET
Pruebas Unitarias - Uso de NUnit dentro de proyectos .NETPruebas Unitarias - Uso de NUnit dentro de proyectos .NET
Pruebas Unitarias - Uso de NUnit dentro de proyectos .NET
 
Prueba de Caja Blanca
Prueba de Caja BlancaPrueba de Caja Blanca
Prueba de Caja Blanca
 
Metodos,variables, pasodeparametros
Metodos,variables, pasodeparametrosMetodos,variables, pasodeparametros
Metodos,variables, pasodeparametros
 
Introducción a JUnit 4
Introducción a JUnit 4Introducción a JUnit 4
Introducción a JUnit 4
 
Caja negra
Caja negraCaja negra
Caja negra
 
Software caja negra y caja blanca
Software caja negra y caja blancaSoftware caja negra y caja blanca
Software caja negra y caja blanca
 
JUnit - Germán Domínguez
JUnit - Germán DomínguezJUnit - Germán Domínguez
JUnit - Germán Domínguez
 
Calidad del software cap2
Calidad del software   cap2Calidad del software   cap2
Calidad del software cap2
 
Clase n°2 3-4 java
Clase n°2 3-4 javaClase n°2 3-4 java
Clase n°2 3-4 java
 
Portafolio
PortafolioPortafolio
Portafolio
 

Destacado

Entrega contínua com arquitetura distribuida
Entrega contínua com arquitetura distribuidaEntrega contínua com arquitetura distribuida
Entrega contínua com arquitetura distribuidaLeonardo Kobus
 
Tutorial imperfecto e indefinido
Tutorial imperfecto e indefinido Tutorial imperfecto e indefinido
Tutorial imperfecto e indefinido Malú Kárdenas
 
Java, Eclipse, Maven & JSF tutorial
Java, Eclipse, Maven & JSF tutorialJava, Eclipse, Maven & JSF tutorial
Java, Eclipse, Maven & JSF tutorialRaghavan Mohan
 
Part 6 debugging and testing java applications
Part 6 debugging and testing java applicationsPart 6 debugging and testing java applications
Part 6 debugging and testing java applicationstechbed
 
Desenvolvimento orientado a testes
Desenvolvimento orientado a testesDesenvolvimento orientado a testes
Desenvolvimento orientado a testesCarlos Santana
 
Java Tutorial Lab 3
Java Tutorial Lab 3Java Tutorial Lab 3
Java Tutorial Lab 3Berk Soysal
 
[GUTS-RS] GUTS Talks - Ferramentas de Automação de Testes
[GUTS-RS] GUTS Talks - Ferramentas de Automação de Testes[GUTS-RS] GUTS Talks - Ferramentas de Automação de Testes
[GUTS-RS] GUTS Talks - Ferramentas de Automação de TestesGUTS-RS
 
TestNG vs JUnit: cease fire or the end of the war
TestNG vs JUnit: cease fire or the end of the warTestNG vs JUnit: cease fire or the end of the war
TestNG vs JUnit: cease fire or the end of the warOleksiy Rezchykov
 
Erosión y formas de modelado
Erosión y formas de modeladoErosión y formas de modelado
Erosión y formas de modeladoGeopress
 
Reseña libro lópez morales por Patricia Nigro
Reseña libro lópez morales por Patricia NigroReseña libro lópez morales por Patricia Nigro
Reseña libro lópez morales por Patricia NigroPatricia Nigro
 

Destacado (18)

Junit
JunitJunit
Junit
 
Entrega contínua com arquitetura distribuida
Entrega contínua com arquitetura distribuidaEntrega contínua com arquitetura distribuida
Entrega contínua com arquitetura distribuida
 
unit_tests_tutorial
unit_tests_tutorialunit_tests_tutorial
unit_tests_tutorial
 
Tutorial imperfecto e indefinido
Tutorial imperfecto e indefinido Tutorial imperfecto e indefinido
Tutorial imperfecto e indefinido
 
Java, Eclipse, Maven & JSF tutorial
Java, Eclipse, Maven & JSF tutorialJava, Eclipse, Maven & JSF tutorial
Java, Eclipse, Maven & JSF tutorial
 
Part 6 debugging and testing java applications
Part 6 debugging and testing java applicationsPart 6 debugging and testing java applications
Part 6 debugging and testing java applications
 
Desenvolvimento orientado a testes
Desenvolvimento orientado a testesDesenvolvimento orientado a testes
Desenvolvimento orientado a testes
 
Java Tutorial Lab 3
Java Tutorial Lab 3Java Tutorial Lab 3
Java Tutorial Lab 3
 
Why unit testingl
Why unit testinglWhy unit testingl
Why unit testingl
 
[GUTS-RS] GUTS Talks - Ferramentas de Automação de Testes
[GUTS-RS] GUTS Talks - Ferramentas de Automação de Testes[GUTS-RS] GUTS Talks - Ferramentas de Automação de Testes
[GUTS-RS] GUTS Talks - Ferramentas de Automação de Testes
 
Junit
JunitJunit
Junit
 
Junit 4.0
Junit 4.0Junit 4.0
Junit 4.0
 
TestNG vs JUnit: cease fire or the end of the war
TestNG vs JUnit: cease fire or the end of the warTestNG vs JUnit: cease fire or the end of the war
TestNG vs JUnit: cease fire or the end of the war
 
Junit tutorial
Junit tutorialJunit tutorial
Junit tutorial
 
TestNG vs. JUnit4
TestNG vs. JUnit4TestNG vs. JUnit4
TestNG vs. JUnit4
 
Erosión y formas de modelado
Erosión y formas de modeladoErosión y formas de modelado
Erosión y formas de modelado
 
JUnit Presentation
JUnit PresentationJUnit Presentation
JUnit Presentation
 
Reseña libro lópez morales por Patricia Nigro
Reseña libro lópez morales por Patricia NigroReseña libro lópez morales por Patricia Nigro
Reseña libro lópez morales por Patricia Nigro
 

Similar a JUnit framework para pruebas unitarias Java

Similar a JUnit framework para pruebas unitarias Java (20)

Pruebas Automatizadas
Pruebas AutomatizadasPruebas Automatizadas
Pruebas Automatizadas
 
Prueba software orientado a objetos
Prueba software orientado a objetosPrueba software orientado a objetos
Prueba software orientado a objetos
 
Calidad del software cap3
Calidad del software   cap3Calidad del software   cap3
Calidad del software cap3
 
Software testing 1
Software testing 1Software testing 1
Software testing 1
 
Pruebas de software
Pruebas de softwarePruebas de software
Pruebas de software
 
S9-DAW-2022S1.pptx
S9-DAW-2022S1.pptxS9-DAW-2022S1.pptx
S9-DAW-2022S1.pptx
 
Test Automation .NET
Test Automation .NETTest Automation .NET
Test Automation .NET
 
Conceptos básicos de Unit Test
Conceptos básicos de Unit Test Conceptos básicos de Unit Test
Conceptos básicos de Unit Test
 
Prueba unitaria
Prueba unitariaPrueba unitaria
Prueba unitaria
 
Aguirre Jimenez
Aguirre JimenezAguirre Jimenez
Aguirre Jimenez
 
Pruebade j unit
Pruebade j unitPruebade j unit
Pruebade j unit
 
Pruebade j unit
Pruebade j unitPruebade j unit
Pruebade j unit
 
JUnit - Pablo Calvache
JUnit - Pablo CalvacheJUnit - Pablo Calvache
JUnit - Pablo Calvache
 
Presentación Seminario1 EA
Presentación Seminario1 EAPresentación Seminario1 EA
Presentación Seminario1 EA
 
Presentacion Pruebas
Presentacion PruebasPresentacion Pruebas
Presentacion Pruebas
 
Tipos de pruebas de software
Tipos de pruebas de softwareTipos de pruebas de software
Tipos de pruebas de software
 
10 pruebas (caso de uso)
10 pruebas  (caso de uso)10 pruebas  (caso de uso)
10 pruebas (caso de uso)
 
10 pruebas
10 pruebas10 pruebas
10 pruebas
 
Software Quality Assurance
Software Quality AssuranceSoftware Quality Assurance
Software Quality Assurance
 
Pruebas-OCW.pdf
Pruebas-OCW.pdfPruebas-OCW.pdf
Pruebas-OCW.pdf
 

JUnit framework para pruebas unitarias Java

  • 1. JUnit JUnit Desarrollador Kent Beck, Erich Gamma, David Saff http://junit.sourceforge.net Información general Última versión estable 4.11 [1] 14 de noviembre de 2012; hace 1 año Género Herramienta para Prueba unitaria Programado en Java Sistema operativo multiplataforma Plataforma Java Licencia Common Public License Idiomas inglés JUnit es un conjunto de bibliotecas creadas por Erich Gamma y Kent Beck que son utilizadas en programación para hacer pruebas unitarias de aplicaciones Java. JUnit es un conjunto de clases (framework) que permite realizar la ejecución de clases Java de manera controlada, para poder evaluar si el funcionamiento de cada uno de los métodos de la clase se comporta como se espera. Es decir, en función de algún valor de entrada se evalúa el valor de retorno esperado; si la clase cumple con la especificación, entonces JUnit devolverá que el método de la clase pasó exitosamente la prueba; en caso de que el valor esperado sea diferente al que regresó el método durante la ejecución, JUnit devolverá un fallo en el método correspondiente. JUnit es también un medio de controlar las pruebas de regresión, necesarias cuando una parte del código ha sido modificado y se desea ver que el nuevo código cumple con los requerimientos anteriores y que no se ha alterado su funcionalidad después de la nueva modificación. El propio framework incluye formas de ver los resultados (runners) que pueden ser en modo texto, gráfico (AWT o Swing) o como tarea en Ant.
  • 2. En la actualidad las herramientas de desarrollo como NetBeans y Eclipse cuentan con plug-ins que permiten que la generación de las plantillas necesarias para la creación de las pruebas de una clase Java se realice de manera automática, facilitando al programador enfocarse en la prueba y el resultado esperado, y dejando a la herramienta la creación de las clases que permiten coordinar las pruebas. Índice  1 JUnit 4  2 Referencias  3 Véase también  4 Enlaces externos JUnit 4 Este framework se encuentra actualmente en la versión 4.6, con grandes mejoras. He aquí una pequeña relación:  4.6  Incluye un nuevo Core experimental: MaxCore. Recuerda los resultados de ejecuciones previas. Existe un plug-in para Eclipse.  Incluye un método para indicar la máquina que ejecuta los tests.  Se pueden comparar Arrays: assertArrayEquals(new double[] {1.0, 2.0}, new double[] {1.0, 2.0}, 0.01);  Desde 4.0 se ha podido ejecutar un único método utilizando la API: Request.method. Ahora el filtro que implementa esta funcionalidad está expuesto en: Filter.matchDescription. Para más información: [2]  4.5  Incluye anotaciones (Java 5 annotations) en lugar de utilizar herencia: o @Test sustituye a la herencia de TestCase. o @Before y @After como sustitutos de setUp y tearDown. o Se añade @Ignore para deshabilitar tests.  Permite timeouts en los tests.  Configurar excepciones esperadas.  Ordenación, priorización, categorización y filtrado de tests.  Forward y backward compatibilidad.  Logging.  Más tipos de aserciones (ej: assertEquals(Object[], Object[]))  Se elimina la distinción entre errores (errors) y fallos (failures).
  • 3. Referencias Véase también  Portal:software libre. Contenido relacionado con software libre.  Prueba unitaria Enlaces externos  Página principal de JUnit  Tutorial de JUnit de la Escuela Super
  • 4. Pruebas de Aceptación José A. Mañas <jmanas@dit.upm.es> Dept. de Ingeniería de Sistemas Telemáticos Universidad Politécnica de Madrid 5 de febrero, 2004 1. Introducción Se dice que un programa es aceptable cuando: 1. hace lo que debe hacer 2. no hace lo que no debe hacer Un programador jamás debería entregar un programa sin haberlo probado. Quien recibe un programa de otro, jamás debería aceptarlo sin haberlo probado. A partir de la especificación de lo que se espera de un programa, se prepara una batería de casos de prueba. La batería que prepara el programador le permite saber cuándo ha terminado. La batería que prepara quien va a recibir el programa le permite saber si puede aceptarlo o no. Los casos de prueba se pueden escribir en papel y ejecutarlos disciplinadamente de forma manual, estrategia que solo es viable para programas pequeños. En programación profesional conviene automatizar las pruebas de forma que se pueden realizar muchas veces, tanto durante el desarrollo (hasta estar satisfechos), como durante la aceptación (para dar el programa por correcto, como si en el futuro hay que modificar el programa (para cerciorarnos de que no hemos roto nada que antes funcionaba). 2. JUnit JUnit es un paquete Java para automatizar las pruebas de clases Java. Se puede coger de http://www.junit.org La forma más sencilla de utilizar JUnit es crear una clase pública que sea extensión de TestCase. En esta clase, cada prueba es un método cuyo nombre debe comenzar por "test...", ser público y no devolver nada (void). La clase suele incluir un constructor para inicializar variables privadas. Este es el patrón: import junit.framework.*; public class MisPruebas extends TestCase { // variables_privadas
  • 5. public MisPruebas () { // inicialización } public void testXXX () { // código que debe funcionar } } Ejemplo sencillo: pruebas de Java package lprg.pruebas; import junit.framework.*; public class Tests extends TestCase { public Tests () { } public void testSumas () { assertEquals(4, 2+2); assertEquals(2, 2+0); assertEquals(2, 0+2); } public void testDivisiones () { assertEquals(1, 2/2); assertEquals(2, 4/2); assertEquals(2, 5/2); } public static void main (String[] args) { // ejecución por consola texto: // junit.textui.TestRunner.run(Tests.class); // ejecución en una ventana: junit.swingui.TestRunner.run(Tests.class); } } 3. Funciones para probar JUnit incluye una serie de métodos para probar que las cosas son como esperamos. Aunque se remite al lector a la documentación detallada del paquete, las siguientes funciones son básicas: assertEquals (X esperado, X real) compara un resultado esperado con el resultado obtenido, determinando que la prueba pasa si son iguales, y que la prueba falla si son diferentes. Realmente el método es una colección de métodos para una amplia variedad de tipos X. assertFalse (boolean verifica que el resultado es FALSE
  • 6. resultado) assertTrue (boolean resultado) verifica que el resultado es TRUE assertNull (Object resultado) verifica que el resultado es "null" assertNotNull (Object resultado) verifica que el resultado no es "null" fail sirve para detectar que estamos en un sitio del programa donde NO deberíamos estar Probablemente necesite la relación íntegra de métodos disponibles. Las pruebas positivas detectan que estamos donde queremos. Por ejemplo: private int n= 2; public void testElemental () { // n vale 2 // y 2+2 = 4 assertEquals(4, n+n); } Las pruebas negativas detectan que NO estamos donde NO queremos. Por ejemplo: private String nombre= "Ana"; public void testElemental () { try { char c= nombre.charAt(4); fail("debería haber saltado una Exception"); } catch (Exception e) { return; } fail("debería haber capturado una Exception"); } 4. Limitaciones JUnit no es útil para probar interfaces de entrada salida por consola o por pantalla gráfica. 5. Diseño de pruebas
  • 7. Diseñar pruebas es un arte que ha sido objeto de estudio durante años. El alumno puede encontrar un estudio en la documentación adjunta. No obstante, las reglas básicas son sencillas:  hay que prever al menos una prueba para cada función del sistema  hay que elegir al menos un caso "normal" de datos  cuando los datos presentan singularidades (límites o cambio de funcionamiento por rango) hay que probar los datos anexos a cada límite Así, para probar una función que divide dos números, probaremos los casos alrededor del valor singular "0":  numerador mayor que cero, denominador mayor que cero  numerador mayor que cero, denominador menor que cero  numerador mayor que cero, denominador igual a cero  numerador menor que cero, denominador mayor que cero  numerador menor que cero, denominador menor que cero  numerador menor que cero, denominador igual a cero  numerador igual a cero, denominador mayor que cero  numerador igual a cero, denominador menor que cero  numerador igual a cero, denominador igual a cero 6. Ejemplo 1: conjuntos Se adjunta SetTest.java, una batería de pruebas para comprobar que funciona correctamente la clase java.util.HashSet como implementación de la clase java.util.Set. La batería de pruebas está organizada en 6 casos de prueba cada uno centrado en una función de las proporcionadas por la clase. Y en cada caso de prueba se buscan los casos singulares  conjunto vacío frente a conjunto con elementos  miembros que ya pertenecen al conjunto frente a miembros que no pertenecen al conjunto 7. Temas avanzados Lo dicho es suficiente para la inmensa mayoría de los casos; pero a veces se necesita controlar más detalles. 7.1. setUp() Si nuestro fichero de pruebas incluye un método public void setUp () { ... } JUnit lo llamará antes de lanzar cada uno de los casos de prueba, testXXX.
  • 8. Puede ser útil cuando todos los casos de prueba requieren la misma inicialización de variables privadas y no basta con hacerlo en el constructor. 7.2. tearDown() Si nuestro fichero de pruebas incluye un método public void tearDown () { ... } JUnit lo llamará después de lanzar cada uno de los casos de prueba, testXXX. Puede ser útil para cerrar elementos abiertos durante la prueba que pudieran quedar en un estado lamentable. Por ejemplo:  ficheros  conexiones Internet  conexiones a bases de datos  ... 7.3. Same A veces no basta probar que dos obketos son iguales con assertEqual() sino que nos interesa comprobar que es exactamente el mismo. Por ejemplo, si estamos probando algoritmos de almacenamiento y recuperación. Para saber si dos objetos son el mismo o no: assertSame (X esperado, X real); assertNotSame (X esperado, X real); 8. Inglés Se incluye un sucinto glosario de terminología inglesa relacionada con la prueba de programas. Se puede encontrar un glosario más extenso en la documentación adjunta. acierto success batería de pruebas test suite caso de prueba test case fallo failure probar to test prueba test
  • 9. pruebas de aceptación acceptance test suite repetición de pruebas regression testing 9. Referencias El alumno puede encontrar prolija documentación el la dirección oficial de JUnit: http://www.junit.org En la Universidad de Rice, en Estados Unidos, han publicado un resumen de cómo hacer pruebas unitarias con JUnit y DrJava: Unit Testing with JUnit in DrJava Y siempre es interesante leer a Bruce Eckel: Thinking in Java