A la lliçó anterior va quedar provat que validarReserva rebutja 25 hores i que el reductor sliceReserves marca una reserva com a cancel·lada sense esborrar-la. Res d'això garanteix que un usuari de CicloUrbano vegi el missatge d'error al costat del camp de durada, ni que el botó «Reservar» estigui deshabilitat per a una bicicleta en manteniment, ni que prémer el filtre «Elèctrica» avisi el pare. Aquesta meitat —la visible, la que l'usuari toca— és la que cobreix aquesta lliçó, i és on el trofeu de proves posa el seu pes més gran.

L'eina és React Testing Library, i el seu valor no és al codi que estalvia sinó en la disciplina que imposa: obliga a cercar els elements com els cercaria una persona —pel seu rol, per la seva etiqueta, pel seu text— en lloc de per classes CSS o estructura del DOM. Això té una conseqüència que cal anunciar d'entrada: tota l'accessibilitat del mòdul 3 era, sense dir-ho, la preparació per a això. Els label htmlFor, els rols, els noms accessibles, l'aria-describedby que associa l'error al seu camp, el role="alert" dels missatges… tot això, que allà es va justificar pels lectors de pantalla, és exactament el mateix mecanisme que Testing Library usa per trobar coses. Un component accessible és un component fàcil de provar, i un d'inaccessible és gairebé impossible de provar bé. No és una coincidència: és el mateix principi dues vegades.

1. La filosofia de Testing Library
2. jsdom: què et dona i què no
3. render i screen, i la neteja entre proves
4. Les tres famílies de consultes: getBy, queryBy, findBy
5. La prioritat de consultes i per què getByRole va primer
6. Depurar una consulta que falla
7. Interacció: userEvent enfront de fireEvent
8. Les assercions de jest-dom
9. EtiquetaEstat: un component de presentació
10. TargetaBicicleta: props, callbacks i estats
11. SelectorTipus: provar un component controlat
12. FormulariReserva: el cas complet
13. La utilitat renderitzar amb els proveïdors reals
14. Components que depenen de la ruta
15. Què no cal provar mai

Testing Library es resumeix en una frase del seu autor, Kent C. Dodds, que convé tenir present en escriure cada consulta:

Com més s'assemblin les teves proves a la manera en què s'usa el teu programari, més confiança et poden donar.

D'aquí surt tota la resta. Un usuari de CicloUrbano no sap que existeix una classe .targeta_a3f9x, ni que l'estat intern es diu tipusEscollit, ni que el segon fill del tercer div conté el preu. El que un usuari percep és: hi ha un botó que diu «Reservar», hi ha un camp etiquetat «Durada (hores)», hi ha un text que diu «En manteniment». I el que un usuari fa és: prémer, escriure, tabular.

Per això la biblioteca no ofereix cap manera d'accedir a l'estat, a les props o als mètodes interns d'un component. No és una mancança: és la característica principal. La versió anterior de l'eina estàndard, Enzyme, sí que ho permetia (wrapper.state(), wrapper.instance(), wrapper.find(MeuComponent)), i el resultat van ser milions de proves fràgils que es trencaven amb cada refactorització. Testing Library va eliminar la temptació traient-ne la possibilitat.

El que sí que ofereix:

Aquest «no hi ha renderitzat superficial» mereix una nota. A Enzyme era habitual renderitzar un component sense els seus fills, substituint-los per marcadors. Testing Library renderitza sempre l'arbre complet, i és el correcte: si TargetaBicicleta pinta EtiquetaEstat a dins, el que importa és que l'usuari vegi «En manteniment», no que existeixi un element anomenat EtiquetaEstat. Això converteix gairebé totes les proves de components en proves d'integració, que és exactament el que vol el trofeu de 09-01.

jsdom és una implementació dels estàndards del DOM i de l'HTML escrita en JavaScript pur, que s'executa a Node. Quan vite.config.js declara environment: 'jsdom', cada fitxer de proves rep un window, un document, un localStorage, un history i tota l'API del DOM, sense obrir cap navegador.

És ràpid —muntar un component costa desenes de mil·lisegons— però és una simulació, i cal conèixer-ne els límits perquè expliquen força sorpreses:

Conseqüències pràctiques per a CicloUrbano:

• toBeVisible() no comprova visibilitat real. Comprova display: none, visibility: hidden, hidden i opacity: 0 declarats en línia o en estils que jsdom hagi processat. Un element tapat per un altre amb position: absolute es considera visible. Aquest tipus de fallada només el detecta una prova d'extrem a extrem (09-05).
• Les classes de CSS Modules existeixen com a cadenes, però no apliquen estil. Una altra raó, a més de la de l'apartat 15, per no afirmar mai sobre elles.
• Si un component usa IntersectionObserver —típic en càrrega mandrosa d'imatges— cal proporcionar-lo a configuracio.js o la prova fallarà amb «is not defined».
• La navegació real no existeix. Per això els components que enruten es proven amb createMemoryRouter (apartat 14), que manté la ruta en memòria.

Què fa cada peça:

• render(element) crea un <div> contenidor, l'afegeix a document.body i hi munta l'arbre de React. Retorna un objecte amb utilitats, de les quals a la pràctica només s'usen tres: rerender (tornar a renderitzar amb altres props), unmount (desmuntar, útil per provar neteges d'efectes) i container (el node arrel, que gairebé mai no cal).
• screen és un objecte amb totes les consultes ja lligades a document.body. És la forma recomanada: screen.getByRole(...) en lloc de desestructurar const { getByRole } = render(...). La raó és doble: no cal mantenir una llista de consultes desestructurades que creix amb cada prova, i screen troba també el que es renderitza fora del contenidor, com un modal muntat amb un portal —just el cas de Modal i DialegReserva a CicloUrbano.

Sobre la neteja: Testing Library desmunta l'arbre i buida el body després de cada prova de manera automàtica, sempre que l'entorn tingui els ganxos globals (globals: true a Vitest, que és el cas). Sense aquesta neteja, la segona prova trobaria dos botons «Reservar» —el seu i el de la prova anterior— i getByRole fallaria amb «s'han trobat diversos elements». A src/proves/configuracio.js ja es va deixar explícit a 09-01, juntament amb el localStorage.clear().

Aquesta és la primera decisió de cada línia de prova, i equivocar-se produeix missatges d'error confusos. Són tres famílies, i cadascuna respon a una pregunta diferent:

I cadascuna té la seva variant en plural, que retorna un array i no falla per trobar-ne diversos:

Les regles d'ús, amb els errors típics:

Aquesta lliçó usarà gairebé sempre getBy i queryBy, perquè encara no hi ha asincronia de xarxa: findBy és el protagonista de 09-04.

Un matís sobre getAllBy, que apareix tan bon punt es prova una llista:

Testing Library defineix un ordre de preferència explícit, i seguir-lo no és purisme: cada esglaó que baixes allunya la prova del que percep l'usuari i l'acosta als detalls de la implementació.

Perquè una consulta per rol comprova dues coses alhora:

1. Que existeix un element amb rol de botó —un <button>, o alguna cosa amb role="button"—, és a dir, que es pot prémer i enfocar de debò.
2. Que el seu nom accessible és «Reservar», el text que anunciaria un lector de pantalla.

Si algú substitueix el <button> per un <div onClick>, aquesta consulta falla. I ha de fallar, perquè aquest canvi trenca el teclat i els lectors de pantalla, exactament la fallada que es va corregir a 03-06 amb la targeta polsable. Una prova escrita amb rols és també una prova d'accessibilitat, gratis.

El nom accessible es calcula, en aquest ordre: aria-labelledby, aria-label, el contingut textual de l'element, el <label> associat, title. Per això funciona igual amb aquests tres:

Els rols més habituals a CicloUrbano:

Fixa't que <input type="number"> té rol spinbutton, no textbox: és dels que més despisten.

La variant amb expressió regular mereix un comentari: { name: /reservar/i } sobreviu a un canvi de majúscules o al fet que el disseny afegeixi una icona al costat. És la manera de no lligar-se al text literal quan el text pot canviar sense que canviï el comportament.

getByTestId és l'últim esglaó, i usar-lo massa aviat anul·la l'avantatge de la biblioteca: un data-testid no comprova accessibilitat, no comprova semàntica i no es trenca quan hauria de fer-ho. Però hi ha tres casos en què és la resposta correcta:

1. Elements sense rol ni text estable: un contenidor de disseny, un gràfic, un llenç. A CicloUrbano, l'EsqueletPagina és exactament això: no té text perquè és una silueta grisa.
2. Textos dinàmics que canvien sovint per motius editorials i que farien fràgil la prova.
3. Proves d'extrem a extrem, on data-testid és el contracte explícit entre la interfície i les proves. S'argumenta a fons a 09-05.

Abans d'escriure un data-testid, fes-te aquesta pregunta: com trobaria aquest element una persona cega? Si no hi ha resposta, el problema no és la prova: és el component.

Quan getByRole no troba res, Testing Library bolca el DOM complet al missatge d'error. Aquest bolcat és l'eina de depuració principal, i cal aprendre a llegir-lo:

Aquí hi ha el diagnòstic: el botó existeix i el seu rol és correcte, però el seu nom accessible és «Reservar bicicleta», no «Reservar». La solució és { name: /reservar/i } o el nom complet.

Les tres eines de depuració, per ordre d'utilitat:

El Testing Playground s'usa de dues maneres: com a extensió del navegador sobre l'aplicació en marxa, o des de la prova amb screen.logTestingPlaygroundURL(), que imprimeix un enllaç amb el DOM actual ja carregat. Assenyales un element i et diu la consulta recomanada, ordenada per prioritat. És la manera més ràpida d'interioritzar la taula de l'apartat 5.

Un detall de configuració: per defecte screen.debug() talla el bolcat a 7.000 caràcters. Per a pàgines grans:

Hi ha dues maneres de simular una interacció, i la diferència importa més del que sembla.

fireEvent dispara un esdeveniment del DOM, exactament el que li demanes:

userEvent simula la seqüència completa d'esdeveniments que produeix aquesta acció en un navegador real:

La fila que decideix és la dels elements deshabilitats. Amb fireEvent.click(botoDeshabilitat) el gestor s'executa i la prova passa, encara que a l'aplicació real aquest clic no faci res: la prova menteix. userEvent reprodueix el comportament del navegador i no crida el gestor, que és el que s'ha de verificar a TargetaBicicleta amb una bicicleta en manteniment.

El mateix amb l'escriptura: fireEvent.change assigna el valor d'una vegada, així que un component amb useDebounce o amb validació per tecla no es comporta com en producció. userEvent.type tecleja de debò.

Per què tot és asíncron i cal esperar-ho. Des de la versió 14, userEvent retorna promeses per dues raons: internament introdueix pauses entre els esdeveniments de la seqüència per semblar-se a una persona, i embolcalla les actualitzacions en act perquè React processi el canvi d'estat abans de retornar el control. Si t'oblides de l'await, l'asserció s'executa abans que React hagi repintat i veus l'estat anterior. Amb usuari.type l'efecte és encara més visible: es perden lletres.

Regla mecànica: si la línia comença per usuari., porta await.

@testing-library/jest-dom, registrat a src/proves/configuracio.js des de 09-01, afegeix matchers que parlen de DOM. Sense ells caldria escriure expect(el.disabled).toBe(true); amb ells, expect(el).toBeDisabled(), que a més produeix un missatge d'error molt més clar.

Els dos que més partit donen i menys s'usen són toHaveAccessibleName i toHaveAccessibleDescription, perquè verifiquen directament el que anunciaria un lector de pantalla. La segona és la manera correcta de comprovar l'aria-describedby de FormulariReserva, i s'usarà a l'apartat 12.

Comencem pel més senzill. EtiquetaEstat rep un estat i el pinta per tres canals: color (classe), símbol (aria-hidden) i text.

Comentaris sobre les decisions:

• test.each per als tres estats evita tres proves idèntiques i fa que afegir un quart estat sigui afegir una fila.
• El cas de l'estat desconegut prova el ?? DESCONEGUT del component. És una branca que l'usuari no hauria de veure mai, i precisament per això ningú la comprovaria a mà.
• L'última prova verifica l'accessibilitat, no l'aparença. queryByText('🔧') retorna null perquè el <span aria-hidden="true"> està exclòs de l'arbre d'accessibilitat i les consultes per text ho respecten. Si algú tragués l'aria-hidden, aquesta prova fallaria i avisaria que un lector de pantalla començaria a llegir «clau anglesa En manteniment».
• No es comprova cap classe CSS. Que el color sigui verd o vermell no és verificable a jsdom ni és responsabilitat d'aquesta prova.

Aquí apareixen les dues coses noves: verificar que s'avisa el pare i verificar un comportament condicional.

El que cal retenir d'aquest bloc:

• La fàbrica pintar compleix aquí la mateixa funció que dadesValides a 09-02: cada prova diu només el que la distingeix, i els callbacks simulats queden disponibles per afirmar-hi.
• La prova de «prémer no avisa» és la que justifica userEvent. Amb fireEvent.click sobre un botó deshabilitat, el gestor s'executaria i alReservar hauria estat cridat: la prova fallaria encara que el codi sigui correcte. És el cas concret de la taula de l'apartat 7.
• L'asserció negativa expect(alReservar).not.toHaveBeenCalled() a la prova de «Veure fitxa» sembla redundant, però atrapa una fallada real i freqüent: dos gestors intercanviats. Compleix la regla de 09-02 d'acompanyar el positiu amb el negatiu.
• S'afirma sobre el preu amb una expressió regular, no amb la cadena exacta '2,50 € / hora'. Intl.NumberFormat insereix un espai irrompible abans del símbol de l'euro, i comparar la cadena literal produeix una fallada desconcertant. L'expressió regular amb \s* n'és immune.
• En cap moment es comprova que el component estigui memoïtzat amb memo. El memo de 08-02 és una optimització, no un comportament: provar-ho seria provar la implementació.

SelectorTipus es va tornar controlat al mòdul 4: ja no guarda el tipus, el rep per props i avisa dels canvis. Aquesta distinció canvia completament el que cal provar.

La quarta prova és la que més ensenya. Podria semblar una fallada —«premo Urbana i no es marca»— però és exactament el contracte d'un component controlat: la font de la veritat és al pare. Documentar-ho amb una prova impedeix que algú «arregli» el component reintroduint estat intern i trencant la sincronització amb Redux i amb la URL.

I fixa't com es comprova el filtre actiu: amb { pressed: true }, que consulta l'atribut aria-pressed. Ni una paraula sobre estils.actiu. Si el disseny canvia el color del botó actiu, la prova continua verda; si el botó deixa d'anunciar el seu estat, falla.

Sobre useTransition: SelectorTipus embolcalla el canvi en una transició per no bloquejar el teclejat (08-03). A jsdom les transicions es resolen de manera síncrona dins de l'act que userEvent ja introdueix, així que no requereix cap tractament especial. És un bon recordatori del principi: l'optimització és invisible per a la prova perquè és invisible per a l'usuari.

Aquest és el component que més es beneficia d'una prova d'integració, perquè combina estat, valors derivats, accessibilitat i un callback cap a fora. I perquè, tal com està, cap prova unitària pot garantir que l'error es vegi.

El useFakeTimers({ shouldAdvanceTime: true }) mereix una explicació: es congela la data del sistema perquè la validació de «no en el passat» sigui determinista, però es deixa que el rellotge avanci sol, perquè userEvent introdueix esperes internes entre esdeveniments i amb temporitzadors completament aturats es quedaria bloquejat. És una combinació que cal conèixer: data fixa + rellotge que avança.

Consultar els errors amb getAllByRole('alert') en lloc de per text és una decisió deliberada: comprova alhora que els missatges existeixen i que estan marcats com a alertes, que és el que fa que un lector de pantalla els anunciï en aparèixer. Torna a ser accessibilitat i prova alhora.

Aquesta és la prova més valuosa del component, i la que enllaça directament amb 03-06:

toHaveAccessibleDescription resol l'aria-describedby, segueix els identificadors —inclosa la cadena 'hores-ajuda hores-error'— i comprova el text resultant. Amb una sola asserció es verifica que l'error existeix, que és al DOM, que té l'identificador correcte i que aquest identificador està referenciat des del camp correcte. Comprovar-ho amb getByText només hauria verificat el primer, i la fallada real més freqüent —l'error visible però associat al camp equivocat— hauria passat desapercebuda.

Detalls importants:

• expect.objectContaining amb stringMatching per a l'identificador. L'identificador es genera amb crypto.randomUUID(), així que no es pot comparar amb un valor fix. Es comprova el format, que és el que forma part del contracte. És el comparador asimètric de 09-02 aplicat aquí.
• L'asserció sobre el total (12,00 €) verifica un valor derivat: preuHora × hores. És la comprovació que el formulari calcula bé sense necessitat d'exposar el càlcul.
• La comprovació que el formulari es neteja és un comportament que un usuari percep i que es trenca amb facilitat en refactoritzar el gestor d'enviament.
• getByRole('checkbox', { name: /Accepto les condicions/ }) funciona perquè la casella està dins de la seva <label>, així que el text de l'etiqueta és el seu nom accessible. Sense aquest embolcall —la fallada d'accessibilitat que es va corregir a 03-06— caldria recórrer a un data-testid.

Tots els exemples anteriors proven components autònoms. Tan bon punt un consumeix useTema, useSelector o useQuery, un render nu esclata:

Hi ha dues sortides. La dolenta: simular els hooks amb vi.mock('react-redux'). La bona: embolcallar el component amb els proveïdors de veritat. I hi ha tres raons sòlides per preferir la segona:

Per això el projecte defineix el seu propi renderitzar:

Decisions que convé entendre:

• L'ordre dels proveïdors replica el de main.jsx: QueryClientProvider > Provider > Proveidors > RouterProvider. Si la prova usés un altre ordre, podria passar amb un cablejat que en producció falla.
• Magatzem i client nous a cada crida. És la prevenció directa contra les proves inestables de 09-01: un QueryClient compartit filtra dades en memòria cau d'una prova a la següent, i un magatzem compartit arrossega reserves creades en proves anteriors.
• retry: false és obligatori. Amb els reintents per defecte, una prova d'error esperaria tres intents amb retrocés exponencial abans de mostrar el missatge, i exhauriria el temps d'espera. És la causa número u de «la meva prova d'error es penja».
• preloadedState permet col·locar l'escenari. Provar la pantalla d'un operari és renderitzar(<PaginaTaller />, { estatInicial: { sessio: { usuari: MARC, carregant: false } } }), sense simular res.
• Es retornen magatzem, client i enrutador per poder afirmar sobre l'estat resultant quan calgui. Amb moderació: afirmar sobre el magatzem és afirmar sobre la implementació, i només es justifica quan l'efecte no és visible en pantalla.
• La reexportació al final permet que cada fitxer de prova importi tot de '../proves/utilitats.jsx' en lloc de repartir importacions entre tres paquets.

Ús:

Tot component que usi useParams, useNavigate, useSearchParams, <Link> o <Outlet> necessita un enrutador. createMemoryRouter manté l'historial en memòria, sense tocar la URL del navegador —que a jsdom no existeix de debò.

El filtre ?tipo= de PaginaCataleg viu a la URL des del mòdul 6:

Quan l'acció produeix una navegació, el que es comprova és la destinació, no que s'hagi cridat useNavigate:

La ruta de destinació se substitueix per un component mínim (<h1>Fitxa de bicicleta</h1>) a propòsit: la prova verifica la navegació, i muntar la pàgina real portaria les seves consultes, les seves dependències i les seves fallades, convertint una fallada de navegació en una fallada de càrrega de dades i arruïnant el diagnòstic.

Comparat amb l'alternativa que es veu sovint —simular useNavigate amb vi.mock('react-router') i comprovar que s'ha cridat amb '/bicicletas/bici-001'—, aquesta manera és millor pel de sempre: la simulació comprova que s'ha demanat navegar; l'enrutador en memòria comprova que s'ha navegat, inclosa la construcció correcta de la URL i l'existència d'una ruta que l'atengui.

Recapitulació operativa del principi de 09-01, ara amb nom i cognoms:

I el senyal d'alarma més fiable: si has de llegir el codi del component per saber què consultar a la prova, la prova està acoblada. Una bona prova de component s'escriu mirant la pantalla, no el fitxer .jsx.

• Usar getBy per comprovar que alguna cosa no existeix. getBy llança en no trobar, així que la prova falla amb un missatge enganyós abans d'arribar al .not. Per a absències, sempre queryBy.
• Oblidar l'await a userEvent. Produeix fallades intermitents, lletres perdudes en escriure i avisos d'act. Regla: tota línia que comenci per usuari. porta await.
• Cridar userEvent.setup() després de render. Ha d'anar abans, perquè setup instal·la la configuració dels esdeveniments sobre el document. I una vegada per prova, mai a l'àmbit del describe.
• Usar fireEvent per costum. Deixa passar clics sobre botons deshabilitats i no mou el focus, així que valida comportaments que en producció no passen. Només per al que userEvent no cobreix.
• Comparar textos formatats amb cadenes literals. Intl.NumberFormat usa espai irrompible abans del símbol de l'euro i coma decimal en català. Usa expressions regulars amb \s* o toHaveTextContent.
• Afirmar sobre classes de CSS Modules. El nom real és targeta_a3f9x, canvia a cada compilació i no representa res visible a jsdom. Si l'estat importa, expressa'l amb un atribut ARIA i comprova'l per rol.
• Començar per getByTestId. És còmode i desactiva la meitat del valor de la biblioteca. Baixa l'escala de prioritats només quan els esglaons superiors no existeixin, i pregunta't abans si el problema és que el component no és accessible.
• Embolcallar tot en act a mà. render i userEvent ja ho fan. Si apareix l'avís d'act, la causa sol ser una actualització asíncrona sense esperar, i s'explica a fons a 09-04.
• Consell: escriu la primera asserció abans que la interacció. Comprovar l'estat inicial —«no hi ha errors», «el botó està deshabilitat»— documenta el punt de partida i fa evident què canvia la interacció.
• Consell: quan una consulta falli, comença per logRoles(container). Resol la majoria dels casos en deu segons, i de passada t'ensenya quins rols té realment la teva maquetació, que sovint no són els que et pensaves.
• Consell: si provar un component exigeix deu proveïdors i quinze props, el component fa massa. La dificultat de la prova és un indicador de disseny, igual que a 09-02.

Exercici 1. Escriu la suite de CercadorBicicletes, que rep la prop alCercar i conté un camp de text etiquetat «Cercar bicicletes». Cobreix: que el camp apareix amb la seva etiqueta, que comença buit, que en escriure «urbana» el camp mostra aquest valor, i que en prémer el botó «Netejar» el camp es buida i s'avisa amb la cadena buida. No provis el retard del useDebounce: explica en un comentari per què aquesta part correspon a 09-04 i què caldria per provar-la aquí.

Exercici 2. Aquesta prova de TargetaEstacio està escrita amb l'estil equivocat. Identifica cinc problemes, reescriu-la seguint la prioritat de consultes i explica quina fallada real detectaria la teva versió que l'original deixa passar.

Exercici 3. RequereixRol protegeix PaginaTaller: si l'usuari de la sessió no té rol operario, redirigeix a /sin-permisos. Escriu dues proves fent servir renderitzar —una per a Ana Ribera (cliente) i una altra per a Marc Solé (operario)— i explica per què usar els proveïdors reals és superior a simular useSelector en aquest cas concret.

Solució 1.

Solució 2. Els cinc problemes:

1. El nom no descriu cap comportament. test('TargetaEstacio') hauria de ser un describe, amb proves que diguin què es verifica.
2. container.querySelector('.targeta-estacio') afirma sobre una classe CSS. Amb CSS Modules aquest nom ni tan sols existeix tal qual, i encara que existís no és una cosa que l'usuari percebi.
3. querySelectorAll('p')[0] i [1] lliguen la prova a l'ordre dels paràgrafs a la maquetació. Intercanviar barri i places per motius de disseny trencaria la prova sense trencar res real.
4. fireEvent.click sobre querySelector('button'). Dues fallades en una línia: se selecciona «el primer botó que hi hagi», sigui quin sigui, i s'usa fireEvent, que dispararia el gestor fins i tot si el botó estigués deshabilitat.
5. Cinc comprovacions inconnexes en una sola prova. En fallar, l'informe només diu «TargetaEstacio», sense indicar si ha fallat la informació, la interacció o el detall.

Reescrita:

Quina fallada detecta la versió nova i l'original no: que el botó deixi d'anunciar el seu estat amb aria-expanded. L'original comprova que apareix un element amb classe .detall; si algú elimina l'aria-expanded o converteix el botó en un <div onClick>, l'original continua verda i l'accessibilitat queda trencada. La nova falla, perquè getByRole('button', …) exigeix un rol de botó real i l'asserció exigeix l'atribut. A més, la nova detectaria que el detall ja era visible des del principi, cosa que l'original no comprova en cap moment.

Solució 3.

Per què els proveïdors reals són superiors aquí: RequereixRol no llegeix el rol directament, sinó a través del selector seleccionarEsOperari, que a 07-04 es va decidir derivar en lloc de guardar. Si se simulés useSelector perquè retornés true, la prova passaria per alt exactament la peça que pot fallar: que el selector derivi bé el rol a partir de l'usuari. Amb el magatzem real i preloadedState, s'exercita la cadena completa —usuari a l'estat → selector → decisió del guardià → redirecció de l'enrutador—, que és on viu la fallada de veritat. I hi ha un segon motiu: amb la simulació no es comprovaria a on redirigeix, només que ha decidit redirigir; amb createMemoryRouter es verifica la destinació real, que és el que l'usuari experimenta.

Amb aquesta lliçó, CicloUrbano té per fi proves del que l'usuari veu i toca, i el pes del trofeu de 09-01 queda on ha d'estar.

L'essencial. La filosofia de Testing Library és una restricció deliberada: no dona accés a l'estat ni a les props, perquè com més s'assembli la prova a l'ús real, més confiança aporta. Renderitza sempre l'arbre complet, sense renderitzat superficial, així que gairebé tota prova de component és en realitat una prova d'integració. Corre sobre jsdom, que dona DOM, esdeveniments, localStorage i historial en mil·lisegons, però no dona maquetació real, ni getBoundingClientRect, ni cascada de CSS, ni navegació de veritat: per això toBeVisible no detecta un botó tapat i per això cal Cypress (09-05).

Saps triar entre les tres famílies de consultes: getBy quan alguna cosa ha d'estar-hi, queryBy —i només queryBy— quan alguna cosa no ha d'estar-hi, i findBy quan apareixerà. I coneixes l'escala de prioritats, amb getByRole al primer esglaó perquè comprova dues coses alhora: que l'element té el rol correcte i que el seu nom accessible és l'esperat. Aquí hi ha la connexió que anunciava la introducció: els label htmlFor, els rols, els noms accessibles i l'aria-describedby de 03-06 no eren una tasca a part, eren els agafadors que ara usen les proves. Un <div onClick> en lloc d'un <button> trenca la prova, i l'ha de trencar. data-testid queda com a últim recurs legítim —elements sense semàntica, com EsqueletPagina— i com a contracte explícit a les proves d'extrem a extrem. I quan una consulta falli, ja tens l'ordre de depuració: llegir el bolcat del DOM, screen.debug(), logRoles(container) i el Testing Playground.

Per interactuar, userEvent sempre, perquè simula la seqüència completa d'esdeveniments, mou el focus i —el decisiu— no dispara res sobre un element deshabilitat, a diferència de fireEvent, que validaria comportaments impossibles en producció. Totes les seves crides són asíncrones: si la línia comença per usuari., porta await. I les assercions de jest-dom donen un vocabulari que parla d'interfície, amb dues joies infrautilitzades: toHaveAccessibleName i toHaveAccessibleDescription.

Els quatre casos de CicloUrbano han anat pujant de dificultat. EtiquetaEstat ha provat presentació pura i, de passada, que el símbol decoratiu continua ocult al lector de pantalla. TargetaBicicleta ha introduït els callbacks amb vi.fn() i el cas que justifica userEvent: prémer «Reservar» en una bicicleta en manteniment no ha d'avisar el pare. SelectorTipus ha ensenyat a provar un component controlat: es verifica que avisa amb 'electrica' i que no canvia el filtre pel seu compte, i l'estat actiu es consulta amb { pressed: true }, no amb una classe. I FormulariReserva ha tancat el cercle del mòdul 3: quatre role="alert" en enviar buit, i sobretot toHaveAccessibleDescription, que en una sola asserció comprova que el missatge existeix, que té l'identificador correcte i que el camp el referencia —la fallada de l'error visible però mal associat, que cap altra comprovació detecta.

Queda fixada la infraestructura: src/proves/utilitats.jsx amb crearMagatzemDeProva, crearClientDeProva i el renderitzar propi, que embolcalla el component amb els proveïdors reals en el mateix ordre que main.jsx i retorna magatzem, client i enrutador. Usar els proveïdors de veritat, i no simular-los, és el que fa que un selector mal escrit trenqui la prova en lloc de colar-se. I retry: false al QueryClient no és un detall: sense ell, qualsevol prova d'error es penja esperant tres reintents. Per a les rutes, createMemoryRouter amb initialEntries permet provar paràmetres (/bicicletas/bici-002), cadena de consulta (?tipo=electrica) i navegació real, comprovant la destinació assolida en lloc que s'hagi cridat useNavigate.

I la llista del que no es prova mai ja té noms concrets: estat intern, classes de CSS Modules, nombre de renders, crides a hooks de biblioteques, memo, estructura del DOM i funcions no exportades. Amb el senyal d'alarma que les resumeix: si necessites llegir el .jsx per saber què consultar, la prova està acoblada.

Falta el terreny on fallen la majoria de les proves del món real: l'asincronia. Tot el d'aquesta lliçó era síncron; tan bon punt PaginaCataleg demani les bicicletes a l'API, l'asserció s'executarà abans que arribi la resposta i apareixerà el temut avís d'act(...). La propera lliçó explica aquest avís de debò, presenta les eines d'espera (findBy, waitFor, waitForElementToBeRemoved) i munta MSW per interceptar la xarxa a nivell de protocol, amb src/proves/gestors.js i src/proves/servidor.js, de manera que es puguin provocar a voluntat els tres estats de la interfície: carregant, èxit i error. A més es proven les mutacions de TanStack Query i els hooks personalitzats amb renderHook. La propera lliçó és Proves de Codi Asíncron i Simulació d'APIs.