Testing
Julio Monetti
8 de abril de 2017
Índice
I Conceptos Generales 3
1. Por qué realizar pruebas ? 3
2. Conceptos 3
3. Consideraciones Importantes 4
4. Principios del Testing 5
5. Recomendaciones 5
6. Qué Probar con Caja Blanca ? 6
6.1. Pruebas de Cubrimiento de Sentencias . . . . . . . . . . . . . . . 6
6.2. Pruebas de Condiciones . . . . . . . . . . . . . . . . . . . . . . . 6
6.3. Prueba de Bucles . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
6.4. Prueba de Cobertura de Llamada a Funciones . . . . . . . . . . . 7
7. Qué Probar con Caja Negra ? 7
7.1. Pruebas de Cubrimiento . . . . . . . . . . . . . . . . . . . . . . . 7
7.2. Pruebas de Clase de Equivalencia . . . . . . . . . . . . . . . . . . 7
7.3. Pruebas de Valores Límite . . . . . . . . . . . . . . . . . . . . . . 8
8. Estrategias de Prueba de Software 8
8.1. Organización de la prueba . . . . . . . . . . . . . . . . . . . . . . 8
II Algunas Clasificaciones 10
1. En Cuanto al Nivel de Conocimiento del Código 10
1.1. Caja Negra . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.2. Caja Blanca . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1
Testing
2. En Cuanto a la Granularidad del Componente Testeado 10
2.1. Pruebas de unidad . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.2. Pruebas de integración . . . . . . . . . . . . . . . . . . . . . . . . 10
2.3. Pruebas de sistema . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3. En Cuanto a los Actores Intervinientes en la Prueba 11
3.1. Pruebas de Aceptación o Validación . . . . . . . . . . . . . . . . 11
3.2. Pruebas de Verificación . . . . . . . . . . . . . . . . . . . . . . . 11
4. Otros tipos de prueba 11
5. Diseño de prueba de escritorio. Diseño de archivos de bitácora. 12
6. Técnicas y Estrategias para la prueba de software. 12
6.1. Pruebas sin Estrategia . . . . . . . . . . . . . . . . . . . . . . . . 12
6.2. Organización para las pruebas de software. Verificación y valida-
ción de programas. . . . . . . . . . . . . . . . . . . . . . . . . . . 13
III Uso de JUnit 14
1. JUNIT 14
2. JUnit 14
3. Clases de Pruebas 15
4. Aserciones 15
5. Ejemplo de Uso 15
5.1. Codificación del Programa . . . . . . . . . . . . . . . . . . . . . . 15
5.2. Creación de la Prueba . . . . . . . . . . . . . . . . . . . . . . . . 16
5.3. Descripción del Código Generado . . . . . . . . . . . . . . . . . . 19
5.4. Ejecución de la Prueba . . . . . . . . . . . . . . . . . . . . . . . . 19
Julio Monetti 2
PARTE I
CONCEPTOS GENERALES
1. Por qué realizar pruebas ?
Aunque se considere un software extremadamente sencillo, no es posible la
realización de pruebas exhaustivas , es decir aquellas que tiendan a abarcar
todo el conjunto de valores posibles a procesar por el mismo.
Esta tarea es impracticable y sería demasiada costosa. Esta situación conlleva
a que sea imposible de garantizar la ausencia de defectos.
2. Conceptos
El testing es el proceso por el cual se demuestra que un programa no tiene
errores, y realiza las funciones para la cual fue construido.
Cuando se habla de Comprobación del Software, se deben considerar los
siguientes conceptos:
Que la demostración se puede realizar manual o automáticamente a tra-
vés de algún software o conjunto de librerías que permitan esta acción. La de-
mostración consiste en la ejecución del programa para, a traves de datos de
entrada, verificar el correcto procesamiento de los mismos.
A partir de la observación de diferencias respecto de los resultados esperados,
se procederá a una inspección manual del código fuente del cual proviene el
programa que está siendo probado (ejecutado).
Este conjunto de demostraciones (o pruebas) se debe realizar contínuamente
a lo largo del tiempo, y para un conjunto diferente de parámetros. Para ello se
deberán diseñar casos de prueba individuales con el objeto de cubrir escena-
rios específicos en la ejecución del sistema.
Se podría concluir que
Si se provocan fallos en la ejecución del programa, seguro que existen
defectos en el software
Pero, si NO aparecen fallos, puede que haya defectos, o no en el software.
3
Testing
En la práctica los términos falla, defecto y error suelen ser usados como
sinónimos. En este momento es conveniente destacar estos importantes términos.
Una FALLA ocurre cuando un programa no se comporta de manera ade-
cuada. La falla representa una propiedad del sistema en ejecución.
Un DEFECTO existe en el código. Si se ejecuta puede causar una falla.
No hay defecto si el sistema no puede fallar.
Un ERROR es una acción humana que resulta en software que contiene un
defecto. Un error puede llevar a incluir un defecto en el sistema, haciéndolo
fallar.
Hay diferentes tipos de defectos en el desarrollo de software. Los mismos
se pueden encontrar en la documentación del sistema, o en la codificación en si.
En la organización del equipo de trabajo, se pueden introducir defectos cuando
se realizan modificaciones en el sofware, incorporación de nuevas librerías o en
el control de versiones. En el código fuente en si, se pueden presentar defectos
principalmente en una deficiente declaración de variables (por ejemplo en la de-
claración en un ámbito erróneo), duplicación de nombres, etc. Por otro lado, se
pueden presentar interfaces poco claras entre diferentes módulos (o con otros
sistemas).
En resumen, algunos tipos de defecto [4]
Chequeo: Mensajes de error, trazas, validaciones.
Datos: Estructuras, contenido.
Función: Errores lógicos, bucles, recursividad.
Sistema: Configuración, instalación, explotación.
Entorno: Diseño, compilación, pruebas.
3. Consideraciones Importantes
A la hora de diseñar un plan de pruebas, el tester debería considerar que
No se puede probar que un programa nunca fallará, solo se puede probar
que contiene defectos.
Un test exitoso es aquel que encuentra muchos defectos.
El propósito del testing es encontrar defectos, es un proceso destruc-
tivo, se sabe mostrar que algo es incorrecto.
No es recomendable probar los propios desarrollos, ya que al inmer-
sos en la tarea constructiva de creación de software, naturalmente creemos
que lo creado es lo correcto, y que la prueba sería una tarea superflua.
Julio Monetti 4
Testing
Cada vez que se corrigen los defectos detectados, al recodificar se pueden
introducir nuevos defectos en el sistema.
4. Principios del Testing
Examinar un programa para ver si no hace lo que debe hacer es solo la
mitad de la tarea; la otra mitad es ver si hace lo que no debe hacer.
El Testing es una tarea extremadamente creativa e intelectualmente desafian-
te.
Desde un punto de vista económico es imposible probar un programa para
encontrar todos los defectos. Ni siquiera para los programas más triviales.
En general, es impráctico, y a menudo imposible encontrar todos los de-
fectos en un programa, ya que habría que probar todas las combinaciones
de entrada, correctas e incorrectas, dadas en general por el número infinito
de casos de prueba.
Por otro lado habría que probar todos los caminos posibles dentro de un
programa, que pueden contener lazos (en general el número de casos de
prueba no es infinito, pero usualmente puede considerarse como tal).
El fin es encontrar defectos en el software
La prueba tendrá exito si descubre un defecto
La prueba fracasa si hay defectos y no los descubre
5. Recomendaciones
El tester, al diseñar sus pruebas deberá considerar lo siguiente:
Evitar casos de prueba espontáneos y que no dejen registro, de hacerlo así
solo se pierde el tiempo.
No planificar un caso de prueba bajo el supuesto tácito que no se encon-
trarán defectos.
La probabilidad de existencia de más defectos en una sección de un progra-
ma es proporcional al número de defectos ya detectados en dicha sección.
6. Alcance de una prueba de software
El alcance de una prueba determina que funcionalidades del producto
y/o software serán probadas durante la misma. Este conjunto de funcionalida-
des a probar es obtenido de un análisis previo, que determina prioridades en
Julio Monetti 5
Testing
sistemas, subsistemas o artefactos de software; basadas en el nivel de riesgo de
falla que presentan. Se analiza la probabilidad de falla, costo de recuperación,
etc. En este análisis del alcance también se determina el tipo de prueba y las
propiedades y elementos del software a ser probado.
7. Qué Probar con Caja Blanca ?
En este tipo de pruebas, conocidas también como Clear Box, Caja Clara o
Transparente que se conoce en detalle el código a probar, procurando ejercitar
tras la ejecución cada elemento del código.
Algunas clases de pruebas [2]:
7.1. Pruebas de Cubrimiento de Sentencias
Esta prueba busca:
Ejecutar al menos una vez cada sentencia
Se necesitan varios casos de prueba
• Determinar posibles caminos independientes
• Cada condición debe cumplirse en un caso y en otro no. En gene-
ral, se necesitan tantos casos como condiciones, más uno (número
ciclomático)
Puede ser imposible cubrir el 100 % debido a:
• Código que nunca se ejecuta: condiciones imposibles
• Ejemplo: detección y notificación de errores internos en un código sin
errores
7.2. Pruebas de Condiciones
Estas pruebas buscan observar que se cumpla o no cada parte de cada
condición.
Se necesitan varios casos de prueba
Determinar expresiones simples en las condiciones
Una por cada operando lógico o comparación
Cada expresión simple debe cumplirse en un caso y en otro no, siendo
decisiva en el resultado
Se debe considerar que puede ser imposible cubrir el 100 % de los casos.
Julio Monetti 6
Testing
7.3. Prueba de Bucles
Ante de la presencia de bucles en el código, al realizar las pruebas se debe
buscar:
Conseguir números de repeticiones especiales
Bucles simples
• Repetir cero, una y dos veces
• Repetir un número medio (típico) de veces
• Repetir el máximo-1, máximo y ¡máximo +1!
Bucles anidados
• Repetir un número medio (típico) los bucles internos, el mínimo los
externos, y variar las repeticiones del bucle intermedio ensayado.
• Ensayarlo con cada nivel de anidamiento
7.4. Prueba de Cobertura de Llamada a Funciones
Esta prueba busca establecer si las funciones declaradas se encuentran en
el camino de ejecución de alguna de las condiciones. Existen casos donde se
han codificado funciones que nunca serán invocadas. En el caso de utilizar un
compilador, donde una de sus fases sea la optimización de código, esta situación
puede ser corregida si se ignora dicha función al generar código de máquina.
(No obstante, la existencia en el código fuente de dicha función puede tornarlo
desprolijo y dificil de leer).
8. Qué Probar con Caja Negra ?
En este tipo de prueba, también conocido como Black Box, no se observa en
detalle el código fuente, sino la funcionalidad general del programa (y sus
funciones), a través del análisis de valores obtenidos en la ejecución, para un
conjunto de parámetros de prueba dado.
En este caso el tester solo conoce la interfaz, intentando ejercitar cada ele-
mento de la misma.
8.1. Pruebas de Cubrimiento
Se intenta invocar cada una de las funciones, sin observar en detalle la eje-
cución interna de las mismas.
Julio Monetti 7
Testing
8.2. Pruebas de Clase de Equivalencia
Los datos de prueba se clasifican según las distinciones visibles en la interfaz
del programa. Por ejemplo para probar la función EsPrimo(Entero) → Booleano
Clase 1: primo >= 2 (2, 3, 5, 7, 11, ...)
Clase 2: no_primo >= 2 (4, 6, 8, 9, 10, ...)
Clase 3: valores singulares (0, 1)
Clase 4: no definido (-1, -2, ...)
Se deberían realizar casos de prueba con datos de cada clase.
8.3. Pruebas de Valores Límite
En lugar de elegir cualquier valor de la clase de equivalencia, se seleccionan
los valores situados en los límites de dichas clases.
Tanto la técnica de valores límite como la de clases de equivalencia pueden
ser aplicadas también al conjunto de valores esperados (resultados), de forma
tal que lo que se particiona no es el dominio de entrada (parámetros de entra-
da), sino el de resultados. Con esto, los casos de prueba que se construyan (que
serán los parámetros de entradas del programa o función bajo prueba) deberán
ser capaces de generar los resultados en cada una de las clases de equivalencia
de salida.
Para obtener una prueba robusta y completa, se deberían considerar varios
casos de prueba para cada partición. Para ello se deberían considerar:
Valores típicos, intermedios
Valores primero y segundo del rango
Valores penúltimo y último
Valores vecinos fuera del rango (en otra partición)
Respecto de este tipo de pruebas, es útil destacar que los programadores se
equivocan con más frecuencia al tratar los valores en la frontera (Ej: >en vez
de >=).
9. Estrategias de Prueba de Software
9.1. Organización de la prueba
De acuerdo a las características del ciclo de vida del sistema, y a la meto-
dología de desarrollo utilizada, se podrán diseñar diferentes tipos de prueba (de
unidades, integración, regresión, validación, etc) a ser ejecutadas en diferentes
Julio Monetti 8
Testing
tiempos del ciclo.
Para la organización del plan de pruebas se deberá contemplar
Especificar requerimientos del producto en forma cuantificable antes de
comenzar el testing.
Establecer explícitamente los objetivos del testing.
Comprender a los usuarios y desarrollar un perfil para cada categoría.
Desarrollar un plan que enfatice pruebas de ciclo rápido.
Construir software robusto que se diseñe para probarse a sí mismo.
Usar revisiones técnicas formales.
Desarrollar un enfoque de mejoramiento continuo para el proceso de tes-
ting.
Cada prueba debería...
Dejar claro qué tipo de propiedades se quieren probar (corrección, robus-
tez, fiabilidad, amigabilidad, etc.).
Dejar claro cómo se mide el resultado.
Especificar en qué consiste la prueba (hasta el último detalle de cómo se
ejecuta).
Definir cual es el resultado que se espera (identificación, tolerancia,...).
Cómo se decide que el resultado es acorde con lo esperado?
Las pruebas aleatorias carecen de utilidad, tanto si no se sabe exactamente
lo que se quiere probar, o si no está claro cómo se prueba, o si el análisis
del resultado se hace a ojo.
Julio Monetti 9
PARTE II
ALGUNAS CLASIFICACIONES
1. En Cuanto al Nivel de Conocimiento del Có-
digo
1.1. Caja Negra
a (black-box testing, o “pruebas de funcionalidad”): centradas en verificar
si los requerimientos son satisfechos. Las pruebas de volumen y de stress (ren-
dimiento con grandes cantidades de datos, y con bloques de datos por unidad
de tiempo, respectivamente), son casos especiales de este tipo de prueba; otras
técnicas son la de clases de equivalencia y la de valores límite.
1.2. Caja Blanca
(white-box testing, o pruebas “de código/diseño”): se revisan, entre otras
cosas, el diseño y código fuente para verificar que sigan los estándares especifi-
cados, los algoritmos sean adecuados, y la arquitectura sea apropiada. Técnicas
comunes son el análisis de algoritmos, la cobertura de decisiones, las revisiones
entre pares y las recorridas.
2. En Cuanto a la Granularidad del Componen-
te Testeado
2.1. Pruebas de unidad
se prueba por separado cada “elemento mínimo de procesamiento” definido
por la organización (objetos, componentes, módulos, funciones). Las técnicas
más utilizadas son las de caja blanca. Típicamente, son realizadas por el equipo
desarrollador.
2.2. Pruebas de integración
se verifica la interacción entre unidades con técnicas como pruebas de inter-
acción y de mutación. Suelen ser ejecutadas por el equipo de prueba.
10
Testing
2.3. Pruebas de sistema
se verifica el sistema como un todo, aplicando pruebas de caja negra utili-
zando perfiles de usuario, haciendo v.gr. pruebas como configuración, seguridad,
confiabilidad y recuperación. Debieran ser ejecutadas por el equipo de prueba.
3. En Cuanto a los Actores Intervinientes en la
Prueba
3.1. Pruebas de Aceptación o Validación
Se verifica la satisfacción de requerimientos con técnicas como pruebas-α
(desarrolladores) y pruebas-β (usuarios). Deberían ser llevadas a cabo por un
equipo que incluya al cliente, usuario(s) y testers. El cliente es el que compro-
bará finalmente si se satisfacen los requisitos.
Estas pruebas se realizan con las mismas técnicas de otros tipos de prueba, pero
con otros objetivos, entre los cuales se busca el cubrimiento del programa com-
pleto.
El tester debería garantizar varios caso de prueba por cada requisito o caso de
uso especificado.
Se prueba también rendimiento, capacidad, etc, (no solamenbte que los re-
sultados sean los correctos).
3.2. Pruebas de Verificación
Ver si cumple las especificaciones de diseño.
4. Otros tipos de prueba
Pruebas Ascendentes
Pruebas Descendentes
Incremental
Pruebas de Stress
Pruebas de Subsistemas
Pruebas Alfa
Pruebas Beta
De solidez
De recuperación ante fallas
De seguridad y protección
De rendimiento
De regresión
De usabilidad
De recorrido
Aleatorias
Julio Monetti 11
Testing
De conformidad u homologación
De interoperabilidad
De cambio o mutación
5. Diseño de prueba de escritorio. Diseño de ar-
chivos de bitácora.
Una prueba de escritorio es una prueba manual que consiste en proporcio-
nar diferentes valores a las variables definidas en la porción de código a probar,
siguiendo el flujo de ejecución para evaluar como evolucionan sus valores, y si
el valor final obtenido es el esperado.
Generalmente la prueba de escritorio se diseña en un formato tabular, donde
se pueda verificar el valor de cada variable a través de la ejecución paso a paso
del programa.
Esta prueba puede ser diseñada previa al algoritmo, especificando en la tabla
cual es la instrucción a ejecutar y como interviene esta en el valor de cada
variable.
6. Técnicas y Estrategias para la prueba de soft-
ware.
6.1. Pruebas sin Estrategia
El software se prueba para descubrir fallas. Si se realiza esta tarea sin es-
tablecer un plan previo, seguramente se desperdiciara tiempo, se dedicará un
esfuerzo innecesario y lo que es peor puede que no se detecten los errores.
La carencia de una estrategia de prueba se debe a veces a
Falta de Motivación
• Las pruebas son incómodas
• La pruebas son aburridas
• “...Estoy seguro de que lo he codificado bien”
Probar todo junto, ...al final
• Falla por todas partes
• Muy difícil diagnosticar las causas de los fallos
• Muy costoso de arreglar
• Resultado: productos finales defectuosos
Julio Monetti 12
Testing
6.2. Organización para las pruebas de software. Verifica-
ción y validación de programas.
Una estrategia de prueba debería proporcionar un esquema que describa los
pasos a seguir en la revisión del software, que esfuerzo realizar en cada porción
del código, que recursos utilizar, cuanto tiempo utilizar para esta tarea, que
cantidad de pruebas realizar, en qué períodos, etc.
Las pruebas se deben planificar con anticipacion y realizarlas de manera
sistematica (y si es posible en forma automática). Por esta razón, debería existir
en la organización documentación que describa fehacientemente que pruebas se
realizarán y los detalles sobre las mismas, por ejemplo: un cronograma de
pruebas.
Una estrategia válida sería, seleccionar componentes individuales de software
a ser testeados, y luego avanzar sobre la prueba de integración de los mismos en
el sistema. Por otro lado, convendría complementar esta estrategia con otras.
La estrategia también debería contemplar las actividades de depuración y
corrección del código.
Para abordar el proceso de pruebas desde un punto de vista cronológico, se
podrían plantear dos etapas: la verificación y la validación. La verificacion [1]
es un conjunto de actividades que aseguran que el software implemente correc-
tamente la funcion específica. La validacion asegura que el software responde
a las necesidades del cliente. El desarrollador debe siempre ser responsable de
probar las unidades individales del software y en muchos casos tambien la inte-
gración.
La estrategia de pruebas debería seguir el siguiente esquema [1]
Julio Monetti 13
PARTE III
USO DE JUNIT
1. JUNIT
2. JUnit
Cuando probamos un programa, lo ejecutamos con algunos datos de entrada
(casos de prueba) para verificar que el funcionamiento cumple con los requisitos
esperados.
Existe un conjunto de herramientas que facilitan la elaboración de pruebas
unitarias en diferentes lenguajes: XUnit. De este conjunto de herramientas,
destacaremos JUnit que es la herramienta utilizada para realizar pruebas uni-
tarias en Java.
JUnit es un framework que permite realizar pruebas unitarias sobre un pro-
grama de manera automatizada.
El fin específico de estas herramientas es la posibilidad de realizar casos de
prueba (test case), y la suite de prueba (test suite). Los casos de prueba son
clases Java que contienen métodos para probar los métodos de la clase original
. Así, para cada clase que quisiéramos probar definiríamos su correspondiente
clase de caso de prueba. Mediante las suites podemos organizar los casos de
prueba, de forma que cada suite agrupa los casos de prueba de módulos que
están funcionalmente relacionados.
Las pruebas que se van construyendo se estructuran así en forma de árbol,
de modo que las hojas son los casos de prueba, y podemos ejecutar cualquier
subárbol (suite).
De esta forma, construimos programas que sirven para probar nuestros mó-
dulos, y que podremos ejecutar de forma automática. A medida que la aplicación
vaya avanzando, se dispondrá de un conjunto importante de casos de prueba,
que servirá para hacer pruebas de regresión. Eso es importante, puesto que
cuando cambiamos un módulo que ya ha sido probado, el cambio puede haber
afectado a otros módulos, y sería necesario volver a ejecutar las pruebas para
verificar que todo sigue funcionando.
Aplicando lo anterior a Java, JUnit es un conjunto de clases opensource que
nos permiten probar nuestras aplicaciones Java. Podemos encontrar información
14
Testing
actualizada de JUnit en http://www.junit.org
Encontraremos una distribución de JUnit, en la que habrá un fichero JAR,
junit.jar, que contendrá las clases que deberemos tener en el CLASSPATH a la
hora de implementar y ejecutar los casos de prueba.
3. Clases de Pruebas
4. Aserciones
5. Ejemplo de Uso
5.1. Codificación del Programa
Se desea codificar un programa que permita la suma y resta de dos números
enteros. Se diseña la solución que provea una clase Calculadora que encapsula
atributos y expone métodos para tal fin.
Ya codificada la clase en Netbeans, queda:
La solución es simple, y a simple vista se puede verificar que el programa no
contaría con errores en su codificación. No obstante, la simpleza del código es
útil para crear nuestro primer test con JUnit.
Julio Monetti 15
Testing
5.2. Creación de la Prueba
El objetivo es crear una clase hermana, que contenga la funciona-
lidad suficiente para probar la clase original Calculadora. Esta clase
hermana contiene un método de prueba que invocará al correspon-
diente método de Calculadora para verificar el valor devuelto, y el
estado final del objeto tras la invocación.
Realizar click con el botón derecho sobre el nombre del proyecto (panel iz-
quierdo de Netbeans). Se desplegará a continuación un menú contextual como
el mostrado en la siguiente figura.
Seleccionar a continuación la opción Create/Update Test, con lo cual el
sistema mostrará la siguiente ventana:
Julio Monetti 16
Testing
En esta ventana el sistema nos solicita que completemos:
El nombre de la clase de prueba.
El paquete donde se alojará la clase de prueba.
El framework a utilizar (por defecto se utilizará JUnit)
La opción para realizar test de integración.
Detalles sobre el código que generará JUnit.
• En el panel de la izquierda, según su visibilidad, los métodos que se
desea testear.
• En el panel de la derecha, los métodos de prueba que se generarán
(en la siguiente sección se verá un detalle de los mismos)
Una vez presionado el boton OK, Netbeans presentará en la ventana de
edición de código la nueva clase creada.
Se puede observar (flecha roja) que la clase ha sido creada, de acuerdo a lo
seleccionado en la ventana anterior, en un paquete destinado a contener única-
mente las clases de prueba. Esto permite que las mismas se encuentren aisladas
de las clases pertenecientes al proyecto principal.
Julio Monetti 17
Testing
package c a l c u l a d o r a ;
import o r g . j u n i t . Test ;
import s t a t i c o r g . j u n i t . A s s e r t . ∗ ;
public c l a s s CalculadoraTest {
public CalculadoraTest () { }
@Test
p u b l i c v o i d testSumar ( ) {
System . out . p r i n t l n ( " sumar " ) ;
C a l c u l a d o r a i n s t a n c e = new C a l c u l a d o r a ( ) ;
i n t expResult = 0 ;
i n t r e s u l t = i n s t a n c e . sumar ( ) ;
a s s e r t E q u a l s ( ex pRe sul t , r e s u l t ) ;
// TODO r e v i e w t h e g e n e r a t e d t e s t code
and remove t h e d e f a u l t c a l l t o f a i l .
f a i l ( " The t e s t c a s e i s a p r o t o t y p e . " ) ;
}
@Test
public void t e st R es t a r ( ) {
System . out . p r i n t l n ( " r e s t a r " ) ;
C a l c u l a d o r a i n s t a n c e = new C a l c u l a d o r a ( ) ;
i n t expResult = 0 ;
int result = instance . restar () ;
a s s e r t E q u a l s ( ex pRe sul t , r e s u l t ) ;
// TODO r e v i e w t h e g e n e r a t e d t e s t code
and remove t h e d e f a u l t c a l l t o f a i l .
f a i l ( " The t e s t c a s e i s a p r o t o t y p e . " ) ;
}
}
De la clase generada se pueden destacar las siguientes características:
Se han importado las clases necesarias desde el el conjunto de librerías de
JUnit.
Se ha creado la clase CalculadoraTest para probar la clase original Cal-
culadora.
Se han creado dos métodos: testSumar() y testRestar(), utilizados para
probar los métodos originales sumar() y restar() de la clase Calcula-
dora.
Julio Monetti 18
Testing
5.3. Descripción del Código Generado
Por defecto, JUnit genera el código descrito en la imagen anterior. Se puede
observar que existe un método de prueba por cada método de la clase original.
Cada método de prueba está contiene la anotación @Test para comunicar al
framework que existe para tal fin.
A continuación el código se puede resumir como sigue:
1. Creación de una instancia de la clase a probar. En este caso el
objeto del tipo Calculadora: instance. Sin la creación del objeto a probar
no sería posible invocar sus métodos.
2. Configuración del valor esperado. El generador de JUnit crea una
variable llamada expResult, sobre la cual el programador debe configurar
el valor esperado tras la invocación al método que se probará.
3. Invocación del método a probar. A través del objeto instance, se
invoca el método de prueba con los parámetros ya configurados. Tras esto
se obtiene como resultado del método el valor en result.
4. Comparación del valor esperado con el valor obtenido. Finalmente,
comparar el valor esperado con valor obtenido (expResult con result), a
través del método provisto por la librería de JUnit: assertEquals.
Se observa en el código generado una invocación al método fail. Este método
provoca que la prueba falle, mas allá del valor obtenido. Esta invocación ha sido
incluida en el código generado solo para recordar al programador que es conve-
niente continuar con la configuración de la prueba. (Al finalizar la programación
de la prueba, la invocación debe ser retirada).
5.4. Ejecución de la Prueba
La ejecución de la prueba se realiza seleccionando (click boton derecho del
mouse) la clase de prueba en el navegador de Netbeans, y luego seleccinando la
opción Test File.
Julio Monetti 19
Testing
Tras la ejecución de la prueba, el framework muestra en el panel central del
ide una barra indicadora con los resultados de la ejecución de la misma.
Julio Monetti 20
Testing
Referencias
[1] Ingeniería de Software, un enfoque práctico. Roger Pressman. 6ta edición.
[2] Pruebas de Sistemas de Información. Macario Polo Usaola. Universidad de
Castilla - La Mancha. Departamento de Tecnologías y Sistemas de Informa-
ción.
[3] Ingeniería de Software Orientada a Objetos con UML, Java E Internet. Al-
fredo Weitzenfeld.
[4] Los Defectos en el Desarrollo de Software Corporativo. Universi-
dad Carlos III de Madrid. Documento electrónico disponible en:
http://ocw.uc3m.es/ingenieria-informatica/
Julio Monetti 21
