Germán Domínguez  Ingeniería Electrónica y telecomunicaciones Universidad del Cuaca 2009
<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><li>Del mismo modo el cliente nunca debe aceptar un programa que no se haya probado previamente. </li></ul><ul><li>Est...
<ul><li>Es un conjunto de herramientas que facilitan la elaboración de pruebas unitarias en diferentes lenguajes de progra...
 
<ul><li>Se define una Matriz para manejar matrices de enteros y una suma para sumar 2 de ellas entre si. También las compa...
<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...
<ul><li>Se define un constructor para darle un nombre a la prueba. </li></ul><ul><li>Se definen 2 objetos de “Matriz”, cuy...
<ul><li>En general la construcción de pruebas sigue siempre estos patrones: -  Construir los objetos de prueba y llamar al...
<ul><li>Una vez hecha la prueba, debemos ejecutarla. </li></ul><ul><li>Junit proporciona 2 tipos de ejecutores para ver lo...
<ul><li>Esta ventana aparece cuando seguimos el anterior proceso. </li></ul>
<ul><li>Para ejecutar el “TestRunner” u otro ejecutor de pruebas, podemos también definirnos un método “main” en nuestra c...
<ul><li>Agregamos otra operación (resta) al primer ejemplo. </li></ul><ul><li>Ahora para la prueba tenemos: </li></ul>
<ul><li>En este caso, al lanzar el  TestRunner  se mostrarán los resultados de las dos pruebas: </li></ul>
<ul><li>Cuando tengamos código común en las pruebas, podemos redefinir el método  setUp()  de “TestCase”   para colocar di...
 
<ul><li>Cuando se quiere probar un método en la clase concreta (en nuestro caso Matriz), que funcione así lance una excepc...
<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 ejecut...
<ul><li>A medida que vamos acumulando métodos de prueba, nos podría interesar organizarlos o agruparlos de determinada for...
<ul><li>definimos otra operación de resta en la clase Matriz, para restar matrices a la inversa (si “restar()” hacía A - B...
<ul><li>Luego añadimos a nuestra clase de prueba “MatrizTest” un método “suite()” que devuelva una instancia de la clase “...
<ul><li>El método “run()” de la clase “TestRunner”, llama al método estático “suite()” que hemos definido implícitamente. ...
<ul><li>En una suite, podemos definir pruebas de distintas clases (no sólo de “MatrizTest”, en este caso), y así poder con...
Próxima SlideShare
Cargando en…5
×

JUnit - Germán Domínguez

924 visualizaciones

Publicado el

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

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

No hay notas en la diapositiva.

JUnit - Germán Domínguez

  1. 1. Germán Domínguez 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>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>
  6. 7. <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>
  7. 8. <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, osea el de la constante SUMA. </li></ul>
  8. 9. <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 sea 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>
  9. 10. <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>
  10. 11. <ul><li>Esta ventana aparece cuando seguimos el anterior proceso. </li></ul>
  11. 12. <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>
  12. 13. <ul><li>Agregamos otra operación (resta) al primer ejemplo. </li></ul><ul><li>Ahora para la prueba tenemos: </li></ul>
  13. 14. <ul><li>En este caso, al lanzar el TestRunner se mostrarán los resultados de las dos pruebas: </li></ul>
  14. 15. <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>
  15. 17. <ul><li>Cuando se quiere probar un método en la 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>
  16. 18. <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>
  17. 19. <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>
  18. 20. <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>
  19. 21. <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>
  20. 22. <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>
  21. 23. <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>

×