Amb la v0.20 el projecte ja té historial: pots tornar a qualsevol punt anterior i saps qui va canviar què i per què. Però Git no respon a la pregunta que de debò importa cada vegada que toques una línia: continua funcionant tota la resta? Fins ara la resposta la donaves a mà, engegant python -m tascafacil, creant una tasca, marcant-la, filtrant, desant i sortint, opció per opció. Això costa cinc minuts, es fa malament a la tercera vegada i s'acaba ometent justament el dia que calia. Aquesta lliçó construeix la xarxa de seguretat que falta: proves automatitzades que comproven soles, en menys d'un segon, que el programa fa el que ha de fer. Veuràs el patró que segueixen totes les proves, les dues eines de l'ecosistema Python —unittest, que ve inclosa, i pytest, la que fa servir tothom—, què val la pena provar i què no, i per què la separació entre entrada/sortida i lògica que vam fer a 04-04 era, en realitat, la preparació per a aquest moment.

1. Per què provar
2. Tipus de prova
3. Què fa provable un codi
4. El patró AAA i el nom del test
5. assert: la primera prova
6. unittest, la biblioteca estàndard
7. pytest, l'eina de l'ecosistema
8. unittest davant de pytest
9. Què provar i què no
10. Cobertura
11. TDD: vermell, verd, refactoritzar
12. TascaFàcil v0.21: la carpeta tests/
13. Errors habituals i consells
14. Exercicis
15. Conclusió

Una prova automatitzada és simplement codi que executa el teu codi i comprova que el resultat és l'esperat. Sona a feina extra, i ho és la primera vegada; deixa de ser-ho així que sumes el que costa el contrari:

• Repassar el menú a mà costa minuts a cada canvi, i es fa pitjor amb el temps: al principi comproves els deu casos, a la desena vegada només el que has tocat, i l'error apareix justament en un altre.
• La por paralitza: sense proves, millorar codi que ja funciona sembla una temeritat, així que ningú no el millora i el projecte es podreix.
• Una prova és documentació que no menteix: test_completar_iguala_fets_a_dies explica el comportament esperat millor que qualsevol paràgraf, i si el comportament canvia, la prova falla.

La paraula clau és regressió: un error que apareix en alguna cosa que abans funcionava. Les proves automatitzades són l'única defensa pràctica contra elles, i són el que permet refactoritzar sense por, que és exactament el que farem a Estil i refactorització.

Aquest curs se centra en les unitàries, amb alguna d'integració, i per una raó pràctica: són ràpides, assenyalen amb precisió què està trencat i no depenen de la interfície. Una prova de sistema que recorre el menú es trenca així que canvies un text, i quan falla no diu on és el problema. La proporció sana en qualsevol projecte és la mateixa: moltes unitàries, algunes d'integració, molt poques de sistema.

Aquí es cobra el deute de Descompondre un programa en funcions, on vam separar l'entrada i la sortida de la lògica i vam dir que això permetria provar el codi. Compara aquestes dues versions:

La primera és impossible de provar de manera raonable: per executar-la cal simular el teclat, i per comprovar el resultat cal capturar el que imprimeix. La segona es prova en una línia: progres(2, 4) == 50.0. La regla que se'n dedueix és la que ja coneixes amb un altre nom: les funcions que reben dades i retornen resultats són provables; les que parlen amb el món, no. Per això model.py i agenda.py no tenen ni un sol print, i per això tot el que es pugui comprovar viu allà i no a interficie.py.

Totes les proves del món tenen la mateixa estructura de tres passos, coneguda com a AAA:

1. Arrange (preparar): crear les dades i els objectes que necessita la prova.
2. Act (actuar): executar exactament una cosa, la que s'està provant.
3. Assert (comprovar): verificar que el resultat és l'esperat.

I el nom importa tant com el contingut, perquè és l'única cosa que veuràs quan la prova falli. Un bon nom diu què es prova i què s'espera: test_completar_marca_la_tasca_i_iguala_els_dies t'estalvia obrir el fitxer; test_1 o test_tasca no diuen res. La convenció habitual és test_<que>_<condicio>_<resultat esperat>, i no importa que quedi llarg: els noms de les proves es llegeixen, no s'escriuen a mà.

Abans de fer servir cap eina, assert ja et permet comprovar coses. La seva forma és assert condicio, "missatge si falla": si la condició és certa no passa res, i si és falsa llança un AssertionError amb el teu missatge.

Desat en un fitxer i executat, o passa en silenci o peta assenyalant la línia. És un primer pas perfectament vàlid, i també la raó que a 08-02 diguéssim que el lloc natural de l'assert són les proves. Els seus límits apareixen de seguida: s'atura al primer error sense comprovar la resta, no agrupa res, no dona cap informe i no hi ha manera d'executar-ne només una part. Per a això hi ha les eines.

unittest ve amb Python, així que no hi ha res a instal·lar. Les seves proves són mètodes que comencen per test_ dins d'una classe que hereta d'unittest.TestCase:

Quatre peces que convé entendre. setUp s'executa abans de cada mètode de prova, de manera que cap prova no hereta l'estat d'una altra —hi ha també tearDown, que s'executa després i serveix per netejar—. Els mètodes assertEqual, assertTrue, assertIn comproven igualtat, veritat i pertinença. I assertRaises, fet servir amb with, comprova el contrari de l'habitual: que el bloc sí que llanci aquesta excepció; si no la llança, la prova falla. S'executa des de la carpeta del projecte:

pytest no ve amb Python, però és el que fa servir pràcticament tothom, perquè treu la cerimònia: no calen classes i es comprova amb l'assert normal.

Tres eines noves aquí. pytest.raises fa el mateix que assertRaises. @pytest.mark.parametrize és la més rendible de totes: escriu una prova i executa-la amb quatre jocs de dades, que apareixen com quatre proves independents a l'informe; sense ella hauries escrit quatre funcions gairebé idèntiques. I fixa't en l'últim cas, (8, 4, 100.0): és un cas límit, més dies fets que previstos, exactament el tipus de cosa que la parametrització convida a afegir.

Les fixtures són la manera que té pytest de preparar dades comunes, l'equivalent del setUp. Es declaren amb un decorador i es demanen pel nom com a paràmetre:

I hi ha una fixture incorporada que resol un problema molt real: tmp_path, una carpeta temporal diferent per a cada prova, que Python esborra en acabar. És el que permet provar el desat en fitxer sense tocar el tasques.json de debò:

Això és una prova d'integració: comprova que Agenda, to_dict, from_dict i el mòdul magatzem encaixen entre si. I comprova l'única cosa que importa de la persistència: que el que hi entra en torna a sortir igual (un cicle desar → carregar, o round-trip).

Totes dues són correctes i conviuen: pytest executa també les proves escrites amb unittest. La recomanació pràctica: aprèn unittest perquè el trobaràs en projectes antics i perquè no requereix instal·lar res, i escriu amb pytest perquè és més curt, més llegible i el seu informe d'errors et diu quin valor ha sortit i quin esperaves.

No es prova tot: es prova el que es pot trencar i fa mal. Per a cada funció val la pena cobrir tres famílies de casos:

• Casos normals: el que passa el 90 % de les vegades. Una tasca amb 2 de 4 dies dona 50 %.
• Casos límit: les vores, on viu la majoria dels errors. Zero dies fets, agenda buida, la llista amb un sol element, més dies fets que previstos, textos amb espais o en majúscules.
• Casos d'error: el que ha de fallar i com ha de fallar. Una prioritat inventada ha de llançar TascaInvalida, no retornar None en silenci.

I hi ha un parany clàssic: provar la implementació en lloc del comportament. Una prova que comprova que Agenda desa internament una llista anomenada _tasques es trencarà el dia que canviïs aquesta llista per un diccionari, encara que el programa continuï funcionant perfectament. Prova sempre el que promet la funció —el que retorna, el que llança, com queda l'objecte—, mai les seves entranyes. El senyal d'alarma és fàcil de reconèixer: si en refactoritzar sense canviar el comportament es trenquen les proves, les proves estaven mal escrites.

La cobertura mesura quin percentatge de les teves línies executen les proves. S'obté amb una eina externa:

L'informe llista cada fitxer amb el seu percentatge i les línies que no s'han executat mai, i aquí hi ha la seva veritable utilitat: descobrir branques senceres que ningú no prova —típicament els except—. Però convé entendre'n el límit: la cobertura mesura què s'executa, no què es comprova. Un test que cridi totes les funcions sense ni un assert dona el 100 % i no garanteix absolutament res. Un 90 % amb proves que comproven els casos límit val infinitament més que un 100 % buit. Fes-la servir per trobar buits, mai com a objectiu.

TDD (Test-Driven Development, desenvolupament dirigit per proves) capgira l'ordre habitual: primer s'escriu la prova, i només després el codi que la fa passar. El cicle té tres passos:

Escriure la prova primer obliga a decidir què ha de fer la funció abans de pensar en com, i garanteix que la prova de debò comprova alguna cosa: si mai no l'has vista fallar, no saps si funciona. No cal aplicar TDD sempre —en aquest curs no ho farem—, però hi ha un cas en què és clarament la millor opció: quan arregles un error. Escriu primer una prova que el reprodueixi (vermell), arregla'l (verd) i aquesta prova quedarà per sempre impedint que l'error torni.

Les proves viuen a la seva pròpia carpeta, al costat del paquet:

Els fitxers de tests/ són els que has vist als apartats 6 i 7: test_model.py comprova la validació de Tasca, la normalització del responsable i completar(); test_agenda.py comprova l'ordre d'ordenades(), el filtre per responsable i el cicle desar/carregar amb tmp_path. I aquesta és una execució real, amb un error de debò:

La prova en vermell és el cas límit (8, 4, 100.0): amb més dies fets que previstos, progres() retornava 200 %. L'informe de pytest ho diu tot: quin cas concret ha fallat, quin valor ha sortit (200.0) i quin s'esperava (100.0). L'arreglada és una línia a model.py:

TascaFàcil v0.21: vuit proves que s'executen en cinc centèsimes de segon i verifiquen el que abans exigia recórrer el menú a mà. A partir d'aquí, cada canvi es valida amb una sola comanda, i el projecte acaba de guanyar la xarxa de seguretat que calia per poder-lo millorar sense por. Existeixen a més eines d'integració contínua que executen aquestes mateixes proves automàticament a cada push al remot; queda molt lluny d'aquest curs, però és bo saber que el pas següent existeix.

• Provar funcions que fan input() i print(). No es pot. Extreu la lògica a una funció que rebi dades i retorni un valor, i prova aquesta.
• Proves que depenen les unes de les altres. Cada prova ha de poder executar-se sola i en qualsevol ordre. Per a això hi ha setUp i les fixtures.
• Tocar les dades reals. Una prova que escriu a tasques.json t'esborrarà la feina algun dia. Fes servir tmp_path.
• Provar la implementació, o posar noms com test_1 i test_tasca. Si en refactoritzar sense canviar el comportament es trenquen les proves, estaven mal escrites; i el nom és l'única cosa que veus quan alguna cosa falla.
• Perseguir el 100 % de cobertura. És fàcil de falsejar i no garanteix res. Cobreix els casos límit i els d'error, que és on són els errors.
• Consell: quan trobis un error, escriu primer la prova que el reprodueix. Et confirma que l'has entès i evita que torni mai més.

Aquesta funció no es pot provar. Separa-la en dues —una amb la lògica i una altra amb la conversa— i escriu dues proves amb pytest per a la part lògica, incloent-hi un cas límit:

Escriu les proves d'Agenda.cercar(titol), que retorna la tasca amb aquest títol (sense distingir majúscules) o None si no existeix. Cobreix un cas normal, dos casos límit i comprova també què passa amb una agenda buida. Fes servir una fixture per a l'agenda d'exemple.

Converteix aquestes tres proves gairebé idèntiques en una de sola parametritzada, i escriu a més una prova del cicle desar/carregar fent servir tmp_path:

Solució 1.

El cas límit de les vuit hores exactes és el més valuós, perquè és on viu l'error clàssic: un >= en lloc d'un > cobraria recàrrec per una jornada normal, i només aquesta prova ho detectaria. Fixa't a més que la funció de conversa ha quedat tan simple que ja no necessita prova: l'única cosa que fa és cridar la que sí que està provada.

Solució 2.

Les quatre proves descriuen el contracte complet de cercar: troba, ignora majúscules, retorna None quan no hi ha coincidència i no peta amb una agenda buida. Cap no mira com està desada la col·lecció per dins, així que si demà Agenda canvia la seva llista per un diccionari, aquestes proves continuaran passant: comproven el comportament, no la implementació.

Solució 3.

Tres proves s'han convertit en una que continua executant-se tres vegades, i afegir-hi un quart cas ara costa una línia. La segona prova fa servir tmp_path per escriure en una carpeta temporal: mai no toca el tasques.json real, i la carpeta desapareix en acabar. És una prova d'integració en tota regla, perquè per passar necessiten funcionar Agenda, Tasca.to_dict, from_dict i les dues funcions del magatzem.

Una prova automatitzada és codi que executa el teu codi i comprova el resultat, i el seu valor real és defensar-te de les regressions: errors que apareixen en alguna cosa que abans funcionava. Hi ha proves unitàries, d'integració i de sistema, i la proporció sana és moltes de les primeres i molt poques de les últimes. El que fa provable una funció és exactament el que vam separar a 04-04: rebre dades i retornar valors, sense input() ni print() pel mig. Tota prova segueix el patró AAA —preparar, actuar, comprovar— i porta un nom descriptiu, que és l'única cosa que veuràs quan falli. Amb assert ja es pot comprovar qualsevol cosa, i sobre aquesta base s'aixequen les dues eines: unittest, inclosa a Python, amb classes TestCase, mètodes test_*, assertEqual/assertTrue/assertIn/assertRaises i setUp/tearDown, executada amb python -m unittest discover; i pytest, que s'instal·la amb pip i prescindeix de classes, comprova amb l'assert normal, informa amb detall de quin valor ha sortit i quin s'esperava, i aporta pytest.raises, @pytest.mark.parametrize per executar una prova amb molts jocs de dades, fixtures per preparar el que és comú i tmp_path per provar fitxers sense tocar les dades reals. Es proven els casos normals, els casos límit —on són gairebé tots els errors— i els casos d'error, sempre contra el comportament i mai contra la implementació. La cobertura serveix per trobar buits, no com a objectiu: mesura què s'executa, no què es comprova. I TDD —vermell, verd, refactoritzar— és especialment útil en arreglar un error: primer la prova que el reprodueix, després l'arreglada.

TascaFàcil és ara la v0.21: una carpeta tests/ amb test_model.py i test_agenda.py, vuit proves que s'executen en centèsimes de segon i que ja han trobat un error real —el progrés que superava el 100 %— i l'han deixat arreglat i protegit per sempre. Amb això tens les quatre peces que faltaven en acabar el mòdul 7: documentació, gestió d'errors, historial i proves. Queda una última cosa, i és la que separa un programa que funciona d'un programa del qual un se sent orgullós: com està escrit. Hi ha funcions a interficie.py que han crescut fins a les quaranta línies, números solts repetits per diversos fitxers, noms heretats de quan el programa era un exercici i trossos de codi duplicats. A Estil, llegibilitat i refactorització s'arregla tot això amb PEP 8, amb eines automàtiques i amb un catàleg de refactoritzacions —recolzant-te, precisament, en les proves que acabes d'escriure.