El entorno ya respira: Vitest encuentra los ficheros, jsdom da un DOM y los matchers de jest-dom están registrados. Toca escribir pruebas de verdad, y esta lección lo hace deliberadamente fuera de React. No hay ni un render en todo el texto. El motivo es doble: primero, porque las herramientas del ejecutor —describe, los ganchos, las aserciones, los dobles de prueba, los temporizadores falsos— se entienden mucho mejor sin el ruido de un árbol de componentes; y segundo, porque la parte más rentable de CicloUrbano en relación coste-beneficio es precisamente la que no necesita React. validarReserva codifica todas las reglas de negocio de las reservas. El reductor sliceReservas codifica el ciclo de vida activa → confirmada / cancelada. Los selectores derivan el catálogo visible. Las tres cosas son funciones puras, y probar una función pura es llamarla y comparar. Eso es lo que se prometió en 05-05 y en 07-04, y esta lección lo cobra.

El título dice «con Jest», y hay una razón para respetarlo: Jest es el modelo mental del ecosistema. Todo lo que aprendas aquí se escribe con Vitest, que es lo que corresponde a un proyecto Vite, pero su API es la misma, así que sirve exactamente igual en los miles de proyectos que usan Jest. Empezaremos por dejar clara esa equivalencia.

1. Qué es un ejecutor de pruebas y qué hace por ti
2. Jest y Vitest: el mismo modelo, dos implementaciones
3. Configurar Jest en un proyecto que no usa Vite
4. Anatomía de un fichero de pruebas: describe, test y los ganchos
5. Aserciones: el catálogo de matchers
6. toBe frente a toEqual: la diferencia que más errores causa
7. La suite de validarReserva, regla por regla
8. Casos límite y test.each
9. Probar el reductor sliceReservas como función pura
10. Probar los selectores
11. Dobles de prueba: espías, stubs y mocks
12. vi.fn(): comprobar que se llamó a un callback
13. vi.spyOn y vi.mock: sustituir sin romper
14. Control del tiempo: vi.useFakeTimers
15. Ejecutar, filtrar y leer la cobertura

Un ejecutor de pruebas (test runner) es un programa que automatiza todo lo que rodea a una prueba. Sin él, tendrías que escribir a mano el bucle que llama a cada función, el try/catch que captura los errores y el console.log que resume el resultado. Con él, escribes solo la parte que aporta valor.

Lo que hace un ejecutor moderno, por orden de ejecución:

Esa última columna del «informar» es la que más se nota al depurar. Cuando falla una aserción sobre objetos, un buen ejecutor no dice «no son iguales»: dice qué campo difiere.

Jest nació en Facebook y se convirtió en el estándar de facto de las pruebas en JavaScript: durante años, «probar en React» y «probar con Jest» eran la misma frase. Create React App lo traía preconfigurado, y la mayor parte de la documentación, de las respuestas de Stack Overflow y del código heredado que te encontrarás está escrita en su API.

Vitest apareció después, para proyectos construidos con Vite, y tomó una decisión de diseño muy deliberada: replicar la API de Jest. No es un dialecto parecido; es la misma API, con el mismo comportamiento, para que migrar cueste casi nada y para que todo lo que sabe el ecosistema siga sirviendo.

Por qué en CicloUrbano se usa Vitest y no Jest:

• Comparte la configuración de Vite. Los alias, los complementos, las variables de entorno y la resolución de módulos ya están definidos en vite.config.js. Con Jest habría que duplicarlo todo y mantener las dos copias sincronizadas.
• Entiende módulos ES de forma nativa. El proyecto entero usa import/export. Jest se apoya en CommonJS y necesita transformación o banderas experimentales para los módulos ES.
• Transforma con esbuild. Arranque en decenas de milisegundos frente a segundos, y modo vigilancia casi instantáneo.
• No hay una segunda cadena de compilación. Lo que se prueba se transforma igual que lo que se ejecuta en desarrollo. Se elimina toda una familia de fallos del tipo «funciona en la aplicación y no en las pruebas».

Las diferencias de verdad se reducen a tres: el prefijo vi en lugar de jest, dónde vive la configuración y cómo se transforma el código. El 95 % del contenido de un fichero de pruebas es idéntico. De hecho, con globals: true en la configuración, un fichero de pruebas escrito para Jest suele ejecutarse en Vitest sin tocar una línea.

En el proyecto se usará siempre vi. Cuando leas código con jest.fn(), sabrás que es exactamente lo mismo.

Esta es la receta para cuando te toque un proyecto con Webpack, con Create React App heredado o sin empaquetador moderno. No se usa en CicloUrbano, pero conviene saber leerla.

Fíjate en el trabajo extra que aparece y que en Vitest sencillamente no existe: un moduleNameMapper para el CSS y las imágenes, una configuración de Babel, un paquete aparte para el entorno DOM y la duplicación de los alias. Eso es exactamente lo que se ahorra al compartir la configuración de Vite, y es el argumento práctico del apartado anterior.

Con globals: true en la configuración, esa primera línea de importación es opcional. En este curso se omitirá para no repetirla en cada ejemplo.

El orden de ejecución es el que marcan los números del ejemplo, y tiene su lógica: los before van de fuera hacia dentro y los after de dentro hacia fuera, como una pila. Es decir, beforeAll exterior → beforeAll interior → beforeEach exterior → beforeEach interior → la prueba → afterEach interior → afterEach exterior → afterAll interior → afterAll exterior.

Consecuencias prácticas:

• Prefiere beforeEach a beforeAll. beforeAll crea estado compartido, que es la causa número uno de pruebas que solo fallan al ejecutar la suite completa (el problema 8.3 de la lección anterior). Solo se usa para lo que es caro y de solo lectura.
• El código dentro de un describe pero fuera de un gancho se ejecuta al cargar el fichero, no antes de cada prueba. Este es un fallo clásico:

• Los ganchos pueden ser asíncronos. Si devuelven una promesa, el ejecutor la espera. Se aprovechará en 09-04 para arrancar el servidor de MSW.

Una aserción es expect(valorObtenido).matcher(valorEsperado). Si la comprobación falla, se lanza un error con la diferencia y la prueba se marca en rojo.

Cualquier matcher se invierte anteponiendo .not:

Un aviso sobre .not, porque es una trampa recurrente: una aserción negativa demuestra menos de lo que parece. expect(errores).not.toHaveProperty('horas') pasa tanto si la validación es correcta como si validarReserva devuelve {} porque se ha roto entera. Siempre que puedas, acompaña una aserción negativa de una positiva:

Esa aserción única dice a la vez que hay error de fecha y que no hay ningún otro, que es exactamente lo que se quiere afirmar.

• toBe usa Object.is, la comparación por identidad. Para primitivos —cadenas, números, booleanos— identidad y contenido coinciden, así que expect('activa').toBe('activa') funciona. Para objetos y arrays, compara referencias.
• toEqual recorre la estructura y compara clave a clave, recursivamente.

Esta distinción no es un detalle académico: es exactamente la misma comparación por identidad que gobierna memo y useMemo en el módulo 8, y la que hace que un selector que devuelve un array nuevo repinte el componente en 07-05. La regla mnemotécnica: toBe para primitivos, toEqual para objetos y arrays.

Y una diferencia entre toEqual y toStrictEqual que conviene tener presente:

toEqual ignora las propiedades con valor undefined; toStrictEqual no, y además comprueba que ambos objetos sean de la misma clase. En CicloUrbano toEqual es lo habitual, porque un campo opcional ausente y un campo opcional a undefined son lo mismo para la aplicación. Usa toStrictEqual cuando la ausencia de una clave sea significativa.

Aquí está el caso central de la lección. Recordemos la función que se probó a escribir en 03-05: recibe datos y el catálogo de bicicletas, y devuelve un objeto con un mensaje por cada campo con error, o {} si todo es válido. Cuatro reglas: bicicleta obligatoria, existente y disponible; fecha obligatoria, válida y no anterior a ahora; horas entero entre 1 y 24; condiciones aceptadas.

Dos decisiones de diseño que valen para cualquier suite de validación:

• La fábrica datosValidos(cambios). Sin ella, cada prueba repetiría los cuatro campos y el lector tendría que compararlos visualmente para saber cuál es el que se está probando. Con ella, datosValidos({ horas: 25 }) dice por sí solo qué se comprueba. Además, si mañana el formulario añade un quinto campo, se cambia en un sitio.
• El reloj congelado en beforeEach. La regla de la fecha compara con Date.now(). Si la prueba usara el reloj real, la fecha '2026-05-04T09:00' sería válida hoy e inválida dentro de un año: una prueba con fecha de caducidad, que es un caso de libro de prueba inestable. Congelando el sistema a 2026-05-04T08:00, la prueba dará el mismo resultado dentro de una década.

Fíjate en la mezcla deliberada de matchers, porque cada uno dice algo distinto:

• toEqual({ bicicletaId: '…' }) en la primera afirma que ese es el único error. Es la aserción más fuerte y la que detectaría una regresión que hiciera fallar también la fecha.
• toBe('Eléctrica Pro no está disponible ahora mismo.') comprueba el mensaje literal, incluida la interpolación del modelo. Es correcto aquí porque ese texto lo lee el usuario y forma parte del comportamiento.
• toContain('no está disponible') es más laxo a propósito: comprueba la regla sin atarse a la redacción exacta. Úsalo cuando el texto pueda cambiar por motivos editoriales sin que cambie el comportamiento.

Esa última prueba es más valiosa de lo que parece. Verifica una decisión de diseño explícita de 03-05: la validación no corta en el primer error, porque un formulario que enseña los errores de uno en uno obliga al usuario a cuatro intentos. Si alguien refactoriza validarReserva con return tempranos, esta prueba lo caza.

Los casos límite son los valores que están justo en la frontera de una regla, y son donde vive la mayoría de los fallos reales. Para horas, la regla es «entero entre 1 y 24». Las fronteras son 0/1 y 24/25.

Escribir ocho pruebas casi idénticas es ruido. test.each recibe una tabla y genera una prueba por fila:

Cómo funciona:

• La tabla es un array de arrays. Cada fila se desestructura en los parámetros de la función de prueba.
• El nombre admite marcadores al estilo printf: %p imprime el valor tal cual (útil para distinguir '' de 'dos'), %s lo convierte a cadena, %i a entero. En el informe aparecen nueve pruebas con nombres distintos, así que un fallo señala la fila exacta.
• También existe la variante con plantillas etiquetadas, más legible cuando hay muchas columnas:

Mira la fila de 2.5. Sin ella, esta implementación alternativa de la regla pasaría todas las demás pruebas:

Con 0, 1, 24 y 25 la suite estaría verde, y sin embargo el usuario podría reservar durante dos horas y media, algo que el precio por hora y el sistema de estaciones no contemplan. Ese es el argumento de los casos límite en una frase: las pruebas de los valores «normales» confirman lo que ya sabías; las de los bordes encuentran lo que no sabías.

La lista de bordes que conviene recorrer siempre: el cero, el valor mínimo, el máximo, el máximo más uno, el negativo, el decimal cuando se espera un entero, la cadena vacía, null, undefined, y la colección vacía.

Aquí se cierra lo que quedó pendiente en 05-05 y se prometió de nuevo en 07-04: un reductor es una función pura (estado, accion) => nuevoEstado, así que probarlo es llamarlo y comparar. No hace falta React, ni un almacén, ni un componente, ni Provider.

Recuerda la forma del estado: { entidades, ids, estadoCarga, error, estadoEnvio }, normalizada.

Esa segunda prueba usa toBe a propósito, y es un buen ejemplo de cuándo la identidad sí es comportamiento observable: si el reductor devolviera una copia ante cada acción ajena, todos los useSelector suscritos a reservas repintarían con cualquier acción de la aplicación. Es el problema de 07-05 convertido en prueba.

Tres cosas que verifican estas pruebas y que no se pueden verificar mirando la pantalla:

1. La forma exacta del estado tras la acción, incluidos estadoEnvio y error, que en la interfaz solo se manifiestan indirectamente.
2. Que prepare genera el identificador con el formato acordado, res- más ocho caracteres. Por eso se espía crypto.randomUUID: sin fijarlo, el identificador sería distinto en cada ejecución y no habría nada que comparar.
3. Que no hay mutación. Aunque escribas estado.ids.push(...) dentro del reductor, Immer —que Redux Toolkit incluye— produce una copia. Esta prueba lo confirma y detectaría el día en que alguien saque esa lógica de createSlice y la mutación pase a ser real.

Las reglas más valiosas del reductor son las guardas, porque son invisibles y difíciles de provocar a mano:

Esa última prueba es exactamente el tipo de comprobación que justifica todo el módulo: reproducir a mano una doble cancelación con la latencia adecuada es tedioso y poco fiable; en código son seis líneas y se ejecuta en dos milisegundos, para siempre.

Un selector es igual de puro: (estado) => valorDerivado. La única particularidad es que los selectores del proyecto reciben el estado global, no el trozo del slice, así que hay que construirlo con la forma que define almacen.js: { reservas, catalogo, sesion }.

Un selector memorizado tiene una propiedad extra que sí merece prueba, porque es la razón de su existencia: devolver la misma referencia si las entradas no cambian. Es lo que evita los repintados de 07-05, y es exactamente lo que rompería alguien que lo sustituyera por una función normal.

Un aviso importante: como la memorización de createSelector guarda un solo resultado, si intercalas llamadas con estados distintos, la caché se invalida en cada una. Si escribes esta prueba y falla inesperadamente, comprueba que no hay una llamada con otro estado entre medias.

Un doble de prueba (test double) es cualquier objeto que sustituye a una dependencia real durante una prueba, igual que un doble sustituye al actor en una escena peligrosa. Los nombres se usan de forma laxa en el día a día, pero las distinciones son útiles:

La regla que gobierna todo esto, y que se repetirá en 09-04 con MSW:

Simula lo mínimo. Cada doble de prueba es una copia de la realidad que puede desincronizarse de ella. Una prueba llena de simulaciones acaba probando las simulaciones.

vi.fn() crea una función simulada que no hace nada, devuelve undefined y registra todas las llamadas. Es la herramienta básica para verificar los callbacks del proyecto: la convención alX de CicloUrbano —alReservar, alCambiarTipo, alCrearReserva— es precisamente lo que se comprueba con ella.

Sobre las aserciones de argumentos: cuando el argumento es un objeto, toHaveBeenCalledWith compara estructuralmente, no por identidad. Y si solo te interesa parte del objeto, existen los comparadores asimétricos:

Esto último es lo correcto para el identificador generado con crypto.randomUUID(): comprobar el formato, no el valor, evita tener que espiar la función criptográfica.

vi.spyOn(objeto, 'metodo') sustituye ese método por una función simulada que, por defecto, sigue llamando al original. El caso más habitual en pruebas de React es silenciar console.error, y aparecerá otra vez en 09-04 al probar LimiteDeError.

El vi.restoreAllMocks() en el afterEach no es opcional. Si no restauras console.error, todas las pruebas posteriores del mismo proceso quedan mudas, incluidos los avisos legítimos de React. Se puede automatizar en la configuración global:

Cuando lo que hay que sustituir es un módulo completo —porque hace peticiones, escribe en un servicio externo o depende del entorno—, se usa vi.mock:

Tres detalles que causan errores si se ignoran:

1. vi.mock se eleva al principio del fichero. Aunque lo escribas después de los import, se ejecuta antes. Por eso la fábrica no puede cerrar sobre variables externas: dentro se declaran los vi.fn() directamente. Si necesitas una referencia fuera, se usa vi.hoisted.
2. El módulo simulado sustituye a todas sus exportaciones. Si monitorizacion.js exportara diez funciones y solo declaras dos en la fábrica, las otras ocho pasan a ser undefined. Para conservar el resto, se combina con importActual:

3. vi.mock es el martillo más grande de la caja. Sustituye el módulo real por una copia que no evoluciona con él: si mañana registrarError cambia de firma, la prueba sigue pasando con la firma antigua. Por eso la regla del apartado 11. En orden de preferencia: pasar la dependencia como parámetro > vi.spyOn sobre un método concreto > vi.mock del módulo entero. Y para la red, ninguna de las tres: MSW (09-04).

El tiempo es la mayor fuente de pruebas lentas e inestables. vi.useFakeTimers() sustituye setTimeout, setInterval, clearTimeout, Date y performance.now por implementaciones controladas: el reloj solo avanza cuando tú lo mandas avanzar.

Vamos a probar el mecanismo de useDebounce a nivel de función, sin React. El hook envuelve un setTimeout que se cancela en la limpieza; la lógica es esta, y es la que hay que verificar:

La tercera prueba es la que justifica todo el useDebounce del módulo 5 y toda la optimización del buscador del módulo 8, y es la que sería casi imposible de verificar a mano: teclear seis letras en menos de 400 ms de forma reproducible no es algo que se pueda hacer con los dedos. Con temporizadores falsos, es determinista y tarda un milisegundo.

Con temporizadores falsos, si olvidas avanzar el reloj, la prueba se queda esperando para siempre. El síntoma es un tiempo de espera agotado. La prueba de useDebounce dentro de React, con renderHook, se ve en 09-04, porque requiere combinar los temporizadores falsos con act.

Vitest se queda escuchando, y al guardar un fichero reejecuta solo las pruebas afectadas por ese cambio, siguiendo el grafo de importaciones. Guardar validarReserva.js reejecuta validarReserva.test.js y FormularioReserva.test.jsx, pero no las 40 pruebas de reservas. En modo vigilancia hay teclas útiles:

Sobre test.only: es utilísimo mientras depuras y catastrófico si se te olvida, porque desactiva silenciosamente el resto del fichero y la suite sigue en verde. La protección es una regla del linter (vitest/no-focused-tests o jest/no-focused-tests) que lo convierte en error. Actívala.

test.todo es la forma correcta de anotar lo que falta: aparece en el informe como pendiente, no falla, y no miente sobre la cobertura como haría un test.skip permanente.

Cómo se lee esto sin caer en la trampa del apartado 8.1 de la lección anterior:

• La columna que más informa es % Branch. Un 100 % de sentencias con un 50 % de ramas significa que se ejecutan todas las líneas pero solo uno de los dos caminos de cada if. En monitorizacion.js, ese 50 % apunta a que la rama de producción nunca se recorre.
• Uncovered Line #s es la lista de tareas. Las líneas 47 y 63 de sliceReservas.js son, muy probablemente, dos guardas (if (!reserva) return;) que aún no se han provocado. Merecen prueba: son reglas de negocio.
• El 0 % de FormularioReserva.jsx es correcto hoy, porque los componentes se prueban en 09-03. No es una alarma: es un hueco conocido y planificado.
• El informe HTML de coverage/index.html pinta el código fuente con las líneas no cubiertas en rojo y las ramas parciales en amarillo. Es mucho más útil que la tabla para decidir qué probar.

Y la regla de siempre: el objetivo no es el número. El objetivo es que las líneas rojas de la lógica de negocio dejen de estar rojas.

• Usar toBe con objetos y arrays. El fallo número uno del principiante. expect({ a: 1 }).toBe({ a: 1 }) siempre falla. Regla: primitivos con toBe, estructuras con toEqual, e identidad deliberada con toBe solo cuando la referencia sea el comportamiento que se prueba (memorización, reductor que no debe copiar).
• Compartir estado entre pruebas con beforeAll o con una constante mutable. Produce pruebas que pasan en solitario y fallan en la suite, o al revés. beforeEach reconstruye; beforeAll solo para lo caro e inmutable.
• Olvidar vi.useRealTimers() en el afterEach. Los temporizadores falsos se quedan activos y contaminan el resto del fichero; una prueba posterior que espere de verdad se cuelga hasta agotar el tiempo. Lo mismo con vi.restoreAllMocks() y console.error.
• Dejarse un test.only en el código. Desactiva el resto del fichero en silencio y la suite se queda verde por vacío. Activa la regla del linter que lo prohíbe.
• Probar la implementación del reductor en vez de su resultado. No compruebes que estado.ids.push fue llamado; comprueba que el estado devuelto contiene el identificador nuevo. Es el principio de 09-01 aplicado a Redux.
• Simular de más. Un vi.mock de un módulo del propio proyecto suele ser señal de acoplamiento. Antes de simular, pregúntate si la dependencia puede entrar como parámetro: validarReserva(datos, bicicletas) recibe el catálogo precisamente por eso, y por eso se prueba sin ningún doble.
• Probar una función pura con más preparación de la necesaria. Si para probar el reductor construyes un almacén de Redux completo, has perdido la ventaja: llámalo directamente.
• Consejo: escribe primero la prueba que falla. Aunque no practiques desarrollo dirigido por pruebas, verificar que la prueba falla antes de escribir el código es la única manera de saber que la prueba comprueba algo. Una prueba que nunca ha estado en rojo puede estar comprobando nada.
• Consejo: cuando arregles un fallo, escribe antes la prueba que lo reproduce. Te da la confirmación de que lo has entendido y evita que vuelva. Es el mejor momento para escribir una prueba, porque el caso concreto ya lo tienes en la mano.
• Consejo: si una prueba necesita más de diez líneas de preparación, el código bajo prueba tiene demasiadas dependencias. La dificultad de probar es un indicador de diseño, no una molestia del ejecutor.

Ejercicio 1. Escribe la suite de src/utilidades/clases.js, la utilidad que compone nombres de clase ignorando los valores falsos:

Cubre al menos: varios nombres, un valor false intercalado (el caso condicion && estilos.activo), undefined y null, la llamada sin argumentos y la llamada con un solo nombre. Usa test.each donde tenga sentido y justifica por qué el resultado se compara con toBe y no con toEqual.

Ejercicio 2. El equipo añade una regla nueva a validarReserva: una bicicleta de tipo carga no se puede reservar más de 8 horas. Escribe las pruebas antes de implementarla —incluyendo los casos límite— y luego la implementación mínima que las hace pasar. Indica qué prueba de la suite existente podría fallar con el cambio y por qué.

Ejercicio 3. Esta prueba de sliceReservas pasa siempre, incluso si el reductor está roto. Explica por qué y reescríbela para que verifique lo que pretende.

Solución 1.

Se compara con toBe porque el resultado es una cadena, es decir, un primitivo: identidad y contenido coinciden, y toBe da además un mensaje de error más claro con la diferencia de texto. toEqual funcionaría igual, pero usar el matcher más específico documenta el tipo del valor devuelto.

Fíjate en la última fila: clases() sin argumentos devuelve '', no undefined ni un espacio. Es un caso límite real, porque ese valor acaba en className y un undefined ahí pintaría el atributo literalmente en algunos escenarios.

Solución 2. Primero las pruebas:

La implementación mínima, añadida tras la comprobación del máximo general:

Qué prueba existente podría fallar: ninguna de las que usan bici-001, porque es urbana. Pero sí fallaría cualquier prueba futura que reservara bici-003 durante más de 8 horas esperando el mensaje genérico de las 24. Y hay un detalle de diseño que la suite obliga a resolver: la comprobación nueva no debe sustituir al error de disponibilidad, de ahí el !errores.horas y de ahí que el caso de prueba use una bicicleta de carga disponible. Escribir la prueba primero es lo que ha hecho aflorar esa decisión antes de implementarla.

Solución 3. Por qué pasa siempre: las tres aserciones son tautológicas.

• expect(resultado).toBeTruthy() pasa con cualquier objeto, incluso con el estado sin tocar.
• expect(resultado.entidades).toBeDefined() pasa mientras el reductor devuelva algo con esa clave.
• Object.keys(resultado.entidades)).toHaveLength(1) cuenta las entidades, que no cambian al cancelar: cancelar marca, no elimina. Es decir, esa aserción pasaría igual si el reductor no hiciera absolutamente nada.

Ninguna de las tres mira estado, que es lo único que la acción debería cambiar. Además, el nombre («la cancelación funciona») no dice qué comportamiento se verifica.

Reescrita:

Ahora cada prueba afirma un comportamiento concreto y verificable, y cualquiera de ellas se pondría en rojo si el reductor dejara de hacer su trabajo. La segunda, además, documenta una decisión de diseño —cancelar no borra— que de otro modo solo estaría en la cabeza de quien lo escribió.

Esta lección ha construido la base del módulo sin tocar React, y ha demostrado por qué esa parte es la más rentable: validarReserva, el reductor sliceReservas y los selectores concentran todas las reglas de negocio de CicloUrbano, y probarlos es llamarlos y comparar.

Lo esencial. Un ejecutor de pruebas descubre, transforma, aísla, paraleliza, informa, vigila y mide. Jest es el modelo mental del ecosistema y Vitest implementa la misma API; las únicas diferencias reales son el prefijo vi en lugar de jest, dónde vive la configuración y cómo se transforma el código, así que lo aprendido aquí sirve en ambos —y tienes la receta de jest.config.js con su moduleNameMapper, su Babel y su jest-environment-jsdom para el día en que te toque un proyecto sin Vite. La anatomía de un fichero es describe, test/it y cuatro ganchos cuyo orden es una pila: los before de fuera hacia dentro, los after de dentro hacia fuera; y la regla derivada de eso es preferir beforeEach a beforeAll, porque el estado compartido es la causa número uno de pruebas que solo fallan en la suite completa.

Del catálogo de matchers, la distinción que más errores causa es toBe frente a toEqual: identidad contra estructura, la misma comparación que gobierna memo en el módulo 8 y los selectores en el 7. Primitivos con toBe, objetos con toEqual, toStrictEqual cuando la ausencia de una clave sea significativa, y .not siempre acompañado de una aserción positiva que lo sujete —porque toEqual({ fechaInicio: '…' }) afirma a la vez que hay ese error y que no hay ningún otro.

La suite de validarReserva ha establecido dos patrones reutilizables: la fábrica datosValidos(cambios), que hace evidente qué campo se está estropeando en cada prueba, y el reloj congelado con vi.setSystemTime, sin el cual la regla de la fecha caducaría. Y test.each ha convertido nueve casos límite de horas en una tabla legible, con la lección de fondo: el caso decimal 2.5 es el que atrapa una implementación que 0, 1, 24 y 25 dejarían pasar. Las pruebas de los valores normales confirman lo que ya sabías; las de los bordes encuentran lo que no.

El reductor ha cerrado lo prometido en 05-05 y 07-04. Se prueba llamándolo directamente —sin almacén, sin Provider, sin componentes—, encadenando el estado de una llamada a la siguiente para recorrer el ciclo activa → confirmada / cancelada, y verificando lo que la pantalla no muestra: las guardas de negocio, la ausencia de mutación y —con toBe— que devuelve la misma referencia ante acciones ajenas, que es lo que evita repintar la aplicación entera. Los selectores se prueban igual, construyendo el estado global con la forma de almacen.js, y los memorizados con createSelector tienen una prueba propia y necesaria: que devuelven la misma referencia si las entradas no cambian.

Sobre los dobles de prueba, ya distingues espía, stub, mock y fake, y dominas las tres herramientas: vi.fn() para verificar los callbacks alX del proyecto con toHaveBeenCalledWith y los comparadores asimétricos como expect.objectContaining; vi.spyOn para envolver console.error sin ensuciar la salida, siempre con su restoreAllMocks; y vi.mock para sustituir un módulo entero, con sus tres trampas —la elevación, la sustitución total de las exportaciones y el desacople silencioso frente al módulo real—. De ahí la jerarquía: parámetro > spyOn > mock, y para la red ninguna de las tres. Los temporizadores falsos han convertido en determinista lo que era imposible de reproducir a mano: seis pulsaciones en 500 ms que deben producir una sola llamada con 'urbana'. Y sabes ejecutar en vigilancia, filtrar con test.only/test.skip/test.todo —con la regla del linter que impide olvidarse un only— y leer un informe de cobertura mirando la columna de ramas y las líneas sin cubrir de la lógica de negocio.

Queda la mitad visible. Las reglas están probadas, pero nadie ha comprobado todavía que el usuario vea el mensaje «La reserva máxima es de 24 horas» junto al campo correcto, ni que el botón «Reservar» esté deshabilitado para una bicicleta en mantenimiento, ni que pulsar un filtro avise al padre con el tipo elegido. Ese es el terreno de la próxima lección, y donde el trofeo de pruebas pone su mayor peso: componentes de verdad, montados en jsdom, consultados como los consultaría una persona —por rol, por etiqueta, por texto accesible— e interactuados con userEvent. Ahí verás por qué toda la accesibilidad del módulo 3 era, sin decirlo, la preparación para esto. La próxima lección es Pruebas de Componentes con React Testing Library.