El mòdul 8 va acabar amb una pregunta incòmoda: quan demà canviïs una línia de Papyrus — un descompte nou, un camp més a vendes.csv — com garanteixes que tot continua funcionant? Els type hints de mypy verifiquen que els tipus encaixen, però no que preu_final() retorni 12.35 € i no 12.36 €. Comprovar-ho a mà cada vegada no escala. La resposta de l'enginyeria de programari és escriure codi que comprova el codi: proves. En aquesta lliçó entendràs per què són imprescindibles, quina anatomia té un test i què val la pena provar primer — abans de tocar cap framework.

1. El cost d'un bug: el matí que l'Anna va trencar el preu de soci
2. Què és una prova: el patró AAA (preparar-actuar-comprovar)
3. assert a pèl: la primera eina i els seus límits
4. El precursor artesanal: if __name__ == "__main__"
5. Tipus de prova i la piràmide
6. Què provar primer: casos feliços, límits i errors esperats
7. Qualitats d'un bon test

Un dimarts, l'Anna decideix "endreçar una mica" el mètode preu_final() de models.py. L'original ho calculava tot en una expressió; ella ho separa en passos i, de passada, arrodoneix el resultat intermedi "perquè quedi més net":

Sembla inofensiu. Però per a L'Odissea (12.50 €), el preu de soci correcte és 12.50 × 0.95 × 1.04 = 12.35 €. Amb l'arrodoniment intermedi: 12.50 × 0.95 = 11.875 → round → 11.88 → × 1.04 = 12.3552 → 12.36 €. Un cèntim de més. L'Anna no se n'adona: ho va provar mentalment amb Hamlet, on el doble arrodoniment casualment dóna el mateix resultat. Una setmana després, la sòcia Júlia reclama, i el tancament_de_caixa() fa set dies que no quadra.

La lliçó no és "l'Anna és descuidada". És que el cost d'un bug creix brutalment com més tard es detecta:

Un test que hagués fixat per escrit «el preu de soci de L'Odissea és 12.35» hauria detectat el bug en segons. Això és exactament el que aprendrem a escriure.

Una prova (test) és un fragment de codi que executa un altre fragment de codi amb entrades conegudes i comprova que el resultat coincideix amb l'esperat. Gairebé tots els tests del món segueixen la mateixa estructura en tres passos, anomenada patró AAA per les sigles en anglès (Arrange, Act, Assert):

En codi, amb el que ja saps del curs:

Fixa't en tres detalls:

• Cada test comprova una cosa. Si aquest test falla, saps exactament què s'ha trencat: el preu de soci de L'Odissea.
• El valor esperat està escrit a mà (12.35), no calculat amb la mateixa fórmula que el codi provat. Si copiessis la fórmula, el test tindria el mateix bug que el codi i no fallaria mai.
• El missatge de l'assert (la f-string després de la coma) et diu què ha passat sense obrir el depurador.

La sentència assert la coneixes del __post_init__ de Llibre i de validacions puntuals: si la condició és falsa, llança AssertionError. Només amb això ja pots escriure un script de comprovació:

Això ja és provar, i és infinitament millor que res. Però té límits seriosos:

Els frameworks de testing (unittest a 09-02, pytest a 09-03) existeixen precisament per resoldre aquesta llista: descobreixen els tests, els executen tots, els aïllen entre ells i produeixen un informe llegible.

Al mòdul 3, quan vam crear papyrus_utils.py, vam afegir al final del fitxer un bloc if __name__ == "__main__": amb una "mini-demo": unes crides d'exemple que només s'executaven en llançar el mòdul directament, no en importar-lo. Allò era, sense saber-ho, l'ancestre d'un test: codi que exercita el mòdul amb dades conegudes.

La diferència clau: aquella demo imprimia i un humà jutjava amb els ulls si el resultat era correcte. Un test afirma (assert) i és el mateix programa qui jutja. Aquest salt — de "mirar la sortida" a "codificar l'expectativa" — és tota l'essència del testing. Tota la resta (frameworks, fixtures, TDD) és maquinària al voltant d'aquesta idea.

No totes les proves operen al mateix nivell. La classificació clàssica en distingeix tres:

La proporció recomanada es dibuixa com una piràmide: base ampla de tests unitaris (ràpids i barats), capa mitjana d'integració, i una punta fina d'E2E (lents, fràgils, cars de mantenir):

En aquest mòdul ens centrarem en la base de la piràmide — les unitàries — amb alguna incursió en integració (provar tancament_de_caixa contra un CSV de prova). Les proves E2E d'una aplicació web les veuràs de passada quan Papyrus arribi a la web al mòdul 10.

Davant d'una funció, quins casos mereixen test? Hi ha tres famílies, per ordre de prioritat:

1. El cas feliç (happy path): la funció usada com s'espera, amb dades normals.
2. Els límits: les vores on nien els bugs — zero, u, exactament-el-màxim, buit.
3. Els errors esperats: les entrades invàlides han de fallar tal com està documentat (les excepcions del mòdul 7 són part del contracte!).

Apliquem-ho a les dues funcions estrella de Papyrus. Per a Llibre.preu_final:

I per a vendre(cataleg, titol, unitats), que té un contracte més ric (el vam blindar al mòdul 7):

Observa la fila d'EstocInsuficientError: el test no només comprova que l'excepció salta, sinó que no hi ha hagut efectes secundaris (l'estoc no ha canviat). Recorda de 08-04 que vendre muta el catàleg al final precisament per garantir això — i un test és la manera que aquesta garantia no es perdi en un refactor futur.

No qualsevol codi amb assert és un bon test. Els bons comparteixen quatre qualitats:

• Ràpid: la suite sencera ha de córrer en segons. Si triga, deixaràs d'executar-la, i un test que no s'executa no protegeix res.
• Aïllat: cada test munta el seu propi escenari i no depèn d'altres tests ni de l'ordre d'execució. L'script artesanal d'abans violava això: el segon bloc heretava el catàleg mutat pel primer.
• Repetible: el mateix resultat avui, demà i al portàtil d'en Lluís. Res de dependre de l'hora actual, de la xarxa o del dades/cataleg.csv real (a 09-03 veuràs tmp_path per a això).
• Llegible: un test és documentació executable. test_vendre_sense_estoc_llanca_error_i_no_muta_cataleg explica el contracte millor que un paràgraf de comentaris.

• Provar només el cas feliç. Els bugs viuen a les vores: estoc 0, llistes buides, títols inexistents. Si els teus tests només proven el normal, protegeixen poc.
• Calcular el valor esperat amb la mateixa fórmula que el codi provat. assert preu == round(12.50 * 0.95 * 1.04, 2) repetiria el bug si la fórmula està malament. Escriu el número literal: 12.35.
• Comparar floats amb == alegrement. Aquí funciona perquè preu_final arrodoneix a 2 decimals, però 0.1 + 0.2 == 0.3 és False (ho vas veure a M1). A 09-02 i 09-03 coneixeràs assertAlmostEqual i pytest.approx.
• Tests que depenen de dades reals. Si el teu test llegeix dades/cataleg.csv, fallarà el dia que l'Anna afegeixi un llibre. Crea les dades dins del test.
• Confiar en assert per a validacions de producció. Recorda: python -O els elimina. Per validar entrades d'usuari, llança excepcions (ValueError); reserva assert per a tests i invariants internes.
• Consell: quan trobis un bug a mà, escriu primer el test que el reprodueix i després corregeix-lo. Aquest test de regressió evitarà que el bug torni (ho sistematitzarem a 09-05).

Escriu, amb assert a pèl i seguint el patró AAA (comenta cada pas), tres comprovacions per a Llibre.preu_final: (a) El Quixot sense soci, (b) El Quixot amb soci, (c) Faust amb soci. Calcula a mà els valors esperats amb les constants canòniques (DESCOMPTE_SOCI=0.05, IVA_LLIBRES=0.04, arrodoniment a 2 decimals).

Sense escriure codi: dissenya en una taula (família / cas / resultat esperat) els casos de prova de reposar(cataleg, titol, unitats) -> None, seguint el model de la taula de vendre. Inclou com a mínim un cas feliç, un límit i dos errors esperats.

Classifica cada escenari com a prova unitària, d'integració o end-to-end: (a) hi_ha_estoc() retorna False quan estoc == 0; (b) tancament_de_caixa() suma correctament un vendes.csv de tres files creat per a la prova; (c) simular una jornada completa de Papyrus: carregar catàleg des de fitxer, vendre 3 llibres, reposar-ne 2 i tancar caixa comprovant el total; (d) EstocInsuficientError guarda titol, demanat i disponible als seus atributs.

Exercici 1

Fixa't com cada valor esperat és un literal calculat a mà, no la fórmula.

Exercici 2

Exercici 3: (a) unitària — un mètode aïllat; (b) integració — col·laboren el lector de CSV, el parseig i la suma contra un fitxer real (de prova); (c) end-to-end — recorre el sistema complet com ho faria l'Anna; (d) unitària — comprova una classe d'excepció aïllada.

Ja tens el mapa: un test és codi que fixa per escrit el que el programa ha de fer — preparar, actuar, comprovar — i el bug de l'Anna va demostrar que detectar un error en segons costa infinitament menys que detectar-lo quan la Júlia reclama. Saps que l'assert a pèl funciona però no escala (s'atura a la primera fallada, no informa, no aïlla), que la piràmide mana moltes proves unitàries i poques E2E, i que cal cobrir casos feliços, límits i errors esperats amb tests ràpids, aïllats, repetibles i llegibles. El if __name__ == "__main__" del mòdul 3 va ser el nostre precursor artesanal; ara toca l'eina industrial. A la propera lliçó, la biblioteca estàndard ens dóna el primer framework complet: unittest, amb classes de test, asercions especialitzades (inclosa una per als floats dels nostres preus) i un executor que descobreix i corre tota la suite amb una sola ordre.