Pruebas del front: qué probar y con qué

Teoría

Por qué probar el front

Hasta ahora probaste el back con JUnit (la lógica de negocio sobre la base de datos) y con Postman (el contrato HTTP desde afuera). El front también falla, y falla de formas que esas pruebas no ven. Probarlo sirve para:

Encontrar errores antes que el usuario. Una pantalla en blanco cuando el back responde un error, un enlace que lleva a la vista equivocada, un campo que nunca se muestra.
Poder cambiar el código sin miedo. Cuando refactorizas (por ejemplo, pasar un detalle de “dato en memoria” a “detalle por ruta”), las pruebas te avisan si algo dejó de funcionar.
Detectar cuándo el front y el back dejan de coincidir. El back cambia el nombre de un campo y el front sigue esperando el anterior.
Dejar documentado el comportamiento. Una prueba bien nombrada dice qué debe hacer la aplicación.

Qué puede fallar en un front

Antes de elegir una herramienta conviene saber qué se quiere probar. En una aplicación como la del curso, los errores se reparten en cinco zonas:

Zona	Ejemplo de error
La lógica de los servicios	Una llamada al back con la URL, el verbo o el cuerpo equivocados
Lo que se pinta	La lista no muestra los elementos que llegaron; el mensaje de error nunca aparece
La navegación	Un enlace lleva a la ruta equivocada; el detalle no lee el `id` de la URL
La comunicación con el back	El back devuelve un campo con otro nombre; la respuesta es un `404` o un `400` y la pantalla no lo maneja
La integración real	El navegador bloquea la respuesta del back por CORS

Los niveles de prueba

Una prueba se puede hacer a distinta altura: desde una función aislada hasta la aplicación completa en un navegador. Son los niveles de prueba, y cada uno ve cosas distintas:

Nivel	Qué prueba	Qué ve	Velocidad	Fragilidad
Servicio (unitaria)	Un servicio o una función, sin pintar nada	Qué petición hace y qué devuelve	Muy rápida	Baja
Componente	Un componente con su plantilla y su estado, con el back simulado	Lo que se pinta y cómo reacciona	Rápida	Baja a media
Integración	Varias piezas juntas (rutas, componentes, servicios) con el back simulado	Que las piezas encajan entre sí	Media	Media
Extremo a extremo (end to end, e2e)	La aplicación completa en un navegador real, contra el back real	El recorrido de un usuario	Lenta	Alta

Se suelen imaginar como una pirámide: muchas pruebas rápidas abajo y pocas lentas arriba.

            /  e2e  \            pocas, lentas, el recorrido completo
           /---------\
          / integración\
         /-------------\
        /   componente   \
       /-----------------\
      /      servicio       \    muchas, rápidas, baratas de mantener
     /-----------------------\

La razón es el costo. Una prueba de servicio corre en milisegundos y, si falla, señala el servicio. Una prueba de punta a punta tarda segundos, necesita el back corriendo y, si falla, el error puede estar en cualquier parte. Por eso las de abajo se escriben en cantidad y las de arriba solo para los recorridos que más importan.

Simular el back: los dobles de prueba

Una prueba de servicio o de componente no debe llamar al back real: sería lenta, dependería de que el back esté corriendo y de los datos que tenga, y un fallo del back haría fallar una prueba del front. Por eso se reemplaza el back por un doble de prueba: un objeto que responde lo que la prueba le indica.

La prueba dice, por ejemplo, “cuando el front pida GET /films/1, responde esta película” o “responde un 404”. Con eso comprueba qué hace el front en cada caso, incluidos los errores que el back real rara vez produce a pedido.

Qué error encuentra cada nivel

Cada nivel tiene su punto ciego. Esta tabla usa errores reales del front del curso:

Error	Lo encuentra
El servicio hace un `POST` a una URL equivocada	La prueba de servicio
El componente pide el recurso con `value()` y, cuando el back falla, se rompe la vista y el mensaje de error nunca aparece	La prueba de componente, simulando una respuesta de error
`/films/:id` no muestra el detalle de la película que indica la URL	La prueba de integración de rutas
El back manda `titulo` y el modelo del front espera `title`	La prueba de contrato
El back no declara en su CORS el origen del front y el navegador bloquea la respuesta	Solo la prueba de punta a punta

La última fila merece atención. Las pruebas con el back simulado no hacen ninguna petición real, así que no pueden ver CORS. Y Postman tampoco lo ve, porque no es un navegador. Es el caso en que una prueba de punta a punta justifica su costo.

Principios para pruebas que sirven

Son los mismos que ya usaste en las pruebas de lógica de negocio y en las pruebas de API:

Un escenario positivo y uno negativo. El caso feliz (llegan los datos y se pintan) y el caso en que algo sale mal (el back responde un error, la lista llega vacía).
Cada prueba es independiente. No debe depender de que otra haya corrido antes.
Se prueba el comportamiento, no la implementación. “Al elegir una película se muestra su título” sobrevive a un refactor; “el signal seleccionada vale tal cosa” no.
Una prueba que nunca falla no protege nada. Después de escribirla, rompe a propósito el código que debería proteger (cambia una URL, quita el manejo del error) y comprueba que la prueba falla.

Qué no probar

El framework. No hace falta comprobar que Angular pinta un @for: eso ya está probado por quien lo escribió.
Lo trivial. Un componente que solo muestra un texto fijo no necesita su prueba.
Todo por cubrir. El porcentaje de cobertura (qué parte del código ejecutan las pruebas) es una medida útil, y SonarQube la muestra en el pipeline, pero no es el objetivo. Se puede tener cobertura alta con pruebas que no verifican nada.

Las herramientas de este curso

Herramienta	Nivel	Obligatoria	Dónde corre
Vitest	Servicio, componente e integración, con el back simulado	Sí	`ng test` y el pipeline (con cobertura)
Playwright	Extremo a extremo, en un navegador real contra el back real	No: es opcional	La máquina del desarrollador

Vitest es la herramienta de pruebas que usa Angular: ya viene en el proyecto y el pipeline la ejecuta en cada PR, así que una prueba que falla deja el build en rojo, igual que en el back. Playwright es la opción para quien quiera recorrer la aplicación completa y detectar errores como el de CORS. La de Pruebas del front con Vitest explica la primera: la estrategia de pruebas del Release 8 y cómo se escribe cada una. Pruebas de punta a punta con Playwright explica la segunda.

Autoevaluación

1. Una prueba de componente simula la respuesta del back en vez de llamar al back real. ¿Por qué?

Porque el back real no se puede probarPorque la prueba debe ser rápida y no depender de que el back esté corriendo ni de sus datosPorque los componentes no pueden hacer peticiones

2. ¿Qué nivel de prueba es más lento y más frágil, pero el único que ve un error de CORS?

De servicioDe componenteDe punta a punta

3. El back cambia el campo titulo por title, pero el modelo del front sigue esperando titulo. ¿Qué prueba lo detecta?

La de contrato, que comprueba una respuesta real del back contra los modelos del frontNinguna: eso solo se ve en producciónLa de servicio, que comprueba la URL

4. ¿Qué dice la pirámide de pruebas?

Que se escriban pocas pruebas rápidas y muchas de punta a puntaQue haya muchas pruebas rápidas y baratas abajo, y pocas lentas de punta a punta arribaQue todas las pruebas deben ser de punta a punta

5. Una prueba pasa en verde y rompes a propósito el código que debería proteger, pero sigue en verde. ¿Qué significa?

Que el código está bienQue la prueba no protege nada y hay que corregirlaQue el framework tiene un error

6. Un proyecto tiene 95% de cobertura con pruebas que no verifican ningún resultado. ¿Qué conclusión es correcta?

El código está bien probadoLa cobertura mide qué código se ejecuta, no si se verifica algo: alta cobertura no garantiza buenas pruebasLa cobertura debe subirse al 100%