L'API d'Escena Viva ven entrades, persisteix comandes amb transaccions que impedeixen la sobrevenda, autentica usuaris, rota tokens de refresc i autoritza operacions segons rols i propietat del recurs. Fa moltíssimes coses. I ningú no ha comprovat mai que funcioni. Ni una sola vegada.

npm test continua fallant a propòsit des del mòdul 5 amb el missatge Sense proves encara — Modul 9, i cada línia de seguretat que vam escriure al mòdul anterior —el hash esquer de bcrypt, la detecció de reutilització del refresc, cada cel·la de la matriu de permisos— descansa avui sobre la confiança que la vam escriure bé. Un if invertit a potGestionarEsdeveniment obriria el catàleg sencer d'esdeveniments a qualsevol organitzador i res no ens n'avisaria.

En aquesta lliçó encara no escriurem la primera prova executable ni instal·larem res: això és la lliçó següent. Aquí construïm els fonaments conceptuals, que és el que separa un projecte amb moltes proves d'un projecte amb bones proves.

1. Per què es prova: canviar el codi sense por
2. Què és una prova automatitzada i l'estructura AAA
3. Tipus de prova i la piràmide
4. Què s'ha de provar i què no: el criteri del risc
5. Què fa bona una prova
6. Proves fràgils i falsos positius
7. TDD explicat amb honestedat
8. El panorama d'eines per a Node
9. El pla de proves d'Escena Viva

Hi ha una idea molt estesa que les proves serveixen «per si de cas», com una assegurança que potser algun dia es cobrarà. És una descripció pobra i explica per què tants equips les abandonen al cap de tres setmanes. El valor real d'una bateria de proves és un altre i és mesurable en el dia a dia: et retorna la capacitat de modificar el codi.

Fem la prova del cotó fluix amb el nostre propi projecte. Respon amb honestedat:

• T'atreviries avui a reescriure comprarEntrades per agrupar diverses sessions en una sola comanda?
• T'atreviries a refactoritzar PERMISOS_PER_ROL per afegir el rol taquiller sense revisar manualment les 30 combinacions?
• T'atreviries a canviar l'ordre de dos middlewares a crearAplicacio perquè autenticar s'executi abans que limitCompra?
• T'atreviries a pujar la versió major de Mongoose?

Si la resposta honesta és «no, o només amb molta cura i provant a mà al navegador», el codi ja t'està governant a tu. Aquesta paràlisi té un cost que no apareix en cap factura: les funcions es van copiant en comptes de reutilitzar-se, els if s'acumulen perquè ningú no esborra branques antigues, i el deute tècnic creix perquè tocar el que ja funciona fa por.

Una bateria de proves converteix la pregunta «hauré trencat alguna cosa?» en una ordre de deu segons. Aquest és el producte que comprem en aquest mòdul. Els beneficis secundaris són reals però secundaris:

I hi ha una cosa que les proves no fan, i convé dir-ho des del principi: no demostren que el programa sigui correcte. Demostren que els casos que se't van acudir es comporten com esperaves. És moltíssim, però no és una garantia matemàtica.

Una prova automatitzada és senzillament un programa que executa un altre programa i comprova el resultat, i que acaba amb èxit o amb error sense que ningú miri la pantalla. No hi ha màgia: un fitxer de proves és JavaScript normal.

L'estructura universal es coneix com a AAA (Arrange, Act, Assert), que en català anomenarem preparar, actuar i comprovar:

1. Preparar: construir l'escenari. Dades, objectes, dobles de prova, estat inicial.
2. Actuar: executar exactament una operació, la que s'està provant.
3. Comprovar: verificar que el resultat observable és l'esperat.

Vegem el primer exemple sobre una peça real del nostre domini, Sessio.vendre(). Encara no és codi executable amb Mocha —falta la instal·lació—, però l'anatomia ja és la definitiva:

Tres observacions importants sobre aquest esbós:

• La preparació és explícita i local. No llegim la sessió de la base de dades ni depenem de la llavor. Si demà algú canvia l'aforament de ses-001-1 a scripts/llavor.js, aquesta prova continua sent vàlida. Una prova que depèn de dades llunyanes és una prova que fallarà per motius aliens al que diu que prova.
• Actuar és una sola línia. Si necessites cinc crides per actuar, probablement estiguis provant cinc coses i la fallada no et dirà quina.
• Comprovem el comportament observable, lliures, no el camp privat #venudes. De fet no podríem: és privat. Això és un avantatge, no un obstacle.

Un quart pas implícit, la neteja, apareixerà quan hi hagi recursos per alliberar (connexions, rellotges falsos, fitxers). Al domini pur no cal, i aquest és justament el seu encant.

No totes les proves costen el mateix ni detecten el mateix. Aquesta taula és el mapa del mòdul sencer:

Les tres primeres formen la piràmide de proves: moltes unitàries a la base, bastants d'integració al mig, molt poques d'extrem a extrem a la punta.

La forma no és un caprici estètic: és economia. Una prova unitària de potGestionarEsdeveniment triga menys d'un mil·lisegon i, quan falla, t'assenyala una funció concreta. Una prova d'extrem a extrem del mateix permís triga deu segons, pot fallar perquè el navegador ha trigat a carregar, i quan falla et diu «el botó no apareixia», que pot significar cinquanta coses diferents.

Quan un equip inverteix la piràmide —moltíssimes proves d'extrem a extrem, algunes d'integració, gairebé cap d'unitària— obté l'anomenat con de gelat. És un desastre reconeixible pels seus símptomes:

• La bateria triga 40 minuts i la gent deixa d'executar-la en local.
• Un canvi d'una línia en una plantilla trenca trenta proves.
• Apareixen proves intermitents (flaky): fallen una de cada cinc vegades sense motiu aparent.
• Com que fallen sovint per soroll, l'equip comença a reintentar fins que passin. En aquell moment la bateria ha deixat d'aportar informació i només aporta espera.

La regla pràctica: cada comportament es prova al nivell més baix que pugui demostrar-lo. Puja de nivell només quan el nivell inferior no pot veure el problema.

Provar-ho tot és impossible i perseguir-ho produeix bateries cares que envelleixen malament. El criteri que farem servir és el risc, entès com a probabilitat de fallada multiplicada pel dany que causaria.

Sí que es prova:

• Lògica de negoci amb regles. Sessio.vendre() valida quantitat, aforament i estat. Si s'equivoca, venem entrades que no existeixen.
• La matriu de permisos. Un error aquí és una bretxa de seguretat silenciosa.
• Càlculs. Totals en cèntims, límits de 6 entrades per comanda, ocupació, llindar d'aforament baix.
• La gestió d'errors. Que RecursNoTrobat acabi sent un 404 amb el format { error: { codi, missatge, estat, detalls } }.
• Casos límit i de frontera. Vendre exactament les últimes entrades, vendre'n una més, quantitat zero, quantitat negativa.
• Tota fallada que hagi passat en producció. Abans d'arreglar-la, una prova que la reprodueixi. Hi tornarem a 09-06.

No es prova (o es prova molt poc):

• Getters trivials. Si get preuEuros() { return this.preuCentims / 100; } mereix una prova és discutible; si tingués arrodoniment, sí, perquè aleshores hi ha una decisió.
• Biblioteques de tercers. No és feina teva comprovar que Express enruta o que bcrypt fa el hash. Sí que ho és comprovar com les fas servir.
• Configuració estàtica. Que PERMISOS tingui cinc claus no diu res; que un rol pugui o no usar-les, sí.
• Detalls d'implementació. Que un mètode cridi internament un altre mètode privat no és un comportament; és una decisió que vols poder canviar.
• Codi generat. Migracions autogenerades, fitxers d'arrencada trivials.

Quatre propietats, en ordre d'importància:

1. Ràpida. Si la bateria unitària triga més d'uns quants segons, deixaràs d'executar-la mentre programes.
2. Determinista. El mateix codi amb la mateixa entrada dona sempre el mateix resultat. Res de Date.now(), Math.random(), xarxa o dependència de l'ordre. Tot això ho domesticarem amb Sinon a 09-03.
3. Aïllada. No depèn que una altra prova s'hagi executat abans ni deixa residus per a la següent.
4. Amb un sol motiu de fallada. Quan es posa vermella, ha de quedar clar quin comportament s'ha trencat.

I una cinquena que no és tècnica però decideix si la bateria sobreviu: el nom ha de descriure el comportament esperat, no el mètode invocat. El nom és l'única cosa que veuràs a la sortida quan falli a les tres de la matinada.

Fixa't que tots els noms bons comencen per un verb en tercera persona i descriuen l'efecte observable. Llegits al costat del describe que els conté formen una frase: Sessio vendre — llanca ConflicteDEstat si no queden localitats suficients.

Hi ha dos defectes de qualitat que arruïnen bateries senceres.

Prova fràgil és la que es trenca quan el codi canvia sense que el comportament canviï. Gairebé sempre neix de provar la implementació en comptes del comportament:

Fals positiu (o fals verd) és la prova que passa sempre, fins i tot amb el codi trencat. És pitjor que no tenir prova, perquè genera confiança infundada. Les causes més habituals a Node:

• Una promesa no esperada: l'it acaba abans que l'asserció s'executi. Ho veurem en detall a 09-02.
• Una asserció dins d'un catch que no s'executa mai.
• Simular tant la dependència que la prova només comprova les teves pròpies suposicions (el perill central de 09-03).

Truc professional que farem servir diverses vegades al mòdul: quan escriguis una prova, trenca-la a propòsit. Canvia un signe al codi de producció i comprova que es posa vermella. Una prova que mai no has vist fallar no és una prova, és una esperança.

El desenvolupament dirigit per proves (Test-Driven Development) inverteix l'ordre habitual: primer la prova, després el codi.

Un cicle complet sobre una regla real d'Escena Viva: cap comanda no pot superar les 6 entrades per sessió.

Vermell. Escrivim la prova abans que existeixi la comprovació:

Executem i falla. Aquest pas no és burocràcia: verifica que la prova sap detectar la fallada. Si ja passés en vermell, la prova estaria mal escrita.

Verd. El codi mínim que la satisfà:

Refactor. Ara sí que millorem: extraiem MAXIM_PER_COMANDA a una constant exportada perquè l'esquema zod i el missatge d'error facin servir el mateix nombre, i afegim els detalls de l'error amb el màxim permès. La prova ens protegeix durant el canvi.

I ara l'honestedat promesa:

No és una religió. En aquest curs escriurem algunes proves abans i moltes després, i a 09-06 farem servir TDD de manera estricta per a una cosa concreta en què és indiscutible: reproduir una fallada abans d'arreglar-la.

L'executor natiu es mereix un paràgraf honest. Des de Node 20 és estable i perfectament utilitzable:

Si comencessis un projecte nou avui, node:test és una elecció defensable i sense dependències.

Per què aquest curs fa servir Mocha + Chai + Sinon + supertest: perquè és la pila més estesa a les APIs de Node que et trobaràs en producció, perquè separa amb claredat les tres responsabilitats (executar, afirmar, simular) i això ensenya millor els conceptes, perquè la seva documentació d'errors és explícita, i perquè les idees es traslladen a qualsevol altra pila en una tarda. Un cop triada la pila, no canviarem a mitja lliçó del mòdul: barrejar executors és una font clàssica de confusió.

Aquest és el recorregut del mòdul:

L'estructura de carpetes que crearem, mirall de src/:

Tres convencions que seguirem sense excepció:

• Sufix .test.js a tots els fitxers de prova: fa trivial el patró de cerca de Mocha i distingeix les proves de les ajudes.
• Mirall del codi font: src/domini/sessio.js es prova a test/unitat/sessio.test.js. Trobar la prova d'un fitxer no ha de requerir mai una cerca.
• test/ajudes/ no conté proves, només utilitats compartides: fàbriques de dades i l'ajuda d'autenticació que resoldrà la promesa del mòdul 8.

• Escriure proves per pujar un número. La cobertura és un indicador, no un objectiu. Ho tractarem a fons a 09-05, però interioritza-ho ja: una prova que executa codi sense comprovar res puja la cobertura i no protegeix de res.
• Començar per les proves d'extrem a extrem perquè «proven de veritat». Acabaràs amb el con de gelat i una bateria que ningú no executa.
• Provar mètodes privats. Si sents aquesta necessitat, normalment aquella lògica vol ser una funció pública en un altre mòdul. #venudes es prova a través de lliures i exhaurida.
• Proves que depenen de l'ordre. «Funciona si executes tot el fitxer però falla sola» és el símptoma. Cada it ha de poder executar-se en solitari.
• Reutilitzar objectes entre proves per «no repetir». Compartir un objecte mutable entre it és la causa número u de proves intermitents. Fes servir fàbriques que retornin objectes nous.
• Consell: comença per la capa de més risc i menys cost. A Escena Viva això és src/autoritzacio/politica.js: funcions pures, sense dependències, que protegeixen el més sensible del sistema. Es prova sencera en cinquanta línies.
• Consell: tracta el codi de les proves com a codi de producció. Es llegeix més vegades de les que s'escriu i s'ha de mantenir.

Per a cada comportament d'Escena Viva, indica a quin nivell de la piràmide el provaries i per què:

1. El total d'una comanda de 2 entrades a 2500 cèntims és 5000.
2. POST /api/comandes sense capçalera Authorization retorna 401.
3. Un organitzador d'org-boveda no pot editar evt-001, que pertany a org-almendra.
4. El middleware limitCompra s'aplica abans que el controlador de comandes.
5. generarHashContrasenya fa servir cost 12.

Reescriu aquests noms de prova seguint les regles de la lliçó:

1. test comprarEntrades
2. politica funciona be
3. error 409
4. no peta amb quantitat 0

Escriu (en pseudocodi, sense executar) el cicle vermell-verd-refactor per a aquesta regla nova: una sessió que ja ha començat no admet vendes. Indica quina prova escriuries primer, quin codi mínim la faria passar i què refactoritzaries després.

Exercici 1

1. Unitària. És un càlcul pur al domini; no necessita HTTP ni base de dades.
2. Integració. El 401 neix de la combinació ruta + middleware autenticar + gestorDErrors. Cap prova unitària del middleware no garanteix que estigui realment muntat en aquella ruta.
3. Unitària, amb potGestionarEsdeveniment, perquè és una funció pura i podem recórrer la matriu sencera de manera barata i exhaustiva. A més una prova d'integració de confirmació (403 real per HTTP), no les trenta.
4. Integració. L'ordre dels middlewares només és observable executant l'aplicació real: és exactament el que les proves unitàries no poden veure.
5. Cap, o gairebé. És una constant de configuració. Provar el cost exacte de bcrypt és provar la biblioteca; sí que té sentit una prova que verificarContrasenya accepta el hash que produeix generarHashContrasenya (comportament, no detall).

Exercici 2

1. crea una comanda amb estat pendent i descompta l aforament de la sessio
2. permet a l administrador gestionar qualsevol esdeveniment
3. retorna ConflicteDEstat si les localitats lliures son menors que les sollicitades
4. llanca ErrorDeValidacio si la quantitat es zero

Exercici 3

Vermell: prova rebutja la venda si la sessio ja ha comencat, que crea una sessió amb inici al passat, crida vendre(1) i espera un ConflicteDEstat. Falla perquè vendre no mira la data.

Verd: afegir al principi de vendre una comprovació if (new Date(this.inici) <= new Date()) { throw new ConflicteDEstat('La sessio ja ha comencat'); }.

Refactor: extreure un getter get haComencat() que encapsuli la comparació, reutilitzable pel catàleg per no llistar sessions passades, i injectar el rellotge en comptes de cridar new Date() directament. Aquest últim punt és justament el que fa possible la lliçó 09-03: el codi que depèn del rellotge real no es pot provar de manera determinista.

Hem posat els fonaments. Sabem per què es prova —per poder canviar el codi sense por, no per si de cas—, com s'estructura una prova amb preparar, actuar i comprovar, quins nivells existeixen i per què la piràmide té la forma que té, què mereix prova segons el risc i què no, quines propietats fan bona una prova, com distingir una prova fràgil d'una de robusta, quan TDD ajuda de veritat i quines eines hi ha a l'ecosistema de Node.

També tenim el pla: test/unitat/, test/integracio/, test/ajudes/, fitxers *.test.js, i la pila Mocha + Chai + Sinon + supertest.

El que encara no tenim és ni una sola línia executable. A la lliçó següent, Proves Unitàries amb Mocha i Chai, instal·lem la pila, arreglem d'una vegada l'script test que fa quatre mòduls que falla a propòsit, i escrivim la bateria unitària completa del domini d'Escena Viva, inclosa aquella taula de casos que recorre la matriu de permisos cel·la per cel·la que portem prometent des del mòdul 8.