¡Descarga Práctica de pruebas unitarias con JUnit en JBuilder y más Apuntes en PDF de Tecnología solo en Docsity!
Capítulo 30
Unit Testing con JUnit
Char lie Calvert
Este capítulo trata una tecnología llamada unit test ing (prueba de unidades). La idea detrás del
unit test ing es la creación de métodos Boolean para probar la mayor parte posible de las
utilidades de su código. Usando una herramienta llamada JUnit, esos métodos serán llamados
automáticamente y generarán un informe para confirmar si todo fue correcto o si alguno de
los métodos falló.
Unit test ing es casi un modo de vida. Es parte de una filosofía de desarrollo llamada
"extreme pro gram ming" (programación extrema). Uno de los conceptos clave es que siempre
se debe producir código que com pile y se ejecute correctamente. Incluso si sólo ha terminado
una utilidad de un proyecto que contiene cientos de ellas, debería comenzar con una versión
de su producto que soporta por completo una de las utilidades.
Para confirmar que su producto funciona correctamente, se tiene que escribir una serie de
pruebas booleanas para verificar el código que ha escrito. Según vaya añadiendo más código a
su proyecto, añadirá nuevos tests. Debería ejecutar los tests una vez al día al menos,
preferiblemente varias veces por día. Verificarán no sólo que sus nuevas utilidades funcionan,
sino también que no se dañó parte de su código base.
Para mantener este proceso lo más sencillo posible, se creó un proyecto de código abierto
llamado JUnit. Su propósito es hacerle lo más fácil posible escribir y ejecutar tests del tipo
descrito en estos párrafos.
NOTA: La mayoría de las utilidades que integran JUnit con JBuilder están en la versión Enter prise
de JBuilder. Sin embargo, JUnit es un proyecto de código abierto. Por lo que no se asuste, puede y
debe usar JUnit independientemente de la versión de JBuilder que esté usando. Primero le
mostraré cómo integrar las herramientas en JBuilder Enter prise y luego mostraré cómo proceder
incluso si está trabajando con JBuilder Per sonal. Todos deberíamos usar JUnit, no sólo los que
dispongan de la versión Enter prise. Debería leer el capítulo desde el principio, no importa la
edición de JBuilder que tenga, ya que hay varios trucos sobre JUnit.
Unit Testing en la versión Enterprise
En esta sección le mostraré como usar JUnit con la edición Enter prise de JBuilder. Después
le mostraré como proceder con la edición Per sonal. El código que se muestra en este capítulo
se basa en su mayoría en un ejemplo llamado UnitTesting, incluido en el CD que acompaña al
libro.
NOTA: El código generado por JBuilder Enter prise no es nada más que código fuente Java para
usar con el proyecto JUnit. Puede descargar JUnit desde www.junit.org y usarlo para ejecutar los
scripts descritos en este capítulo. Los propios scripts son fáciles de entender, y no debería tener
problemas para generarlos. El sitio Web de JUnit también tiene código para generar tests
automáticos, por lo que puede usar el código fuente abierto junto con el código de la versión
555
Enter prise de JBuilder. Para resumir, este capítulo está dirigido a todos los lectores, y no sólo a los
de la edición Enter prise de JBuilder.
Comience una nueva aplicación usando las técnicas descritas en el Capítulo 3, y añada los
siguientes dos métodos a Frame1.java:
public int add(int a, int b) { return a + b; }
public int multiply(int a, int b) { return a * b; }
No se preocupe en desde dónde los va a usar. Por ahora, lo que importa es que los dos
métodos estén incluidos en Frame1.java.
Asegúrese de que Frame1 está seleccionado en el panel de contenido. Seleccione ahora
Archivo | Nuevo del menú y vaya a la página Test de la Galería de objetos. Seleccione la
opción Test Case. Aparecerá la ventana mostrada en la Figura 30-1. Ilumine los dos métodos
públicos que aparecen en la ventana, pulse el botón Finalizar. No se preocupe por el resto de
pasos del asistente; pulse Finalizar al rellenar la primera página.
Tras pulsar Finalizar, se generará automáticamente el código mostrado en el Listado 30-1.
Este es el código usado para confirmar que las funciones que ha escrito funcionan
correctamente. Note la presencia de la sentencia import junit.frame work.* al principio del
código fuente. Note también que TestFrame1 extiende una clase del marco de trabajo de JUnit
llamada TestCase. Extiende esta clase de modo que pueda añadir en ella la funcionalidad de
prueba de sus métodos. El resto de utilidades necesarias para llamar automáticamente a sus
métodos y darle un informe gráfico están incluidas en el propio JUnit.
Listado 30-1: Una clase generada por JBuilder, diseñada para probar automáticamente los
métodos de Frame1. Sólo necesita añadir sentencias assert al código.
package unittesting;
import junit.framework.; import java.awt.event.;
556 Capítulo 30
Fig ura 30-1: Seleccione los métodos add y
multiply de Frame1, para poder probarlos con
JUnit.
public void testAdd() { Frame1 frame1 = new Frame1(); int a1= 2; int b2= 2; int intRet = frame1.add(a1, b2); assertEquals( intRet, 4); }
public void testMultiply() { Frame1 frame1 = new Frame1(); int a1= 2; int b2= 3; int intRet = frame1.multiply(a1, b2); assertEquals( intRet, 6); } }
Eche un vistazo al método testAdd. Usa código generado por JBuilder para inicializar el test.
A continuación se llama al método assertEquals. Este método verifica si el valor devuelto del
método Frame1.add es igual a 4. Si lo es, el test tuvo éxito. Si no es igual a 4, el test falla. El
mismo principio se aplica al método testMultiply.
Ahora que configuró su TestCase, el próximo paso es ejecutarlo para ver si funciona. La
forma más sencilla de hacerlo es seleccionar TestFrame1.java de la lista del panel de
proyecto. Haga clic con el botón derecho del ratón sobre ella, y seleccione Ejecutar. No
queremos ejecutar la aplicación prin ci pal; queremos ejecutar el test generado por el asistente
de JBuilder. Los resultados de una ejecución con éxito aparecen en la Figura 30-2.
El IDE le informa visualmente de los resultados de los tests. La Figura 30-2 le muestra el
caso en el que ambos test tuvieron éxito, mientras que la Figura 30-3 le muestra el caso en el
que el segundo test falla. Los fallos y éxitos son visibles claramente en una pantalla de color.
Las llamadas con éxito se muestran en verde, y los fallos en rojo.
El segundo test podría fallar si cambia el método testMultiply de este modo:
public void testMultiply() {
558 Capítulo 30
Fig ura 30-2: Un test de JUnit con éxito, ejecutado
en el IDE de JBuilder. Note las marcas en los
círculos mostrados en el panel de mensajes.
Frame1 frame1 = new Frame1(); int a1= 3; int b2= 3; int intRet = frame1.multiply(a1, b2); assertEquals( intRet, 6); }
El test fallará porque 3 veces 3 no es 6. La llamada a assertEquals establece que la vari able
intRet debería ser 6. Si es igual a 6, la llamada tiene éxito; en caso contrario, JUnit gen era un
error.
assertEquals es uno de los métodos proporcionados por los desarrolladores de JUnit para
probar su código. Los otros métodos se llaman assertNotNull, assertNull, assertSame, y
assertTrue. Hay un método llamado assert, pero fue desactualizado (dep re cated) porque el
JDK tiene un método del mismo nombre. El método assertTrue fue escrito para reemplazar a
la antigua llamada assert de JUnit.
Añadiendo tests a la clase CodeBox
Ahora que tiene una idea de cómo funciona
JUnit, el próximo paso es crear tests más
complejo. En par tic u lar, crearemos tests para la
unidad StringBox, que se encuentra en el
fichero JAR libre CodeBox de Elvenware, que
viene con el CD del libro.
Añada el código de Elvenware a la página Vía
de acceso de la ventana Propiedades de
proyecto, mostrada en la Figura 30-4. Tras
instalar el código del libro, debería tener en su
sistema un directorio llamado
jbbook\src\personal. Este es el directorio que
debe añadir a su path fuente.
Al hacer clic en Aceptar en la ventana,
probablemente necesite pulsar el botón
Actualizar (cuarto desde la izquierda) en la barra
de herramientas, encima del panel de proyecto,
de modo que pueda ver los paquetes
com.elvenware.*, como muestra la Figura 30-5.
Unit Testing con JUnit 559
Fig ura 30-3: Un test sin éxito de JUnit, ejecutado
en el IDE de JBuilder. Note las marcas X en los
círculos del panel de mensajes. Aparecerán en
rojo en su pantalla.
Fig ura 30-4: Configurando el path fuente de
un proyecto de JBuilder para que pueda
acceder al código en los paquetes Elvenware.
Listado 30-3: Código generado por JBuilder para probar su clase.
package com.elvenware.codebox;
import junit.framework.*;
public class TestStringBox extends TestCase {
public TestStringBox(String s) { super(s); }
protected void setUp() { }
protected void tearDown() { }
public void testGetFirstWord() { String value1= "STRING0"; String stringRet = StringBox.getFirstWord(value1); /** @todo: Insert test code here. Use assertEquals(), for example. / } public void testIncludeCR() { String value1= "STRING0"; String stringRet = StringBox.includeCR(value1); /* @todo: Insert test code here. Use assertEquals(), for example. / } public void testIncludeTrailingDelimiter() { String fileName1= "STRING0"; String stringRet = StringBox.includeTrailingDelimiter(fileName1); /* @todo: Insert test code here. Use assertEquals(), for example. / } public void testIntToStrPad0() { int value1= 0; int paddings2= 0; String stringRet = StringBox.intToStrPad0(value1, paddings2); /* @todo: Insert test code here. Use assertEquals(), for example. / } public void testReverse() { String stringToReverse1= "STRING0"; String stringRet = StringBox.reverse(stringToReverse1); /* @todo: Insert test code here. Use assertEquals(), for example. */ } public void testShorten() { String s1= "STRING0"; int charsToCut2= 0; String stringRet = StringBox.shorten(s1, charsToCut2);
Unit Testing con JUnit 561
/** @todo: Insert test code here. Use assertEquals(), for example. / } public void testStripFirstWord() { String value1= "STRING0"; String stringRet = StringBox.stripFirstWord(value1); /* @todo: Insert test code here. Use assertEquals(), for example. */ } }
Puede ver que se ha creado un método de test para cada método en la clase StringBox. Todo
lo que tenemos que hacer es incluir algunas vari ables y componer los métodos assertEquals o
assertTrue que verificarán que el test funciona. En el Listado 30-4 muestro el TestCase que
yo utilicé.
Listado 30-4: Un test JUnit para la clase StringBox.
package unittesting;
import junit.framework.; import com.elvenware.codebox.;
public class TestStringBox extends TestCase {
public TestStringBox(String s) { super(s); }
protected void setUp() { }
protected void tearDown() { }
public void testGetFirstWord() { int value = 1; String theWord = "OneWord"; String result = StringBox.getFirstWord(theWord); System.out.println("GetFirstWord: " + result); assertTrue(result.equals(theWord)); }
public void testGetFirstWord2() { int value = 1; String theWord = ""; String result = StringBox.getFirstWord(theWord); System.out.println("GetFirstWord: " + result); assertTrue(result.equals(theWord));
562 Capítulo 30
public void testReverse() { String stringToReverse1= "STRING0"; String stringRet = StringBox.reverse(stringToReverse1); assertEquals(stringRet, "0GNIRTS"); }
public void testShorten() { String s1= "STRING0"; int charsToCut2= 4; String stringRet = StringBox.shorten(s1, charsToCut2); assertEquals(stringRet, "STR"); }
public void testStripFirstWord() { String value1= "STRING0"; String stringRet = StringBox.stripFirstWord(value1); assertEquals(stringRet, ""); }
public void testStripFirstWord2() { String value1= ""; String stringRet = StringBox.stripFirstWord(value1); assertEquals(stringRet, ""); }
public void testStripFirstWord3() { String value1= "This time"; String stringRet = StringBox.stripFirstWord(value1); assertEquals(stringRet, "time"); }
public void testStripFirstWord4() { String value1= "This time is true"; String stringRet = StringBox.stripFirstWord(value1); assertEquals(stringRet, "time is true"); } }
Quizá lo más interesante en ese código es lo repetitivo que es. Por ejemplo, hay cuatro casos
de test para los métodos stripFirstWord y getFirstWord. Los tests incluyen: asegurarse de
que los métodos funcionan correctamente cuando se les pasa un string con varias palabras, un
string con una sola palabra, y un string vacío. Cuanto más inventivo sea con los tests, más
prob a ble será que su código se mantenga libre de errores. No es necesario decir que debería
añadir nuevos tests en el momento que encuentre un error en esas rutinas. Los defensores
de "extreme pro gram ming" dirían que debería añadir el test incluso antes de intentar resolver
564 Capítulo 30
el error. El primer paso es producir un test que verifique condiciones de error, y el segundo
es arreglar el propio error.
NOTA: Es literalmente cierto que muchos partidarios de "extreme pro gram ming" le indicarían que
lo primero que debe hacer al comenzar un nuevo proyecto es escribir un test. Cuanto antes tenga
el test, antes podrá empezar a escribir un programa que pase el test. Todo esto se explica en
mayor profundidad en http://www.extremeprogramming.org. También tiene otros recursos
interesantes en: http://ootips.org/xp.html.
Esos tests pueden ayudarle a definir exactamente lo que un método debe hacer. Por ejemplo,
en realidad todavía no he pensado si el método stripFirstWord debería devolver una palabra o
un string vacío al pasarle un string que contenga una sola palabra. El crear casos de prueba
me obligó a plantearme este método y definir cómo debe comportarse. (Decidí que debería
devolver un string vacío).
Otro aspecto importante en tests como éste es que le dan confianza a la hora de resolver
errores en su código o mejorar su rendimiento. Si necesito mejorar el método getFirstWord,
puedo proceder con confianza porque sé que esos tests detectarán los errores más obvios que
pueda introducir al tratar de mejorar el código.
Una de las ideas clave tras el "extreme pro gram ming" es que en realidad es divertido crear
tests. Sólo necesita un poco de trabajo, y prácticamente de forma instantánea comienza a
recibir información. Por una vez, no debe preocuparse de si el código que está escribiendo
hará más lento a su programa. Por el contrario, debe ejercitar al máximo su creatividad para
generar la máxima cantidad de tests. Esto es algo que debería integrar en sus hábitos diarios
de trabajo. Sin embargo, también se trata de algo útil que puede hacer cuando no le quedan
energías para tareas más complejas. ¡Diviértase con ello!
Métodos de prueba que devuelven Strings
Para esos momentos en los que no esté muy creativo, debería intentar seguir algunas reglas
que le ayuden a componer tests. Por ejemplo, al probar una rutina de manejo de cadenas,
siempre debería generar código para al menos dos casos:
n Probar el método pasándole un string normal.
n Probar el método pasándole un string vacío.
Aquí tiene dos ejemplos de lo que quiero decir para la clase StringBox:
public void testReverse() { String value1= "abc"; String stringRet = StringBox.reverse(value1); assertEquals(stringRet, "cba"); }
public void testReverseEmpty() { String value1= ""; String stringRet = StringBox.reverse(value1); assertEquals(stringRet, ""); }
También tiene reglas sencillas como ésta para métodos matemáticos. Por ejemplo, verifique
siempre los casos con parámetro 0, positivo, y negativo.
Unit Testing con JUnit 565
Pulse el botón Finalizar para cerrar el Asistente para conjuntos de tests. El código generado
se muestra en el Listado 30-5.
Listado 30-5: Un conjunto de tests JUnit sencillos.
package unittesting;
import junit.framework.*;
public class AllTests extends TestCase {
public AllTests(String s) { super(s); }
public static Test suite() { TestSuite suite = new TestSuite(); suite.addTestSuite(unittesting.TestFrame1.class); suite.addTestSuite(unittesting.TestStringBox.class); return suite; } }
Puede ver cómo se ha creado un objeto TestSuite en el método suite de esta clase. Las
llamadas a addTestSuite registran los casos de prueba JUnit que hemos creado. El resultado
final es que todos los tests de las clases TestFrame1 y TestStringBox serán llamados
automáticamente por este conjunto de tests, como muestra la Figura 30-8.
NOTA: En otras par tes del texto, indiqué las virtudes de escribir clases sencillas y fáciles de usar.
JUnit es un excelente ejemplo de arquitectura para un conjunto de clases relativamente
complejas.
Ejecución de tests JUnit desde la línea de comandos
En esta sección aprenderá cómo ejecutar conjuntos de tests desde la línea de comandos. No
es necesario decir que ésta es la parte del capítulo donde aquéllos que usen la versión
Unit Testing con JUnit 567
Fig ura 30-9: Use el botón Añadir para añadir al
conjunto de tests los casos que quiera ejecutar.
Per sonal de JBuilder podrán aprender cómo ejecutar tests de JUnit. Como dije anteriormente,
quizá la mejor forma de usar JUnit sea automatizándolo desde la línea de comandos, por lo que
realmente no está perdiendo demasiado si no tiene las herramientas de JBuilder.
NOTA: Como mencioné anteriormente, el código del Listado 30-5 es código estándar de JUnit
como el que todos los usuarios de la herramienta crearían. JBuilder le ayuda generando el código
automáticamente, pero el código generado es código estándar. Por lo tanto, puede crear un
proyecto como se describe al comienzo del capítulo. Inserte los métodos add y mul ti ply en
Frame1.java como se indicó al comienzo del capítulo. Escriba el código JUnit mostrado en los
Listados 30-2, 30-4 y 30-5, o use los ficheros fuente del CD. Guarde el código de JUnit en el
mismo directorio de Frame1.java, y úselo como se indica en las secciones restantes del capítulo.
El código abierto de JUnit se encuentra en el fichero junit.jar. Este fichero JAR se encuentra
en el directorio /JBuilder7/lib de JBuilder. Puede descargar versiones actualizadas del fichero
en www.junit.org. El código de esa web es abierto, por lo que sólo tiene que hacer una
descarga sencilla.
NOTA: Hay una licencia asociada al código fuente de JUnit, pero no es demasiado restrictiva. El
código fue pensado para usarse libremente por desarrolladores en su trabajo diario. JUnit se
ofrece bajo la licencia de IBM Com mon Pub lic License Ver sion 0.5. Si es valiente, puede leer sobre
ella en: http://oss.soft ware.ibm.com/developerworks/oss/licensecpl.html. Este es un extracto de
esa licencia (en inglés):"Sub ject to the terms of this Agree ment, each Con trib u tor hereby grants
Recipient a non-exclusive, world wide, roy alty-free copy right license to repro duce, pre pare
derivative works of, pub licly dis play, pub licly per form, dis trib ute and sublicense the Con tr i bu tion of
such Con trib u tor, ir any, and such deriv a tive works, in source code and object code form." No
tengo ni idea de lo que eso significa, pero parece ser algo bueno.
El fichero JAR de JUnit viene con una interfaz GUI para los conjuntos de tests y una versión
de línea de comandos. La interfaz GUI es buena si quiere ejecutar tests interactivamente, y la
versión de línea de comandos es buena si quiere integrar los tests a su proceso de generación.
La Figura 30-10 muestra la interfaz gráfica de JUnit.
Una forma práctica de ejecutar el GUI es asegurar que codebox.jar y junit.jar están es su
classpath. Como recordará, codebox.jar viene en el CD del libro. También puede descargarlo
de www.elvenware.com. Vaya al directorio raíz del proyecto UnitTesting desarrollado en este
capítulo. Escriba este comando:
568 Capítulo 30
Fig ura 30-10: Una ejecución con éxito de 16 tests
sobre la clase StringBox desarrollada anteriormente,
así como de la clase Frame1, creada en este capítulo.
proyecto Apache Jakarta Ant es la versión Java de la utilidad make. Ant es más fácil de usar
que make, y al menos para el desarrollo Java, mucho más potente. En par tic u lar, es fácil
extender la funcionalidad de Ant.
Ant le permite automatizar el proceso de generación de sus aplicaciones. La sinergia entre
Ant y JUnit está en el hecho de que puede usar Ant para ejecutar automáticamente los tests
que crea con JUnit. En par tic u lar, puede incluir en su proceso diario de generación la
ejecución de un conjunto de tests de JUnit.
Los desarrolladores de Borland reconocen que tanto Ant como JUnit han hecho una
contribución significativa al proceso de desarrollo. Por ello, ambas herramientas se integraron
en el IDE de JBuilder.
Las herramientas Ant y JUnit de JBuilder son, en su mayoría, herramientas de desarrollo a
nivel empresarial. Sin embargo, puede y debe usar esas herramientas con todas las ediciones
de JBuilder. En par tic u lar, hay proyectos abiertos para integrar Ant en la edición Per sonal de
JBuilder. AntRunner es una herramienta que integra Ant en JBuilder. Puede encontrarlo en:
http://antrunner.sourceforge.net/.
Una vez haya integrado Ant con JBuilder, también puede integrar JUnit en su proceso de
desarrollo usando scripts de Ant. O, si lo desea, vaya a codecentral.borland.com para obtener
la herramienta de pruebas. Debería poder descargarla de: http://codecentral.borland.com/
codecentral/ccweb.exe/list ing?id=17168.
Para un examen más detallado de Ant y JUnit, vea el útil libro titulado Java Tools for
Extreme Pro gramming por Hightower y Lesiecki (John Wiley & Sons). Su énfasis en el
desarrollo corporativo J2EE es desafortunado, pero está bien escrito y contiene gran cantidad
de información útil.
Resumen
En este capítulo hemos hecho una breve introducción al unit test ing con la herramienta JUnit.
Ha visto que esta herramienta está bien integrada con el IDE de JBuilder. Sin embargo, puede
usarla desde la línea de comandos igualmente.
Si está usando la versión Developer o Per sonal de JBuilder, debería visitar www.junit.org.
Ese sitio tiene muchos trucos sobre el uso de JUnit. En él, hay herramientas que le
permitirán generar automáticamente casos de test usando utilidades similares a las que se
incluyen en la versión Enter prise de JBuilder. También encontrará algunas herramientas
únicas, que pueden ayudarle a validar las par tes GUI de sus aplicaciones.
570 Capítulo 30
