Pruebas unitarias (frontend)

Las pruebas del frontend verifican que se hagan requests HTTP a las URLs correctas, que las llamadas (¡no las respuestas!) contengan los datos esperados, y que la interfaz gráfica muestre los elementos correspondientes a las respuestas. Hay un archivo de pruebas por cada página de la aplicación.

Mocks

Las pruebas del frontend están aisladas de las pruebas del backend. Por consiguiente, las llamadas a la API no llegan al servidor real, y es necesario simularlas. Se usa axios-mock-adapter para interceptar los requests y responder con datos predefinidos, o con un error si conviene. De forma similar a las pruebas del backend, la librería permite indicar una URL y qué JSON se desea retornar cuando el código haga un request a esa URL.

La librería también permite inspeccionar los requests interceptados. Esto permite, por ejemplo, verificar que las llamadas a la API que requieren autenticación tengan los headers requeridos, o que se haya realizado un número específico de llamadas a una URL específica.

Ejecución de las pruebas

Las pruebas unitarias del frontend pueden ejecutarse con npm run test:unit en la carpeta app/frontend. No es necesario que el servidor esté activo, pero tampoco es necesario que esté detenido.

Estructura de las pruebas

La mayoría de archivos de prueba siguen un patrón similar:

1. beforeEach() configura mocks para las URLs a las que la página hará requests GET o POST, además de mocks para algunas funciones de Vue (por ejemplo, la función push() del router, o la función para mostrar una alerta modal) que permitirán verificar posteriormente que se haya hecho push() para navegar a una nueva página después de que se haya creado un vuelo exitosamente, o que se haya mostrado una alerta después de un error.
2. En cada caso de prueba se instancia y monta el componente y se verifica que aparezcan o no ciertos elementos (texto, botones, etc.).
3. Algunos casos de prueba terminan aquí. En otros, posteriormente se interactúa con algún elemento (por ejemplo, se rellena un campo de texto y se simula un clic en un botón), se espera a que la aplicación se estabilice (esto es, que terminen las transiciones y animaciones y que todos los requests HTTP sean resueltos) y luego se realizan más aserciones.
4. En las aserciones se puede verificar, por ejemplo, que la aplicación haya navegado a otra página, que el request a la API haya incluido el valor ingresado en el campo de texto, que se haya mostrado un mensaje de error o que la página ahora muestre los valores retornados por la API (simulada).