El módulo anterior terminó con una afirmación y una pregunta. La afirmación: la red de Ribalta está protegida. La pregunta: ¿cómo lo sabemos? Sabemos que un ciudadano no puede finalizar el alquiler de otro porque lo hemos probado a mano con curl una tarde de martes, y porque leyendo @PreAuthorize nos parece que dice lo correcto. Eso no es conocimiento: es confianza. Y la confianza se evapora en cuanto alguien reordena una regla de authorizeHttpRequests, sube la versión de una dependencia o toca el SelectorTarifa para añadir una tarifa nueva.

CicloUrbana tiene hoy una aplicación completa —REST, JPA sobre PostgreSQL, Flyway, seguridad con JWT— y exactamente cero pruebas: solo el contextLoads vacío que generó Spring Initializr en la lección 01-04. Este módulo corrige eso. En esta primera lección no escribiremos todavía una suite: construiremos el criterio. Qué se prueba y por qué, qué tipos de prueba existen y qué detecta cada uno, cómo se reparten en una pirámide sana, qué trae ya spring-boot-starter-test sin añadir nada, dónde se colocan los ficheros, cómo se llaman las clases y los métodos, cuál es la anatomía de una prueba bien escrita, cómo se ejecutan, cómo se mide la cobertura con JaCoCo y por qué esa métrica engaña si se convierte en objetivo. Al final tendremos escrita la primera prueba real del proyecto: pequeña, pero verdadera.

1. Por qué se prueba
2. Los tipos de prueba
3. La pirámide de pruebas y el cono de helado
4. Qué merece la pena probar y qué no
5. spring-boot-starter-test: la caja de herramientas
6. Dónde viven las pruebas: estructura y convenciones
7. Anatomía de una prueba: Preparar-Actuar-Comprobar
8. Ejecutar las pruebas
9. Surefire y Failsafe: *Test frente a *IT
10. Cobertura con JaCoCo
11. TDD: rojo, verde, refactor
12. Los dobles de prueba
13. Errores Comunes y Consejos
14. Ejercicios

La respuesta ingenua es «para encontrar errores». Es la menos importante de las cuatro razones reales.

Una regresión es un fallo introducido en algo que antes funcionaba. Es el fallo más caro del ciclo de vida de un programa, porque nadie lo busca: el cambio se probó a mano, el cambio funciona, y lo que se rompió está tres capas más allá.

En CicloUrbana hay decenas de regresiones esperando su turno. Estas son reales y plausibles:

Ninguno de esos cambios produce un error de compilación. Todos los detecta una prueba escrita una sola vez y ejecutada mil veces.

Refactorizar es cambiar la estructura interna sin cambiar el comportamiento observable. La definición contiene una trampa: para saber que el comportamiento no ha cambiado hay que poder comprobarlo. Sin pruebas, «refactorizar» es un eufemismo de «reescribir y rezar», y el resultado práctico es que nadie toca el código feo: se acumula, se rodea y se hereda.

Con una suite decente, el mapeador de 03-05 que consulta repositorios —y que admitíamos que estaba mal diseñado— se puede reescribir en una tarde. Sin ella, se queda ahí para siempre.

Un comentario miente en cuanto alguien cambia el código y no lo actualiza. Una prueba que miente falla. El nombre de un método de prueba bien escrito es una frase del dominio:

Leídos en el informe de una ejecución, esos nombres son la especificación de CicloUrbana, y es una especificación que se compila y se verifica sola.

Esta es la razón menos evidente y la más valiosa. Un código difícil de probar es un código mal diseñado, y la prueba te lo dice antes que ningún revisor.

Si AlquilerService llamara a LocalDateTime.now() directamente, probar «un alquiler de dos horas» exigiría esperar dos horas o manipular el reloj del sistema. Que en la lección 02-01 inyectáramos un Clock no fue elegancia gratuita: fue diseñar para poder probar. Lo mismo vale para la inyección por constructor de 02-02 (permite construir el objeto en una prueba con colaboradores falsos), para la interfaz EstacionRepositorio de 02-01 (permite sustituir la implementación) y para SeguridadAlquileres de 05-05 (una regla de seguridad convertida en un bean normal, comprobable con una prueba unitaria).

«Prueba» no es una categoría única. Estas son las que nos interesan, ordenadas de más rápida y barata a más lenta y cara:

Dos matices que ahorran discusiones estériles:

• La frontera entre unitaria e integración es un continuo, no una línea. Lo que importa no es la etiqueta sino dos propiedades: si la prueba es rápida y si es determinista. Una prueba que tarda 40 ms y no toca red ni disco se comporta como unitaria aunque instancie tres clases reales.
• Las de carga y las de contrato quedan fuera de este módulo. Las de rendimiento aparecerán en 09-01, y las de contrato tienen sentido cuando CicloUrbana se parta en varios servicios (07-05 y 07-06). Aquí construimos las cuatro primeras filas.

La pirámide de pruebas describe la proporción sana entre tipos: muchas pruebas rápidas y baratas en la base, muy pocas lentas y frágiles en la cima.

La lógica de la forma es económica. Una prueba unitaria cuesta milisegundos, así que se pueden tener miles y ejecutarlas en cada guardado del fichero. Una E2E cuesta segundos y falla a veces sin motivo (la red, un tiempo de espera, un dato residual), así que cada una que añades encarece la suite y erosiona la confianza en ella.

El cono de helado es la pirámide invertida: casi todo se comprueba arrancando la aplicación entera —o peor, a mano— y apenas existen pruebas unitarias. Sus síntomas son inconfundibles:

• La suite tarda 25 minutos, así que nadie la ejecuta en local.
• Hay pruebas que fallan «a veces» y el equipo las reintenta en lugar de arreglarlas: son pruebas escamosas (flaky), y una sola envenena la confianza en todas las demás.
• Cuando algo falla, el mensaje es Expected 200 but was 500 y hay que leer 300 líneas de log para saber qué se ha roto. Una prueba unitaria te dice qué método y qué valor.

La proporción recomendada para CicloUrbana, dado su tamaño y su forma:

No son porcentajes que haya que medir con una hoja de cálculo. Son un recordatorio: si escribir una prueba nueva te obliga siempre a levantar el contexto de Spring, el problema no es la prueba, es el diseño de la clase.

Escribir pruebas cuesta tiempo y mantenerlas cuesta más. Gastarlo bien exige decir que no.

Sí merece la pena probar:

• La lógica de negocio con ramas: el cálculo de tarifas con sus minutos gratuitos, la regla de los anclajes mínimos, la comprobación del umbral de batería, el recargo por superar la duración máxima.
• Los casos límite y los límites exactos: 0 minutos, 1 minuto, exactamente 15 minutos con la tarifa de estudiante, exactamente el umbral de batería, la estación con un anclaje libre y con ninguno.
• Los caminos de error: qué pasa cuando la estación no existe, cuando la bicicleta está en mantenimiento, cuando el alquiler ya está finalizado.
• Las reglas de seguridad, sin excepción. Son las que fallan en silencio y las que más caras salen.
• El contrato público de la API: los códigos de estado, la forma del JSON, los ProblemDetail de 03-06.
• Todo error encontrado en producción: antes de arreglarlo, una prueba que lo reproduzca. Es la regla que impide que el mismo fallo vuelva dos veces.

No merece la pena probar:

La pregunta que resuelve casi todos los casos dudosos: «si esto se rompe, ¿me entero antes de que se entere un ciudadano de Ribalta?» Si la respuesta es «solo con una prueba», escríbela.

Spring Initializr ya añadió esta dependencia en 01-03, y es la única que necesitamos para todo el módulo salvo dos añadidos concretos (seguridad en 06-04 y contenedores en 06-05):

El <scope>test</scope> es esencial: estas librerías se usan al compilar y ejecutar src/test/java, y no se empaquetan en el JAR de producción. Un assertThat no puede acabar en el artefacto desplegado.

Lo que trae dentro:

Por qué no hay que añadir dependencias sueltas. El BOM de Spring Boot fija versiones compatibles entre sí de todas ellas. Si añades org.mockito:mockito-core con una versión propia, acabas con dos Mockito en el classpath y errores de arranque de la extensión que cuesta media mañana diagnosticar. La regla del proyecto: si algo ya está en el starter, no se declara; y si necesitas cambiarle la versión, se hace con <mockito.version> en <properties>, que es la palanca que el BOM ofrece para eso.

Comprueba qué tienes realmente con:

Maven separa el código de producción del de pruebas en dos árboles paralelos:

Tres reglas que se siguen sin excepción:

1. La prueba vive en el mismo paquete que la clase probada, aunque en otro árbol. Así puede acceder a miembros con visibilidad de paquete sin abrir la clase de producción, y el árbol de pruebas es un espejo navegable del de producción.
2. src/test/resources está antes que src/main/resources en el classpath de prueba. Un application.yml colocado ahí no se suma al de producción: lo sustituye por completo. Es un error clásico; la forma correcta de configurar las pruebas es un perfil (application-test.yml), que veremos en 06-04.
3. Nada de src/test/java acaba en el JAR. Puedes crear ahí las clases de apoyo que quieras.

Sobre los nombres de método, la política del curso merece una justificación. testCalcular1() no dice nada: cuando falla en la integración continua a las tres de la tarde, hay que abrir el fichero. rechazaLaEstacionCuandoLaCapacidadEsMenorQueOcho describe la regla de negocio de Ribalta, en el idioma del proyecto, y el informe de fallos se lee como una lista de requisitos incumplidos. Tres formas válidas, elige una y sé consistente:

Y una nota que evita un fallo desconcertante: en JUnit 5 las clases y los métodos de prueba no necesitan ser public. La visibilidad de paquete es suficiente y es la convención actual. Lo que sí sigue prohibido es que sean private o static.

Toda prueba bien escrita tiene tres partes, separadas visualmente. El patrón se conoce como Arrange-Act-Assert (AAA) o Given-When-Then; en este curso lo llamaremos Preparar-Actuar-Comprobar:

La primera prueba real de CicloUrbana. Probamos TarifaEstandar de 02-02: 0,50 € de desbloqueo más 0,12 € por minuto.

Cada línea tiene una decisión detrás:

• class TarifaEstandarTest, sin public, en el paquete com.ciclourbana.alquileres, espejo exacto de la clase probada.
• new TarifaEstandar(): no hay Spring por ninguna parte. TarifaEstandar es una clase Java normal que resulta estar anotada con @Component; la anotación no impide instanciarla. Esta prueba se ejecuta en menos de un milisegundo, y esa es exactamente la propiedad que la hace útil.
• import static ...Assertions.assertThat: el import estático de AssertJ, presente en todas las pruebas del curso.
• isEqualByComparingTo("4.10") y no isEqualTo(new BigDecimal("4.10")). El equals de BigDecimal compara también la escala, de modo que 4.1 y 4.10 no son iguales para él aunque valgan lo mismo. Con dinero, siempre isEqualByComparingTo. Es la primera de las trampas de AssertJ y se detalla en 06-02.
• El comentario del cálculo esperado: 4.10 no es un número mágico si al lado está la operación que lo produce. Quien lea la prueba dentro de un año sabrá si el fallo está en el código o en la expectativa.

Ejecutémosla:

CicloUrbana tiene su primera prueba. Es minúscula, y sin embargo ya afirma algo que antes solo estaba en la cabeza de quien escribió la clase.

Veamos ahora cómo falla, que es lo que de verdad importa. Si alguien cambia POR_MINUTO a 0.15:

El mensaje dice el nombre de la regla incumplida, el valor esperado y el obtenido. La calidad de un mensaje de fallo es una característica de la prueba, no un accidente, y es la razón principal por la que este curso usa AssertJ.

Una advertencia sobre esa última línea, porque la diferencia se pregunta en cada revisión de código:

Usa siempre la primera. La segunda deja pasar pruebas rotas sin avisar.

Desde el IDE, el flujo cotidiano es distinto y mejor: el triángulo verde junto al método ejecuta esa prueba en milisegundos, y el atajo de «repetir la última ejecución» (Ctrl+Shift+F10 en IntelliJ, Ctrl+F11 en Eclipse) es el que más se usa mientras se programa. El IDE ejecuta JUnit directamente, sin pasar por Maven: es mucho más rápido, pero no aplica la configuración de Surefire, así que una prueba puede pasar en el IDE y fallar en ./mvnw test si depende de argumentos de JVM o perfiles configurados en el pom.xml. Antes de subir nada, ./mvnw verify.

Maven tiene dos plugins de pruebas, y confundirlos es la causa de que muchas suites nunca ejecuten sus pruebas de integración.

La diferencia de comportamiento ante un fallo tiene una razón práctica: si una prueba de integración levanta un contenedor de PostgreSQL (06-05), Failsafe debe llegar siempre a la fase que lo apaga; por eso no aborta al primer fallo y deja que verify sea quien rompa la construcción.

Failsafe no viene activado por defecto. Se añade así:

Y a partir de ahí, la convención de CicloUrbana:

Por qué separar. Si las pruebas lentas están mezcladas con las rápidas, la suite entera tarda minutos y deja de ejecutarse durante el desarrollo; y cuando una suite deja de ejecutarse, deja de servir. Separarlas permite el ciclo corto —guardar, ./mvnw test, cinco segundos— sin renunciar a la comprobación completa antes de subir el cambio.

La cobertura de código mide qué porcentaje del código se ejecuta durante la suite de pruebas. JaCoCo lo instrumenta en tiempo de ejecución y genera un informe HTML. Se configura así:

El informe colorea cada línea del código fuente: verde si se ejecutó, rojo si no, amarillo si es una rama de la que solo se ha recorrido una salida (un if que siempre se evaluó a cierto). El amarillo es el color más informativo: señala exactamente los casos límite que faltan por probar.

Dos métricas conviven en el informe, y solo una es interesante:

La cobertura mide qué código se ha ejecutado, no qué comportamiento se ha verificado. Estas dos cosas no se parecen en nada, y aquí está la demostración:

JaCoCo informará del 100 % de cobertura de las tres tarifas. Si mañana alguien cambia el precio por minuto de 0,12 € a 1,20 €, esta prueba seguirá pasando, y la ciudad de Ribalta facturará diez veces de más con la construcción en verde.

De ahí la ley de Goodhart aplicada al software: cuando una medida se convierte en objetivo, deja de ser una buena medida. Si el equipo se marca «85 % de cobertura o falla la construcción», lo que se obtiene son pruebas sin asertos escritas la tarde antes de la entrega. La política de CicloUrbana:

• La cobertura se mira, no se persigue. Su uso correcto es buscar el rojo: un if de negocio entero sin cubrir es una pregunta legítima.
• Un umbral mínimo bajo (40–50 %) que solo impida el retroceso grosero es defendible; uno alto es contraproducente.
• Mucho más valioso que el porcentaje global es el porcentaje del código nuevo, que es lo que los sistemas de revisión modernos muestran en cada cambio.

Si aun así quieres un umbral que rompa la construcción, jacoco:check con una regla:

El desarrollo guiado por pruebas invierte el orden habitual: primero la prueba, después el código. Su ciclo tiene tres pasos y se repite en minutos, no en horas.

Aplicado a una regla real de Ribalta —el ayuntamiento exige que ninguna estación tenga menos de 8 anclajes, la capacidadMinima de RedProperties de 02-05:

Rojo. La prueba se escribe antes de que exista el método:

No compila: validarCapacidad no existe. Eso ya es el rojo, y es informativo: al escribir la llamada has diseñado la firma del método antes de escribirlo.

Verde. Lo mínimo que la hace pasar:

Refactor. Con la prueba en verde, el 8 literal se sustituye por redProperties.capacidadMinima(). Si al hacerlo la prueba sigue pasando, el refactor es correcto; si se rompe, lo has sabido en cinco segundos.

Qué aporta realmente, más allá del eslogan:

Y una postura honesta: TDD no es obligatorio y este curso no lo impone. Es especialmente cómodo en lógica algorítmica con reglas claras —tarifas, validaciones, cálculos— y bastante incómodo cuando estás explorando una API que no conoces. Lo que sí es innegociable es que la prueba exista antes de dar la tarea por terminada, se escriba antes o después.

Para probar AlquilerService en aislamiento hace falta darle un AlquilerRepositorio que no toque PostgreSQL. Los objetos que sustituyen a un colaborador real se llaman genéricamente dobles de prueba, y no son todos iguales:

Dos observaciones que orientan todo el módulo 6:

• En la práctica cotidiana, «mock» se usa para todo, y Mockito lo alimenta: su método se llama mock(...) aunque lo habitual sea usarlo como stub. La distinción conceptual sigue importando, porque verificar el estado produce pruebas robustas y verificar interacciones produce pruebas frágiles, acopladas a cómo está escrito el método por dentro.
• CicloUrbana ya tiene un fake escrito: EstacionRepositorioEnMemoria. En muchos casos es preferible a cinco líneas de when(...).thenReturn(...), y en 06-03 compararemos ambas opciones con un criterio claro.

La lección 06-03 está dedicada por completo a Mockito. Aquí basta con reconocer los nombres.

Escribir pruebas sin asertos. El caso del apartado 10: se ejecuta el código, no se comprueba nada, JaCoCo dice 100 %. Regla mecánica de revisión: toda prueba tiene al menos un assertThat o un assertThatThrownBy; si no lo tiene, no es una prueba.

Confundir «no falla» con «funciona». Llamar a un método y comprobar que no lanza excepción es el aserto más débil posible. Comprueba el valor devuelto, el estado resultante o la interacción concreta.

Pruebas dependientes entre sí. Si pruebaB necesita que pruebaA haya insertado un dato, la suite es una casa de naipes: JUnit no garantiza el orden y cambiar una rompe la otra. Cada prueba prepara lo suyo y no deja rastro. Si sientes la tentación de fijar el orden con @TestMethodOrder, casi siempre es la señal de un problema de diseño.

Poner un application.yml en src/test/resources. No se fusiona con el de producción: lo reemplaza, y las pruebas empiezan a fallar por propiedades que «están puestas». Usa application-test.yml con @ActiveProfiles("test") (06-04).

Usar @SpringBootTest para todo. Es el error estructural que construye el cono de helado. Levantar el contexto para probar una fórmula de tarifa multiplica por mil el tiempo de ejecución y no detecta ni un fallo más. El contexto se levanta cuando lo que pruebas es la integración.

Lógica dentro de la prueba. Un if, un for o un cálculo dentro del bloque de comprobación introducen la posibilidad de que la prueba tenga su propio error, y entonces ¿quién prueba la prueba? Los valores esperados se escriben literales; para varios casos existen las pruebas parametrizadas de 06-02.

Consejo: la prueba se escribe pensando en el día que falle. Un nombre que describa la regla, un mensaje de fallo que se entienda sin abrir el código y una única razón para fallar. Cuando una prueba te ahorre media hora de depuración a las once de la noche, entenderás por qué.

Consejo: cuando llegue un fallo de producción, la prueba primero. Reproduce el error con una prueba que falla, arréglalo y observa cómo se pone en verde. Así se sabe que se ha arreglado lo que se creía y se garantiza que no vuelva.

Consejo: si probar es difícil, no fuerces la prueba: arregla el diseño. La necesidad de simular métodos estáticos, de instanciar seis colaboradores o de manipular el reloj del sistema son síntomas, no obstáculos.

Escribe TarifaEstudianteTest con tres pruebas que cubran la regla de los 15 minutos gratuitos de 02-02: un alquiler de 10 minutos (gratis), uno de exactamente 15 minutos (gratis: el límite es inclusivo) y uno de 45 minutos. Aplica el patrón Preparar-Actuar-Comprobar con los comentarios de fase, usa isEqualByComparingTo y nombra los métodos en español describiendo la regla. Justifica en un comentario por qué el caso de los 15 minutos exactos es el más importante de los tres.

Configura JaCoCo en el pom.xml de CicloUrbana según el apartado 10, ejecuta ./mvnw verify con las pruebas de las tarifas ya escritas y abre target/site/jacoco/index.html. Responde por escrito: ¿qué porcentaje de cobertura de ramas tiene el paquete com.ciclourbana.alquileres? ¿Qué clase del proyecto tiene 0 %? ¿Y cuál es el if amarillo más preocupante que encuentres? Después escribe una prueba deliberadamente inútil (sin asertos) sobre SelectorTarifa, vuelve a generar el informe y anota cuánto ha subido el porcentaje.

Clasifica las siguientes ocho comprobaciones pendientes de CicloUrbana por tipo de prueba (unitaria, rodaja, integración, E2E) y decide para cada una si merece la pena escribirla, justificando la decisión en una frase:

1. Que TarifaJubilado.nombre() devuelve "jubilado".
2. Que GET /api/v1/estaciones/99 devuelve un ProblemDetail con estado 404.
3. Que EstacionResponse es un record con seis componentes.
4. Que un ciudadano recibe 403 al finalizar el alquiler de otro.
5. Que findByUsuarioIdAndFinIsNull devuelve solo alquileres sin fecha de fin.
6. Que la migración V4 crea el índice sobre alquileres(inicio).
7. Que server.port vale 8080.
8. Que un token JWT caduca a los quince minutos.

Solución 1

Comentario: el campo private final TarifaEstudiante tarifa como estado compartido es aceptable aquí precisamente porque la clase no tiene estado mutable —la misma propiedad que en 02-03 la hacía segura como singleton—. Si lo tuviera, cada prueba debería crear su propia instancia en un @BeforeEach. Nótese también que las tres pruebas comprueban con isEqualByComparingTo("0.00") y no con isZero(): isZero() funcionaría, pero deja de leerse como un importe.

Solución 2

Con solo las pruebas de las tarifas escritas, el informe muestra algo parecido a esto:

• Con 0 % están casi todas, incluidas las tres clases que más importan: AlquilerService, ManejadorGlobalExcepciones y todo el paquete seguridad. Ese es el valor real del primer informe: el mapa de lo que no está protegido.
• El amarillo más preocupante suele ser TarifaEstandar.calcular: la línea Math.max(1, duracion.toMinutes()) contiene una rama que las pruebas de 30 y 45 minutos nunca recorren, la del alquiler de menos de un minuto. Ahí hay una regla de negocio escondida —«se cobra un minuto como mínimo»— que nadie ha verificado nunca.
• Tras añadir la prueba sin asertos sobre SelectorTarifa, su cobertura salta a cerca del 100 % y el total del paquete sube varios puntos. Ni un solo comportamiento nuevo está verificado. La conclusión del ejercicio es esa: el número subió, la seguridad no. La cobertura es útil leída como mapa del rojo, y engañosa leída como puntuación.

Solución 3

El patrón que emerge de la tabla: se prueba lo que puede fallar en silencio. Lo que rompe la compilación o impide el arranque ya tiene quien lo vigile.

Este módulo empieza donde terminaba el anterior: con la sospecha de que CicloUrbana funciona y sin ninguna forma automática de demostrarlo. Ahora tienes el criterio para construirla. Sabes que se prueba por cuatro razones —regresiones, refactorización segura, documentación viva y presión de diseño— y que la última explica decisiones que arrastramos desde el módulo 2: el Clock inyectado, la inyección por constructor, la interfaz EstacionRepositorio y el bean SeguridadAlquileres no eran elegancia académica, eran diseño para poder probar. Conoces los seis tipos de prueba con su coste y lo que detecta cada uno, la pirámide y el cono de helado, y la proporción concreta que buscamos en CicloUrbana: setenta por ciento de unitarias que se ejecutan en segundos, veinte de rodajas, nueve de integración con base de datos real y un uno por ciento de extremo a extremo.

Sabes decir que no: no se prueban los getters, ni el framework ajeno, ni la configuración trivial, y sí todo lo que puede fallar en silencio, empezando por las reglas de seguridad y terminando por cada error encontrado en producción. Tienes inventariado lo que spring-boot-starter-test ya trae —JUnit 5, Spring Test, AssertJ, Hamcrest, Mockito, JSONassert, JsonPath y Awaitility— y la razón para no añadir ni una dependencia suelta al lado. Conoces la estructura espejo de src/test/java, la trampa de colocar un application.yml en src/test/resources, las convenciones de nombres del curso y el patrón Preparar-Actuar-Comprobar, aplicado ya a TarifaEstandarTest: la primera prueba real de CicloUrbana, con su isEqualByComparingTo y su comentario del cálculo esperado. Sabes ejecutarlas con ./mvnw test y sus filtros, distinguir Surefire de Failsafe y por qué *Test y *IT viven separadas, configurar JaCoCo y —sobre todo— leerlo como un mapa del rojo y nunca como una puntuación, después de ver una prueba sin asertos alcanzar el 100 %. Y has visto el ciclo rojo-verde-refactor aplicado a la regla de los ocho anclajes, y la tabla de los cinco dobles de prueba.

Con el criterio puesto, toca la técnica. La lección siguiente, Pruebas Unitarias con JUnit, entra a fondo en la herramienta: la arquitectura de JUnit 5, el ciclo de vida completo de sus anotaciones, el catálogo de aserciones de AssertJ por tipo de dato —con su trampa de BigDecimal y las aserciones blandas—, las pruebas parametrizadas aplicadas a las tres tarifas de Ribalta en una sola clase, la organización con @Nested y @DisplayName, el Clock.fixed que hace determinista el cálculo de la duración de un alquiler y las buenas prácticas de datos de prueba con el patrón Object Mother. Vamos a llenar la base de la pirámide.