El mòdul anterior acabava amb una afirmació i una pregunta. L'afirmació: la xarxa de Ribalta està protegida. La pregunta: com ho sabem? Sabem que un ciutadà no pot finalitzar el lloguer d'un altre perquè ho hem provat a mà amb curl una tarda de dimarts, i perquè llegint @PreAuthorize ens sembla que diu el que toca. Això no és coneixement: és confiança. I la confiança s'esvaeix així que algú reordena una regla d'authorizeHttpRequests, puja la versió d'una dependència o toca el SelectorTarifa per afegir-hi una tarifa nova.

CicloUrbana té avui una aplicació completa —REST, JPA sobre PostgreSQL, Flyway, seguretat amb JWT— i exactament zero proves: només el contextLoads buit que va generar Spring Initializr a la lliçó 01-04. Aquest mòdul ho corregeix. En aquesta primera lliçó encara no escriurem una suite: construirem el criteri. Què es prova i per què, quins tipus de prova existeixen i què detecta cadascun, com es reparteixen en una piràmide sana, què porta ja spring-boot-starter-test sense afegir res, on es col·loquen els fitxers, com s'anomenen les classes i els mètodes, quina és l'anatomia d'una prova ben escrita, com s'executen, com es mesura la cobertura amb JaCoCo i per què aquesta mètrica enganya si es converteix en objectiu. Al final tindrem escrita la primera prova real del projecte: petita, però verdadera.

1. Per què es prova
2. Els tipus de prova
3. La piràmide de proves i el con de gelat
4. Què val la pena provar i què no
5. spring-boot-starter-test: la caixa d'eines
6. On viuen les proves: estructura i convencions
7. Anatomia d'una prova: Preparar-Actuar-Comprovar
8. Executar les proves
9. Surefire i Failsafe: *Test davant d'*IT
10. Cobertura amb JaCoCo
11. TDD: vermell, verd, refactor
12. Els dobles de prova
13. Errors Comuns i Consells
14. Exercicis

La resposta ingènua és «per trobar errors». És la menys important de les quatre raons reals.

Una regressió és una fallada introduïda en alguna cosa que abans funcionava. És la fallada més cara del cicle de vida d'un programa, perquè ningú no la busca: el canvi es va provar a mà, el canvi funciona, i el que s'ha trencat és tres capes més enllà.

A CicloUrbana hi ha desenes de regressions esperant el seu torn. Aquestes són reals i plausibles:

Cap d'aquests canvis produeix un error de compilació. Tots els detecta una prova escrita una sola vegada i executada mil vegades.

Refactoritzar és canviar l'estructura interna sense canviar el comportament observable. La definició conté un parany: per saber que el comportament no ha canviat cal poder comprovar-ho. Sense proves, «refactoritzar» és un eufemisme de «reescriure i resar», i el resultat pràctic és que ningú no toca el codi lleig: s'acumula, es volta i s'hereta.

Amb una suite decent, el mapejador de 03-05 que consulta repositoris —i que admetíem que estava mal dissenyat— es pot reescriure en una tarda. Sense ella, es queda allà per sempre.

Un comentari menteix així que algú canvia el codi i no l'actualitza. Una prova que menteix falla. El nom d'un mètode de prova ben escrit és una frase del domini:

Llegits a l'informe d'una execució, aquests noms són l'especificació de CicloUrbana, i és una especificació que es compila i es verifica sola.

Aquesta és la raó menys evident i la més valuosa. Un codi difícil de provar és un codi mal dissenyat, i la prova t'ho diu abans que cap revisor.

Si LloguerService cridés LocalDateTime.now() directament, provar «un lloguer de dues hores» exigiria esperar dues hores o manipular el rellotge del sistema. Que a la lliçó 02-01 injectéssim un Clock no va ser elegància gratuïta: va ser dissenyar per poder provar. El mateix val per a la injecció per constructor de 02-02 (permet construir l'objecte en una prova amb col·laboradors falsos), per a la interfície EstacioRepositori de 02-01 (permet substituir la implementació) i per a SeguretatLloguers de 05-05 (una regla de seguretat convertida en un bean normal, comprovable amb una prova unitària).

«Prova» no és una categoria única. Aquestes són les que ens interessen, ordenades de més ràpida i barata a més lenta i cara:

Dos matisos que estalvien discussions estèrils:

• La frontera entre unitària i integració és un continu, no una línia. El que importa no és l'etiqueta sinó dues propietats: si la prova és ràpida i si és determinista. Una prova que triga 40 ms i no toca xarxa ni disc es comporta com a unitària encara que instanciï tres classes reals.
• Les de càrrega i les de contracte queden fora d'aquest mòdul. Les de rendiment apareixeran a 09-01, i les de contracte tenen sentit quan CicloUrbana es parteixi en diversos serveis (07-05 i 07-06). Aquí construïm les quatre primeres files.

La piràmide de proves descriu la proporció sana entre tipus: moltes proves ràpides i barates a la base, molt poques lentes i fràgils al cim.

La lògica de la forma és econòmica. Una prova unitària costa mil·lisegons, així que se'n poden tenir milers i executar-les cada cop que es desa el fitxer. Una E2E costa segons i falla de vegades sense motiu (la xarxa, un temps d'espera, una dada residual), així que cadascuna que hi afegeixes encareix la suite i erosiona la confiança que s'hi té.

El con de gelat és la piràmide invertida: gairebé tot es comprova arrencant l'aplicació sencera —o pitjor, a mà— i tot just existeixen proves unitàries. Els seus símptomes són inconfusibles:

• La suite triga 25 minuts, així que ningú no l'executa en local.
• Hi ha proves que fallen «de vegades» i l'equip les reintenta en lloc d'arreglar-les: són proves escamoses (flaky), i una de sola enverina la confiança en totes les altres.
• Quan alguna cosa falla, el missatge és Expected 200 but was 500 i cal llegir 300 línies de log per saber què s'ha trencat. Una prova unitària et diu quin mètode i quin valor.

La proporció recomanada per a CicloUrbana, atesa la seva mida i la seva forma:

No són percentatges que calgui mesurar amb un full de càlcul. Són un recordatori: si escriure una prova nova t'obliga sempre a aixecar el context d'Spring, el problema no és la prova, és el disseny de la classe.

Escriure proves costa temps i mantenir-les costa més. Gastar-lo bé exigeix dir que no.

Sí que val la pena provar:

• La lògica de negoci amb branques: el càlcul de tarifes amb els seus minuts gratuïts, la regla dels ancoratges mínims, la comprovació del llindar de bateria, el recàrrec per superar la durada màxima.
• Els casos límit i els límits exactes: 0 minuts, 1 minut, exactament 15 minuts amb la tarifa d'estudiant, exactament el llindar de bateria, l'estació amb un ancoratge lliure i amb cap.
• Els camins d'error: què passa quan l'estació no existeix, quan la bicicleta està en manteniment, quan el lloguer ja està finalitzat.
• Les regles de seguretat, sense excepció. Són les que fallen en silenci i les que surten més cares.
• El contracte públic de l'API: els codis d'estat, la forma del JSON, els ProblemDetail de 03-06.
• Tot error trobat en producció: abans d'arreglar-lo, una prova que el reprodueixi. És la regla que impedeix que la mateixa fallada torni dues vegades.

No val la pena provar:

La pregunta que resol gairebé tots els casos dubtosos: «si això es trenca, me n'assabento abans que se n'assabenti un ciutadà de Ribalta?» Si la resposta és «només amb una prova», escriu-la.

Spring Initializr ja va afegir aquesta dependència a 01-03, i és l'única que necessitem per a tot el mòdul tret de dos afegits concrets (seguretat a 06-04 i contenidors a 06-05):

El <scope>test</scope> és essencial: aquestes biblioteques s'usen en compilar i executar src/test/java, i no s'empaqueten al JAR de producció. Un assertThat no pot acabar a l'artefacte desplegat.

El que porta a dins:

Per què no cal afegir dependències soltes. El BOM d'Spring Boot fixa versions compatibles entre si de totes elles. Si afegeixes org.mockito:mockito-core amb una versió pròpia, acabes amb dos Mockito al classpath i errors d'arrencada de l'extensió que costen mig matí de diagnosticar. La regla del projecte: si una cosa ja és al starter, no es declara; i si necessites canviar-ne la versió, es fa amb <mockito.version> a <properties>, que és la palanca que el BOM ofereix per a això.

Comprova què tens realment amb:

Maven separa el codi de producció del de proves en dos arbres paral·lels:

Tres regles que se segueixen sense excepció:

1. La prova viu al mateix paquet que la classe provada, encara que en un altre arbre. Així pot accedir a membres amb visibilitat de paquet sense obrir la classe de producció, i l'arbre de proves és un mirall navegable el de producció.
2. src/test/resources va abans que src/main/resources al classpath de prova. Un application.yml col·locat allà no se suma al de producció: el substitueix del tot. És un error clàssic; la manera correcta de configurar les proves és un perfil (application-test.yml), que veurem a 06-04.
3. Res de src/test/java acaba al JAR. Hi pots crear les classes de suport que vulguis.

Sobre els noms de mètode, la política del curs mereix una justificació. testCalcular1() no diu res: quan falla a la integració contínua a les tres de la tarda, cal obrir el fitxer. rebutjaEstacioQuanLaCapacitatEsMenorQueVuit descriu la regla de negoci de Ribalta, en l'idioma del projecte, i l'informe de fallades es llegeix com una llista de requisits incomplerts. Tres formes vàlides, tria'n una i sigues consistent:

I una nota que evita una fallada desconcertant: a JUnit 5 les classes i els mètodes de prova no cal que siguin public. La visibilitat de paquet és suficient i és la convenció actual. El que sí que continua prohibit és que siguin private o static.

Tota prova ben escrita té tres parts, separades visualment. El patró es coneix com Arrange-Act-Assert (AAA) o Given-When-Then; en aquest curs l'anomenarem Preparar-Actuar-Comprovar:

La primera prova real de CicloUrbana. Provem TarifaEstandard de 02-02: 0,50 € de desbloqueig més 0,12 € per minut.

Cada línia té una decisió al darrere:

• class TarifaEstandardTest, sense public, al paquet com.ciclourbana.lloguers, mirall exacte de la classe provada.
• new TarifaEstandard(): no hi ha Spring enlloc. TarifaEstandard és una classe Java normal que resulta estar anotada amb @Component; l'anotació no impedeix instanciar-la. Aquesta prova s'executa en menys d'un mil·lisegon, i aquesta és exactament la propietat que la fa útil.
• import static ...Assertions.assertThat: l'import estàtic d'AssertJ, present a totes les proves del curs.
• isEqualByComparingTo("4.10") i no isEqualTo(new BigDecimal("4.10")). L'equals de BigDecimal compara també l'escala, de manera que 4.1 i 4.10 no són iguals per a ell encara que valguin el mateix. Amb diners, sempre isEqualByComparingTo. És el primer dels paranys d'AssertJ i es detalla a 06-02.
• El comentari del càlcul esperat: 4.10 no és un número màgic si al costat hi ha l'operació que el produeix. Qui llegeixi la prova d'aquí a un any sabrà si la fallada és al codi o a l'expectativa.

Executem-la:

CicloUrbana té la seva primera prova. És minúscula, i tanmateix ja afirma una cosa que abans només era al cap de qui va escriure la classe.

Vegem ara com falla, que és el que de veritat importa. Si algú canvia PER_MINUT a 0.15:

El missatge diu el nom de la regla incomplerta, el valor esperat i l'obtingut. La qualitat d'un missatge de fallada és una característica de la prova, no un accident, i és la raó principal per la qual aquest curs fa servir AssertJ.

Un advertiment sobre aquesta darrera línia, perquè la diferència es pregunta a cada revisió de codi:

Fes servir sempre la primera. La segona deixa passar proves trencades sense avisar.

Des de l'IDE, el flux quotidià és diferent i millor: el triangle verd al costat del mètode executa aquesta prova en mil·lisegons, i la drecera de «repetir la darrera execució» (Ctrl+Shift+F10 a IntelliJ, Ctrl+F11 a Eclipse) és la que més s'utilitza mentre es programa. L'IDE executa JUnit directament, sense passar per Maven: és molt més ràpid, però no aplica la configuració de Surefire, de manera que una prova pot passar a l'IDE i fallar a ./mvnw test si depèn d'arguments de JVM o de perfils configurats al pom.xml. Abans de pujar res, ./mvnw verify.

Maven té dos connectors de proves, i confondre'ls és la causa que moltes suites no executin mai les seves proves d'integració.

La diferència de comportament davant d'una fallada té una raó pràctica: si una prova d'integració aixeca un contenidor de PostgreSQL (06-05), Failsafe ha d'arribar sempre a la fase que l'apaga; per això no avorta a la primera fallada i deixa que verify sigui qui trenqui la construcció.

Failsafe no ve activat per defecte. S'afegeix així:

I a partir d'aquí, la convenció de CicloUrbana:

Per què separar-les. Si les proves lentes estan barrejades amb les ràpides, la suite sencera triga minuts i deixa d'executar-se durant el desenvolupament; i quan una suite deixa d'executar-se, deixa de servir. Separar-les permet el cicle curt —desar, ./mvnw test, cinc segons— sense renunciar a la comprovació completa abans de pujar el canvi.

La cobertura de codi mesura quin percentatge del codi s'executa durant la suite de proves. JaCoCo l'instrumenta en temps d'execució i genera un informe HTML. Es configura així:

L'informe acoloreix cada línia del codi font: verd si s'ha executat, vermell si no, groc si és una branca de la qual només s'ha recorregut una sortida (un if que sempre es va avaluar a cert). El groc és el color més informatiu: assenyala exactament els casos límit que falten per provar.

Dues mètriques conviuen a l'informe, i només una és interessant:

La cobertura mesura quin codi s'ha executat, no quin comportament s'ha verificat. Aquestes dues coses no s'assemblen gens, i aquí en tens la demostració:

JaCoCo informarà del 100 % de cobertura de les tres tarifes. Si demà algú canvia el preu per minut de 0,12 € a 1,20 €, aquesta prova continuarà passant, i la ciutat de Ribalta facturarà deu vegades de més amb la construcció en verd.

D'aquí la llei de Goodhart aplicada al programari: quan una mesura es converteix en objectiu, deixa de ser una bona mesura. Si l'equip es marca «85 % de cobertura o falla la construcció», el que s'obté són proves sense assercions escrites la tarda abans del lliurament. La política de CicloUrbana:

• La cobertura es mira, no es persegueix. El seu ús correcte és buscar el vermell: un if de negoci sencer sense cobrir és una pregunta legítima.
• Un llindar mínim baix (40–50 %) que només impedeixi el retrocés grosser és defensable; un de alt és contraproduent.
• Molt més valuós que el percentatge global és el percentatge del codi nou, que és el que els sistemes de revisió moderns mostren a cada canvi.

Si tot i així vols un llindar que trenqui la construcció, jacoco:check amb una regla:

El desenvolupament guiat per proves inverteix l'ordre habitual: primer la prova, després el codi. El seu cicle té tres passos i es repeteix en minuts, no en hores.

Aplicat a una regla real de Ribalta —l'ajuntament exigeix que cap estació no tingui menys de 8 ancoratges, la capacitatMinima de XarxaProperties de 02-05:

Vermell. La prova s'escriu abans que existeixi el mètode:

No compila: validarCapacitat no existeix. Això ja és el vermell, i és informatiu: en escriure la crida has dissenyat la signatura del mètode abans d'escriure'l.

Verd. El mínim que la fa passar:

Refactor. Amb la prova en verd, el 8 literal se substitueix per xarxaProperties.capacitatMinima(). Si en fer-ho la prova continua passant, el refactor és correcte; si es trenca, ho has sabut en cinc segons.

Què aporta realment, més enllà de l'eslògan:

I una postura honesta: TDD no és obligatori i aquest curs no l'imposa. És especialment còmode en lògica algorítmica amb regles clares —tarifes, validacions, càlculs— i força incòmode quan estàs explorant una API que no coneixes. El que sí que és innegociable és que la prova existeixi abans de donar la tasca per acabada, s'escrigui abans o després.

Per provar LloguerService en aïllament cal donar-li un LloguerRepositori que no toqui PostgreSQL. Els objectes que substitueixen un col·laborador real s'anomenen genèricament dobles de prova, i no són tots iguals:

Dues observacions que orienten tot el mòdul 6:

• A la pràctica quotidiana, «mock» s'usa per a tot, i Mockito hi contribueix: el seu mètode s'anomena mock(...) encara que l'habitual sigui fer-lo servir com a stub. La distinció conceptual continua important, perquè verificar l'estat produeix proves robustes i verificar interaccions produeix proves fràgils, acoblades a com està escrit el mètode per dins.
• CicloUrbana ja té un fake escrit: EstacioRepositoriEnMemoria. En molts casos és preferible a cinc línies de when(...).thenReturn(...), i a 06-03 compararem totes dues opcions amb un criteri clar.

La lliçó 06-03 està dedicada per complet a Mockito. Aquí n'hi ha prou de reconèixer els noms.

Escriure proves sense assercions. El cas de l'apartat 10: s'executa el codi, no es comprova res, JaCoCo diu 100 %. Regla mecànica de revisió: tota prova té almenys un assertThat o un assertThatThrownBy; si no en té, no és una prova.

Confondre «no falla» amb «funciona». Cridar un mètode i comprovar que no llança excepció és l'asserció més feble possible. Comprova el valor retornat, l'estat resultant o la interacció concreta.

Proves dependents entre si. Si provaB necessita que provaA hagi inserit una dada, la suite és un castell de cartes: JUnit no garanteix l'ordre i canviar-ne una trenca l'altra. Cada prova prepara el que li cal i no deixa rastre. Si sents la temptació de fixar l'ordre amb @TestMethodOrder, gairebé sempre és el senyal d'un problema de disseny.

Posar un application.yml a src/test/resources. No es fusiona amb el de producció: el reemplaça, i les proves comencen a fallar per propietats que «hi són posades». Fes servir application-test.yml amb @ActiveProfiles("test") (06-04).

Fer servir @SpringBootTest per a tot. És l'error estructural que construeix el con de gelat. Aixecar el context per provar una fórmula de tarifa multiplica per mil el temps d'execució i no detecta ni una fallada més. El context s'aixeca quan el que proves és la integració.

Lògica dins de la prova. Un if, un for o un càlcul dins del bloc de comprovació introdueixen la possibilitat que la prova tingui el seu propi error, i llavors qui prova la prova? Els valors esperats s'escriuen literals; per a diversos casos existeixen les proves parametritzades de 06-02.

Consell: la prova s'escriu pensant en el dia que falli. Un nom que descrigui la regla, un missatge de fallada que s'entengui sense obrir el codi i una única raó per fallar. Quan una prova t'estalviï mitja hora de depuració a les onze de la nit, entendràs per què.

Consell: quan arribi una fallada de producció, la prova primer. Reprodueix l'error amb una prova que falla, arregla'l i observa com es posa en verd. Així se sap que s'ha arreglat el que es creia i es garanteix que no torni.

Consell: si provar és difícil, no forcis la prova: arregla el disseny. La necessitat de simular mètodes estàtics, d'instanciar sis col·laboradors o de manipular el rellotge del sistema són símptomes, no obstacles.

Escriu TarifaEstudiantTest amb tres proves que cobreixin la regla dels 15 minuts gratuïts de 02-02: un lloguer de 10 minuts (gratis), un d'exactament 15 minuts (gratis: el límit és inclusiu) i un de 45 minuts. Aplica el patró Preparar-Actuar-Comprovar amb els comentaris de fase, fes servir isEqualByComparingTo i anomena els mètodes en català descrivint la regla. Justifica en un comentari per què el cas dels 15 minuts exactes és el més important dels tres.

Configura JaCoCo al pom.xml de CicloUrbana segons l'apartat 10, executa ./mvnw verify amb les proves de les tarifes ja escrites i obre target/site/jacoco/index.html. Respon per escrit: quin percentatge de cobertura de branques té el paquet com.ciclourbana.lloguers? Quina classe del projecte té 0 %? I quin és l'if groc més preocupant que hi trobis? Després escriu una prova deliberadament inútil (sense assercions) sobre SelectorTarifa, torna a generar l'informe i anota quant ha pujat el percentatge.

Classifica les vuit comprovacions pendents de CicloUrbana següents per tipus de prova (unitària, llesca, integració, E2E) i decideix per a cadascuna si val la pena escriure-la, justificant la decisió en una frase:

1. Que TarifaJubilat.nom() retorna "jubilat".
2. Que GET /api/v1/estacions/99 retorna un ProblemDetail amb estat 404.
3. Que EstacioResponse és un record amb sis components.
4. Que un ciutadà rep 403 en finalitzar el lloguer d'un altre.
5. Que findByUsuariIdAndFiIsNull retorna només lloguers sense data de fi.
6. Que la migració V4 crea l'índex sobre lloguers(inici).
7. Que server.port val 8080.
8. Que un token JWT caduca als quinze minuts.

Solució 1

Comentari: el camp private final TarifaEstudiant tarifa com a estat compartit és acceptable aquí precisament perquè la classe no té estat mutable —la mateixa propietat que a 02-03 la feia segura com a singleton—. Si en tingués, cada prova hauria de crear la seva pròpia instància en un @BeforeEach. Cal notar també que les tres proves comproven amb isEqualByComparingTo("0.00") i no amb isZero(): isZero() funcionaria, però deixa de llegir-se com un import.

Solució 2

Només amb les proves de les tarifes escrites, l'informe mostra una cosa semblant a això:

• Amb 0 % hi ha gairebé totes, incloses les tres classes que més importen: LloguerService, GestorGlobalExcepcions i tot el paquet seguretat. Aquest és el valor real del primer informe: el mapa del que no està protegit.
• El groc més preocupant sol ser TarifaEstandard.calcular: la línia Math.max(1, durada.toMinutes()) conté una branca que les proves de 30 i 45 minuts no recorren mai, la del lloguer de menys d'un minut. Aquí hi ha una regla de negoci amagada —«es cobra un minut com a mínim»— que ningú no ha verificat mai.
• Després d'afegir la prova sense assercions sobre SelectorTarifa, la seva cobertura salta a prop del 100 % i el total del paquet puja uns quants punts. Ni un sol comportament nou està verificat. La conclusió de l'exercici és aquesta: el número va pujar, la seguretat no. La cobertura és útil llegida com a mapa del vermell, i enganyosa llegida com a puntuació.

Solució 3

El patró que emergeix de la taula: es prova el que pot fallar en silenci. El que trenca la compilació o impedeix l'arrencada ja té qui el vigili.

Aquest mòdul comença on acabava l'anterior: amb la sospita que CicloUrbana funciona i sense cap manera automàtica de demostrar-ho. Ara tens el criteri per construir-la. Saps que es prova per quatre raons —regressions, refactorització segura, documentació viva i pressió de disseny— i que la darrera explica decisions que arrosseguem des del mòdul 2: el Clock injectat, la injecció per constructor, la interfície EstacioRepositori i el bean SeguretatLloguers no eren elegància acadèmica, eren disseny per poder provar. Coneixes els sis tipus de prova amb el seu cost i el que detecta cadascun, la piràmide i el con de gelat, i la proporció concreta que busquem a CicloUrbana: setanta per cent d'unitàries que s'executen en segons, vint de llesques, nou d'integració amb base de dades real i un u per cent d'extrem a extrem.

Saps dir que no: no es proven els getters, ni el framework aliè, ni la configuració trivial, i sí tot allò que pot fallar en silenci, començant per les regles de seguretat i acabant per cada error trobat en producció. Tens inventariat el que spring-boot-starter-test ja porta —JUnit 5, Spring Test, AssertJ, Hamcrest, Mockito, JSONassert, JsonPath i Awaitility— i la raó per no afegir-hi ni una dependència solta al costat. Coneixes l'estructura mirall de src/test/java, el parany de col·locar un application.yml a src/test/resources, les convencions de noms del curs i el patró Preparar-Actuar-Comprovar, aplicat ja a TarifaEstandardTest: la primera prova real de CicloUrbana, amb el seu isEqualByComparingTo i el seu comentari del càlcul esperat. Saps executar-les amb ./mvnw test i els seus filtres, distingir Surefire de Failsafe i per què *Test i *IT viuen separades, configurar JaCoCo i —sobretot— llegir-lo com un mapa del vermell i mai com una puntuació, després de veure una prova sense assercions arribar al 100 %. I has vist el cicle vermell-verd-refactor aplicat a la regla dels vuit ancoratges, i la taula dels cinc dobles de prova.

Amb el criteri posat, toca la tècnica. La lliçó següent, Proves Unitàries amb JUnit, entra a fons a l'eina: l'arquitectura de JUnit 5, el cicle de vida complet de les seves anotacions, el catàleg d'assercions d'AssertJ per tipus de dada —amb el seu parany de BigDecimal i les assercions toves—, les proves parametritzades aplicades a les tres tarifes de Ribalta en una sola classe, l'organització amb @Nested i @DisplayName, el Clock.fixed que fa determinista el càlcul de la durada d'un lloguer i les bones pràctiques de dades de prova amb el patró Object Mother. Anem a omplir la base de la piràmide.