YouTube

Got a YouTube account?

New: enable viewer-created translations and captions on your YouTube channel!

Spanish, Mexican subtitles

← 03-38 Añadir tests a tu app

03-38 Añadir tests a tu app

Get Embed Code
4 Languages

Showing Revision 10 created 09/29/2014 by Fran Ontanaya.

  1. Ahora que tu aplicación
    ya es bastante funcional,
  2. estaría bien que añadiesen
    algunos tests unitarios.
  3. En la carpeta de la tercera lección,
  4. del código que descargaste
    del GitHub de Udacity
  5. encontraran la capeta, Test.
  6. La carpeta contiene tests
    que son aplicables
  7. hasta el fin de la tercera lección.
  8. Son básicamente
    tests de la funcionalidad del perfil.
  9. Probablemente no lo pueden ver,
    pero aquí está ProfileTest.java
  10. y ConferenceApiTest.java.
  11. Continúen y copien la carpeta de tests
    en la carpeta matriz SRC
  12. donde están tus proyectos
    para Conference Central.
  13. Basta con arrastrar y soltar;
    aquí lo tienen.
  14. Ahora quiero que sigan y borren
    el directorio de destino de esta carpeta.
  15. Cuando quiera que ejecuten el proyecto,
    o lo abran en Dev Server
  16. o lo implementen en AppSpot,
  17. la salida del build
    termina en el directorio de destino.
  18. Y se volverá a crear si lo borran.
  19. A veces la versión antigua
    y los archivos nuevos no encajan.
  20. Si dudan, borren el directorio de destino.
  21. Puesto que estamos añadiendo tests
    queremos cerciorarnos
  22. de que la hoja está en blanco.
  23. Lo voy a borrar y ya está.
  24. Parece que se ha borrado,
    pero no se va a quedar así.
  25. Bien, vamos a Eclipse.
  26. Refresco el proyecto porque
    he añadido el directorio de tests
  27. y he borrado el directorio de destino.
  28. Pero el directorio sigue ahí.
  29. Cuando borren un directorio de destino,
    se crea otro de inmediato con algo dentro.
  30. Pero no tiene todo lo necesario.
  31. Aquí en el directorio de origen
    verán la carpeta de tests.
  32. Tiene dos tests.
  33. Tiene ProfileTest.java
    en el paquete de dominio
  34. y tiene ConferenceApiTest.java
    en el paquete SPI.
  35. Echemos un vistazo a los tests.
  36. Primero observo ProfileTest.java.
  37. Aquí está la clase ProfileTest.
  38. Empiezo definiendo los valores
    que nos harán falta en nuestros tests.
  39. Y realizamos la configuración
    para este conjunto de aquí
  40. creando un nuevo perfil
    e incluyendo algunos valores.
  41. Luego tenemos el método tearDown,
    que siempre hace falta.
  42. Y aquí está el primer test;
    probamos los Getters.
  43. Bien fácil.
  44. Comprobamos que los valores
    del perfil son los adecuados.
  45. Luego comprobamos lo que pasa
    cuando se actualiza el perfil.
  46. Vamos a actualizar el nombre
    y la talla de camiseta.
  47. Y luego queremos comprobar
    que el nombre se actualiza
  48. y lo mismo con la talla de camiseta.
  49. Pero, el ID de usuario y el email
    no se deben actualizar.
  50. Deben permanecer como estaban.
  51. Y esta función queda excluida
    porque prueba funcionalidades
  52. que aún no se han implementado,
    por ende no funcionarían.
  53. Ahora veamos ConferenceApiTest.java.
  54. Aquí lo tenemos.
  55. De nuevo, lo primero que hacemos
    es establecer valores de prueba.
  56. Vamos a la ayuda de servicio,
    hacemos la configuración,
  57. Y en este caso, lo que estamos haciendo
    es crear un nuevo usuario
  58. con un email y un ID de usuario.
  59. Tenemos el método tearDown.
  60. Y comenzamos el test.
  61. Lo primero que se comprueba
    es que obtenemos el perfil la primera vez.
  62. Ahora probamos guardando el perfil.
  63. Ahora lo mismo con valores nulos
    y así sucesivamente.
  64. Vean los diferentes test que hacemos
    y cómo terminan por descartarse
  65. porque están usando una funcionalidad
    que no se ha implementado.
  66. No pueden crear la conferencia,
    pues no han escrito la función
  67. para crear una conferencia.
  68. Conforme avancen en la lección,
    vuelvan a ConferenceApiTest.java
  69. Y comenten el test de funciones,
    que ya estarán listas.
  70. Vale, veamos cómo ejecutar el proyecto
    cuando hay tests.
  71. Vamos a Conference Central
    y esta vez escogemos Run As
  72. y después Run Configurations.
  73. Esta es mi configuración para ejecutar
    Dev Server en localhost.
  74. Vean que hay una casilla Skip Tests.
  75. Por defecto los tests no se omiten.
  76. Hasta ahora no ha importado,
    porque no había tests.
  77. Daba igual tenerlos o no,
    pero ahora se van a ejecutar.
  78. Si en algún momento se bloquean
    y desean ejecutar sin tests,
  79. pueden marcar Skip Tests,
    pero ahora mismo no.
  80. Vale, voy a ejecutar.
  81. Todo normal. ¿Ven los tests?
  82. Bien, Dev Server se está ejecutando.
  83. Déjenme ir hacia arriba
    para ver los resultados del test.
  84. Bien, Se han hecho siete tests,
    ha habido cero fallos,
  85. cero errores, se saltan cero tests,
    tomó 0,415 segundos
  86. y luego aparece el resumen.
  87. Genial, todo bien.
  88. Pero, ¿qué ocurre si hay un error?
  89. Verifiquemos los tests
    introduciendo un error.
  90. Como estamos probando la funcionalidad
    de perfil, haré que alguna función
  91. devuelva un resultado inesperado.
  92. Tenemos el método getProfile
  93. y este obtiene el perfil
    asociado con el usuario registrado.
  94. Para extraer la entidad de perfil
    del almacén de datos,
  95. primero hay que crear una clave.
  96. Y especificar la clase profile.class
  97. para luego ver cuál es la clave,
    el ID de usuario.
  98. Pero digamos que hemos cometido
    un error poniendo el ID en una cadena.
  99. Esto suele ocurrir.
  100. Aquí no aparecen errores.
  101. Es un valor factible,
    por eso no se muestra un error.
  102. Veamos ahora qué pasa cuando
    se ejecutan los tests.
  103. Ahora lo voy a ejecutar en localhost
  104. Esta vez aparece un error.
  105. Error de ejecución y error en el test.
  106. El error sale en testGetProfile.
  107. No es ninguna sorpresa.
  108. Y ahí tenemos el seguimiento de la pila,
    pero al final está el resumen.
  109. Ahí están los tests, el error de entrada
    y cuántos fallos hay.
  110. Y ahora el otro asunto
    que querría comentar.
  111. Está en el directorio de destino.
  112. Puede hacer falta refrescar el proyecto.
  113. En el directorio de destino
    hay una carpeta llamada surefire-reports.
  114. El directorio contiene los resultados
    del informe.
  115. Si observamos ProfileTest.txt,
    no es ahí donde están los errores.
  116. Cero fallos, cero errores.
  117. Pero en ConferenceApiTest.txt,
    ¡vaya si hay errores!
  118. Aquí, fallos, en si solo hay un error,
    pero esto es el seguimiento de la pila.
  119. Si seguimos hacia abajo,
    vean lo que ocurre con los archivos XML.
  120. Al hacer clic en ConferenceApiTest.xml
  121. se ven las funciones solicitadas
  122. y las que tienen errores, o fallos.
  123. En este caso, me lleva directamente
    a donde está el error.
  124. El problema que veo es que
    el ID de usuario no es el esperado.
  125. Lo que voy a hacer es repararlo
    antes de que me olvide.
  126. Vale, este es el código reparado.
  127. Al ejecutarlo, no habrá algún error.
  128. Conforme avancen en la lección,
    asegúrense de añadir el test
  129. para la nueva funcionalidad
    cuando la implementen.
  130. En ciertos casos,
    hará falta los archivos de test
  131. de la carpetas de clase relevantes.
  132. Al implementar las nuevas funciones
    endpoint, pueden descartarse
  133. los tests que ya están
    en Conference API Tests.
  134. Si se desvían del código
    que les hemos pedido,
  135. bien sea añadiendo sus funciones
    o cambiando lo que estas hacen,
  136. entonces tendrán que actualizar los tests
    y añadir sus propios tests
  137. para asegurarse de que comprueban
    la funcionalidad de su aplicación.