El teu projecte fa el que promet: el domini compleix les regles, les dades sobreviuen a la recàrrega, l'aplicació parla amb una API i treballa sense connexió. I ara arriba la pregunta incòmoda, la que separa una demo d'un producte: com saps que ho continua fent demà? Perquè tens migracions que poden corrompre dades silenciosament, sincronització amb curses que només apareixen amb mala xarxa, i vistes que poden retenir memòria en navegar — tres coses que no es veuen mirant la pantalla i que, quan fallen, fallen al dispositiu d'una altra persona. En aquesta lliçó portes al projecte propi tot el que vas aprendre al Mòdul 8, però amb una diferència important: allà les proves se't donaven escrites, i aquí has de decidir què provar, en quin nivell i fins on. Veuràs com definir una estratègia de proves amb la piràmide aplicada als teus mòduls concrets i un objectiu de cobertura raonat en lloc de cosmètic; com provar el domini exhaustivament amb proves parametritzades de les quinze regles; com provar la capa de dades amb dobles, temporitzadors falsos i fetch simulat, incloses les migracions i la cua; com provar la vista consultant per rol i també el recorregut amb teclat; com triar tres recorreguts d'extrem a extrem i per què no més; com muntar la integració contínua completa amb pressupost de rendiment; com depurar tres errades que apareixeran de debò al teu projecte, amb la tècnica de reproduir primer i escriure una prova que falli; com automatitzar i complementar les proves d'accessibilitat; i com mesurar el teu projecte contra la línia base de Nómada Tasques. En acabar tindràs la suite completa en verd a la CI i l'informe d'accessibilitat i rendiment.

1. L'estratègia de proves: decidir què es prova i on
2. La piràmide aplicada als teus mòduls concrets
3. Un objectiu de cobertura raonat, no cosmètic
4. Provar el domini: les quinze regles parametritzades
5. Provar les transicions i els casos límit
6. Provar la capa de dades amb dobles i temporitzadors falsos
7. Provar les migracions i la cua offline
8. Provar la vista amb jsdom i Testing Library
9. Provar el recorregut amb teclat
10. Tres recorreguts d'extrem a extrem, i per què no més
11. Integració contínua amb GitHub Actions
12. Lighthouse CI i el pressupost de rendiment
13. Depurar el projecte propi: el mètode aplicat
14. Errada 1: la migració que corromp dades
15. Errada 2: la condició de cursa en sincronitzar
16. Errada 3: la fuita de memòria en navegar
17. Proves d'accessibilitat: automàtiques i manuals
18. Mesurar el rendiment del projecte propi
19. Les proves intermitents
20. Errors Habituals i Consells
21. Exercicis
22. Conclusió

Abans d'escriure ni una prova més, cal respondre tres preguntes. Escriure-les a docs/estrategia-proves.md és mitja hora que estalvia setmanes de proves mal col·locades.

Pregunta 1 · Què és el que no pot fallar mai?

A Òrbita, la resposta és concreta: les regles de negoci i la persistència. Que un botó estigui dos píxels a l'esquerra és un defecte cosmètic; que una migració perdi les tasques d'algú és la mort del producte. Les proves es concentren on l'errada és catastròfica, no on és fàcil escriure-les.

Pregunta 2 · Què canvia sovint i què no?

El que canvia molt —la maquetació, els textos, les classes CSS— no ha d'estar acoblat a les proves, o cada retoc visual trencarà vint proves que no detecten cap errada real. El que canvia poc —les regles, els contractes— es pot provar a fons sense cost de manteniment.

Pregunta 3 · Quant costa cada prova i quant val?

La conclusió operativa: moltes unitàries, bastants d'integració, molt poques d'extrem a extrem. No és una preferència estètica; és una conseqüència directa de la taula.

La regla de decisió que resol gairebé tots els casos:

Prova en el nivell més baix que capti l'errada que et preocupa.

Si et preocupa que R13 no bloquegi el tancament, és una prova unitària de domini: no cal un navegador. Si et preocupa que el botó no estigui deshabilitat quan toca, és d'integració amb DOM. Si et preocupa que crear una tasca, recarregar i veure-la no funcioni de punta a punta, és d'extrem a extrem. Provar R13 des de Cypress és cent vegades més lent i dona la mateixa informació.

La piràmide de proves genèrica no ajuda gaire. Aquesta sí, perquè anomena els teus fitxers:

Total orientatiu: unes 250 proves, de les quals tres són d'extrem a extrem. Nómada Tasques tenia 124 proves i 3 recorreguts amb menys funcionalitats; l'ordre de magnitud és coherent.

Dues observacions sobre aquesta taula:

• regles.js no es prova directament. Són constants. Una prova que comprova que MAX_HORES === 40 no verifica res: reescriu el valor en un altre lloc. El que es prova és que la regla s'aplica, i això passa a tasca.js.
• La proporció vista/domini és d'aproximadament 1 a 2. Si el teu projecte tingués més proves de vista que de domini, seria senyal que la lògica és a la vista — exactament el que l'arquitectura de 11-01 pretenia evitar. La distribució de les teves proves és un diagnòstic de la teva arquitectura.

La cobertura mesura quin percentatge del codi s'executa durant les proves. És una mètrica útil i perillosa a parts iguals, i convé entendre per què.

El que la cobertura sí que diu: quin codi no està provat en absolut. Un 0 % a migracions.js és una alarma real.

El que la cobertura no diu: si el que és provat està ben provat. Aquesta prova dona 100 % de cobertura i no verifica res:

Per això un objectiu únic per a tot el projecte és un mal objectiu. El raonable és per capa, i amb criteri:

La justificació de cada llindar, que és el que cal escriure a la teva estratègia:

I la mètrica que de debò importa no és el percentatge: és la cobertura de les regles. Mantén una taula a docs/estrategia-proves.md:

Quinze regles × tres casos = quaranta-cinc proves mínimes. Aquesta taula és un objectiu molt més honest que «85 % de cobertura», perquè no es pot aprovar sense verificar res.

Les proves parametritzades són l'eina natural per a les regles, perquè una regla és una afirmació sobre un conjunt de casos.

Quatre decisions d'aquesta taula que la fan valuosa:

1 · La taula és llegible com a especificació. Qualsevol que la llegeixi sap exactament què accepta i què rebutja el model, sense llegir el codi de Tasca.

2 · Cada regla té els seus límits exactes. Per a R3: 0 no, 0.5 sí, 40 sí, 40.1 no. Les errades dels desenvolupadors viuen als > que haurien de ser >=, i només es cacen provant el valor exacte del límit.

3 · Es comprova error.camp, no només el tipus. Aquesta dada és el que permet al formulari marcar el camp correcte (11-02). Si no es prova, un dia algú posa camp: 'hores' en lloc de 'horesEstimades' i el formulari deixa de ressaltar res, en silenci.

4 · Hi ha casos de tipus, no només de valor. '12' com a text i NaN són els que se sobrepassen per validacions ingènues com if (hores > 40). Amb NaN, aquesta comparació és false i el valor passa.

El cas R14 mereix una prova especial, perquè la seva invariant no és sobre un valor sinó sobre l'estructura:

La matriu de transicions de R6 es prova sencera, com a 11-02. Però hi ha tres tipus de cas límit que s'obliden sistemàticament i que convé enumerar:

Els límits numèrics. Per a cada comparació del teu domini, prova el valor exacte, un per sota i un per sobre:

Els límits de col·lecció. Per a cada funció que rep una llista:

Els límits temporals. Els que més errades produeixen i menys es proven:

La segona fila és la que trenca gairebé totes les implementacions casolanes de setmana ISO, i afecta directament R15 i l'informe de càrrega. Si el teu projecte fa servir setmanes, aquesta prova no és opcional.

I un cas que només apareix en projectes amb arbres: l'arbre degenerat. Una tasca amb 200 subtasques en un sol nivell, i una cadena de 3 nivells amb una fulla a cadascun. Tots dos exerciten camins diferents de la teva recursivitat.

Aquí s'aplica tot el de 08-04. La regla que ho governa: se substitueix el que és lent, no determinista o extern; mai la lògica que estàs provant.

El detall de throw new Error('fetch inesperat') és important: una crida de més que no esperaves és una errada que vols veure, no una cosa que hagi de retornar undefined i produir un error confús més endavant.

Les dues asseveracions sobre crides.length són el cor d'aquestes proves. Sense elles, totes dues passarien encara que el reintent estigués mal implementat.

advanceTimersByTimeAsync i no advanceTimersByTime. La versió asíncrona buida també la cua de microtasques entre avenços, i sense ella les promeses intermèdies no es resolen i la prova es penja. És un d'aquells detalls que costen una tarda la primera vegada, i té tot el sentit a la llum de 05-07: les microtasques i els temporitzadors són cues diferents.

Recorda restaurar els temporitzadors reals. Un jest.useFakeTimers() que es queda actiu contamina les proves següents amb errades aparentment aleatòries. Posa-ho en un afterEach global.

Ja vas veure les sis proves base a 11-03. Afegeix-hi aquestes tres, que cobreixen el que surt malament a la pràctica:

La segona és una prova de rendiment a la suite, i aquí sí que està justificada: la migració passa en arrencar, bloquejant la primera pintada. Una migració de dos segons arruïna l'LCP del pressupost de 11-01, i aquesta errada només apareix amb dades d'usuari real. Posar-li un llindar a la prova ho prevé.

La tercera prova és la que evita el duplicat de l'apartat 13 de 11-03, i és impossible de comprovar a mà de manera fiable. És l'exemple perfecte d'una errada que només es caça amb una prova automatitzada.

El principi de 08-05, que convé recordar perquè ho canvia tot:

Prova com fa servir l'aplicació una persona, no com està construïda per dins.

A la pràctica, això significa consultar per rol i per text accessible, mai per classe CSS ni per estructura.

El benefici doble: la prova sobreviu a un canvi de classes CSS, i a més verifica accessibilitat de propina. Si getByRole('button', { name: /crear/i }) no troba res, és perquè el teu botó no és un botó o no té nom accessible — i això és una errada real que un querySelector hauria amagat.

Fixa't que la meitat d'aquestes proves verifiquen requisits d'accessibilitat i d'experiència —llista semàntica, text a més del color, anunci del recompte, estat buit amb sortida— que a 11-01 vas escriure com a criteris d'acceptació. El cercle es tanca: història → criteri → prova.

Aquesta és la part que gairebé cap projecte de portafoli no té, i és la que més impressiona en una revisió.

Les tres cobreixen les tres errades de focus més comunes: no entrar-hi en obrir, no tornar en tancar i escapar-se'n mentre és obert. Si fas servir <dialog> amb showModal(), les tres passen gairebé sense esforç — que és exactament l'argument de 11-02 sobre fer servir l'element correcte.

Advertiment sobre jsdom: jsdom implementa <dialog> de manera incompleta en algunes versions, i no calcula estils, així que no pot verificar visibilitat ni contrast. Les proves de teclat a jsdom cobreixen la lògica del focus; la verificació real que es veu on ets és manual o d'extrem a extrem.

Les proves d'extrem a extrem (08-06) són les més valuoses per prova i les més cares per prova. Aquesta doble condició dicta l'estratègia: poques i molt ben triades.

El criteri de selecció, en una frase: tria els recorreguts que, si es trenquessin, el producte no serviria per a res. Per a Òrbita:

Recorregut 1 · El cicle de vida complet d'una tasca.

Aquest recorregut cobreix d'una vegada: crear amb validació, l'arbre, R13 aplicada de debò des de la interfície, el missatge d'error, la transició completa i la persistència després de recarregar. Un recorregut, sis riscos.

Recorregut 2 · Filtrar, compartir el filtre i veure l'informe. Cobreix l'estat compartit, la URL com a font de veritat, el càlcul de càrrega i l'estat buit.

Recorregut 3 · Treballar sense connexió i recuperar. Cobreix la cua, la persistència i la reconciliació:

Aquest últim should('have.length', 1) és la prova del duplicat: si la idempotència falla, n'apareixen dos.

Per què exactament tres. Amb tres recorreguts cobreixes els tres riscos sistèmics —el flux principal, l'estat compartit i la resiliència— en uns 30 segons d'execució. Amb vint tindries cinc minuts de CI, errades intermitents setmanals i una càrrega de manteniment que acabaria amb algú desactivant-los. Una suite d'extrem a extrem desactivada val zero, així que el nombre correcte és el màxim que pots mantenir sempre en verd. Tres ho és. Nómada Tasques també en tenia tres, amb menys funcionalitats: la proporció s'aguanta.

La integració contínua executa npm run verificar a cada push, en una màquina neta. Aquest «màquina neta» és la meitat del valor: caça els «a la meva màquina funciona» que es deuen a un fitxer no confirmat o a una dependència global.

Les decisions del fitxer, una a una:

La protecció de la branca. La CI no serveix de res si es pot fusionar en vermell. A la configuració del repositori, marca main com a protegida i exigeix que els tres treballs passin abans de fusionar. És un clic que converteix una recomanació en una garantia — la mateixa idea que la regla d'ESLint de 11-01.

A 11-01 vas fixar el pressupost. Aquí el fas complir automàticament.

Quatre observacions:

• numberOfRuns: 3. Lighthouse té soroll; amb una sola execució tindries errades aleatòries. Tres i pren la mediana, exactament la disciplina de mesura de 09-01.
• error davant de warn. El que trenca la compilació és el del pressupost signat; la resta informa. Si tot és error, acabaràs desactivant-lo sencer el primer divendres complicat.
• resource-summary:script:size a 61440 són els 60 kB del pressupost de 11-01, en bytes. Aquesta única línia és la que impedeix que un dia algú afegeixi una llibreria de gràfics i ningú no se n'assabenti.
• Les tres auditories d'accessibilitat amb minScore: 1 —contrast, etiquetes, noms de botó— són les que més es degraden amb el temps. Exigir perfecció en aquestes tres és assumible i evita l'erosió.

Quan el pressupost falla, hi ha tres sortides legítimes i una d'il·legítima:

La lliçó 08-01 va donar el mètode. Aquí s'aplica a errades teves, i el canvi important és que ningú no et dirà on és el problema.

El procediment, en sis passos:

El pas 3 és el que gairebé tothom es salta, i és el més rendible dels sis. Escriure la prova abans de corregir té quatre beneficis simultanis:

1. Demostra que has entès l'errada. Si no pots escriure la prova, no saps què està malament: només tens un símptoma.
2. Et diu quan has acabat. Sense ella, «sembla que ja funciona» és tot el que tens.
3. Evita la reaparició. Les errades corregides sense prova tornen, i tornen en el pitjor moment.
4. Documenta el cas rar. D'aquí a un any, aquesta prova explicarà per què el codi té aquella línia aparentment innecessària.

El pas 4 mereix un matís. Una hipòtesi útil és falsable i concreta: «l'id que arriba al PUT és undefined perquè el servidor retorna _id». Una hipòtesi inútil és «alguna cosa passa amb els ids». La primera es comprova amb una mesura; la segona et porta a tocar coses a veure si s'arregla, que és la manera més cara de depurar que existeix.

Els tres apartats següents recorren tres errades que apareixeran al teu projecte. No són exemples inventats: són les conseqüències directes del que has construït a 11-02 i 11-03.

El símptoma. Un usuari de prova (o tu, amb el teu perfil de desenvolupament antic) actualitza l'aplicació i veu el tauler amb les tasques, però totes apareixen sense responsable i l'informe de càrrega surt a zero. No hi ha cap error a consola.

Pas 1 · Reproduir. L'errada no passa amb dades noves, només amb dades antigues. La reproducció exigeix el document original — i aquí es cobra la còpia de seguretat de 11-03:

Les dades antigues sí que tenen responsable. Per tant, ho perd la migració.

Pas 2 · Reduir. Al cas mínim: dues tasques i un usuari.

Pas 3 · La prova que falla:

Pas 4 · Hipòtesi. El mapa perNom no troba 'Iván'. Possibles causes: (a) els usuaris no estan carregats quan corre la migració, (b) el nom no coincideix exactament, (c) l'ordre de les migracions és incorrecte.

Pas 5 · Comprovar amb una mesura:

Ja hi és. Els dos textos es veuen idèntics a la pantalla i no són iguals: un fa servir el caràcter precompost í (U+00ED) i l'altre una i seguida d'un accent combinant (U+0301). És un clàssic de les dades que han passat per sistemes operatius o navegadors diferents.

Pas 6 · Corregir. Normalitzant Unicode a tots dos costats:

I les tres lliçons generalitzables:

1. Emparellar per text és fràgil. Emparella per identificador, sempre que sigui possible. Si no queda més remei, normalitza (normalize('NFC'), trim(), i valora toLocaleLowerCase()).
2. Una errada silenciosa és pitjor que una de sorollosa. La migració posava null sense avisar. Hauria de comptar quantes assignacions no ha pogut resoldre i registrar-ho: registrar('migracio v2: 6 de 8 responsables sense resoldre'). Un avís hauria revelat l'errada el primer dia.
3. La còpia de seguretat va salvar la investigació. Sense ella, les dades originals haurien desaparegut i només tindries el símptoma.

La prova de regressió que es queda, amb el cas Unicode explícit:

El símptoma. Amb la xarxa lenta, de vegades —no sempre— en marcar una tasca com a feta, torna a aparèixer com a pendent al cap d'un segon. No passa a la teva màquina amb xarxa ràpida. No hi ha error a consola.

Aquest és el pitjor tipus d'errada: intermitent i depenent de l'entorn. I la primera regla és no intentar depurar-la fins a poder reproduir-la a voluntat.

Pas 1 · Reproduir. Amb el panell Network en Slow 3G, surt una de cada tres vegades. Encara no n'hi ha prou. Per fer-ho determinista, cal controlar els temps:

Amb tres segons de retard, passa sempre. Ja és reproduïble.

Pas 2 · Reduir. La seqüència mínima resulta ser:

La llista es refresca amb dades anteriors al meu canvi i trepitja l'actualització optimista.

Pas 3 · La prova que falla, amb temporitzadors falsos per fer-la determinista:

Pas 4 · Hipòtesi. El GET substitueix la llista sencera amb el que retorna el servidor, sense tenir en compte que hi ha canvis locals pendents de confirmar.

Pas 5 · Confirmat: refrescarTasques fa magatzem.actualitzar({ tasques: delServidor }).

Pas 6 · Corregir. Tres solucions possibles, i convé veure per què se'n tria una:

Les tres lliçons generalitzables:

1. Una errada intermitent gairebé sempre és una cursa. Quan alguna cosa passa «de vegades», busca dues operacions asíncrones que puguin acabar en ordre diferent.
2. Reproduir exigeix controlar el temps. Retardar peticions a propòsit converteix «una de cada tres vegades» en «sempre», i això és el que fa possible depurar.
3. Qualsevol estat que se substitueix sencer és sospitós. actualitzar({ tasques: noves }) descarta informació que pot ser més recent. Substituir sempre ha de ser una decisió, no el camí per defecte.

El símptoma. Després de navegar entre tauler, informe i historial una estona, l'aplicació es torna lenta. Al principi no es nota; després de vint navegacions, cada canvi de pantalla triga visiblement més.

Pas 1 · Reproduir i mesurar, amb el protocol de 09-03:

1. Obrir el panell Memory en mode incògnit.
2. Instantània 1 (línia base).
3. Navegar 20 vegades entre les tres pantalles.
4. Forçar la recol·lecció d'escombraries (la icona de la paperera).
5. Instantània 2.
6. Comparar per Objects allocated between snapshots.

El resultat:

Vint-i-una instàncies de TaulerVista vives. N'hi hauria d'haver una. Els 4.812 nodes separats són el DOM de les vint anteriors, retingut per alguna cosa.

Pas 2 · Trobar el retenidor. Al panell Memory, seleccionar una instància i mirar Retainers:

El magatzem està retenint vint funcions subscriptores, cadascuna amb la seva clausura sobre la seva vista i el seu DOM.

Pas 3 · La prova que falla:

Pas 4 i 5 · La causa. El codi era aquest:

Pas 6 · Corregir, desant totes les baixes:

Les quatre lliçons generalitzables:

1. Tot el que es connecta s'ha de desconnectar. Escoltes, subscripcions, temporitzadors, observadors, sockets. El patró «desar la baixa en un array» converteix destruir() en tres línies sempre iguals.
2. La fuita no es veu, es mesura. Ningú no detecta 26 MB mirant la pantalla. Sense el protocol de tres instantànies de 09-03, això es descobreix quan un usuari diu «va lenta després d'una estona».
3. És comprovable en una prova unitària. No cal el panell Memory per prevenir la reaparició: n'hi ha prou amb exposar nombreDeSubscriptors i comptar. Aquesta prova triga un mil·lisegon i corre a cada push.
4. Afegeix el comptador de navegacions a la teva llista de comprovació. Entrar i sortir tres vegades de cada pantalla, amb el comptador d'escoltes a la vista, hauria de ser part del tancament de cada increment.

Hi ha una xifra que convé tenir present: les eines automàtiques detecten al voltant d'un terç dels problemes reals d'accessibilitat. Són imprescindibles i no són suficients.

Els dos últims casos —estat buit i estat d'error— són els que ningú no prova i on més incidències apareixen, perquè es maqueten de pressa i sense revisar.

I a Cypress, sobre l'aplicació real (que sí que calcula estils, i per tant sí que detecta contrast):

Cap eina no detecta que l'ordre de tabulació sigui absurd, que un text alternatiu digui «imatge1», o que el flux sigui impossible de seguir sense veure la pantalla. Això es prova a mà, amb aquesta llista:

Uns 50 minuts per revisió completa. Fes-la en tancar cada fita, no al final.

El punt 3 fa por la primera vegada i és el que més ensenya. Consells per començar: aprèn cinc dreceres (llegir-ho tot, element següent, encapçalament següent, llista d'enllaços, llista d'encapçalaments), tanca els ulls de debò, i intenta completar una tasca concreta. El que descobriràs gairebé segur: que els teus encapçalaments no formen una estructura navegable, que els teus botons d'icona no diuen res, i que quan alguna cosa canvia a la pantalla no te n'assabentes.

Un lliurable de la fita, a docs/accessibilitat.md:

Aquest document, amb les seves limitacions declarades, val més en una entrevista que una puntuació de 100 a Lighthouse. Demostra que has mirat de debò.

Aplica el protocol de 09-01 al teu projecte: mediana de 15 repeticions després de 5 d'escalfament, CPU 4×, xarxa Slow 4G, incògnit, mateixa màquina.

Genera dades realistes primer. Mesurar amb sis tasques no diu res:

I la taula de resultats, amb la referència de Nómada Tasques al costat:

Com interpretar la comparació honestament, que és la part que importa:

• Òrbita és una mica més pesada que Nómada Tasques, i ho ha de ser. Té tres pantalles més, arbre de subtasques, historial i cua de sincronització. Estar dins del pressupost amb més funcionalitat és el resultat correcte.
• Estar per sota del pressupost no és motiu per relaxar-se: és marge per al que vingui. Anota el marge: 5,9 kB de JavaScript i 400 ms d'LCP.
• Si estàs fora, la taula et diu on mirar. Cada fila té la seva lliçó del Mòdul 9: render() alt → 09-04; JS alt → 09-05; memòria → 09-03; INP → 09-02.

I una regla contra l'autoengany: mesura en mode incògnit, sense extensions i sense el servidor de desenvolupament. Vite en desenvolupament serveix mòduls sense empaquetar, i mesurar allà dona números que no tenen res a veure amb producció. Es mesura sobre npm run build i npm run preview.

Una prova intermitent (o flaky) passa unes vegades i falla d'altres sense que canviï el codi. Són el pitjor enemic d'una suite, per una raó concreta: destrueixen la confiança. Així que la gent comença a rellançar la CI «a veure si aquesta vegada passa», les proves deixen de ser un senyal i passen a ser soroll.

Les causes, amb la seva solució:

El protocol quan apareix una intermitent:

1. No la rellancis mai i continuïs. Aquest és l'hàbit que arruïna les suites.
2. Etiqueta-la i executa-la en bucle per mesurar-ne la freqüència:

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

3. Aïlla la causa amb la taula de dalt. Gairebé sempre és temps o estat compartit.
4. Corregeix la causa, no el símptoma. Afegir cy.wait(2000) no arregla res: fa la prova més lenta i continua fallant en una màquina més lenta.
5. Si no la pots arreglar avui, marca-la amb test.skip i obre una incidència amb data. Una prova desactivada i anotada és honesta; una prova intermitent activa és corrosiva.

I la regla d'higiene: executa la suite completa cinc vegades seguides abans de donar per bona una fita. Si les cinc passen, tens una suite fiable. Si en falla una, tens una intermitent que ja coneixes — i és molt millor conèixer-la ara que un divendres durant un desplegament.

Provar la implementació en lloc del comportament. Una prova que comprova que s'ha cridat un mètode intern es trenca amb cada refactorització sense detectar cap errada real. Prova el que entra i el que surt, o el que veu l'usuari. La regla pràctica: si en reorganitzar el codi per dins, sense canviar-ne el comportament, es trenquen proves, aquestes proves estaven malament.

Perseguir el 100 % de cobertura. Els últims punts percentuals acostumen a ser branques defensives que no s'executen mai, i forçar-los produeix proves artificials que no aporten confiança. Puja el llistó on el risc és alt —domini i migracions— i accepta menys on el cost és alt i el risc baix.

Escriure vint proves d'extrem a extrem. Són lentes, fràgils i intermitents. Amb vint, la CI triga cinc minuts i algú acabarà desactivant-les. Tres de ben triades donen gairebé la mateixa confiança sistèmica a una fracció del cost.

querySelector per classe CSS a les proves de vista. Acobla la prova a la maquetació i no verifica accessibilitat. getByRole fa totes dues coses bé i falla quan el teu HTML no és semàntic, que és informació valuosa.

No netejar l'estat entre proves. localStorage, temporitzadors falsos, dobles de fetch i el DOM s'arrosseguen d'una prova a una altra i produeixen errades que depenen de l'ordre. beforeEach que ho neteja tot, sempre.

Fer servir advanceTimersByTime amb codi asíncron. No buida la cua de microtasques i la prova es penja o falla sense explicació. advanceTimersByTimeAsync i await.

Corregir una errada sense escriure abans la prova que falla. Perds els quatre avantatges: la demostració que ho vas entendre, el criteri de finalització, la protecció contra la reaparició i la documentació del cas rar. És l'hàbit que més separa qui depura amb mètode de qui toca coses a veure què passa.

Depurar una errada intermitent sense fer-la determinista primer. «De vegades passa» no es pot depurar. Controla el temps, les respostes i l'aleatorietat fins que passi sempre; llavors comença a investigar.

Rellançar la CI fins que passi. Cada vegada que ho fas, la teva suite perd valor. Tracta cada intermitent com una errada real, perquè acostuma a ser-ho: la cursa que produeix l'errada a la CI existeix també en producció.

Creure que axe n'hi ha prou. Detecta al voltant d'un terç dels problemes. Un teclat i vint minuts amb un lector de pantalla troben coses que cap eina no veu.

Consell · Executa les proves en mode vigilància mentre programes. npm run test:watch amb Jest executa només el que està afectat pel que acabes de desar. El cicle de retroalimentació baixa de minuts a menys d'un segon, i això canvia com treballes.

Consell · Escriu el nom de la prova com una frase que descrigui el comportament. 'rebutja tancar una tasca amb subtasques obertes', no 'test canviarEstat 3'. Quan falli a la CI d'aquí a tres mesos, el nom serà tota la informació que tindràs al principi.

Consell · Mantén una carpeta test/ajudes/ cuidada. Fàbriques d'entitats, muntatge de l'aplicació, fetch simulat, generadors de dades. Cada minut invertit allà es multiplica pel nombre de proves que escriuràs després.

Consell · Afegeix el nombre de proves i la cobertura al README. «251 proves · 3 recorreguts E2E · 94 % de cobertura al domini» és un senyal immediat de serietat per a qui miri el teu repositori, i a tu et recorda mantenir-ho.

Aquests exercicis són la fita H5 del teu projecte: la suite completa en verd a la CI i l'informe d'accessibilitat i rendiment.

Exercici 1 — L'estratègia i la suite completa.

1. Escriu docs/estrategia-proves.md amb: les tres preguntes de l'apartat 1 respostes per al teu projecte, la taula de la piràmide amb els teus mòduls i els seus números, i els llindars de cobertura per capa amb la seva justificació.
2. Configura Jest amb projectes separats: node per a domini i jsdom per a la resta, amb coverageThreshold per ruta.
3. Completa la taula de cobertura de regles: les 15 regles × (cas que passa, cas que falla, cas límit). Mínim 45 proves de domini.
4. Escriu proves parametritzades amb describe.each per a almenys: la validació de camps, la matriu de transicions completa i els casos de data (inclosa la setmana 53).
5. Prova la capa de dades amb fetch simulat i temporitzadors falsos: codis d'estat, reintents selectius, temps esgotat, cancel·lació i retrocés exponencial verificat amb temps.
6. Prova les migracions (mínim 9 proves, incloses idempotència, validesa per al domini i la de rendiment) i la cua (mínim 6, inclosa la clau d'idempotència compartida entre reintents).
7. Prova la vista amb Testing Library consultant sempre per rol o text accessible, incloses almenys tres proves de recorregut amb teclat (entrada de focus, retorn de focus, sense escapada).
8. Escriu exactament tres recorreguts de Cypress i justifica per escrit per què aquests tres.

Exercici 2 — La integració contínua completa.

1. Escriu .github/workflows/ci.yml amb els tres treballs: qualitat, extrem a extrem i Lighthouse, amb concurrency, memòria cau d'npm, needs i pujada d'artefactes.
2. Configura lighthouserc.json amb el teu pressupost de 11-01 traduït a asseveracions, distingint error de warn.
3. Activa la protecció de la branca main exigint els tres treballs.
4. Provoca una errada a propòsit de cada tipus i comprova que la CI la detecta: un error de lint, una prova trencada, una regressió de cobertura per sota del llindar, i un augment de mida del paquet per sobre del pressupost (importa una llibreria gran i treu-la després).
5. Documenta al README l'estat de la CI amb la seva insígnia.

Exercici 3 — Les tres errades, l'informe i la línia base.

1. Reprodueix les tres errades dels apartats 14, 15 i 16 al teu propi projecte. Si alguna no es dona de manera natural, provoca-la: treu la normalització d'una migració, retarda artificialment un PUT, o elimina una baixa de subscripció.
2. Per a cadascuna, documenta a docs/depuracio.md: símptoma, procediment de reproducció, cas mínim, prova que falla, hipòtesi (incloses les descartades), causa arrel i correcció.
3. Deixa les tres proves de regressió a la suite.
4. Executa la revisió d'accessibilitat completa: axe automatitzat sobre les 7 pantalles (inclosos estat buit i d'error) i les 8 proves manuals. Escriu docs/accessibilitat.md amb el format de l'apartat 17.3, incloses les limitacions conegudes.
5. Genera dades realistes (≥ 500 tasques, ≥ 3.000 entrades d'historial) i mesura la teva línia base amb el protocol de 09-01 sobre la compilació de producció. Escriu docs/rendiment.md amb la taula de 9 files comparant pressupost, el teu resultat i Nómada Tasques.
6. Executa la suite completa cinc vegades seguides. Si alguna falla, troba i arregla la intermitent abans de donar la fita per tancada.

Criteris d'acceptació de l'exercici 1 — Suite

Rúbrica de l'exercici 1 (27 punts)

Llindar: 19/27, amb obligatòriament ≥ 2 a «Cobertura de regles» i a «Fiabilitat».

Criteris d'acceptació de l'exercici 2 — CI

Criteris d'acceptació de l'exercici 3 — Depuració i informes

Rúbrica global de la fita H5 (24 punts)

Llindar: 17/24. I una condició addicional que no es compensa: la suite ha d'estar en verd cinc vegades seguides. Una suite intermitent no està acabada, per moltes proves que tingui.

Autoavaluació de la fita H5:

Has convertit «funciona a la meva màquina» en «funciona, i hi ha una màquina que ho comprova a cada push».

Tens una estratègia de proves construïda sobre tres preguntes —què no pot fallar mai, què canvia sovint, i quant costa i quant val cada prova— i sobre una regla de decisió que resol gairebé tots els casos: prova en el nivell més baix que capti l'errada que et preocupa. Tens la piràmide traduïda als teus fitxers concrets, amb unes 250 proves de les quals només tres són d'extrem a extrem, i amb una observació que és un diagnòstic gratuït: si tinguessis més proves de vista que de domini, la teva lògica estaria al lloc equivocat.

Saps fer servir la cobertura sense deixar-te enganyar per ella: diu què no està provat, no si el que és provat està ben provat. Per això els teus llindars són per capa i justificats —95 % a domini, 100 % a migracions, 65 % a vista— i per això la mètrica que de debò governa no és el percentatge sinó la taula de regles × tres casos: quinze regles, quaranta-cinc proves mínimes, i cap buit que es pugui aprovar sense verificar res.

Saps provar el domini amb taules parametritzades que es llegeixen com a especificació, amb els límits exactes on viuen les errades —40 i 40.1, no 20—, amb els casos de tipus que se sobrepassen per les validacions ingènues —'12' i NaN—, comprovant error.camp i no només el tipus d'error, i amb les tres famílies de casos límit que tothom oblida: numèrics, de col·lecció i temporals, inclosa la setmana 53 que trenca gairebé totes les implementacions casolanes de setmana ISO.

Saps provar la capa de dades substituint només el que és lent, extern i no determinista: fetch simulat que falla davant de crides inesperades, temporitzadors falsos amb advanceTimersByTimeAsync —i no la versió síncrona, que deixa les microtasques sense buidar—, rellotge fixat, i asseveracions sobre el nombre de crides, que és el que distingeix una prova de reintents real d'una que passaria igual amb el reintent trencat. Amb les migracions provades contra documents reals, inclosa la prova de rendiment que evita que una migració lenta arruïni l'LCP, i amb la cua provada en el que és impossible verificar a mà: que el reenviament fa servir la mateixa clau d'idempotència.

Saps provar la vista com la fa servir una persona: per rol i per text accessible, mai per classe CSS, amb el doble benefici de sobreviure als canvis de maquetació i de verificar accessibilitat de propina. I saps provar el recorregut amb teclat, que gairebé cap projecte no té, cobrint les tres errades de focus clàssiques —no entrar-hi, no tornar, escapar-se'n—, que amb <dialog> natiu passen gairebé soles.

Tens tres recorreguts d'extrem a extrem triats amb un criteri explícit —els que, si es trenquessin, deixarien el producte inservible—, cobrint el cicle de vida complet amb R13 aplicada de debò, l'estat compartit a la URL amb l'informe, i la resiliència sense connexió amb la comprovació del duplicat. I saps per què no vint: una suite d'extrem a extrem desactivada val zero, així que el nombre correcte és el màxim que pots mantenir sempre en verd.

Tens la integració contínua completa i comentada línia a línia: concurrency que cancel·la l'obsolet, memòria cau d'npm, npm ci en comptes d'install, artefactes que es pugen també quan falla —que és justament quan els necessites—, treballs lents que depenen del ràpid, i la protecció de branca que converteix la recomanació en garantia. Amb Lighthouse CI fent complir el teu pressupost de 11-01 traduït a asseveracions, tres execucions pel soroll, error només on vas signar, i la línia de 61.440 bytes que impedeix que un dia entri una llibreria de gràfics sense que ningú no se n'assabenti.

I saps depurar el teu propi projecte amb un mètode de sis passos el tercer pas del qual —escriure la prova que falla abans de corregir— és el que gairebé tothom es salta i el que dona quatre beneficis alhora. Ho has aplicat a tres errades reals: la migració que corrompia dades per emparellar noms amb normalització Unicode diferent, amb les seves tres lliçons —emparellar per identificador, no fallar en silenci, i que la còpia de seguretat va salvar la investigació—; la condició de cursa en què un refresc en vol trepitjava una actualització optimista, on reproduir va exigir controlar el temps per convertir «una de cada tres vegades» en «sempre»; i la fuita de memòria de vint-i-una vistes vives retingudes per subscripcions sense baixa, que no es veu però es mesura, i que es prevé per sempre amb una prova unitària d'un mil·lisegon.

Saps que les eines automàtiques d'accessibilitat detecten al voltant d'un terç dels problemes, i tens les dues meitats: axe sobre les set pantalles —inclosos l'estat buit i el d'error, que ningú no prova i on més incidències hi ha— i les vuit proves manuals de cinquanta minuts, amb el lector de pantalla i els ulls tancats com la que més ensenya. Amb un informe que declara les seves limitacions, que val més que un 100 de Lighthouse.

Tens la teva línia base mesurada sobre la compilació de producció, amb dades realistes, comparada amb Nómada Tasques fila a fila, i la saps interpretar: ser una mica més pesat amb més funcionalitat és correcte, estar per sota del pressupost és marge i no permís, i cada fila fora de rang apunta a la seva lliçó del Mòdul 9.

I saps tractar les proves intermitents com el que són: errades reals que destrueixen la confiança en la suite. Amb les vuit causes i les seves solucions, el protocol de no rellançar mai, i la regla d'higiene de cinc execucions seguides abans de tancar una fita.

La fita H5 està tancada. El teu projecte funciona, està provat, es mesura i es vigila sol. Li falta l'única cosa que converteix un repositori en un producte: que altres persones el puguin fer servir. Compilar per a producció sense filtrar ni un secret, triar on allotjar-lo, configurar memòria cau, seguretat i HTTPS, desplegar de manera contínua amb possibilitat de revertir, i vigilar-lo quan ja no és a la teva màquina, és Desplegament del Projecte.