Les proves de les dues lliçons anteriors són verdes: el domini calcula bé, la matriu de permisos és correcta cel·la per cel·la, el conversor de divises degrada amb elegància. I tot i així, l'API d'Escena Viva podria estar completament trencada.

Considera aquest escenari, que passa de veritat. Algú reordena els middlewares a crearAplicacio i col·loca la ruta de comandes abans que express.json(). Resultat: req.body arriba undefined, l'esquema zod ho rebutja tot i cada compra retorna 400. Quantes proves unitàries ho detecten? Cap. El controlador funciona perfectament quan li passes un req fabricat a mà, l'esquema valida bé el que se li dona, el repositori guarda correctament. Totes les peces estan bé; el cablatge està malament.

Això és el que proven les proves d'integració: que les peces encaixen quan s'executen juntes de veritat.

1. Què integra una prova d'integració
2. supertest i el disseny del mòdul 6
3. La primera prova d'extrem a extrem
4. La base de dades a les proves
5. Aïllament entre proves
6. Autenticar a les proves
7. Provar els camins que importen
8. Provar la concurrència contra la sobrevenda
9. Contracte del format d'error i serveis externs

Una prova d'integració executa diverses capes reals juntes. Una petició a POST /api/comandes recorre això:

Cada fletxa és un punt de fallada invisible per a una prova unitària: middleware mal ordenat o no muntat; una ruta amb el verb o el prefix incorrectes; el gestorDErrors col·locat abans que les rutes i per tant no assolit mai; un esquema zod que valida un camp que el controlador espera amb un altre nom; el repositori retornant un document de Mongoose on s'espera un objecte del domini; la transacció del mòdul 7 que a la pràctica no aïlla el que creiem; i l'estat HTTP real de cada error de la jerarquia.

Què fa supertest, exactament: pren la teva aplicació d'Express, l'arrenca en un port efímer que li assigna el sistema operatiu, fa una petició HTTP real contra aquell port i tanca el servidor en acabar. És una petició de veritat, no una simulació: passa per tots els middlewares, l'enrutador, l'anàlisi del cos i el gestor d'errors. I com que el port és efímer, mai no xocaràs amb un EADDRINUSE encara que tinguis el servidor de desenvolupament al 3000.

Aquí es cobra una decisió del mòdul 6 que aleshores va poder semblar un caprici: src/app.js exporta una factoria que no crida mai listen, i és src/servidor.js qui connecta la base de dades, escolta i gestiona l'aturada ordenada. Gràcies a aquesta separació, la prova és una línia:

Si app.js cridés listen en carregar-se —l'error més comú en projectes d'Express—, cada fitxer de proves obriria un servidor al 3000, el segon fallaria i el procés no acabaria mai. Aquesta és la raó real de la factoria.

L'última té un matís: desactivar els límits està bé, però aleshores cal provar-los en un fitxer a part amb limitar: true, o ningú no comprovarà mai que funcionen.

La tercera és de les més rendibles que existeixen: comprova que la serialització no filtra els camps interns de Mongoose. És una fallada que apareix tan bon punt algú retorna el document cru en lloc de l'objecte del domini, i que ningú no mira fins que un client pregunta què és __v.

El repertori s'encadena: .post(ruta), .set(capcalera, valor), .send(cosJSON), .query({ divisa: 'GBP' }), .expect(estat), .expect('Content-Type', /json/) i .expect((res) => ...) per a una asserció a mida sobre la resposta.

Consell pràctic: fes servir .expect() per a l'estat i les capçaleres, i Chai per al cos, perquè els missatges de fallada de Chai sobre objectes són molt més informatius. I si escrius .expect(200) i el servidor retorna 500, supertest imprimeix els estats però no el cos de l'error: mentre depures, desa la resposta i imprimeix resposta.body.

Aquesta és la decisió de disseny més important de la lliçó.

La nostra elecció: una base real dedicada, escena_viva_test. La prova estrella d'aquesta lliçó és la de concurrència contra la sobrevenda, que depèn del comportament transaccional real del motor: amb SQLite o amb un repositori fals passaria sempre sense demostrar res. A més ja tenim la llavor idempotent del mòdul 7, src/config/index.js és l'únic punt que llegeix process.env —canviar de base és canviar una variable— i a CI s'aixeca un servei amb dues línies.

Creem .env.test amb NODE_ENV=test, MONGODB_URI=mongodb://localhost:27017/escena_viva_test, DATABASE_URL=postgres://escena:escena@localhost:5432/escena_viva_test, un JWT_SECRET de proves, BCRYPT_COST=4, NIVELL_REGISTRE=silent i TZ=UTC. I el carreguem abans que res des del fitxer d'arrencada de Mocha:

L'ordre importa moltíssim. src/config/index.js llegeix process.env en carregar-se i congela el resultat; si dotenv s'executa després del primer require d'un mòdul que importi la configuració, la teva prova es connectarà alegrement a la base de desenvolupament i la buidarà. Carregar-lo des del require de .mocharc.json, abans que qualsevol altra cosa, és la garantia. I com a salvaguarda barata, una funció comprovarBaseDeProves() que llança si configuracio.mongodbUri no inclou _test, invocada abans de qualsevol esborrat.

Les proves no poden dependre de l'ordre en què s'executen. Si la prova B només passa després de l'A, tens una bomba de rellotgeria: el dia que algú afegeixi .only, executi un sol fitxer o activi el paral·lelisme, B fallarà sense motiu aparent.

El seu ús a cada fitxer és beforeEach(sembrarDadesDeProva) i afterEach(netejar). Per què beforeEach i no before: perquè la primera prova que compri entrades modificarà l'aforament i la segona esperaria un número diferent. Sembrar a cada prova costa uns mil·lisegons i compra determinisme.

Compartir estat entre proves és la font número u de proves intermitents, i apareix de tres maneres: un objecte de mòdul mutat per una prova i llegit per una altra, dades a la base que sobreviuen a la prova que les va crear, i una memòria cau en memòria (com la de canvi-divises.js) que no es buida.

Aquí hi ha la promesa del mòdul 8: gairebé totes les rutes interessants exigeixen un usuari autenticat. Com aconsegueix la prova un token vàlid?

La mala idea és fer l'entrada des de la prova amb credencials escrites al codi: fica credencials al repositori (un hàbit que acaba amb una contrasenya real en un commit), és lent perquè cada entrada executa bcrypt a propòsit, acobla tota la bateria al punt d'entrada de sessió —si es trenca fallen cinquanta proves en comptes d'una— i és fràgil davant de qualsevol canvi de la política de contrasenyes.

La bona idea és una ajuda que crea l'usuari que la prova necessita i signa un token amb el mateix servei que fa servir l'aplicació:

Es fa servir desplegant l'array a .set(...): const lucia = await comAssistent() i després request(app).post('/api/comandes').set(...lucia.capcalera), o comOrganitzador('org-almendra') per editar un esdeveniment del Teatro Almendra. En veuràs desenes d'exemples a la resta de la lliçó.

Per què això és correcte i no una trampa: fem servir el mateix signarAcces que fa servir producció, així que el token passa exactament per la mateixa verificació que qualsevol token real —signatura HS256 amb el mateix secret, caducitat, format de la càrrega—. No ens saltem l'autenticació; ens saltem l'entrada de sessió, que és una operació diferent i que es prova a part, una sola vegada, a test/integracio/autenticacio.test.js: credencials vàlides, 401 amb la mateixa latència si el correu no existeix (el hash esquer de bcrypt), 401 amb contrasenya incorrecta i no revelar quina de les dues ha fallat.

La segona prova lliga el món HTTP amb el món de les dades: comprova que la compra ha tingut efecte real i persistent, no només que ha retornat 201.

Cada estat d'error de la jerarquia del mòdul 6 mereix la seva prova:

Hi falten tres germanes evidents, del mateix motlle: el 400 amb un cos que no compleix l'esquema ({ quantitat: 'dos' }, sense sessioId, el error.detalls del qual ha de ser un array amb les fallades de zod), el 401 amb un token manipulat (Bearer no.es.un.token) i el 403 d'un assistent que intenta editar un esdeveniment.

De totes les proves del mòdul, aquesta és la que més val per línia escrita. És la fallada de seguretat més comuna de les APIs REST: un identificador a l'URL que el servidor serveix sense comprovar de qui és.

El 404 en comptes de 403 és deliberat i el vam decidir al mòdul 8: respondre 403 confirmaria al Marc que aquella comanda existeix, informació que no li correspon. La prova fixa aquesta decisió de seguretat perquè ningú no la desfaci creient que millora els missatges d'error. El seu complement és la prova que un administrador sí que pot veure la comanda de qualsevol assistent.

Aquesta prova valida tota la feina transaccional del mòdul 7, i no hi ha manera d'escriure-la que no sigui d'integració.

L'asserció decisiva és l'última: venudes no supera mai aforament. Si el mòdul 7 hagués implementat la compra amb un llegir → comprovar → escriure sense transacció ni actualització condicional, aquesta prova posaria en evidència la condició de cursa immediatament: les deu compres llegirien «5 lliures», les deu passarien la comprovació i vendríem 20 entrades per a 5 seients.

Dos advertiments honestos: la prova és no determinista en el seu detall —el nombre exacte d'èxits pot variar si la lògica permet compres parcials, així que afirma la invariant i no un repartiment concret— i és lenta, uns quants centenars de mil·lisegons amb base real. Val la pena: és la prova que impedeix vendre una butaca dues vegades.

El format { error: { codi, missatge, estat, detalls } } és un contracte amb qui consumeixi l'API, i val la pena fixar-lo amb una taula de casos:

Val la pena afegir-hi una prova més, que comprova que la resposta d'error no filtra la pila de crides: expect(body.error).to.not.have.property('stack') i expect(JSON.stringify(body)).to.not.include('node_modules'). Filtrar una traça al client revela rutes del servidor, versions de biblioteques i de vegades fragments de consultes, i és una fallada silenciosa que apareix tan bon punt algú «millora» el gestor d'errors per depurar i s'oblida de treure-ho.

En integració provem el nostre sistema complet, però no els serveis de tercers: cridar el proveïdor real de taxes a cada execució produeix proves lentes, intermitents i dependents d'una quota. La tècnica és simular a la vora: mantenir tota la integració real i substituir únicament la crida sortint amb Sinon.

Aquesta prova té un valor enorme: garanteix que una caiguda d'un proveïdor extern no tomba el catàleg, un requisit de negoci real que només una prova d'integració amb la vora simulada pot demostrar.

Nota sobre extrem a extrem amb navegador. Per sobre hi ha el nivell real: un navegador automatitzat que obre el web, busca el Festival de Jazz de Primavera, tria butaques, paga i comprova que l'entrada apareix. Playwright és avui la referència a Node, amb Cypress com a alternativa. És fora de l'abast d'aquest curs, que és de servidor, i hi ha una raó de fons a més del temari: són les proves més cares i fràgils de la piràmide. La recomanació professional és tenir-ne molt poques, només sobre els fluxos que enfonsen el negoci, i resoldre la resta als nivells de sota, que és el que hem fet.

• Apuntar a la base de desenvolupament. Es descobreix quan desapareixen les dades. Carrega .env.test des del require de Mocha i comprova _test abans de qualsevol esborrat.
• Oblidar l'await a supertest. request(app).get('/api/esdeveniments').expect(200) sense await retorna una promesa: la prova passa sempre. És el parany de 09-02 disfressat.
• Deixar els límits de peticions actius. La prova de concurrència rep 429 en lloc de 409 i en culpes la transacció.
• Sembrar a before en comptes de beforeEach. Cada compra altera l'aforament i la segona prova espera un número que ja no és el seu. I no facis l'entrada de sessió a cada prova: bcrypt és lent a propòsit, per a això hi ha l'ajuda d'autenticació.
• No tancar la connexió en acabar. Amb "exit": false el procés es queda penjat: aquest és l'afterAll amb desconnectar(). I no depenguis de l'ordre d'un array: Mongo no el garanteix sense sort, així que cerca per id amb dades.find(...).
• Consell: quan una prova d'integració falli, imprimeix resposta.body abans que res; el cos de l'error sol dir exactament què ha passat. I executa la bateria dues vegades seguides sense netejar a mà: si la segona falla, la teva neteja és incompleta.

Crea test/integracio/limits.test.js amb una aplicació construïda amb limitar: true. Escriu una prova que repeteixi POST /api/autenticacio/entrada fins a superar limitEntrada i comprovi que l'última retorna 429 amb el seu codi i la capçalera Retry-After. Pensa com evitar que aquest fitxer contamini els altres.

Escriu les proves del refresc rotatori del mòdul 8: que POST /api/autenticacio/refrescar amb una galeta vàlida retorna 200 i una galeta nova diferent; que reutilitzar la galeta antiga després de rotar-la retorna 401 i revoca la família sencera; i que després de la revocació ni tan sols la galeta nova funciona.

Escriu les proves de GET /api/esdeveniments/:id/informe, que només pot consultar l'organitzador propietari de la sala o un administrador. Cobreix 200 per a l'organitzador propietari, 403 per al d'una altra sala, 403 per a l'assistent, 401 sense token, 200 per a l'administrador i 404 per a un esdeveniment inexistent demanat per un administrador.

Exercici 1

La contaminació s'evita fent servir una instància pròpia de l'aplicació (cada crearAplicacio crea els seus propis comptadors d'express-rate-limit) i no reutilitzant-la en altres fitxers. Si el magatzem de límits fos extern —Redis, mòdul 10—, caldria buidar-lo a afterEach.

Exercici 2

És una de les proves més valuoses del projecte: la detecció de reutilització és lògica de seguretat subtil que ningú no recorda sis mesos després i que una refactorització ben intencionada pot desactivar sense que es noti.

Exercici 3

Les altres quatre són del mateix motlle: 403 per a l'organitzador d'org-boveda, 403 per a l'assistent, 401 sense token i 200 per a l'administrador. Fixa't en l'ordre que revelen aquestes proves: primer autenticació (401), després autorització (403) i només aleshores existència (404). Si el 404 es comprovés abans que el 403, un assistent podria esbrinar quins identificadors d'esdeveniment existeixen sondejant l'API.

Hem pujat un nivell a la piràmide i hem guanyat el que les proves unitàries no podien donar: la certesa que les peces encaixen. Ara sabem que les rutes estan muntades, que els middlewares s'executen en l'ordre correcte, que el gestorDErrors tradueix cada error de la jerarquia al seu estat HTTP i al seu format de contracte, que l'aforament es descompta de veritat a la base de dades, que un assistent no pot veure la comanda d'un altre, i que deu compres simultànies per cinc butaques venen cinc butaques.

I hem resolt la promesa del mòdul 8 amb test/ajudes/autenticacio.js: una ajuda que crea l'usuari amb el rol necessari i signa un token vàlid amb el mateix servei que fa servir l'aplicació, sense ni una sola contrasenya escrita al codi i sense pagar el cost de bcrypt a cada prova.

Ens queda una pregunta incòmoda. Tenim moltes proves, però cobreixen el que importa? Hi ha branques del codi que cap it no ha executat mai? Quant triga la bateria i què passarà quan trigui el triple? Com s'assegura l'equip que ningú no puja codi amb les proves vermelles?

A la lliçó següent, Cobertura i Automatització de les Proves, mesurem què estem provant de veritat amb c8, fixem llindars que només poden pujar, organitzem els scripts d'npm, aprenem a caçar una prova intermitent i deixem el projecte a punt perquè un servidor d'integració contínua executi tot això sense intervenció humana.