JUnit - Pablo Calvache

1.011 visualizaciones

Publicado el

0 comentarios
0 recomendaciones
Estadísticas
Notas
  • Sé el primero en comentar

  • Sé el primero en recomendar esto

Sin descargas
Visualizaciones
Visualizaciones totales
1.011
En SlideShare
0
De insertados
0
Número de insertados
7
Acciones
Compartido
0
Descargas
0
Comentarios
0
Recomendaciones
0
Insertados 0
No insertados

No hay notas en la diapositiva.

JUnit - Pablo Calvache

  1. 1. Pablo Calvache y German Dominguez Ingeniería Electrónica y telecomunicaciones Universidad del Cuaca 2009
  2. 2. <ul><li>Se dice que un programa es funcional cuando: </li></ul><ul><ul><ul><ul><li>Hace lo que debe hacer </li></ul></ul></ul></ul><ul><ul><ul><ul><li>No hace lo que no debe hacer </li></ul></ul></ul></ul><ul><li>En pocas palabras, un programador nunca debe entregar un programa sin haberlo probado previamente. </li></ul>
  3. 3. <ul><li>Del mismo modo el cliente nunca debe aceptar un programa que no se haya probado previamente. </li></ul><ul><li>Estas observaciones son los incentivos para la creación de las pruebas unitarias de aceptación, en su conjunto total “Xunit” (muy útiles en aplicaciones a gran escala) </li></ul>
  4. 4. <ul><li>Es un conjunto de herramientas que facilitan la elaboración de pruebas unitarias en diferentes lenguajes de programación. </li></ul><ul><li>En el caso de java esta herramienta es JUnit. </li></ul>
  5. 6. <ul><li>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. </li></ul>
  6. 7. <ul><li>Se define una Matriz para manejar matrices de enteros y una suma para sumar 2 de ellas entre si. También las compara para verificar si son iguales. </li></ul>
  7. 8. <ul><li>Ahora vamos a utilizar Junit para probar el método suma. </li></ul><ul><ul><ul><ul><ul><li>Definimos una clase que herede de la clase “ junit.framework.TestCase” que implementen métodos sin parámetros que son los que van a hacer las pruebas. </li></ul></ul></ul></ul></ul><ul><ul><ul><ul><ul><li>Como convención se le suele poner el mismo nombre de la clase pero con la palabra “Test” a lo último, y definimos un método TestSuma() para comprabar la suma de las matrices. </li></ul></ul></ul></ul></ul>
  8. 9. <ul><li>Se define un constructor para darle un nombre a la prueba. </li></ul><ul><li>Se definen 2 objetos de “Matriz”, cuyos valores son los de la constante MATRIZ. </li></ul><ul><li>Luego se calculo la suma en “msumaTest” </li></ul><ul><li>Finalmente con el método “assertTrue” de la clase “TestCase”, comprobamos que la matriz calculada coincide con “msumaOK” la cual contiene el resultado correcto, ósea el de la constante SUMA. </li></ul>
  9. 10. <ul><li>En general la construcción de pruebas sigue siempre estos patrones: - Construir los objetos de prueba y llamar al método assertTrue o diferente sea cual se a el caso de TestCase. Para la verificación del cumplimiento de la propiedad requerida. </li></ul><ul><li>Colocar las clases de prueba en el mismo paquete de las clases probadas, para facilitar la localización y mantenimiento. </li></ul>
  10. 11. <ul><li>Una vez hecha la prueba, debemos ejecutarla. </li></ul><ul><li>Junit proporciona 2 tipos de ejecutores para ver los datos sea textualmente o gráficamente: </li></ul><ul><ul><ul><ul><li>junit.textui.TestRunner (modo texto) </li></ul></ul></ul></ul><ul><ul><ul><ul><li>junit.swingui.TestRunner (modo gráfico) </li></ul></ul></ul></ul><ul><li>Para ejecutarlas es necesario incluir el jar “junit.jar” en el CLASSPATH al ejecutar: </li></ul><ul><li>“ java -cp ./junit.jar junit.swingui.TestRunner” </li></ul>
  11. 12. <ul><li>Esta ventana aparece cuando seguimos el siguiente proceso. </li></ul>
  12. 13. <ul><li>Para ejecutar el “TestRunner” u otro ejecutor de pruebas, podemos también definirnos un método “main” en nuestra clase de prueba que lance el ejecutor, en nuestro caso: </li></ul><ul><li>Vemos que al “main” del “TestRunner” se le pueden pasar como parámetros los nombres de las clases de prueba que queremos probar. </li></ul>
  13. 14. <ul><li>Agregamos otra operación (resta) al primer ejemplo. </li></ul><ul><li>Ahora para la prueba tenemos: </li></ul>
  14. 15. <ul><li>En este caso, al lanzar el TestRunner se mostrarán los resultados de las dos pruebas: </li></ul>
  15. 16. <ul><li>Cuando tengamos código común en las pruebas, podemos redefinir el método setUp() de “TestCase” para colocar dicho código que se ejecutará antes de realizar las pruebas. </li></ul><ul><li>Esto se hace con la creación de 2 objetos de prueba (en nuestro caso) para los métodos “TestSuma()” y “TestResta()” que tienen código en común. ASI: </li></ul>
  16. 18. <ul><li>Cuando se quiere probar un método (por ejemplo “miMetodo()” en una clase concreta (en nuestro caso Matriz), que funcione así lance una excepción tipo IOException, el código de la prueba sería: </li></ul>
  17. 19. <ul><li>Se utiliza el método “fail(...)” para generar el error en el caso de que no se lance la excepción, Si no se ejecuta el “fail”, es porque hemos saltado al “catch”, y la prueba saldrá satisfactoria </li></ul>
  18. 20. <ul><li>A medida que vamos acumulando métodos de prueba, nos podría interesar organizarlos o agruparlos de determinada forma. </li></ul><ul><li>Mediante las suites podemos asignar métodos de prueba a grupos. </li></ul>
  19. 21. <ul><li>definimos otra operación de resta en la clase Matriz, para restar matrices a la inversa (si “restar()” hacía A - B, el nuevo método “restar2()” hará B - A). </li></ul><ul><li>“ restar2()”: </li></ul><ul><li>“ restar2()-prueba”: </li></ul>
  20. 22. <ul><li>Luego añadimos a nuestra clase de prueba “MatrizTest” un método “suite()” que devuelva una instancia de la clase “Junit.frame.work.TestSuite” </li></ul>
  21. 23. <ul><li>El método “run()” de la clase “TestRunner”, llama al método estático “suite()” que hemos definido implícitamente. </li></ul><ul><li>Al cargar “TestRunner&quot; nos aparece la organización en árbol de las suites. </li></ul>
  22. 24. <ul><li>En una suite, podemos definir pruebas de distintas clases (no sólo de “MatrizTest”, en este caso), y así poder controlar todo desde una sola estructura de árbol, si nos conviene. </li></ul><ul><li>También podemos añadir con el método “addTest” todas las pruebas de una clase entera, construyendo la suite con el campo “class” de la clase que se quiere probar: </li></ul>
  23. 25. <ul><li>Ignacio Iborra © Departamento de Ciencia de la Computación e Inteligencia Artificial, Universidad de Alicante, 2004 </li></ul>

×