El documento describe una herramienta llamada Jester que prueba la calidad de las pruebas de software mediante la introducción de pequeños cambios en el código y verificando si las pruebas fallan. Jester realiza modificaciones simples como cambiar números o condiciones lógicas y puede ayudar a identificar áreas del código que no están suficientemente probadas. El documento también discute técnicas para mejorar el rendimiento de Jester.

1. Grupo I: Jester
 Marcelo H. Giusseppin
 Samanta I. Ramiro
 Jorge G. Rojas
 Maximiliano Zorzoli

2. Probar las pruebas
 ¿Los proyectos tienen amplios
conjuntos de pruebas?
 ¿El conjunto de pruebas, prueba todo
lo que debería?
 ¿Qué pasa si no se están probando
todas las posibles entradas, y por lo
tanto no se prueba el código diseñado
para soportar las condiciones de
borde, por ejemplo?

3. Mutation testing
 Evalúa la calidad de los tests de software.
 Se hacen pequeñas modificaciones en el
código fuente de un programa o de una
porción del mismo.
 El propósito es desarrollar pruebas
efectivas o, localizar puntos débiles en los
casos de prueba usados para el programa
o en las secciones del código que rara vez
o nunca son accedidos durante la
ejecución.

4. Jester: El “probador
de pruebas” de
JUnit
 Herramienta usada principalmente por
programadores XP y sólo con código Java.
 Realiza algunos cambios en el archivo
original, lo recompila, ejecuta los casos de
test y si un test pasa, muestra un mensaje
indicando lo que modificó.
 Los cambios son de a uno por vez.
 Puede modificar el código que los casos de
test deben probar y también puede
modificar el código del mismo test .

5. Modificaciones
 Jester realiza las siguientes modificaciones
sencillas:
 Modificar números; ej. 0 es modificado a 1
 Modificar verdadero a falso, o viceversa
 Modificar if( a if(true ||
 Modificar if( a if(false &&
 Las modificaciones más complejas serán
contempladas en versiones posteriores de
Jester.

6. Ejecutando a Jester
 jester.jar y junit.jar deben estar en la misma
ruta de clase, y hay que añadir todos los
archivos .jar o los directorios que requiera
la aplicación para probarla.
 Todas las pruebas deben pasar por el
código fuente sin modificar.
 Por cada cambio, Jester imprime el nombre
del archivo modificado, la posición en el
archivo modificado y una porción del código
fuente original para identificar fácilmente el
cambio.

7. Rendimiento de Jester
 Debido a que recompila el código
original y vuelve a ejecutar el conjunto
de pruebas para cada cambio que
produce, ejecuta las órdenes más
lentamente.
 Se pueden utilizar una serie de
técnicas para acelerar las ejecuciones
de Jester:

8. Rendimiento de Jester
 Si la compilación consume un tiempo
significativo, probar con un compilador más
rápido.
 Analice y optimice su conjunto de pruebas.
 Reorganizar el conjunto de pruebas para
que las pruebas más frágiles sean
ejecutadas antes que las menos frágiles.
 Ordenar las pruebas por tiempo
aproximado de ejecución.
 Limitar las pruebas para una clase a la vez,
y ejecutar solamente las pruebas que
puedan exponer realmente baches en la
cobertura de esa clase.

9. Jester no es infalible
 La herramienta tiende a reportar una
gran cantidad de falsos positivos,
pero son fáciles de detectar.
 Ej: La construcción de un Vector(5) a
Vector(6). Esto puede afectar en la
performance, pero no tiene efecto en
el comportamiento del vector.

10. Cobertura de código vs. Jester
 La cobertura de  Jester puede
código indica qué detectar código no
código no es probado a pesar de
ejecutado por los que éste sea
casos de prueba. ejecutado.
 Indica si faltan tests  Puede dar una
o el código es ayuda sobre el tipo
redundante. de caso de prueba
que no se tuvo en
cuenta.

11. Referencias
 Moore, Ivan. Jester - a JUnit test tester.
Londres, 2001
 Harold, Elliot Rusty. Test your tests
with Jester. Polytechnic University , 2005
 A. Jeerson Outt. A Practical System for
Mutation Testing: Help for the Common
Programmer. ISSE Department, George
Mason University, 2002