Fa quatre mòduls que arrosseguem un npm test que falla a propòsit. Avui s'acaba. Instal·lem Mocha i Chai, configurem l'executor, arreglem l'script test del package.json i escrivim la bateria unitària del domini d'Escena Viva: Sessio, Esdeveniment, GestorDeVendes i —la promesa pendent des del mòdul 8— la matriu sencera de src/autoritzacio/politica.js recorreguda cel·la per cel·la.

1. Instal·lar la pila i arreglar l'script test
2. Anatomia d'un fitxer de proves
3. Els ganxos i el seu ordre d'execució exacte
4. Enfocar i saltar proves
5. Chai: estils i catàleg d'assercions
6. Assercions sobre errors
7. Proves asíncrones i timeouts
8. La bateria unitària d'Escena Viva
9. Fàbriques de dades de prova

La versió importa: Chai 5 només publica ESM i no es carrega amb require(). Com que Escena Viva és CommonJS, fixem la 4; si veus "chai": "^5..." tindràs ERR_REQUIRE_ESM a la primera execució.

Les opcions de l'executor van a .mocharc.json, a l'arrel, perquè siguin visibles per a l'equip i per al servidor d'integració contínua:

L'última mereix comentari. Si Mocha acaba però el procés no mor, és perquè alguna cosa continua viva: una connexió a Mongo, un setInterval, un servidor escoltant. "exit": true amaga el problema; false t'obliga a tancar bé els recursos. A 09-06 veurem com diagnosticar què ha quedat obert.

I ara, per fi, l'script que fa des del mòdul 5 que falla. Al costat dels que ja existien (start, dev, llavor, lint, format, auditoria), hi afegim:

Ja no cal passar rutes: Mocha llegeix .mocharc.json. test:veure reexecuta en desar, que és la manera de treballar mentre desenvolupes. npm test respon ara 0 passing amb codi de sortida 0: el primer verd del projecte.

Mocha exposa globals (describe, it, before...) sense importar-les; Chai sí que s'importa.

describe agrupa i s'imbrica lliurement: per convenció l'exterior anomena la unitat i els interiors el mètode o l'escenari. it és una prova: passa si la funció acaba sense llançar, falla si llança (i una asserció de Chai incomplerta llança). Regla d'estil: no facis servir funcions fletxa si necessites el this de Mocha (per exemple this.timeout(10000)), perquè les fletxes no tenen this propi.

Amb un describe exterior que té els quatre ganxos i la prova A, i un describe interior amb els seus quatre ganxos i les proves B i C, la traça real és exactament aquesta:

Les tres regles que se'n dedueixen: els beforeEach s'executen de fora cap a dins i els afterEach de dins cap a fora, com una pila; el beforeEach exterior s'executa també per a les proves dels blocs interiors (font habitual del «per què es reinicia el meu objecte?»); i el before interior no s'executa fins a la primera prova d'aquell bloc.

Què posar a cadascun: a before, només allò car i immutable, mai estat que les proves hagin de mutar. A beforeEach, la preparació, perquè si dues proves comparteixen un objecte mutable tard o d'hora es trepitjaran. A afterEach, la neteja obligatòria (sinon.restore(), esborrar col·leccions, restaurar rellotges): Mocha l'executa encara que la prova falli, i per això és el lloc correcte. A after, tancar el que va obrir before, o el procés no acabarà.

L'error clàssic amb .only és oblidar-se'l, pujar-lo i que CI passi en verd executant una sola prova. Per això hi hem posat forbidOnly: true: un .only oblidat trenca CI de manera sorollosa en comptes de mentir en silenci (en local es desactiva amb mocha --forbid-only=false).

Les proves pendents són una manera honesta de deixar escrit el comportament que falta: apareixen a l'informe, així que no s'obliden com un TODO. Existeix a més el salt condicional, before(function () { if (!process.env.MONGODB_URI_TEST) this.skip(); }), útil quan una prova requereix un servei que pot no estar-hi.

Chai ofereix tres estils per dir el mateix: assert.equal(a, b), expect(a).to.equal(b) i a.should.equal(b). Farem servir expect perquè es llegeix gairebé com una frase, no modifica Object.prototype (a diferència de should, que peta amb null i undefined) i els seus missatges de fallada inclouen el valor esperat i l'obtingut.

Regla mnemotècnica: equal per a primitius, deep.equal per a tot el que s'escrigui amb claus o claudàtors. Quan vegis expected { id: 'evt-001' } to equal { id: 'evt-001' } amb dos objectes aparentment idèntics, et falta el deep.

Amb la jerarquia del mòdul 6, comprovar només que «alguna cosa ha llançat» és insuficient: si vendre(0) llancés un TypeError intern en lloc de l'ErrorDeValidacio esperat, una prova fluixa passaria igualment. L'escala va de to.throw() a seques (fluixa), a to.throw(ErrorDeValidacio) (millor), a to.throw(ErrorDeValidacio, /enter/) (tipus i missatge).

Però el que de veritat viatja al client és el codi, del qual depèn l'estat HTTP a través d'ESTAT_PER_CODI. El patró de captura permet fer-hi assercions:

L'expect.fail(...) és imprescindible: sense ell, si vendre(5) no llancés, el catch no s'executaria, capturat continuaria sent null i les assercions fallarien amb un missatge confús. Quan n'hi ha prou amb una propietat hi ha versió compacta: expect(() => sessio.vendre(5)).to.throw(ConflicteDEstat).with.property('codi', 'AFORAMENT_INSUFICIENT').

Mocha ofereix tres mecanismes: async/await a l'it (la forma correcta), retornar la promesa (equivalent) i el callback done, herència de l'era pre-promeses que continua sent la millor opció per a esdeveniments que s'emeten en el futur.

Veuràs done en acció unes pàgines més avall, amb GestorDeVendes. Els seus paranys: si no el crides mai la prova mor per timeout amb un missatge genèric; si una asserció falla dins del callback pot no atribuir-se a la prova correcta; i no el barregis mai amb async (Mocha llança Resolution method is overspecified).

Mocha dona l'it per bo immediatament i l'asserció s'avalua en el buit: si falla, apareixerà com un unhandledRejection sense relació aparent amb la prova, o directament no apareixerà. Regla: si al cos d'un it apareix async o .then, l'it ha de ser async i ha d'esperar.

Per provar que una promesa es rebutja serveix el mateix try/catch amb expect.fail, o el complement chai-as-promised (npm i -D chai-as-promised@7 i chai.use(chaiComPromeses)), que afegeix await expect(promesa).to.be.rejectedWith(RecursNoTrobat). Compte amb l'await davant d'expect: sense ell tornes a tenir una promesa no esperada i la prova passa sempre. És el mateix parany disfressat.

El missatge Error: Timeout of 2000ms exceeded significa una de tres coses, per freqüència: t'has oblidat el done() o has retornat una promesa que no es resol mai; l'operació és realment lenta (base de dades, bcrypt amb cost 12); o hi ha un interblocatge esperant un esdeveniment que ningú no emet. S'ajusta per bloc (describe('...', function () { this.timeout(10000); })), per prova, o es desactiva amb this.timeout(0) mentre depures. No apugis el timeout global per tapar una prova lenta: convertiries un interblocatge de dos segons en una espera de trenta.

Hi faltarien les propietats derivades (ocupacio amb be.closeTo, preuEuros, exhaurida en fals), que segueixen el mateix motlle. El cas frontera —vendre exactament les últimes tres— és el <= contra < que un dia s'escriu malament i provoca una sobrevenda d'una entrada.

Esdeveniment és un agregat, així que les seves proves van sobre les sumes i sobre la reconstrucció: aforamentTotal és 800 i venudesTotals 350 amb dues sessions de 400 i 100/250 venudes; exhaurit és false si una sola sessió encara té lloc; i Esdeveniment.desDeJSON({ id, titol, salaId, sessions }) retorna una instanceOf(Esdeveniment) les sessions de la qual són instàncies de Sessio amb el seu lliures ja calculat, a més de llançar si el JSON no porta identificador. És el mateix patró que a Sessio: escenari mínim, una operació, asserció sobre el valor observable.

La prova promesa al mòdul 8. Com que tePermis, potGestionarEsdeveniment i potVeureComanda són funcions pures, recorrem la matriu completa amb taules de casos i bucles:

Disset cel·les recorregudes amb dos bucles de tres línies, casos límit inclosos. La sortida de Mocha es llegeix com una especificació de seguretat, i si algú inverteix un if a potGestionarEsdeveniment, diverses proves es posen vermelles anomenant exactament el problema.

GestorDeVendes és un EventEmitter, així que provem que emet el que ha d'emetre:

Amb un beforeEach(() => { gestor = new GestorDeVendes(); }) al davant i una tercera prova anàloga per a sessio-exhaurida. Hi conviuen dues tècniques: done per a l'esdeveniment asíncron i recollir en una variable per als síncrons, que permet comptar quantes vegades s'ha emès. La segona és la mena de regla que ningú no recorda en refactoritzar sis mesos després.

Repetir el constructor complet a cada prova és soroll: amaga quina dada és rellevant per a cada cas. La solució són fàbriques amb valors per defecte i sobreescriptura parcial:

Tres propietats fan bona una fàbrica: retorna sempre un objecte nou (res de constants compartides), els seus valors per defecte són vàlids (crearSessio() sense arguments produeix una sessió utilitzable) i la sobreescriptura fa visible el que és rellevant (crearSessio({ venudes: 398 }) diu sense soroll que aquesta prova tracta de l'aforament gairebé ple).

Executa ara npm test: 38 passing (52 ms). Aquesta és la velocitat de les proves unitàries sobre domini pur, i la raó que la base de la piràmide sigui tan ampla.

• ERR_REQUIRE_ESM en importar Chai. Ets a Chai 5 amb CommonJS. Instal·la chai@4.
• Fer servir equal amb objectes. La fallada mostra dos objectes idèntics i et torna boig: necessites deep.equal.
• Resolution method is overspecified. Has posat done i async al mateix it. Tria'n un.
• Un .only oblidat. CI passa en verd executant una prova. Activa forbidOnly.
• this.timeout() en una funció fletxa. No funciona: fes servir function ().
• Preparar a before en comptes de a beforeEach. La primera prova muta l'objecte i les següents el reben brut. Si dubtes, beforeEach.
• Assercions que no s'executen. Tota prova amb try/catch necessita el seu expect.fail al camí feliç.
• Consell: verifica cada prova nova trencant el codi a propòsit (canvia >= per > a vendre i comprova que es posa vermella), i llança un sol fitxer amb npx mocha test/unitat/sessio.test.js en comptes de tocar .only.

Escriu test/unitat/comanda.test.js amb quatre proves per a Comanda: que el total suma les línies en cèntims, que una comanda acabada de crear està en estat pendent, que no admet més de 6 entrades per sessió i que una comanda sense línies llança. Fes servir una fàbrica local.

A la taula CASOS hi falta PERMISOS.ANULLAR_COMANDA. Afegeix-lo per als tres rols amb aquesta regla: l'assistent pot anul·lar les seves comandes, l'organitzador no, l'administrador sí. Després escriu la prova de potCanviarRol que verifiqui que només l'administrador pot canviar rols i que ningú no es pot canviar el rol a si mateix.

Explica per què aquesta prova passa sempre, fins i tot si cercarPerId retorna null, i reescriu-la:

Exercici 1. Amb una fàbrica local crearComanda(s) que per defecte porta una línia de 2 entrades a 2500 cèntims:

Les altres tres són directes: crearComanda().estat ha de ser 'pendent' amb pagatEl nul; una línia amb quantitat: 7 ha de llançar ErrorDeValidacio amb un missatge que inclogui el 6; i crearComanda({ linies: [] }) també ha de llançar.

Exercici 2. Tres files noves a CASOS (['assistent', PERMISOS.ANULLAR_COMANDA, true], ['organitzador', ..., false], ['administrador', ..., true]) i quatre proves de potCanviarRol amb admin, marta (organitzadora) i lucia (assistent):

L'última és la important: impedeix que l'últim administrador es degradi per error i deixi la plataforma sense ningú que pugui gestionar usuaris.

Exercici 3. L'it no és async i no retorna la promesa del .then, així que Mocha dona la prova per acabada abans que el .then s'executi; si l'asserció falla després, la fallada arriba òrfena. La versió correcta és async, amb await i un expect(esdeveniment).to.not.be.null previ que dona un missatge de fallada molt més clar que un Cannot read properties of null.

npm test està verd. Tenim Mocha configurat amb .mocharc.json, Chai amb l'estil expect, els ganxos amb el seu ordre entès de veritat, el catàleg d'assercions que es fa servir cada dia, la tècnica per comprovar que un error és l'error correcte amb el seu codi, les maneres de provar codi asíncron amb el seu parany de la promesa no esperada, i una bateria real que cobreix el domini i la matriu de permisos completa.

Però fixa't en el que totes aquestes proves comparteixen: cap de les seves unitats no depèn de res extern. Sessio no crida la xarxa, politica.js no consulta la base de dades, GestorDeVendes no mira el rellotge. Per això es proven en mil·lisegons i de manera determinista.

Tan bon punt sortim d'aquesta bombolla, el terreny canvia. canvi-divises.js crida una API amb fetch, generarCodiEntrada fa servir l'any actual, els tokens d'accés caduquen als 15 minuts i els repositoris obren connexions a Mongo. Cap d'aquestes unitats no es pot provar de manera determinista tal com està.

A la lliçó següent, Dobles de Prova amb Sinon, substituirem el rellotge, la xarxa i la base de dades per versions controlades: espies, stubs, mocks i rellotges falsos. I veurem també on és el límit, perquè simular massa produeix proves que només comproven les teves pròpies suposicions.