Tu proyecto hace lo que promete: el dominio cumple las reglas, los datos sobreviven a la recarga, la aplicación habla con una API y trabaja sin conexión. Y ahora llega la pregunta incómoda, la que separa una demo de un producto: ¿cómo sabes que sigue haciéndolo mañana? Porque tienes migraciones que pueden corromper datos silenciosamente, sincronización con carreras que solo aparecen con mala red, y vistas que pueden retener memoria al navegar — tres cosas que no se ven mirando la pantalla y que, cuando fallan, fallan en el dispositivo de otra persona. En esta lección llevas al proyecto propio todo lo que aprendiste en el Módulo 8, pero con una diferencia importante: allí las pruebas se te daban escritas, y aquí tienes que decidir qué probar, en qué nivel y hasta dónde. Verás cómo definir una estrategia de pruebas con la pirámide aplicada a tus módulos concretos y un objetivo de cobertura razonado en lugar de cosmético; cómo probar el dominio exhaustivamente con pruebas parametrizadas de las quince reglas; cómo probar la capa de datos con dobles, temporizadores falsos y fetch simulado, incluidas las migraciones y la cola; cómo probar la vista consultando por rol y también el recorrido con teclado; cómo elegir tres recorridos de extremo a extremo y por qué no más; cómo montar la integración continua completa con presupuesto de rendimiento; cómo depurar tres fallos que van a aparecer de verdad en tu proyecto, con la técnica de reproducir primero y escribir una prueba que falle; cómo automatizar y complementar las pruebas de accesibilidad; y cómo medir tu proyecto contra la línea base de Nómada Tareas. Al terminar tendrás la suite completa en verde en CI y el informe de accesibilidad y rendimiento.

1. La estrategia de pruebas: decidir qué se prueba y dónde
2. La pirámide aplicada a tus módulos concretos
3. Un objetivo de cobertura razonado, no cosmético
4. Probar el dominio: las quince reglas parametrizadas
5. Probar las transiciones y los casos límite
6. Probar la capa de datos con dobles y temporizadores falsos
7. Probar las migraciones y la cola offline
8. Probar la vista con jsdom y Testing Library
9. Probar el recorrido con teclado
10. Tres recorridos de extremo a extremo, y por qué no más
11. Integración continua con GitHub Actions
12. Lighthouse CI y el presupuesto de rendimiento
13. Depurar el proyecto propio: el método aplicado
14. Fallo 1: la migración que corrompe datos
15. Fallo 2: la condición de carrera al sincronizar
16. Fallo 3: la fuga de memoria al navegar
17. Pruebas de accesibilidad: automáticas y manuales
18. Medir el rendimiento del proyecto propio
19. Las pruebas intermitentes
20. Errores Comunes y Consejos
21. Ejercicios
22. Conclusión

Antes de escribir una sola prueba más, hay que responder a tres preguntas. Escribirlas en docs/estrategia-pruebas.md es media hora que ahorra semanas de pruebas mal colocadas.

Pregunta 1 · ¿Qué es lo que no puede fallar nunca?

En Órbita, la respuesta es concreta: las reglas de negocio y la persistencia. Que un botón esté dos píxeles a la izquierda es un defecto cosmético; que una migración pierda las tareas de alguien es la muerte del producto. Las pruebas se concentran donde el fallo es catastrófico, no donde es fácil escribirlas.

Pregunta 2 · ¿Qué cambia a menudo y qué no?

Lo que cambia mucho —la maquetación, los textos, las clases CSS— no debe estar acoplado a las pruebas, o cada retoque visual romperá veinte pruebas que no detectan ningún fallo real. Lo que cambia poco —las reglas, los contratos— se puede probar a fondo sin coste de mantenimiento.

Pregunta 3 · ¿Cuánto cuesta cada prueba y cuánto vale?

La conclusión operativa: muchas unitarias, bastantes de integración, muy pocas de extremo a extremo. No es una preferencia estética; es una consecuencia directa de la tabla.

La regla de decisión que resuelve casi todos los casos:

Prueba en el nivel más bajo que capte el fallo que te preocupa.

Si te preocupa que R13 no bloquee el cierre, es una prueba unitaria de dominio: no hace falta un navegador. Si te preocupa que el botón no esté deshabilitado cuando debe, es de integración con DOM. Si te preocupa que crear una tarea, recargar y verla no funcione de punta a punta, es de extremo a extremo. Probar R13 desde Cypress es cien veces más lento y da la misma información.

La pirámide de pruebas genérica no ayuda mucho. Esta sí, porque nombra tus ficheros:

Total orientativo: unas 250 pruebas, de las cuales tres son de extremo a extremo. Nómada Tareas tenía 124 pruebas y 3 recorridos con menos funcionalidades; el orden de magnitud es coherente.

Dos observaciones sobre esta tabla:

• reglas.js no se prueba directamente. Son constantes. Una prueba que comprueba que MAX_HORAS === 40 no verifica nada: reescribe el valor en otro sitio. Lo que se prueba es que la regla se aplica, y eso ocurre en tarea.js.
• La proporción vista/dominio es de aproximadamente 1 a 2. Si tu proyecto tuviera más pruebas de vista que de dominio, sería señal de que la lógica está en la vista — exactamente lo que la arquitectura de 11-01 pretendía evitar. La distribución de tus pruebas es un diagnóstico de tu arquitectura.

La cobertura mide qué porcentaje del código se ejecuta durante las pruebas. Es una métrica útil y peligrosa a partes iguales, y conviene entender por qué.

Lo que la cobertura sí dice: qué código no está probado en absoluto. Un 0 % en migraciones.js es una alarma real.

Lo que la cobertura no dice: si lo probado está bien probado. Esta prueba da 100 % de cobertura y no verifica nada:

Por eso un objetivo único para todo el proyecto es un mal objetivo. Lo razonable es por capa, y con criterio:

La justificación de cada umbral, que es lo que hay que escribir en tu estrategia:

Y la métrica que de verdad importa no es el porcentaje: es la cobertura de las reglas. Mantén una tabla en docs/estrategia-pruebas.md:

Quince reglas × tres casos = cuarenta y cinco pruebas mínimas. Esa tabla es un objetivo mucho más honesto que «85 % de cobertura», porque no se puede aprobar sin verificar nada.

Las pruebas parametrizadas son la herramienta natural para las reglas, porque una regla es una afirmación sobre un conjunto de casos.

Cuatro decisiones de esta tabla que la hacen valiosa:

1 · La tabla es legible como especificación. Cualquiera que la lea sabe exactamente qué acepta y qué rechaza el modelo, sin leer el código de Tarea.

2 · Cada regla tiene sus límites exactos. Para R3: 0 no, 0.5 sí, 40 sí, 40.1 no. Los fallos de los desarrolladores viven en los > que deberían ser >=, y solo se cazan probando el valor exacto del límite.

3 · Se comprueba error.campo, no solo el tipo. Ese dato es lo que permite al formulario marcar el campo correcto (11-02). Si no se prueba, un día alguien pone campo: 'horas' en lugar de 'horasEstimadas' y el formulario deja de resaltar nada, en silencio.

4 · Hay casos de tipo, no solo de valor. '12' como texto y NaN son los que se cuelan por validaciones ingenuas como if (horas > 40). Con NaN, esa comparación es false y el valor pasa.

El caso R14 merece una prueba especial, porque su invariante no es sobre un valor sino sobre la estructura:

La matriz de transiciones de R6 se prueba entera, como en 11-02. Pero hay tres tipos de caso límite que se olvidan sistemáticamente y que conviene enumerar:

Los límites numéricos. Para cada comparación de tu dominio, prueba el valor exacto, uno por debajo y uno por encima:

Los límites de colección. Para cada función que recibe una lista:

Los límites temporales. Los que más fallos producen y menos se prueban:

La segunda fila es la que rompe casi todas las implementaciones caseras de semana ISO, y afecta directamente a R15 y al informe de carga. Si tu proyecto usa semanas, esta prueba no es opcional.

Y un caso que solo aparece en proyectos con árboles: el árbol degenerado. Una tarea con 200 subtareas en un solo nivel, y una cadena de 3 niveles con una hoja en cada uno. Los dos ejercitan caminos distintos de tu recursividad.

Aquí se aplica todo lo de 08-04. La regla que gobierna: se sustituye lo que es lento, no determinista o externo; nunca la lógica que estás probando.

El detalle de throw new Error('fetch inesperado') es importante: una llamada de más que no esperabas es un fallo que quieres ver, no algo que deba devolver undefined y producir un error confuso más adelante.

Las dos aserciones sobre llamadas.length son el corazón de estas pruebas. Sin ellas, ambas pasarían aunque el reintento estuviera mal implementado.

advanceTimersByTimeAsync y no advanceTimersByTime. La versión asíncrona vacía también la cola de microtareas entre avances, y sin ella las promesas intermedias no se resuelven y la prueba se cuelga. Es uno de esos detalles que cuestan una tarde la primera vez, y tiene todo el sentido a la luz de 05-07: las microtareas y los temporizadores son colas distintas.

Recuerda restaurar los temporizadores reales. Un jest.useFakeTimers() que se queda activo contamina las pruebas siguientes con fallos aparentemente aleatorios. Ponlo en un afterEach global.

Ya viste las seis pruebas base en 11-03. Añade estas tres, que cubren lo que sale mal en la práctica:

La segunda es una prueba de rendimiento en la suite, y aquí sí está justificada: la migración ocurre al arrancar, bloqueando la primera pintura. Una migración de dos segundos arruina el LCP del presupuesto de 11-01, y ese fallo solo aparece con datos de usuario real. Ponerle un umbral en la prueba lo previene.

La tercera prueba es la que evita el duplicado del apartado 13 de 11-03, y es imposible de comprobar a mano de forma fiable. Es el ejemplo perfecto de un fallo que solo se caza con una prueba automatizada.

El principio de 08-05, que conviene recordar porque lo cambia todo:

Prueba como usa la aplicación una persona, no como está construida por dentro.

En la práctica, eso significa consultar por rol y por texto accesible, nunca por clase CSS ni por estructura.

El beneficio doble: la prueba sobrevive a un cambio de clases CSS, y además verifica accesibilidad de propina. Si getByRole('button', { name: /crear/i }) no encuentra nada, es porque tu botón no es un botón o no tiene nombre accesible — y eso es un fallo real que un querySelector habría ocultado.

Fíjate en que la mitad de estas pruebas verifican requisitos de accesibilidad y de experiencia —lista semántica, texto además del color, anuncio del recuento, estado vacío con salida— que en 11-01 escribiste como criterios de aceptación. El círculo se cierra: historia → criterio → prueba.

Esta es la parte que casi ningún proyecto de portafolio tiene, y es la que más impresiona en una revisión.

Las tres cubren los tres fallos de foco más comunes: no entrar al abrir, no volver al cerrar y escaparse mientras está abierto. Si usas <dialog> con showModal(), las tres pasan casi sin esfuerzo — que es exactamente el argumento de 11-02 sobre usar el elemento correcto.

Advertencia sobre jsdom: jsdom implementa <dialog> de forma incompleta en algunas versiones, y no calcula estilos, así que no puede verificar visibilidad ni contraste. Las pruebas de teclado en jsdom cubren la lógica del foco; la verificación real de que se ve dónde estás es manual o de extremo a extremo.

Las pruebas de extremo a extremo (08-06) son las más valiosas por prueba y las más caras por prueba. Esa doble condición dicta la estrategia: pocas y muy bien elegidas.

El criterio de selección, en una frase: elige los recorridos que, si se rompieran, el producto no serviría para nada. Para Órbita:

Recorrido 1 · El ciclo de vida completo de una tarea.

Este recorrido cubre de una vez: crear con validación, el árbol, R13 aplicada de verdad desde la interfaz, el mensaje de error, la transición completa y la persistencia tras recargar. Un recorrido, seis riesgos.

Recorrido 2 · Filtrar, compartir el filtro y ver el informe. Cubre el estado compartido, la URL como fuente de verdad, el cálculo de carga y el estado vacío.

Recorrido 3 · Trabajar sin conexión y recuperar. Cubre la cola, la persistencia y la reconciliación:

Ese último should('have.length', 1) es la prueba del duplicado: si la idempotencia falla, aparecen dos.

Por qué exactamente tres. Con tres recorridos cubres los tres riesgos sistémicos —el flujo principal, el estado compartido y la resiliencia— en unos 30 segundos de ejecución. Con veinte tendrías cinco minutos de CI, fallos intermitentes semanales y una carga de mantenimiento que acabaría con alguien desactivándolos. Una suite de extremo a extremo desactivada vale cero, así que el número correcto es el máximo que puedes mantener siempre en verde. Tres lo es. Nómada Tareas también tenía tres, con menos funcionalidades: la proporción se sostiene.

La integración continua ejecuta npm run verificar en cada push, en una máquina limpia. Ese «máquina limpia» es la mitad del valor: caza los «en mi máquina funciona» que se deben a un fichero no confirmado o a una dependencia global.

Las decisiones del fichero, una a una:

La protección de la rama. La CI no sirve de nada si se puede fusionar en rojo. En los ajustes del repositorio, marca main como protegida y exige que los tres trabajos pasen antes de fusionar. Es un clic que convierte una recomendación en una garantía — la misma idea que la regla de ESLint de 11-01.

En 11-01 fijaste el presupuesto. Aquí lo haces cumplir automáticamente.

Cuatro observaciones:

• numberOfRuns: 3. Lighthouse tiene ruido; con una sola ejecución tendrías fallos aleatorios. Tres y toma la mediana, exactamente la disciplina de medición de 09-01.
• error frente a warn. Lo que rompe la compilación es lo del presupuesto firmado; lo demás informa. Si todo es error, acabarás desactivándolo entero al primer viernes complicado.
• resource-summary:script:size en 61440 son los 60 kB del presupuesto de 11-01, en bytes. Esta única línea es la que impide que un día alguien añada una librería de gráficos y nadie se entere.
• Las tres auditorías de accesibilidad con minScore: 1 —contraste, etiquetas, nombres de botón— son las que más se degradan con el tiempo. Exigir perfección en esas tres es asumible y evita la erosión.

Cuando el presupuesto falla, hay tres salidas legítimas y una ilegítima:

La lección 08-01 dio el método. Aquí se aplica a fallos tuyos, y el cambio importante es que nadie te va a decir dónde está el problema.

El procedimiento, en seis pasos:

El paso 3 es el que casi todo el mundo se salta, y es el más rentable de los seis. Escribir la prueba antes de corregir tiene cuatro beneficios simultáneos:

1. Demuestra que has entendido el fallo. Si no puedes escribir la prueba, no sabes qué está mal: solo tienes un síntoma.
2. Te dice cuándo has terminado. Sin ella, «parece que ya funciona» es todo lo que tienes.
3. Evita la reaparición. Los fallos corregidos sin prueba vuelven, y vuelven en el peor momento.
4. Documenta el caso raro. Dentro de un año, esa prueba explicará por qué el código tiene esa línea aparentemente innecesaria.

El paso 4 merece un matiz. Una hipótesis útil es falsable y concreta: «el id que llega al PUT es undefined porque el servidor devuelve _id». Una hipótesis inútil es «algo pasa con los ids». La primera se comprueba con una medición; la segunda te lleva a tocar cosas a ver si se arregla, que es la forma más cara de depurar que existe.

Los tres apartados siguientes recorren tres fallos que van a aparecer en tu proyecto. No son ejemplos inventados: son las consecuencias directas de lo que has construido en 11-02 y 11-03.

El síntoma. Un usuario de prueba (o tú, con tu perfil de desarrollo antiguo) actualiza la aplicación y ve el tablero con las tareas, pero todas aparecen sin responsable y el informe de carga sale a cero. No hay ningún error en consola.

Paso 1 · Reproducir. El fallo no ocurre con datos nuevos, solo con datos antiguos. La reproducción exige el documento original — y aquí se cobra el respaldo de 11-03:

Los datos antiguos sí tienen responsable. Luego lo pierde la migración.

Paso 2 · Reducir. Al caso mínimo: dos tareas y un usuario.

Paso 3 · La prueba que falla:

Paso 4 · Hipótesis. El mapa porNombre no encuentra 'Iván'. Posibles causas: (a) los usuarios no están cargados cuando corre la migración, (b) el nombre no coincide exactamente, (c) el orden de las migraciones es incorrecto.

Paso 5 · Comprobar con una medición:

Ahí está. Los dos textos se ven idénticos en pantalla y no son iguales: uno usa el carácter precompuesto í (U+00ED) y el otro una i seguida de un acento combinante (U+0301). Es un clásico de los datos que han pasado por distintos sistemas operativos o navegadores.

Paso 6 · Corregir. Normalizando Unicode en ambos lados:

Y las tres lecciones generalizables:

1. Emparejar por texto es frágil. Emparejar por identificador, siempre que sea posible. Si no queda más remedio, normaliza (normalize('NFC'), trim(), y valora toLocaleLowerCase()).
2. Un fallo silencioso es peor que uno ruidoso. La migración ponía null sin avisar. Debería contar cuántas asignaciones no pudo resolver y registrarlo: registrar('migracion v2: 6 de 8 responsables sin resolver'). Un aviso habría revelado el fallo el primer día.
3. El respaldo salvó la investigación. Sin él, los datos originales habrían desaparecido y solo tendrías el síntoma.

La prueba de regresión que se queda, con el caso Unicode explícito:

El síntoma. Con la red lenta, a veces —no siempre— al marcar una tarea como hecha, vuelve a aparecer como pendiente al cabo de un segundo. No pasa en tu máquina con red rápida. No hay error en consola.

Este es el peor tipo de fallo: intermitente y dependiente del entorno. Y la primera regla es no intentar depurarlo hasta poder reproducirlo a voluntad.

Paso 1 · Reproducir. Con el panel Network en Slow 3G, sale una de cada tres veces. Todavía no basta. Para hacerlo determinista, hay que controlar los tiempos:

Con tres segundos de retraso, ocurre siempre. Ya es reproducible.

Paso 2 · Reducir. La secuencia mínima resulta ser:

La lista se refresca con datos anteriores a mi cambio y pisa la actualización optimista.

Paso 3 · La prueba que falla, con temporizadores falsos para hacerla determinista:

Paso 4 · Hipótesis. El GET sustituye la lista entera con lo que devuelve el servidor, sin tener en cuenta que hay cambios locales pendientes de confirmar.

Paso 5 · Confirmado: refrescarTareas hace almacen.actualizar({ tareas: delServidor }).

Paso 6 · Corregir. Tres soluciones posibles, y conviene ver por qué se elige una:

Las tres lecciones generalizables:

1. Un fallo intermitente casi siempre es una carrera. Cuando algo pasa «a veces», busca dos operaciones asíncronas que puedan terminar en distinto orden.
2. Reproducir exige controlar el tiempo. Retrasar peticiones a propósito convierte «una de cada tres veces» en «siempre», y eso es lo que hace posible depurar.
3. Cualquier estado que se sustituye entero es sospechoso. actualizar({ tareas: nuevas }) descarta información que puede ser más reciente. Sustituir siempre debe ser una decisión, no el camino por defecto.

El síntoma. Tras navegar entre tablero, informe e historial durante un rato, la aplicación se vuelve lenta. Al principio no se nota; tras veinte navegaciones, cada cambio de pantalla tarda visiblemente más.

Paso 1 · Reproducir y medir, con el protocolo de 09-03:

1. Abrir el panel Memory en modo incógnito.
2. Instantánea 1 (línea base).
3. Navegar 20 veces entre las tres pantallas.
4. Forzar la recolección de basura (el icono de la papelera).
5. Instantánea 2.
6. Comparar por Objects allocated between snapshots.

El resultado:

Veintiuna instancias de TableroVista vivas. Debería haber una. Los 4.812 nodos separados son el DOM de las veinte anteriores, retenido por algo.

Paso 2 · Encontrar el retenedor. En el panel Memory, seleccionar una instancia y mirar Retainers:

El almacén está reteniendo veinte funciones suscriptoras, cada una con su clausura sobre su vista y su DOM.

Paso 3 · La prueba que falla:

Paso 4 y 5 · La causa. El código era este:

Paso 6 · Corregir, guardando todas las bajas:

Las cuatro lecciones generalizables:

1. Todo lo que se conecta debe desconectarse. Escuchas, suscripciones, temporizadores, observadores, sockets. El patrón «guardar la baja en un array» convierte destruir() en tres líneas siempre iguales.
2. La fuga no se ve, se mide. Nadie detecta 26 MB mirando la pantalla. Sin el protocolo de tres instantáneas de 09-03, esto se descubre cuando un usuario dice «va lenta después de un rato».
3. Es comprobable en una prueba unitaria. No hace falta el panel Memory para prevenir la reaparición: basta con exponer numeroDeSuscriptores y contar. Esa prueba tarda un milisegundo y corre en cada push.
4. Añade el contador de navegaciones a tu lista de comprobación. Entrar y salir tres veces de cada pantalla, con el contador de escuchas a la vista, debería ser parte del cierre de cada incremento.

Hay una cifra que conviene tener presente: las herramientas automáticas detectan alrededor de un tercio de los problemas reales de accesibilidad. Son imprescindibles y no son suficientes.

Los dos últimos casos —estado vacío y estado de error— son los que nadie prueba y donde más incidencias aparecen, porque se maquetan deprisa y sin revisar.

Y en Cypress, sobre la aplicación real (que sí calcula estilos, y por tanto sí detecta contraste):

Ninguna herramienta detecta que el orden de tabulación sea absurdo, que un texto alternativo diga «imagen1», o que el flujo sea imposible de seguir sin ver la pantalla. Eso se prueba a mano, con esta lista:

Unos 50 minutos por revisión completa. Hazla al cerrar cada hito, no al final.

El punto 3 asusta la primera vez y es el que más enseña. Consejos para empezar: aprende cinco atajos (leer todo, siguiente elemento, siguiente encabezado, lista de enlaces, lista de encabezados), cierra los ojos de verdad, e intenta completar una tarea concreta. Lo que descubrirás casi seguro: que tus encabezados no forman una estructura navegable, que tus botones de icono no dicen nada, y que cuando algo cambia en pantalla no te enteras.

Un entregable del hito, en docs/accesibilidad.md:

Ese documento, con sus limitaciones declaradas, vale más en una entrevista que una puntuación de 100 en Lighthouse. Demuestra que has mirado de verdad.

Aplica el protocolo de 09-01 a tu proyecto: mediana de 15 repeticiones tras 5 de calentamiento, CPU 4×, red Slow 4G, incógnito, misma máquina.

Genera datos realistas primero. Medir con seis tareas no dice nada:

Y la tabla de resultados, con la referencia de Nómada Tareas al lado:

Cómo interpretar la comparación honestamente, que es la parte que importa:

• Órbita es algo más pesada que Nómada Tareas, y debe serlo. Tiene tres pantallas más, árbol de subtareas, historial y cola de sincronización. Estar dentro del presupuesto con más funcionalidad es el resultado correcto.
• Estar por debajo del presupuesto no es motivo para relajarse: es margen para lo que venga. Anota el margen: 5,9 kB de JavaScript y 400 ms de LCP.
• Si estás fuera, la tabla te dice dónde mirar. Cada fila tiene su lección del Módulo 9: render() alto → 09-04; JS alto → 09-05; memoria → 09-03; INP → 09-02.

Y una regla contra el autoengaño: mide en modo incógnito, sin extensiones y sin el servidor de desarrollo. Vite en desarrollo sirve módulos sin empaquetar, y medir ahí da números que no tienen nada que ver con producción. Se mide sobre npm run build y npm run preview.

Una prueba intermitente (o flaky) pasa unas veces y falla otras sin que cambie el código. Son el peor enemigo de una suite, por una razón concreta: destruyen la confianza. En cuanto la gente empieza a relanzar la CI «a ver si esta vez pasa», las pruebas dejan de ser una señal y pasan a ser ruido.

Las causas, con su solución:

El protocolo cuando aparece una intermitente:

1. Nunca la relances y sigas. Ese es el hábito que arruina las suites.
2. Etiquétala y ejecútala en bucle para medir la frecuencia:

   npx jest --testNamePattern="nombre" --runInBand --repeat=50
   

3. Aísla la causa con la tabla de arriba. Casi siempre es tiempo o estado compartido.
4. Corrige la causa, no el síntoma. Añadir cy.wait(2000) no arregla nada: hace la prueba más lenta y sigue fallando en una máquina más lenta.
5. Si no puedes arreglarla hoy, márcala con test.skip y abre una incidencia con fecha. Una prueba desactivada y anotada es honesta; una prueba intermitente activa es corrosiva.

Y la regla de higiene: ejecuta la suite completa cinco veces seguidas antes de dar por bueno un hito. Si las cinco pasan, tienes una suite fiable. Si falla una, tienes una intermitente que ya conoces — y es mucho mejor conocerla ahora que un viernes durante un despliegue.

Probar la implementación en lugar del comportamiento. Una prueba que comprueba que se llamó a un método interno se rompe con cada refactorización sin detectar ningún fallo real. Prueba lo que entra y lo que sale, o lo que ve el usuario. La regla práctica: si al reorganizar el código por dentro, sin cambiar el comportamiento, se rompen pruebas, esas pruebas estaban mal.

Perseguir el 100 % de cobertura. Los últimos puntos porcentuales suelen ser ramas defensivas que nunca se ejecutan, y forzarlos produce pruebas artificiales que no aportan confianza. Sube el listón donde el riesgo es alto —dominio y migraciones— y acepta menos donde el coste es alto y el riesgo bajo.

Escribir veinte pruebas de extremo a extremo. Son lentas, frágiles e intermitentes. Con veinte, la CI tarda cinco minutos y alguien acabará desactivándolas. Tres bien elegidas dan casi la misma confianza sistémica a una fracción del coste.

querySelector por clase CSS en las pruebas de vista. Acopla la prueba a la maquetación y no verifica accesibilidad. getByRole hace las dos cosas bien y falla cuando tu HTML no es semántico, que es información valiosa.

No limpiar el estado entre pruebas. localStorage, temporizadores falsos, dobles de fetch y el DOM se arrastran de una prueba a otra y producen fallos que dependen del orden. beforeEach que limpia todo, siempre.

Usar advanceTimersByTime con código asíncrono. No vacía la cola de microtareas y la prueba se cuelga o falla sin explicación. advanceTimersByTimeAsync y await.

Corregir un fallo sin escribir antes la prueba que falla. Pierdes las cuatro ventajas: la demostración de que lo entendiste, el criterio de terminación, la protección contra la reaparición y la documentación del caso raro. Es el hábito que más separa a quien depura con método de quien toca cosas a ver.

Depurar un fallo intermitente sin hacerlo determinista primero. «A veces pasa» no se puede depurar. Controla el tiempo, las respuestas y la aleatoriedad hasta que pase siempre; entonces empieza a investigar.

Relanzar la CI hasta que pase. Cada vez que lo haces, tu suite pierde valor. Trata cada intermitente como un fallo real, porque suele serlo: la carrera que produce el fallo en CI existe también en producción.

Creer que axe basta. Detecta alrededor de un tercio de los problemas. Un teclado y veinte minutos con un lector de pantalla encuentran cosas que ninguna herramienta ve.

Consejo · Ejecuta las pruebas en modo vigilancia mientras programas. npm run test:watch con Jest ejecuta solo lo afectado por lo que acabas de guardar. El ciclo de retroalimentación baja de minutos a menos de un segundo, y eso cambia cómo trabajas.

Consejo · Escribe el nombre de la prueba como una frase que describa el comportamiento. 'rechaza cerrar una tarea con subtareas abiertas', no 'test cambiarEstado 3'. Cuando falle en CI dentro de tres meses, el nombre será toda la información que tengas al principio.

Consejo · Mantén una carpeta test/ayudas/ cuidada. Fábricas de entidades, montaje de la aplicación, fetch simulado, generadores de datos. Cada minuto invertido ahí se multiplica por el número de pruebas que escribirás después.

Consejo · Añade el número de pruebas y la cobertura al README. «251 pruebas · 3 recorridos E2E · 94 % de cobertura en el dominio» es una señal inmediata de seriedad para quien mire tu repositorio, y a ti te recuerda mantenerlo.

Estos ejercicios son el hito H5 de tu proyecto: la suite completa en verde en CI y el informe de accesibilidad y rendimiento.

Ejercicio 1 — La estrategia y la suite completa.

1. Escribe docs/estrategia-pruebas.md con: las tres preguntas del apartado 1 respondidas para tu proyecto, la tabla de la pirámide con tus módulos y sus números, y los umbrales de cobertura por capa con su justificación.
2. Configura Jest con proyectos separados: node para dominio y jsdom para el resto, con coverageThreshold por ruta.
3. Completa la tabla de cobertura de reglas: las 15 reglas × (caso que pasa, caso que falla, caso límite). Mínimo 45 pruebas de dominio.
4. Escribe pruebas parametrizadas con describe.each para al menos: la validación de campos, la matriz de transiciones completa y los casos de fecha (incluida la semana 53).
5. Prueba la capa de datos con fetch simulado y temporizadores falsos: códigos de estado, reintentos selectivos, tiempo agotado, cancelación y retroceso exponencial verificado con tiempos.
6. Prueba las migraciones (mínimo 9 pruebas, incluidas idempotencia, validez para el dominio y la de rendimiento) y la cola (mínimo 6, incluida la clave de idempotencia compartida entre reintentos).
7. Prueba la vista con Testing Library consultando siempre por rol o texto accesible, incluidas al menos tres pruebas de recorrido con teclado (entrada de foco, retorno de foco, sin escape).
8. Escribe exactamente tres recorridos de Cypress y justifica por escrito por qué esos tres.

Ejercicio 2 — La integración continua completa.

1. Escribe .github/workflows/ci.yml con los tres trabajos: calidad, extremo a extremo y Lighthouse, con concurrency, caché de npm, needs y subida de artefactos.
2. Configura lighthouserc.json con tu presupuesto de 11-01 traducido a aserciones, distinguiendo error de warn.
3. Activa la protección de la rama main exigiendo los tres trabajos.
4. Provoca un fallo a propósito de cada tipo y comprueba que la CI lo detecta: un error de lint, una prueba rota, una regresión de cobertura por debajo del umbral, y un aumento de tamaño del paquete por encima del presupuesto (importa una librería grande y quítala después).
5. Documenta en el README el estado de la CI con su insignia.

Ejercicio 3 — Los tres fallos, el informe y la línea base.

1. Reproduce los tres fallos de los apartados 14, 15 y 16 en tu propio proyecto. Si alguno no se da de forma natural, provócalo: quita la normalización de una migración, retrasa artificialmente un PUT, o elimina una baja de suscripción.
2. Para cada uno, documenta en docs/depuracion.md: síntoma, procedimiento de reproducción, caso mínimo, prueba que falla, hipótesis (incluidas las descartadas), causa raíz y corrección.
3. Deja las tres pruebas de regresión en la suite.
4. Ejecuta la revisión de accesibilidad completa: axe automatizado sobre las 7 pantallas (incluidos estado vacío y de error) y las 8 pruebas manuales. Escribe docs/accesibilidad.md con el formato del apartado 17.3, incluidas las limitaciones conocidas.
5. Genera datos realistas (≥ 500 tareas, ≥ 3.000 entradas de historial) y mide tu línea base con el protocolo de 09-01 sobre la compilación de producción. Escribe docs/rendimiento.md con la tabla de 9 filas comparando presupuesto, tu resultado y Nómada Tareas.
6. Ejecuta la suite completa cinco veces seguidas. Si alguna falla, encuentra y arregla la intermitente antes de dar el hito por cerrado.

Criterios de aceptación del ejercicio 1 — Suite

Rúbrica del ejercicio 1 (27 puntos)

Umbral: 19/27, con obligatoriamente ≥ 2 en «Cobertura de reglas» y en «Fiabilidad».

Criterios de aceptación del ejercicio 2 — CI

Criterios de aceptación del ejercicio 3 — Depuración e informes

Rúbrica global del hito H5 (24 puntos)

Umbral: 17/24. Y una condición adicional que no se compensa: la suite tiene que estar en verde cinco veces seguidas. Una suite intermitente no está terminada, por muchas pruebas que tenga.

Autoevaluación del hito H5:

Has convertido «funciona en mi máquina» en «funciona, y hay una máquina que lo comprueba en cada push».

Tienes una estrategia de pruebas construida sobre tres preguntas —qué no puede fallar nunca, qué cambia a menudo, y cuánto cuesta y cuánto vale cada prueba— y sobre una regla de decisión que resuelve casi todos los casos: prueba en el nivel más bajo que capte el fallo que te preocupa. Tienes la pirámide traducida a tus ficheros concretos, con unas 250 pruebas de las que solo tres son de extremo a extremo, y con una observación que es un diagnóstico gratuito: si tuvieras más pruebas de vista que de dominio, tu lógica estaría en el sitio equivocado.

Sabes usar la cobertura sin dejarte engañar por ella: dice qué no está probado, no si lo probado está bien probado. Por eso tus umbrales son por capa y justificados —95 % en dominio, 100 % en migraciones, 65 % en vista— y por eso la métrica que de verdad gobierna no es el porcentaje sino la tabla de reglas × tres casos: quince reglas, cuarenta y cinco pruebas mínimas, y ningún hueco que se pueda aprobar sin verificar nada.

Sabes probar el dominio con tablas parametrizadas que se leen como especificación, con los límites exactos donde viven los fallos —40 y 40.1, no 20—, con los casos de tipo que se cuelan por las validaciones ingenuas —'12' y NaN—, comprobando error.campo y no solo el tipo de error, y con las tres familias de casos límite que todo el mundo olvida: numéricos, de colección y temporales, incluida la semana 53 que rompe casi todas las implementaciones caseras de semana ISO.

Sabes probar la capa de datos sustituyendo solo lo lento, lo externo y lo no determinista: fetch simulado que falla ante llamadas inesperadas, temporizadores falsos con advanceTimersByTimeAsync —y no la versión síncrona, que deja las microtareas sin vaciar—, reloj fijado, y aserciones sobre el número de llamadas, que es lo que distingue una prueba de reintentos real de una que pasaría igual con el reintento roto. Con las migraciones probadas contra documentos reales, incluida la prueba de rendimiento que evita que una migración lenta arruine el LCP, y con la cola probada en lo que es imposible verificar a mano: que el reenvío usa la misma clave de idempotencia.

Sabes probar la vista como la usa una persona: por rol y por texto accesible, nunca por clase CSS, con el doble beneficio de sobrevivir a los cambios de maquetación y de verificar accesibilidad de propina. Y sabes probar el recorrido con teclado, que casi ningún proyecto tiene, cubriendo los tres fallos de foco clásicos —no entrar, no volver, escaparse—, que con <dialog> nativo pasan casi solos.

Tienes tres recorridos de extremo a extremo elegidos con un criterio explícito —los que, si se rompieran, dejarían el producto inservible—, cubriendo el ciclo de vida completo con R13 aplicada de verdad, el estado compartido en la URL con el informe, y la resiliencia sin conexión con la comprobación del duplicado. Y sabes por qué no veinte: una suite de extremo a extremo desactivada vale cero, así que el número correcto es el máximo que puedes mantener siempre en verde.

Tienes la integración continua completa y comentada línea a línea: concurrency que cancela lo obsoleto, caché de npm, npm ci en vez de install, artefactos que se suben también cuando falla —que es justo cuando los necesitas—, trabajos lentos que dependen del rápido, y la protección de rama que convierte la recomendación en garantía. Con Lighthouse CI haciendo cumplir tu presupuesto de 11-01 traducido a aserciones, tres ejecuciones por el ruido, error solo donde firmaste, y la línea de 61.440 bytes que impide que un día entre una librería de gráficos sin que nadie se entere.

Y sabes depurar tu propio proyecto con un método de seis pasos cuyo tercer paso —escribir la prueba que falla antes de corregir— es el que casi todo el mundo se salta y el que da cuatro beneficios de una vez. Lo has aplicado a tres fallos reales: la migración que corrompía datos por emparejar nombres con distinta normalización Unicode, con sus tres lecciones —emparejar por identificador, no fallar en silencio, y que el respaldo salvó la investigación—; la condición de carrera en la que un refresco en vuelo pisaba una actualización optimista, donde reproducir exigió controlar el tiempo para convertir «una de cada tres veces» en «siempre»; y la fuga de memoria de veintiuna vistas vivas retenidas por suscripciones sin baja, que no se ve pero se mide, y que se previene para siempre con una prueba unitaria de un milisegundo.

Sabes que las herramientas automáticas de accesibilidad detectan alrededor de un tercio de los problemas, y tienes las dos mitades: axe sobre las siete pantallas —incluidos el estado vacío y el de error, que nadie prueba y donde más incidencias hay— y las ocho pruebas manuales de cincuenta minutos, con el lector de pantalla y los ojos cerrados como la que más enseña. Con un informe que declara sus limitaciones, que vale más que un 100 de Lighthouse.

Tienes tu línea base medida sobre la compilación de producción, con datos realistas, comparada con Nómada Tareas fila a fila, y sabes interpretarla: ser algo más pesado con más funcionalidad es correcto, estar por debajo del presupuesto es margen y no permiso, y cada fila fuera de rango apunta a su lección del Módulo 9.

Y sabes tratar las pruebas intermitentes como lo que son: fallos reales que destruyen la confianza en la suite. Con las ocho causas y sus soluciones, el protocolo de no relanzar nunca, y la regla de higiene de cinco ejecuciones seguidas antes de cerrar un hito.

El hito H5 está cerrado. Tu proyecto funciona, está probado, se mide y se vigila solo. Le falta lo único que convierte un repositorio en un producto: que otras personas puedan usarlo. Compilar para producción sin filtrar un solo secreto, elegir dónde alojarlo, configurar caché, seguridad y HTTPS, desplegar de forma continua con posibilidad de revertir, y vigilarlo cuando ya no está en tu máquina, es Despliegue del Proyecto.