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
Notas del editor
- #3: Introducción
- #5: Para usar Jester con otro lenguaje u otro framework de testeo, podría requerir la existencia de un compilador (test runner)?? de tests que pueda ser ejecutado de la misma manera y que de el resultado esperado de PASÓ o FALLÓ. ? ? Si el test es modificado pero no falla cuando se ejecuta, entonces el test puede ser erróneo o redundante.
- #6: Las modificaciones son del tipo “buscar y reemplazar” texto. Las últimas dos tienen el efecto de hacer la condición de la declaración IF siempre verdadero o siempre falso respectivamente. La razón de estos reemplazos, más allá de la simplificación de las condiciones, es la de evitar la necesidad de encontrar el final de la condición, lo cual requeriría análisis y por lo tanto no sería sencillo de implementar. No hay posibilidad de realizar 2 cambios que se cancelen entre sí ya que los cambios son aplicados de a uno por vez, quedando sin completar hasta el siguiente cambio.
- #9: Muchos usuarios han reportado notables aceleraciones usando Jikes en lugar de javac JUnit reinicializa todos los campos para todos y cada uno de los método ejecutados, por lo que la extracción de datos de pruebas fuera de los campo y en variables locales puede acelerar a Jester significativamente cuando los campos no son usados por cada método en la clase de prueba.?? Las más frágiles son las que “más probablemente” fallarán después de los cambios. Las pruebas que se ejecutan puramente en la memoria deben estar antes de las pruebas que tienen acceso al disco, las que están antes de las pruebas que tienen acceso a la red LAN, que están antes de las pruebas que tienen acceso al Internet. Si algunas pruebas son particularmente lentas, dejarlas, aunque esto aumente el número de falsos positivos.?? Puede ser que tome más tiempo probar cada clase, pero esta manera usted puede comenzar a llenar los baches y corregir errores casi de inmediato, en lugar de esperar unos días hasta que Jester se ejecute hasta completar.
- #10: Versiones anteriores de Jester hacían cambios en los comentarios, lo que producía pérdida de tiempo y aumento de los costos de testeo.
- #11: Sabiendo que una declaración no es ejecutada por el conjunto de pruebas demuestra que no se probó. Sin embargo, la inversa no es verdad. Si una línea de código se ejecuta, no se deduce necesariamente que ésta es probada. Es muy posible que la prueba no compruebe si la línea de código produce el resultado correcto. ? Jester debe ser tomado como un enfoque complementario de la herramienta de cobertura de código. Jester muestra cómo el código puede ser modificado, y aún pasen las pruebas. Por lo tanto, hay que crear un caso de prueba.