El mòdul anterior va acabar amb una confessió incòmoda: nou refactoritzacions sobre codi que funcionava —la signatura de LlistaBicicletes, l'estat mogut de lloc, el value de dos proveïdors de context reescrit, les rutes partides en nou fragments, una capa de càrrega mandrosa amb els seus fallats de xarxa— i una única comprovació en totes elles: obrir el navegador i mirar. Va funcionar perquè el projecte és petit i perquè la persona que tocava el codi recordava què calia mirar. Cap d'aquestes dues condicions sobreviu al creixement. Aquest mòdul construeix el que faltava: una xarxa de seguretat automàtica que s'executa en segons, que comprova el que un humà no pot recordar i que falla quan el comportament canvia. Aquesta primera lliçó encara no escriu proves de l'aplicació: estableix el criteri. Què és una prova, quins tipus n'hi ha, quins compensen en una interfície de React, què val la pena provar de CicloUrbano i què no, quines són les mètriques que enganyen, i com es deixa l'entorn a punt perquè les quatre lliçons següents escriguin codi de prova des de la primera línia.

1. El cost real de refactoritzar sense proves
2. Què és una prova automatitzada: preparar, actuar, comprovar
3. Les tres coses que aporta una prova
4. Tipus de prova: estàtica, unitària, d'integració i d'extrem a extrem
5. La piràmide de proves enfront del trofeu de proves
6. El principi rector del mòdul: comportament, no implementació
7. Què val la pena provar a CicloUrbano i què no
8. Falsos amics: cobertura, proves fràgils i proves inestables
9. Com s'anomena una prova
10. Posada en marxa de l'entorn: Vitest, jsdom i Testing Library
11. La primera prova: verificar que l'entorn respira
12. L'estratègia del Mòdul 9

Recupera el tancament del mòdul 8 i pensa en el que va passar realment a cadascuna d'aquelles nou refactoritzacions. A cadascuna hi va haver un moment, després de desar el fitxer, en què l'estat del projecte era desconegut. Es va resoldre mirant la pantalla. Mirar la pantalla comprova, com a molt, el que hi ha en pantalla en aquell instant: el catàleg amb les cinc bicicletes i el filtre per tipus. No comprova el que hi havia a l'altra pestanya, ni el cas de la reserva amb zero hores, ni què passa quan json-server retorna un 500, ni si el botó «Reservar» continua deshabilitat per a bici-003, que és en manteniment.

Això es pot formular amb precisió. En tocar codi, la pregunta és sempre la mateixa:

Quins comportaments podria haver trencat aquest canvi, i com sé que no els he trencat?

Sense proves, la resposta a la segona meitat és «no ho sé», i l'equip la substitueix per dues estratègies, totes dues dolentes:

• No tocar el codi. El fitxer que ningú s'atreveix a modificar acaba sent el que més ho necessita. El deute tècnic no és el codi dolent: és el codi dolent que no es pot canviar.
• Tocar-lo i esperar. El fallat arriba a l'usuari, que ho explica dies després, quan ja ningú recorda el canvi que ho va causar.

Una prova automatitzada converteix «no ho sé» en «ho comprovo en quatre segons». Aquesta és la diferència, i és una diferència de grau tan gran que canvia com s'escriu el codi: amb xarxa, es refactoritza sovint i en passos petits; sense xarxa, s'acumula i es reescriu de cop.

L'eix horitzontal d'aquest diagrama és temps, i és on és l'estalvi: el cost d'arreglar una fallada creix amb la distància entre el moment en què s'introdueix i el moment en què es detecta.

Una prova automatitzada és, sense cap màgia, una funció que executa codi de l'aplicació i llança un error si el resultat no és l'esperat. Res més. L'executor de proves s'encarrega de trobar aquestes funcions, cridar-les, capturar els errors i presentar un informe.

Tota prova, sigui del tipus que sigui, té tres parts. A la literatura anglosaxona es coneixen com Arrange, Act, Assert (AAA); en aquest curs les anomenarem preparar, actuar i comprovar.

Tres regles que surten directament d'aquesta estructura i que convé interioritzar abans d'escriure res:

• Una prova, una acció. Si al bloc d'actuar hi ha tres coses, quan la prova falli no sabràs quina de les tres l'ha trencat. Divideix.
• La preparació ha de ser explícita i local. Una dada que ve d'un altre fitxer, d'una prova anterior o d'un estat compartit converteix la fallada en un misteri. Cada prova construeix el seu escenari.
• Comprovar el resultat, no els passos. La prova de dalt no comprova que s'hagi cridat bicicletes.find; comprova què retorna la funció. Això és el principi de l'apartat 6, en miniatura.

Val la pena separar els tres beneficis, perquè cadascun justifica un tipus de prova diferent i explica decisions que es prenen més endavant.

És el benefici principal i el que motiva aquest mòdul. Una refactorització, per definició, canvia la implementació sense canviar el comportament. Si tens una bateria de proves que descriu el comportament i no la implementació, refactoritzar es converteix en un procediment mecànic: canvies el codi, executes les proves, i si totes passen, la refactorització és correcta.

Aplicat al que ja vas fer: si LlistaBicicletes hagués tingut una prova que digués «donades cinc bicicletes, pinta cinc targetes, i en prémer “Reservar” a la primera avisa amb bici-001», el canvi de signatura i la introducció d'useCallback haurien quedat verificats a l'acte. I si el memo hagués deixat de propagar un camp, la prova hauria fallat.

La contrapartida és a la lletra petita: només funciona si la prova no depèn de la implementació. Una prova que comprova noms d'estat intern o nombre de renders es trenca amb cada refactorització, i llavors la xarxa de seguretat es converteix en un llast. D'aquí ve la insistència de l'apartat 6.

Un fitxer de proves ben escrit respon a la pregunta «què fa exactament, això?» millor que qualsevol comentari, per una raó senzilla: els comentaris menteixen amb el temps i les proves no, perquè si menteixen, fallen.

Aquesta sortida és l'especificació de les regles de negoci de les reserves de CicloUrbano, generada pel propi codi. Qui entri nou a l'equip la llegeix en trenta segons.

Una regressió és un comportament que funcionava i ha deixat de funcionar. És el tipus de fallada més car, perquè ningú el busca: es descobreix per accident, normalment en producció i normalment a la part de l'aplicació en què ningú estava treballant.

Les proves inverteixen aquesta dinàmica: cada comportament que es prova una vegada queda vigilat per sempre, sense cost marginal. És l'única manera que una aplicació pugui créixer sense que la superfície de risc creixi amb ella.

No totes les proves costen ni aporten el mateix. Aquesta taula és el mapa del mòdul sencer, i convé tornar-hi en començar cada lliçó.

Algunes precisions que solen faltar:

• Les proves estàtiques són proves. ESLint amb eslint-plugin-react-hooks detecta avui una família sencera de fallades que el 2018 requerien proves: un useEffect amb dependències incompletes, un hook dins d'un if. Configurar-lo bé és la inversió més rendible del projecte, i és requisit previ, no alternativa.
• La frontera entre unitària i integració és difusa, i no importa. Quan es prova TargetaBicicleta, que renderitza EtiquetaEstat a dins, és unitària o d'integració? És d'integració, i és el correcte. Discutir l'etiqueta és temps perdut; el que importa és el criteri de l'apartat següent.
• La confiança no és proporcional al nombre de proves, sinó al seu tipus. Mil proves unitàries de funcions auxiliars no garanteixen que l'aplicació arrenqui. Una prova e2e que reserva una bicicleta sí.

Durant dues dècades, el model dominant va ser la piràmide de proves (Mike Cohn, 2009): moltes unitàries a la base, algunes d'integració al mig, molt poques d'extrem a extrem al cim. La justificació era econòmica: les unitàries eren barates i ràpides; les d'integració, lentes i fràgils.

Kent C. Dodds va proposar el trofeu de proves per al front-end actual, i el canvi de forma respon a tres fets concrets:

1. Les proves d'integració han deixat de ser cares. jsdom munta un DOM complet en memòria en mil·lisegons, i Testing Library permet interactuar-hi com ho faria una persona. El que el 2010 requeria aixecar un navegador avui costa 50 ms.
2. L'anàlisi estàtica ha absorbit bona part del que provaven les unitàries. Un tipus mal passat o un hook mal cridat ja no necessiten prova: el linter i el compilador de tipus els atrapen abans.
3. En una interfície, gairebé totes les fallades reals són al cablejat, no a les unitats. El component funciona, el reductor funciona, el hook funciona… i la pantalla és buida perquè el selector retorna undefined. Les proves unitàries de cada peça passen les tres. La prova d'integració falla, que és el que es vol.

D'aquí surt la regla operativa d'aquest mòdul, i la que s'aplicarà a CicloUrbano:

El pes cau en les proves d'integració de components. Les unitàries es reserven per a la lògica pura amb casos límit —validacions, reductors, selectors, utilitats— i les d'extrem a extrem per a tres o quatre fluxos crítics de negoci.

Si d'aquest mòdul només t'enduus una idea, que sigui aquesta:

Prova el que l'usuari veu i fa, no com ho has escrit per dins.

La manera pràctica de saber si una prova respecta el principi és la prova de la refactorització: si pots reescriure l'interior del component sense canviar res del que l'usuari percep, i la prova falla, la prova està malament.

Mira-ho amb dues versions de la mateixa comprovació sobre SelectorTipus. Aquí només interessa el contrast; la mecànica de render i screen és matèria de 09-03.

Ara aplica un canvi perfectament legítim: renombrar tipusTriat a tipusActiu, o substituir l'useState per un useReducer, o —com va passar de debò al mòdul 7— pujar aquest estat a Redux i passar el tipus per props.

Aquesta última fila és la més eloqüent: la prova acoblada a la implementació no només es trenca quan no ha de fer-ho, sinó que deixa passar la fallada que sí que importa. Falla quan no toca i calla quan toca. És pitjor que no tenir prova, perquè a més consumeix temps de manteniment.

La llista de coses que no es proven mai, i que es repetirà a 09-03 amb exemples:

• L'estat intern d'un component i el nom de les seves variables.
• Els noms de les classes de CSS (estils.actiu és un hash generat per CSS Modules).
• Quantes vegades s'ha renderitzat un component (per a això hi ha el Profiler de 08-05, que és una eina de diagnòstic, no de verificació).
• Que s'hagi cridat un hook concret o un mètode concret d'una biblioteca.
• Mètodes privats i funcions no exportades: si mereixen prova, és que mereixen ser exportades.

Provar-ho tot és impossible i provar a l'atzar és inútil. El criteri que funciona combina dos eixos: quant fa mal si es trenca i quant costa la prova. Aplicat al codi que ja existeix al projecte:

Dos criteris més per desempatar quan dubtis:

• Ha fallat mai? Cada fallada real que arriba a producció mereix una prova que la reprodueixi abans d'arreglar-la. Aquesta prova és la que garanteix que no torni.
• És al camí dels diners? A CicloUrbano, crear una reserva és el camí dels diners. Canviar el tema a fosc no ho és. El pressupost de proves es reparteix en conseqüència.

La cobertura de codi (code coverage) mesura quin percentatge del codi s'ha executat durant les proves, normalment desglossat en quatre dimensions:

Per al que serveix de debò: per trobar el que no has provat. Obres l'informe, veus que la branca de l'error 500 de PaginaCataleg és en vermell, i decideixes si mereix una prova. Aquest ús és excel·lent.

Per al que no serveix: com a objectiu. Aquesta prova dona un 100 % de cobertura de validarReserva i no comprova absolutament res:

Executa la funció, recorre línies… i no té ni una sola asserció. La cobertura mesura execució, no verificació. Per això el 100 % no és l'objectiu: perseguir-lo empeny a escriure proves de farciment per a embolcalls trivials i a provar codi que no ho mereix, i el temps surt del pressupost de les proves que sí que importen. Un rang raonable en un projecte sa és entre el 70 % i el 85 %, amb una condició: que aquest percentatge inclogui la lògica de negoci. Un 90 % que deixa validarReserva sense cobrir val menys que un 60 % que la cobreix sencera.

Una prova fràgil (brittle) és la que falla davant canvis que no trenquen res. És exactament la de l'apartat 6, i les seves causes habituals són sempre les mateixes:

• Assercions sobre detalls interns (estat, classes CSS, estructura exacta del DOM).
• Selectors acoblats a la maquetació: «el tercer <div> dins de la segona <section>».
• Textos complets i literals amb puntuació inclosa, que es trenquen en corregir un accent.
• Dependència de l'ordre entre proves: la prova B només passa si abans s'ha executat l'A.

El símptoma reconeixible: a cada pull request cal «arreglar les proves». Quan això passa, l'equip deixa de creure's les fallades, i una prova en què ningú creu ja no protegeix res.

Una prova inestable és la que passa o falla amb el mateix codi, sense canviar res. És el pitjor dels mals, perquè destrueix l'única propietat que fa útil una suite: que una fallada signifiqui alguna cosa.

I la regla més important sobre elles: una prova inestable no es reintenta, s'arregla o s'esborra. Marcar-la com «reintentar tres vegades» amaga una fallada real d'aïllament que, tard o d'hora, serà una fallada de l'aplicació.

El nom d'una prova és l'única cosa que es veu quan falla en un registre d'integració contínua a les tres de la matinada. Ha de bastar per entendre què s'ha trencat, sense obrir el fitxer.

La fórmula que millor funciona descriu el comportament esperat, no el mecanisme:

<subjecte> + què fa + en quina circumstància

Convencions del projecte, perquè les cinc lliçons siguin coherents:

• Els noms van en català, com tots els textos del projecte; describe, test i expect no es tradueixen, són API.
• Els describe agrupen per subjecte: el nom del mòdul o del component, tal qual (describe('validarReserva', …), describe('TargetaBicicleta', …)).
• Res de «hauria de»: test('rebutja…') en present d'indicatiu. És més curt i es llegeix millor a l'informe.
• Un describe imbricat quan comparteixen circumstància: describe('quan la bicicleta és en manteniment', …).

CicloUrbano es construeix amb Vite, i l'executor de proves natural per a un projecte Vite és Vitest: comparteix la mateixa configuració, el mateix sistema de resolució de mòduls i les mateixes transformacions, així que no hi ha una segona cadena de compilació a mantenir. I —això importa per a la lliçó següent— implementa la mateixa API que Jest, l'estàndard de l'ecosistema.

Tot va a devDependencies (-D): no forma part del paquet que es desplega.

Apartat per apartat:

1. environment: 'jsdom' és el que permet que render(<TargetaBicicleta />) tingui un document on pintar. Sense això, l'entorn per defecte és node i qualsevol accés al DOM llança document is not defined. Per provar només funcions pures, node és més ràpid; es pot fixar per fitxer amb un comentari // @vitest-environment node.
2. globals: true fa que describe, test, expect, beforeEach i vi estiguin disponibles sense importar-los. És el que dona compatibilitat de codi amb Jest i el que permet que @testing-library/jest-dom s'hi enganxi. Sense aquesta opció cal importar tot de vitest a cada fitxer.
3. setupFiles apunta al fitxer de preparació comú, que és l'apartat següent. Allà es registren els matchers i, a 09-04, s'arrencarà el servidor simulat de MSW.
4. coverage exclou el que no té sentit mesurar: les pròpies utilitats de prova, el punt d'entrada main.jsx (que només crida createRoot) i els fitxers .test.

La importació és @testing-library/jest-dom/vitest, amb el sufix: aquesta variant crida expect.extend de l'expect de Vitest. Si importes @testing-library/jest-dom a seques a Vitest, els matchers poden no registrar-se i toBeInTheDocument apareixerà com «no és una funció».

localStorage.clear() a l'afterEach no és decoració: useMagatzemLocal i ProveidorTema hi escriuen, i sense neteja una prova heretaria el tema fosc que va deixar l'anterior. És prevenció directa del punt 8.3.

Els fitxers de prova es col·loquen al costat del codi que proven, i les utilitats compartides en una carpeta pròpia:

Col·locar la prova al costat del codi, i no en un __tests__ llunyà, té tres avantatges mesurables: es veu d'una ullada què està provat i què no, la ruta d'importació és './TargetaBicicleta.jsx' en lloc de '../../components/TargetaBicicleta.jsx', i en moure o esborrar un component la prova viatja o desapareix amb ell.

test:ui requereix npm install -D @vitest/ui, i la cobertura requereix npm install -D @vitest/coverage-v8. Vitest ho demana per consola la primera vegada que executes l'script.

Abans d'escriure una sola prova de l'aplicació, convé confirmar que la canonada funciona. Aquesta prova no comprova CicloUrbano: comprova Vitest, jsdom i els matchers.

Què verifica cadascuna:

• La primera comprova que Vitest troba el fitxer, l'executa i avalua una asserció. Si aquesta falla, el problema és a la configuració, no al teu codi.
• La segona comprova dues coses alhora: que environment: 'jsdom' és actiu, perquè existeix document; i que els matchers de jest-dom s'han registrat, perquè toBeInTheDocument i toHaveTextContent no són de Vitest, vénen del fitxer de preparació.

Amb aquesta sortida en pantalla, l'entorn és a punt. Aquesta prova es pot esborrar després —no aporta res a llarg termini—, però és un bon primer pas, perquè separa «la meva prova està malament» de «la meva configuració està malament», que són dos problemes molt diferents i es depuren de maneres molt diferents.

Aquest és el pla, i respon punt per punt al buit que va deixar el mòdul 8:

I al mòdul 11, la lliçó 11-04 aplicarà tot això al projecte final. Aquí s'aprèn la tècnica; allà s'executa sobre una aplicació completa.

• Escriure proves per pujar la cobertura. És l'error que més temps consumeix i menys aporta. La cobertura és un mapa per trobar forats, no una nota. Un 72 % amb la lògica de negoci coberta val més que un 95 % ple de proves d'embolcalls.
• Provar l'estat intern «perquè és més fàcil». Sol ser-ho, i és exactament la raó per la qual cal resistir-s'hi: una prova fàcil que es trenca a cada refactorització té cost negatiu. Si provar el comportament costa molt, gairebé sempre vol dir que el component fa massa coses; el senyal és útil.
• Començar per les proves d'extrem a extrem. Són les que donen més confiança i les més cares. Començar per aquí produeix una suite lenta i inestable que l'equip acaba desactivant. Es comença per allò pur i per la integració de components; e2e al final i només per als fluxos crítics.
• Confondre «no té proves» amb «cal provar-ho tot ja». En un projecte existent, l'estratègia que funciona és: prova cada fallada abans d'arreglar-la, prova cada funcionalitat nova, i prova les zones que toques. La cobertura creix per on es mou el projecte, que és on fa falta.
• Deixar proves comentades o amb test.skip permanent. Una prova desactivada és una mentida emmagatzemada: sembla que hi ha xarxa on no n'hi ha. S'arregla o s'esborra; l'historial de Git guarda el que es va esborrar.
• No executar les proves en integració contínua. Una suite que només s'executa quan algú se'n recorda no protegeix res. A 09-05 veuràs el flux de treball mínim de GitHub Actions que les llança a cada canvi.
• Consell: instal·la primer, escriu després. Deixa l'entorn de l'apartat 10 funcionant amb la prova trivial de l'11 abans d'intentar provar res real. Depurar una configuració i una prova alhora multiplica el temps per tres.
• Consell: quan una prova falli, llegeix-la com si fos un informe de fallada. Si el nom i el missatge no et diuen què s'ha trencat, el problema és la prova. Millora-la en aquell moment, quan tens el context al cap.

Exercici 1. Classifica cadascun d'aquests comportaments de CicloUrbano segons el tipus de prova que li correspon (estàtica, unitària, d'integració o d'extrem a extrem) i justifica per què no li correspon el nivell immediatament inferior:

a) validarReserva rebutja una reserva de 25 hores. b) FormulariReserva mostra el missatge «La reserva màxima és de 24 hores» al costat del camp de durada quan s'escriu 25 i s'envia. c) Ana Ribera entra a /acceso, reserva bici-001 i veu la reserva a /reservas. d) useEffect a CercadorBicicletes declara alBuscar a les seves dependències. e) seleccionarBicicletesVisibles retorna les bicicletes urbanes ordenades per preu quan l'estat té tipus: 'urbana' i ordre: 'preu'.

Exercici 2. Un company presenta aquesta prova de TargetaBicicleta i afirma que dona confiança perquè cobreix el 100 % del component. Identifica quatre problemes diferents i reescriu l'enunciat de les proves que la substituirien (només els noms, no la implementació).

Exercici 3. L'equip de CicloUrbano té una prova que falla aproximadament una de cada deu execucions en integració contínua i sempre passa en local. Comprova que, després de crear una reserva, apareix l'avís «Reserva creada». Un membre de l'equip proposa embolcallar-la en retry(3). Explica per què és mala idea, enumera tres causes possibles de la inestabilitat donades les eines del projecte, i descriu què comprovaries primer i per què.

Solució 1.

Solució 2. Els quatre problemes:

1. El nom no descriu res. test('TargetaBicicleta') no diu quin comportament es verifica, així que la seva fallada en integració contínua no informa. I el describe hauria de dur aquest nom, no el test.
2. Asserció sobre una classe de CSS Modules. .targeta_a3f9x és un identificador generat: canvia a cada compilació i amb cada versió de Vite. A més, que existeixi un div amb aquesta classe no és un comportament que l'usuari percebi.
3. Comptar botons amb querySelectorAll. Es comprova l'estructura del DOM, no la funció. Si s'afegeix un tercer botó legítim, la prova falla sense que res estigui trencat; i si el botó «Reservar» deixa d'estar deshabilitat en manteniment —la fallada real que importa—, la prova continua passant.
4. Diverses comprovacions inconnexes en una sola prova i sense screen. S'usen container.querySelector i innerHTML en lloc de les consultes accessibles, i en fallar només se sap que «TargetaBicicleta» falla, no quina de les tres coses.

Els enunciats que la substitueixen:

Solució 3. Per què retry(3) és mala idea: no arregla res, amaga el símptoma i, sobretot, desactiva el senyal. Si la prova falla una de cada deu vegades per una condició de cursa real, aquesta mateixa condició de cursa afecta els usuaris; tapar-la amb reintents converteix una fallada de producció detectada en una fallada de producció invisible. A més contamina el criteri de l'equip: així que s'accepta que «de vegades fallen», ningú torna a mirar una fallada vermella.

Tres causes possibles amb les eines del projecte:

1. Espera per temps en lloc de per resultat. Si la prova usa un retard fix després d'enviar el formulari, a la màquina més lenta d'integració contínua la mutació encara no ha resolt quan es comprova l'avís. Es corregeix esperant l'avís amb findByText, que reintenta fins que apareix (09-04).
2. Estat compartit entre proves. Un QueryClient reutilitzat entre fitxers deixa en memòria cau la llista de reserves d'una prova anterior; segons l'ordre d'execució, la llista ja conté la reserva i l'avís mai es dispara. Es corregeix creant un client nou per prova amb retry: false.
3. La xarxa no està interceptada. Si la prova arriba a json-server de debò, depèn que el procés estigui aixecat, de la seva latència i que db.json no hagi estat modificat per una altra prova. Es corregeix amb MSW.

Què comprovaria primer: executar el fitxer en solitari i després dins de la suite completa. És el diagnòstic més barat i separa d'un cop les dues famílies de causes. Si passa en solitari i falla a la suite, el problema és d'aïllament (causes 2 i 3). Si falla en tots dos casos de forma intermitent, el problema és d'espera (causa 1). Sense aquesta bifurcació, qualsevol correcció és a cegues.

Aquesta lliçó ha posat el criteri abans que l'eina, que és l'ordre correcte: sense criteri, una bateria de proves es converteix en un llast que cal «arreglar» a cada pull request.

L'essencial que t'enduus. Una prova automatitzada no és més que una funció amb tres parts —preparar, actuar i comprovar— i aporta tres coses diferents: permet refactoritzar sense por (el buit exacte que van deixar les nou refactoritzacions del mòdul 8), serveix de documentació executable que no pot mentir sense fallar, i detecta regressions abans que les compti un usuari. Hi ha quatre nivells —estàtica, unitària, d'integració i d'extrem a extrem— i cadascun detecta fallades que els altres no veuen: el linter atrapa el hook mal declarat, la unitària el cas límit de 25 hores, la d'integració el cablejat trencat entre peces que funcionen per separat, i la e2e el CSS que tapa el botó de reservar. El repartiment de pes ja no és la piràmide clàssica sinó el trofeu: en front-end modern la majoria de les proves són d'integració, perquè jsdom les ha abaratit, perquè l'anàlisi estàtica ha absorbit bona part de les unitàries i perquè és allà on són les fallades de debò.

Per damunt de tot queda el principi rector del mòdul: es prova el comportament visible, no la implementació. La prova que afirma sobre tipusTriat falla en renombrar una variable i calla quan el component deixa d'avisar el pare —falla quan no toca i calla quan toca—; la que afirma que alCanviarTipus rep 'electrica' sobreviu a useState, a useReducer i a pujar l'estat a Redux, i es trenca només si es trenca alguna cosa. D'aquí surt la llista del que no es prova mai: estat intern, classes de CSS Modules, nombre de renders i detalls de biblioteques de tercers. I el repartiment per a CicloUrbano: a fons les utilitats pures, els reductors i els selectors; amb integració els components i el formulari; amb MSW les pàgines amb dades; amb Cypress només tres fluxos crítics; i res per als estils, les constants i el codi de tercers.

Coneixes també els falsos amics. La cobertura és un mapa per trobar forats, no un objectiu: mesura execució, no verificació, i una prova sense una sola asserció pot donar el 100 %. Les proves fràgils fallen davant canvis innocus i acaben amb la credibilitat de la suite. Les inestables són pitjors, perquè destrueixen el significat del color vermell, i no es reintenten: s'arreglen o s'esborren. I saps anomenar una prova perquè la seva fallada s'entengui sola, amb la fórmula subjecte + què fa + en quina circumstància.

Finalment, l'entorn és muntat i verificat: Vitest amb environment: 'jsdom', globals: true i setupFiles: './src/proves/configuracio.js'; els matchers de @testing-library/jest-dom/vitest registrats; localStorage net entre proves; els fitxers .test.jsx al costat del codi i les utilitats compartides a src/proves/; i els scripts npm test, npm run test:ui i npm run cobertura. La prova trivial d'entorn.test.js confirma en 400 ms que la canonada sencera funciona, que és el que separa «la meva prova està malament» de «la meva configuració està malament».

Amb el criteri fixat i l'entorn respirant, toca escriure proves de debò. La propera lliçó es queda deliberadament fora de React: l'executor per dins, l'anatomia d'un fitxer de proves amb describe i els seus ganxos, el catàleg d'assercions —començant per la diferència entre toBe i toEqual, que causa més confusió que cap altra—, els dobles de prova amb vi.fn() i vi.mock, i el control del temps amb temporitzadors falsos. Tot això aplicat a validarReserva i al reductor sliceReserves, tancant per fi el que es va prometre a 05-05 i 07-04: que un reductor pur es prova cridant-lo. I com que l'índex mana, es farà des del model de Jest, amb la taula d'equivalències que et permetrà endur-te el que has après a qualsevol projecte. La propera lliçó és Proves Unitàries amb Jest.