La lliçó anterior va acabar amb un límit clar. EstacioService es va poder provar sense Spring perquè existia EstacioRepositoriEnMemoria, un fake escrit a mà al mòdul 2. Però LloguerService —la classe que concentra les regles de negoci de CicloUrbana— depèn de quatre repositoris JPA, del SelectorTarifa, del Clock, de XarxaProperties i del publicador d'esdeveniments d'Spring. Escriure un doble a mà per a cadascun serien centenars de línies de codi que ningú no mantindria, i molts d'aquests tipus són interfícies generades per Spring Data que ni tan sols podem implementar còmodament.

Mockito resol exactament això: genera dobles al vol per a qualsevol interfície o classe, permet programar què retornen i comprovar com se'ls ha cridat. En aquesta lliçó veurem per què calen els dobles, com es creen, com es programen les seves respostes, com funcionen els matchers d'arguments i per què la seva regla de tot-o-res produeix un error desconcertant, com verificar interaccions sense caure en proves fràgils, com capturar els arguments amb ArgumentCaptor, què són els spies i per què gairebé sempre són una olor de disseny, què t'està dient la UnnecessaryStubbingException i quan un fake continua sent millor que cinc línies de stubbing. I ho aplicarem a la prova completa del LloguerService, amb els seus escenaris de bicicleta no disponible, estació plena, durada excedida i càlcul de l'import.

1. Per què calen dobles
2. Tres formes de crear un mock
3. Programar respostes: el stubbing
4. Matchers d'arguments
5. Verificació d'interaccions
6. ArgumentCaptor
7. Spies: què són i per què gairebé mai
8. Strictness i UnnecessaryStubbingException
9. Simulació d'estàtics i constructors
10. El cas central: LloguerServiceTest
11. Mock o fake: quan cadascun
12. Què no s'ha de simular
13. Errors Comuns i Consells
14. Exercicis

Tres motius, i tots tres es veuen a CicloUrbana:

Aïllar la unitat. Si LloguerServiceTest fes servir repositoris reals, una fallada podria venir de la consulta, del mapatge, de la transacció o de la lògica. Amb dobles, si la prova falla, l'error és a LloguerService. Aquest és tot el valor d'una prova unitària.

Evitar recursos lents o externs. Base de dades, xarxa, sistema de fitxers, serveis de tercers. Cadascun multiplica el temps per mil i afegeix una raó perquè la prova falli sense que el codi estigui malament.

Forçar escenaris difícils o impossibles. Aquest és el motiu menys evident i el més valuós. Com proves que LloguerService reacciona bé quan el repositori llança una DataAccessException per una fallada de connexió? O quan SelectorTarifa rep un nom de tarifa que no existeix? Provocar-ho de veritat és difícil; amb un doble, és una línia:

Mockito 5 ve inclòs a spring-boot-starter-test. No es declara cap dependència addicional, i fer-ho amb una versió pròpia és la via ràpida a un conflicte al classpath (06-01).

@ExtendWith(MockitoExtension.class) és el que fa que els camps @Mock s'inicialitzin abans de cada prova —amb el mateix mecanisme de resolució de paràmetres que vam veure a 06-02— i el que activa les comprovacions de strictness de l'apartat 8. Sense l'extensió, els camps anotats queden a null i la prova falla amb un NullPointerException que despista.

La tercera forma és @InjectMocks, i mereix un advertiment:

Sembla còmode, però té tres riscos reals:

La política del curs: construir l'objecte amb new al @BeforeEach. És possible precisament perquè a 02-02 vam decidir injectar per constructor: la classe es pot instanciar en dues línies sense cap artefacte màgic. I quan aquestes dues línies comencin a ocupar-ne deu, la prova t'estarà dient que LloguerService té massa responsabilitats.

Per defecte, un mock retorna valors buits: null per a objectes, 0 per a números, false per a booleans, col·leccions buides per a List o Set i Optional.empty() per a Optional. Això últim és molt pràctic: el cas «no trobat» de qualsevol findById no necessita stubbing.

thenAnswer és l'eina per al cas més comú de tots a Spring Data: save retorna l'entitat amb l'identificador ja assignat. Sense ell, el save simulat retornaria null i el codi de producció fallaria per un motiu que no té res a veure amb el que s'està provant.

Existeix una segona sintaxi, amb el verb al davant:

La raó de l'excepció és mecànica: when(mock.metodeVoid()) no compila, perquè void no és una expressió. I amb un spy, when(spy.metode()) executa el mètode real abans de programar-lo, amb els efectes secundaris que això comporti. Amb doReturn la crida no passa mai.

Un stub amb un valor literal només respon a aquest valor exacte. Els matchers generalitzen:

La regla de tot-o-res. Si un mètode rep diversos arguments i uses un matcher en un, has de fer servir matchers a tots:

L'error que produeix la primera forma és cèlebre pel que costa de llegir:

La causa és a la implementació: els matchers no són valors, sinó que es registren en una pila interna en avaluar-se. Mockito compta els registrats i els compara amb el nombre d'arguments; si no quadren, no pot saber quin era quin. La conseqüència pràctica és que l'error de vegades apareix a la línia següent, en una prova que no hi té res a veure, cosa que fa perdre una bona estona. Si veus un InvalidUseOfMatchersException en un lloc absurd, busca la barreja al stubbing anterior.

Prefereix valors literals quan coneguis l'argument. when(repo.findById(1L)) és més específic i més informatiu que when(repo.findById(anyLong())): si el codi de producció comença a demanar l'identificador 2, vols que la prova t'ho digui, no que continuï passant.

Fins aquí hem fet servir els mocks com a stubs: fonts de dades. També serveixen per comprovar que se'ls ha cridat:

I ara l'advertiment, que és el més important de l'apartat. Verificar interaccions acobla la prova a com està escrit el mètode, no a què fa. Una prova plena de verify es trenca amb cada refactorització, encara que el comportament no canviï, i llavors l'equip comença a veure les proves com un impost en lloc d'una xarxa.

verifyNoMoreInteractions mereix una menció a part: sembla rigorós i a la pràctica produeix les proves més fràgils de la suite, perquè qualsevol crida afegida —un log, una consulta de suport— la trenca. Reserva'l per als casos en què «no tocar res més» sigui la regla de negoci.

Quan l'objecte que interessa es passa a un col·laborador en lloc de retornar-se, cal capturar-lo. És exactament el cas de LloguerService.iniciar: construeix un Lloguer internament i el passa a save.

Amb @Captor sobre un camp s'evita la línia forClass, i amb getAllValues() es recuperen totes les captures quan el mètode s'ha cridat diverses vegades.

Captor o argThat: argThat(a -> a.getEstat() == EN_CURS) és més curt, però quan falla només diu «no hi ha hagut cap invocació que coincidís», sense mostrar què ha arribat realment. L'ArgumentCaptor produeix un missatge de fallada amb el valor concret. Per a assercions, captor; per seleccionar entre diverses crides, argThat.

Un spy embolcalla un objecte real: per defecte tots els seus mètodes s'executen de veritat, i només els que programis se substitueixen.

Per què són una olor de disseny. La necessitat de simular part d'una classe significa gairebé sempre que aquesta classe fa dues coses: la que vols provar i la que vols evitar. La solució correcta és extreure la segona a un col·laborador i injectar-lo, que és el que vam fer amb CalculadoraTarifa a 02-02 i amb Clock a 02-01. Un spy és un pedaç sobre un problema estructural.

Els seus dos usos defensables: codi heretat que no pots reestructurar encara, i classes de tercers de les quals només vols alterar un mètode. Fora d'aquí, quan et trobis escrivint @Spy, atura't i mira la classe.

MockitoExtension aplica per defecte el mode STRICT_STUBS, que és una de les millors decisions de Mockito 5:

L'error típic:

Què t'està dient, que gairebé mai no és «treu aquesta línia». Hi ha tres causes possibles, en ordre de gravetat:

1. El codi no arriba on creies. Vas programar estacioRepositori.findById i la validació de la bicicleta talla abans. El stub sobra perquè la prova no està provant el que pensaves: és una troballa, no una molèstia.
2. La prova arrossega preparació d'una altra. Es va copiar un @BeforeEach amb cinc stubs i aquest cas només en fa servir dos. Mou al @BeforeEach únicament el que és comú.
3. El codi va canviar i la prova no. És el senyal que vols: hi ha stubbing mort.

Si un stub ha d'existir encara que no sempre s'usi, lenient().when(...) l'eximeix, i @MockitoSettings(strictness = Strictness.LENIENT) desactiva el mode a la classe sencera. Fes servir el primer amb moderació i el segon gairebé mai: apagar l'avís perd la informació.

Des de Mockito 3.4 es poden simular mètodes estàtics, i des de la 3.5 la construcció d'objectes:

Dos detalls tècnics importants: el mock estàtic només afecta el fil actual i s'ha de tancar, d'aquí el try amb recursos; si s'escapa, contamina les proves següents amb fallades impossibles d'atribuir.

I ara la part que importa: gairebé sempre és la solució equivocada. Compara les dues formes de provar el càlcul de la durada d'un lloguer:

La conclusió és la de 06-02 dita des de l'altra banda: injecta el que no és determinista en lloc de simular-ho. mockStatic és l'eina per a codi heretat que no pots canviar avui, no una alternativa de disseny.

Tot l'anterior, aplicat a la classe més important de CicloUrbana.

Quatre decisions que convé assenyalar, perquè són el resum pràctic de la lliçó:

1. El Clock congelat al @BeforeEach fa que «trenta minuts» i «tres hores» siguin afirmacions exactes, no aproximacions dependents de quan s'executi la suite.
2. selectorTarifa està simulat, no és real. La correcció del càlcul de tarifes ja la vam provar a 06-02 amb les proves parametritzades; aquí el que es prova és que LloguerService demana la tarifa correcta i fa servir el resultat, inclòs el recàrrec que suma pel seu compte.
3. Es verifica poc i s'afirma molt. Només hi ha tres verify a tota la classe, i els tres corresponen a efectes observables reals: publicar l'esdeveniment, no desar res després d'un rebuig i no tocar el publicador. La resta són assercions sobre el valor retornat.
4. El cas «no trobat» no necessita stubbing, perquè el valor per defecte d'un mock que retorna Optional és Optional.empty(). Menys codi i més clar.

CicloUrbana té un fake escrit a mà, EstacioRepositoriEnMemoria, i ara també mocks. No competeixen: serveixen per a coses diferents.

La regla pràctica: si una prova necessita més de tres o quatre línies de stubbing per preparar el mateix repositori, o si l'escenari consisteix a «desar alguna cosa i després llegir-la», el fake és millor. Quatre when encadenats per simular una seqüència de lectures són illegibles; un repositori.desar(placaMajor()) no.

I a l'inrevés: si només necessites que un mètode retorni un valor i vols comprovar que s'ha cridat, escriure una classe sencera és un malbaratament.

El risc del fake és real i cal anomenar-lo: pot divergir de la implementació de veritat. EstacioRepositoriEnMemoria filtra amb stream().filter(...), mentre que el repositori JPA genera SQL amb regles diferents d'ordenació i de majúscules. Per això el fake mai no substitueix les proves de 06-04 i 06-05 sobre la base de dades real: és una eina per provar la lògica que el fa servir, no per provar la persistència.

El primer punt té un exemple dolorós a CicloUrbana: simular JwtParser de JJWT per provar ServeiJwt produiria una prova que passa sempre, perquè el que pot fallar de veritat —la signatura, la caducitat, l'emissor— és just a la part simulada. La prova correcta de ServeiJwt és la de 06-02: JJWT real, Clock injectat.

Oblidar @ExtendWith(MockitoExtension.class). Els camps @Mock queden a null i la fallada apareix dins del codi de producció, lluny de la causa.

Barrejar matchers i literals. InvalidUseOfMatchersException, sovint assenyalant la línia equivocada. Embolcalla els literals amb eq(...).

when(spy.metode()) sobre un spy. Executa el mètode real abans de programar-lo. Amb spies, sempre doReturn(...).when(spy).metode().

Simular mètodes final, static o private sense voler. Mockito 5 fa servir l'inline mock maker per defecte i ja pot amb final, però un mètode private continua sent inabastable: si necessites simular-lo, és que hauria de ser una classe a part.

Sobreverificar. Una prova amb vuit verify i cap asserció sobre el resultat no comprova comportament, comprova una transcripció del mètode. Es trencarà a la primera refactorització.

Silenciar la UnnecessaryStubbingException amb lenient() sense llegir-la. És el consell més important de la lliçó: aquest error és informació, i moltes vegades t'està dient que la prova no executa el camí que creus.

Stubs que menteixen. when(repo.save(any())).thenReturn(lloguerAmbImport) fa que la prova passi encara que el servei no calculi mai l'import: el valor l'hi vas posar tu. Retorna sempre el que retornaria el col·laborador real —amb thenAnswer(i -> i.getArgument(0)) per als save— i afirma sobre el que produeix el codi.

Consell: prepara al @BeforeEach només el que fan servir totes les proves. La resta va a cada prova, on es llegeix al costat del que verifica. Amb STRICT_STUBS, a més, el contrari falla.

Consell: anomena les dades, no els mocks. BicicletesDeProva.ambBateria(12) diu per què aquest valor importa; bicicleta1 no diu res.

Escriu una prova de LloguerService.iniciar que verifiqui, fent servir ArgumentCaptor, que l'esdeveniment LloguerIniciat publicat porta l'identificador del lloguer acabat de desar i l'instant del Clock injectat, i no Instant.now() del sistema. Explica per què aquesta prova fallaria si algú substituís el Clock per una crida estàtica, i per què això és exactament el que es vol.

SeguretatLloguers.esPropietari(idLloguer, usuari) de 05-05 consulta lloguerRepositori.existsByIdAndUsuariId. Escriu la seva classe de prova amb Mockito cobrint quatre casos: és el propietari, no ho és, idLloguer nul i usuari nul. Para atenció a un detall: en dos dels quatre casos el repositori no s'ha de consultar gens. Verifica-ho i raona per què aquest verify sí que està justificat.

Aquesta prova té cinc defectes dels vistos a la lliçó. Enumera'ls i reescriu-la:

Solució 1

Comentari: el thenAnswer que assigna l'identificador és imprescindible. Sense ell, save retornaria null o un lloguer sense id, i l'asserció sobre 99L no podria distingir «el servei no propaga l'id» de «el mock no l'hi va posar». Aquí es veu també per què el captor és superior a argThat en aquest cas: si el moment no coincidís, el missatge mostra l'instant rebut, i amb argThat només diria que no hi ha hagut coincidències.

Per què fallaria amb Instant.now(): l'asserció compara contra ARA, l'instant exacte del Clock.fixed del @BeforeEach. Una crida estàtica retornaria l'hora real de l'execució, que mai no és aquesta. I això és just el que es busca: la prova actua com a guardiana del disseny. Si demà algú «simplifica» el codi traient el Clock, la suite es posa en vermell assenyalant la regressió de disseny abans que arribi a producció. És la quarta raó per provar de 06-01 —la pressió de disseny— convertida en una asserció concreta.

Solució 2

Per què el verifyNoInteractions està justificat aquí, quan l'apartat 5 advertia contra la sobreverificació: perquè en aquests dos casos no consultar és part del comportament correcte, no un detall d'implementació. Si el codi fes existsByIdAndUsuariId(null, null), el resultat continuaria sent false i una asserció sobre el valor retornat no distingiria totes dues versions; però la segona llança una consulta a PostgreSQL a cada petició anònima, i en un endpoint públic això és una via de saturació. La regla: verifica una absència d'interacció quan aquesta absència és la garantia que vols.

Cal notar a més que aquestes quatre proves s'executen en mil·lisegons i ja converteixen en assercions la meitat de la regla de seguretat de 05-05. L'altra meitat —que @PreAuthorize estigui posada i Spring l'apliqui— no es pot comprovar aquí: necessita el context, i és la feina de 06-04.

Solució 3

Els cinc defectes:

1. @InjectMocks: si LloguerService té més dependències de les declarades —i en té: EstacioRepositori, Clock, el publicador—, Mockito injecta null en silenci.
2. test() com a nom: no descriu cap regla; ni l'informe ni la fallada no diran res.
3. anyLong() i anyString() on es coneixen els valors: si el codi comença a demanar un altre identificador o la tarifa «estudiant», la prova continua passant. Els matchers laxos amaguen regressions.
4. when(selectorTarifa.calcular(...)) no es fa servir a iniciar: la tarifa només es calcula en finalitzar. Amb STRICT_STUBS això és una UnnecessaryStubbingException, i el que assenyala és que la prova barreja dos fluxos.
5. Sobreverificació i cap asserció: tres verify (dos d'ells equivalents, perquè verify(x) ja significa times(1)) i zero assertThat sobre el resultat. És la prova sense assercions de 06-01 disfressada. S'hi suma un sisè problema de fons: when(save(any())).thenReturn(new Lloguer()) és un stub que menteix, perquè retorna un lloguer buit que no té res a veure amb el que se li va passar.

Reescrita, amb un sol comportament per prova:

El càlcul de la tarifa es trasllada a la seva pròpia prova dins del bloc AlFinalitzar, que és on passa.

LloguerService ha deixat de ser la part no provada de CicloUrbana. Saps per què calen els dobles —aïllar la unitat, evitar recursos lents i, sobretot, forçar escenaris que seria difícil provocar de veritat— i les tres formes de crear-los, amb la política del curs ben fonamentada: @Mock amb MockitoExtension i construcció explícita de l'objecte al @BeforeEach, sense @InjectMocks, perquè la injecció per constructor de 02-02 ho fa innecessari i perquè el dia que construir la classe resulti incòmode, aquesta incomoditat és informació que no convé amagar.

Domines el stubbing en les seves dues sintaxis i saps quan doReturn deixa de ser una alternativa estilística i passa a ser obligatori: mètodes void i spies. Coneixes els matchers, la regla de tot-o-res i el motiu mecànic —la pila interna— pel qual InvalidUseOfMatchersException apareix de vegades a la línia equivocada. Saps verificar amb times, never, inOrder i verifyNoInteractions, i saps el més difícil: verificar poc, reservant-ho per als efectes observables reals, perquè una prova plena de verify és una transcripció del mètode que es trenca a la primera refactorització. Captures arguments amb ArgumentCaptor quan l'objecte interessant es passa a un col·laborador —el cas del Lloguer que va a save i de l'esdeveniment LloguerIniciat—, i saps quan el captor guanya a argThat: quan el missatge de fallada importa.

Has vist per què els spies són gairebé sempre una olor de disseny i per què mockStatic no ha de competir amb injectar un Clock, i has après a llegir la UnnecessaryStubbingException com el que és: tres diagnòstics possibles, el més interessant dels quals és «la teva prova no està executant el camí que creus». Tens la comparació entre mock i fake amb un criteri operatiu —més de tres o quatre línies de stubbing sobre el mateix repositori, o un escenari de desar-i-llegir, demanen un fake— i la llista del que no se simula mai: els tipus que no posseeixes, els objectes de valor i la classe sota prova.

Però mira el que continua sense estar cobert. Que @PreAuthorize estigui posada sobre LloguerService.finalitzar i que Spring l'apliqui de veritat; que EstacioController retorni un 404 amb format ProblemDetail; que findByUsuariIdAndFiIsNull generi el SQL correcte; que les regles d'authorizeHttpRequests tanquin el que creiem. Res d'això no es pot comprovar amb mocks, perquè el que falla allà no és la lògica: és el cablejat, les anotacions i el framework. La lliçó següent, Proves d'Integració, aixeca el context d'Spring amb criteri: @SpringBootTest i la seva memòria cau de contextos, les llesques @WebMvcTest i @DataJpaTest, MockMvc, @MockitoBean —el substitut de l'obsolet @MockBean— i les anotacions d'spring-security-test que convertiran en assercions automàtiques cada regla del mòdul 5.