La lección anterior dejó a CicloUrbana con una prueba: TarifaEstandarTest, doce líneas que afirman que treinta minutos cuestan 4,10 €. Sirvió para ilustrar el patrón Preparar-Actuar-Comprobar, pero es evidente que no basta. Ribalta tiene tres tarifas, cada una con su franquicia de minutos gratuitos, y los casos que importan son los límites: cero minutos, exactamente quince, exactamente treinta. Escribir doce clases casi idénticas sería el peor camino posible.

Esta lección llena la base de la pirámide con la herramienta adecuada. Veremos la arquitectura de JUnit 5, el catálogo de anotaciones con su ciclo de vida demostrado en ejecución, AssertJ a fondo —el estilo de aserción de todo el curso— con sus trampas de BigDecimal y sus aserciones blandas, las pruebas parametrizadas aplicadas a las tarifas de Ribalta en una sola clase legible, la organización por escenarios con @Nested, 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. Todo sin levantar el contexto de Spring ni una sola vez: aquí no hace falta, y esa es precisamente la lección.

1. La arquitectura de JUnit 5
2. Las anotaciones fundamentales y su ciclo de vida
3. AssertJ: por qué es el estilo del curso
4. El catálogo de aserciones por tipo
5. Excepciones y aserciones blandas
6. Pruebas parametrizadas
7. La CalculadoraTarifa parametrizada
8. Organizar con @Nested, @DisplayName y @Tag
9. Probar código dependiente del tiempo
10. @TempDir, suposiciones y @RepeatedTest
11. EstacionService sin Spring
12. Datos de prueba: Object Mother y builders
13. Errores Comunes y Consejos
14. Ejercicios

JUnit 5 no es una librería, son tres módulos con responsabilidades separadas:

La separación tiene una consecuencia práctica: la Platform puede ejecutar varios motores a la vez, de modo que un proyecto en migración corre Jupiter y Vintage en la misma construcción. CicloUrbana nace en JUnit 5, así que Vintage no está en el classpath y no debe añadirse: solo sirve para arrastrar deuda.

El error asociado más habitual: mezclar org.junit.Test (JUnit 4) con org.junit.jupiter.api.Test (JUnit 5) en el mismo fichero. La prueba compila y no se ejecuta nunca, sin aviso. Si un método «no aparece» en el informe, mira el import antes que ninguna otra cosa.

El punto que sorprende a quien viene de JUnit 4 es el segundo recuadro: JUnit crea una instancia nueva de la clase de prueba para cada método @Test. Es aislamiento deliberado: un campo que una prueba modifique no lo verá la siguiente, porque la siguiente corre sobre otro objeto. Esta prueba lo demuestra:

Lo importante está en dos números: contador vale 1 en ambas pruebas, no 1 y 2, y el hashCode es distinto, que es la causa. Esa es la garantía de independencia sobre la que descansa todo lo demás; el orden de ejecución es determinista pero no el del fichero, y jamás debe importar.

Dos detalles con consecuencias. @BeforeAll y @AfterAll deben ser static, justamente porque no hay una instancia que dure más que una prueba; existe la alternativa @TestInstance(Lifecycle.PER_CLASS), que este curso no usa porque abre la puerta a que el estado de una prueba contamine la siguiente. Y @Disabled sin motivo es basura acumulada: escribe @Disabled("Bloqueado por CU-412; reactivar al corregirlo"), o la prueba se quedará desactivada para siempre dando la impresión de que algo está cubierto.

El parámetro TestInfo del ejemplo no es casual: JUnit 5 inyecta parámetros en los métodos mediante resolvedores, y es el mismo mecanismo con el que @ExtendWith(MockitoExtension.class) inyectará los mocks en 06-03.

JUnit trae sus propias aserciones y funcionan. AssertJ, incluido también en spring-boot-starter-test, hace el mismo trabajo mucho mejor:

La inversión de argumentos produce mensajes que mienten: assertEquals(importe, new BigDecimal("4.10")) informa «expected: 5.00 but was: 4.10», al revés, y a depurar. Con AssertJ el error es imposible. Regla del curso: todas las aserciones se escriben con AssertJ; la única excepción es Hamcrest dentro de jsonPath(...) en MockMvc (06-04), porque esa API lo exige.

Objetos generales:

usingRecursiveComparison() resuelve un problema real: las entidades JPA de 04-03 definen equals por identificador, así que isEqualTo diría que dos estaciones con el mismo id son iguales aunque una tenga el nombre cambiado. La forma habitual es assertThat(guardada).usingRecursiveComparison().ignoringFields("id", "version", "creadoEn", "modificadoEn").isEqualTo(esperada), ignorando lo que asigna la base de datos.

Cadenas y números:

BigDecimal: la trampa que hay que memorizar.

BigDecimal.equals compara valor y escala: 4.1 tiene escala 1 y 4.10 escala 2, luego no son equals aunque compareTo devuelva 0. Como isEqualTo usa equals, una prueba correcta puede fallar solo porque el cálculo produjo un decimal más. Con dinero, siempre isEqualByComparingTo. En CicloUrbana afecta a todos los importes y tarifas.

Optional y colecciones, donde AssertJ es incomparable:

La diferencia entre los métodos de contenido se olvida siempre:

Y sobre mapas, aplicado al SelectorTarifa de 02-02, assertThat(selector.disponibles()).hasSize(3).containsKeys("estandar", "estudiante", "jubilado").doesNotContainKey("TarifaEstandar") verifica de una vez el registro completo y, con la última cláusula, el fallo de olvidar nombre() en una tarifa nueva.

Tres formas de verificar un fallo, en orden de preferencia:

Comprobar el codigo —el campo estable de CicloUrbanaException de 03-06— es lo que convierte el aserto en una verificación del contrato con el cliente de la API. El aserto peligrosamente débil es isInstanceOf(RuntimeException.class): cualquier NullPointerException accidental lo satisface y tiñe la prueba de verde.

Aserciones blandas. Cuando una prueba tiene varios asertos, el primero que falla oculta los demás: arreglas uno, ejecutas, falla el segundo. assertSoftly los evalúa todos:

Son ideales para verificar un solo objeto compuesto: un concepto expresado en varios campos. No son una licencia para meter cinco comprobaciones inconexas en una prueba.

Una prueba parametrizada ejecuta el mismo método con distintos datos. Es la respuesta al problema con el que abría la lección, y junit-jupiter-params ya viene en el starter.

El atributo name merece atención: sin él el informe muestra [1], [2], [3]; con él, «una capacidad de -5 anclajes debe rechazarse». Los marcadores son {0}, {1}... para los argumentos, {index} para el número de caso y {displayName}.

El ejemplo central de la lección: las tres tarifas de Ribalta, con sus reglas y sus límites, en una sola clase legible. Las reglas de 02-02:

Qué hace bueno a este diseño:

• Los casos límite de cada franquicia están juntos y a la vista: 14, 15 y 16 minutos para el estudiante; 30 y 31 para el jubilado. Leyendo la lista se ve que el límite es inclusivo. Es la documentación viva de 06-01 en su forma más pura.
• @CsvSource convierte automáticamente "4.10" a BigDecimal, "30" a long y "MANTENIMIENTO" a la constante del enum (para tipos propios existe @ConvertWith), y @MethodSource es la fuente para objetos complejos: su método debe ser static, salvo con Lifecycle.PER_CLASS.
• Un fallo señala el caso exacto: el informe dirá [5] estudiante: 16 min -> 0.08 €, no «falló la prueba de tarifas».

Cuando la lista crece y se comparte entre clases, @ArgumentsSource la extrae a un ArgumentsProvider reutilizable, con la misma forma que casosDeTarifa pero implementando provideArguments(ExtensionContext).

Una clase con veinte métodos planos es tan ilegible como un método de doscientas líneas. @Nested agrupa por escenario, y cada grupo tiene su propio @BeforeEach:

Reglas que hay que conocer: la clase interna no puede ser static —necesita la instancia externa—, y los @BeforeEach se acumulan de fuera hacia dentro, que es lo que permite la preparación incremental. El informe se muestra jerárquico y se lee como una especificación:

@DisplayName no sustituye a un buen nombre de método: el nombre es lo que aparece en las trazas de fallo y en los filtros de -Dtest=.

@Tag corta la suite por criterios transversales al nombre del fichero:

Usa pocas etiquetas y con significado claro: en CicloUrbana bastan lento y seguridad. Y recuerda que para separar unitarias de integración ya tenemos un mecanismo mejor, el sufijo *IT con Failsafe de 06-01, que no depende de que nadie se acuerde de anotar.

Aquí se cobra una decisión tomada en 02-01. ConfiguracionComun declara @Bean Clock relojRibalta(), y en su momento pareció una formalidad. Si AlquilerService calculara la duración con Instant.now(), probar un alquiler de dos horas exigiría esperar dos horas, cambiar el reloj del sistema o simular un método estático (06-03: se puede, y casi nunca se debe). Con el Clock inyectado —Instant.now(clock)— el tiempo es un argumento más:

Las dos fábricas que se usan en pruebas:

La segunda es la que permite probar que un token JWT caduca a los quince minutos: se genera con un reloj y se valida con otro adelantado dieciséis. Sin esperar dieciséis minutos.

La regla general: cualquier fuente de no determinismo debe ser inyectable. El reloj, el generador aleatorio —el Random con semilla fija de 02-01 responde a la misma idea— y el generador de identificadores. Un new Random() o un UUID.randomUUID() incrustados en la lógica hacen imposible una aserción exacta.

@TempDir da un directorio que JUnit crea antes y borra después, sin código de limpieza:

Las suposiciones abortan la prueba sin marcarla como fallida cuando no se dan las condiciones: assumeTrue(DockerClientFactory.instance().isDockerAvailable(), "Docker no disponible") la omite entera, y assumingThat(condicion, () -> assertThat(...)) omite solo un bloque de asertos. La diferencia con @Disabled es que este desactiva siempre y la suposición decide en ejecución. El matiz que hay que vigilar: una prueba omitida aparece en verde en el resumen, así que una suposición laxa oculta que algo no se ejecuta nunca. Ponles siempre mensaje.

@RepeatedTest(100) ejecuta la misma prueba varias veces; su uso legítimo es comprobar algo con aleatoriedad interna, como un generador de matrículas RB-\d{4}. No sirve para detectar problemas de concurrencia: repetir cien veces en el mismo hilo no crea contención. Y si una prueba pasa 99 veces de 100, no tienes una prueba escamosa: tienes un error.

Poniéndolo todo junto sobre una clase real. EstacionService recibe su repositorio por constructor (02-02), así que le entregamos el EstacionRepositorioEnMemoria de 02-01 —el fake de la tabla de dobles de 06-01— y no hace falta nada más:

Por qué esta prueba no levanta el contexto, aunque EstacionService sea un @Service:

La anotación @Service no impide instanciar la clase con new: son metadatos que Spring lee en el arranque. Una prueba unitaria no levanta el contexto porque no está probando el contexto. Que el cableado funciona se comprueba una vez, en las pruebas de integración de 06-04, no en cada una de las doscientas pruebas de lógica.

Ha aparecido varias veces EstacionesDePrueba.plazaMayor(). Es el patrón Object Mother: una fábrica en src/test/java que produce objetos del dominio válidos y con nombre de negocio.

Cuando los objetos tienen muchos campos y cada prueba varía uno, el builder es más flexible:

Lo que se gana es sustancial: la prueba solo menciona lo que le importa. Los otros seis campos existen con valores válidos pero no ensucian la lectura, y si mañana Alquiler gana un campo obligatorio se cambia el builder y no las cuarenta pruebas.

Un consejo sobre la línea que separa esto de un antipatrón: el objeto de la prueba se construye, no se calcula. Si el builder empieza a contener lógica —«si está finalizado, calcula el importe con la tarifa»— has duplicado la implementación dentro de las pruebas, y entonces la prueba pasa aunque el código esté mal.

Mezclar org.junit.Test con org.junit.jupiter.api.Test. La prueba compila y no se ejecuta jamás; si el número de pruebas del informe no cuadra, revisa los import. En la misma familia está olvidar el static en @BeforeAll, @AfterAll o en el método de @MethodSource: el error de configuración es claro, pero cuesta reconocerlo la primera vez.

isEqualTo sobre BigDecimal. Falla por la escala aunque el valor sea correcto. Con importes, siempre isEqualByComparingTo. Es el fallo que más tiempo hace perder en un dominio con dinero como el de CicloUrbana.

Depender del orden de ejecución. JUnit no lo garantiza y crea una instancia nueva por prueba para impedirlo. Si una prueba solo pasa cuando otra la precede, hay estado compartido —un campo static, un fichero, un singleton—: arréglalo, no lo ordenes con @TestMethodOrder. En la misma familia está el aserto laxo (isNotNull() como única comprobación, o isInstanceOf(RuntimeException.class) esperando una excepción concreta): pasa siempre y no protege de nada.

Lógica condicional dentro de una prueba. Un if (esFinDeSemana) { ... } else { ... } significa que hay dos pruebas escritas en una y que en cada ejecución solo se comprueba una rama. La solución es una prueba parametrizada, o dos métodos.

Consejo: una razón para fallar por prueba. No significa un solo assertThat, sino un solo concepto. Cinco asertos sobre los cinco campos de un AlquilerResponse son un concepto; comprobar el importe y que se publicó el evento son dos, y merecen dos métodos.

Consejo: si necesitas más de tres o cuatro líneas de preparación, mira la clase. Una preparación larga es la queja de la prueba sobre el diseño: demasiadas dependencias, demasiado estado, demasiadas responsabilidades.

Amplía CalculadoraTarifaTest con una prueba parametrizada que verifique la propiedad transversal de las tres tarifas: ningún importe puede ser negativo y todos deben tener exactamente dos decimales de escala. Usa @MethodSource para combinar las tres tarifas con las duraciones 0, 1, 15, 30, 45 y 120 minutos, y assertSoftly para informar de todos los fallos de un caso a la vez. Explica por qué esta prueba y las del apartado 7 no se solapan.

Escribe ServicioJwtCaducidadTest con dos pruebas que usen Clock para verificar la regla de 05-04 —el token de acceso caduca a los quince minutos— sin esperar quince minutos: una que compruebe que un token generado hace 14 minutos sigue siendo válido y otra que uno de hace 16 ya no lo es. Supón que ServicioJwt recibe JwtProperties y Clock por constructor. Razona por qué la prueba del minuto 16 es más importante, y qué hace clockSkewSeconds(30) con el caso de los 15 minutos y 10 segundos.

Refactoriza esta prueba, que reúne cinco defectos de los vistos en la lección, y enumera cuáles son:

Solución 1

Comentario: no se solapan porque comprueban cosas distintas. Las del apartado 7 son pruebas basadas en ejemplos: verifican un valor exacto para una entrada exacta y detectan errores de fórmula. Esta es una prueba basada en propiedades: no sabe cuánto debe costar, pero afirma invariantes que se cumplen siempre. Detecta otra clase de errores —un importe negativo por una resta sin Math.max, o una escala perdida por olvidar setScale— y sigue siendo válida cuando el ayuntamiento cambie los precios, cosa que las del apartado 7 no. El as(...) añade contexto al mensaje de fallo, imprescindible con 18 combinaciones. Y .scale() es exigente a propósito: una tarifa que devuelva BigDecimal.ZERO (escala 0) en vez de new BigDecimal("0.00") fallará, y es correcto que falle: un importe de factura debe formatearse como 0,00 €.

Solución 2

Sobre clockSkewSeconds(30): la tolerancia de 05-04 hace que un token de 15 minutos y 10 segundos siga siendo aceptado, porque está dentro del margen previsto para el desfase entre máquinas. Es correcto y deliberado, pero significa que una prueba de caducidad no debe situarse a pocos segundos del límite: sería frágil y ambigua. Por eso los casos elegidos son 14 y 16 minutos, holgadamente a cada lado. Si quisieras verificar la tolerancia en sí, ese es un tercer caso con su propio nombre: aceptaElTokenDentroDelMargenDeTreintaSegundos.

Solución 3

Los cinco defectos:

1. static List<Estacion> estaciones: estado compartido entre pruebas. Rompe el aislamiento y hace que el resultado dependa del orden.
2. TestEstaciones y test1: nombres que no describen ninguna regla. Cuando falle en la integración continua habrá que abrir el fichero.
3. if (estaciones.size() > 0): lógica condicional. Si la lista estuviera vacía, la prueba pasaría sin comprobar nada.
4. Dos conceptos en un método: la gestión de estaciones y el cálculo de la tarifa no tienen relación. Dos razones para fallar, y ningún nombre puede describirlas.
5. assertEquals(new BigDecimal("4.1"), importe): falla por la escala, usa aserciones de JUnit en vez de AssertJ y pone los argumentos en el orden esperado-real, propenso a invertirse. Como añadido, assertNotNull sobre un objeto que la propia prueba acaba de crear no verifica nada del código de producción.

Refactorizada, son dos clases:

El aserto sobre buscarPorId es lo que convierte la segunda en una prueba de verdad: no comprueba que el objeto recién creado no sea nulo —eso ya lo sabemos—, sino que el servicio lo ha guardado y sabe recuperarlo, que es la responsabilidad real de crear.

La base de la pirámide de CicloUrbana ya tiene cimientos. Conoces la arquitectura de JUnit 5 —Platform, Jupiter y Vintage— y la trampa del import equivocado que hace que una prueba no se ejecute nunca sin decirlo. Dominas el ciclo de vida completo y, sobre todo, la decisión que lo gobierna: una instancia nueva de la clase por cada @Test, la garantía de aislamiento sobre la que descansa que el orden de ejecución no importe. Sabes usar @BeforeEach para preparación incremental, por qué @BeforeAll es static y por qué un @Disabled sin motivo es peor que no tener la prueba.

Tienes el catálogo de AssertJ por tipo de dato con sus casos delicados: usingRecursiveComparison para entidades cuyo equals compara por identificador, la diferencia entre containsExactly, containsExactlyInAnyOrder y contains, extracting con tuplas y, la que más disgustos evita, isEqualByComparingTo para todo BigDecimal, porque el equals compara la escala y en Ribalta se factura en euros. Sabes exigir el tipo concreto de excepción con assertThatThrownBy, comprobar el codigo estable de las excepciones de 03-06 y agrupar los asertos de un objeto compuesto con assertSoftly. Y has escrito el ejemplo estrella del módulo: las tres tarifas de Ribalta con sus franquicias y sus límites exactos —14, 15 y 16 minutos; 30 y 31— en una sola clase parametrizada, donde @CsvSource cubre lo simple y @MethodSource lo complejo, y donde el nombre de cada caso identifica el fallo sin abrir el fichero. Sabes organizar por escenarios con @Nested, poner nombres legibles con @DisplayName, cortar la suite con @Tag sin abusar, aislar ficheros con @TempDir y omitir con criterio mediante suposiciones. Y has cobrado la deuda del módulo 2: el Clock inyectado convierte el tiempo en un argumento, y Clock.fixed hace que un alquiler de dos horas se pruebe en dos milisegundos. Cierras con EstacionService probado sin una sola línea de Spring —veinte milisegundos frente a varios segundos— y con los datos encapsulados en EstacionesDePrueba y un builder de alquileres, para que cada prueba mencione solo lo que le importa.

Queda un límite evidente. EstacionService se pudo probar así porque existe EstacionRepositorioEnMemoria, un fake que escribimos en el módulo 2 y que ya no representa la implementación real. AlquilerService es otra historia: depende de cuatro repositorios JPA, del SelectorTarifa, del Clock y del publicador de eventos, y no hay ningún fake para ninguno de ellos. Escribirlos a mano sería absurdo. La lección siguiente, Simulación con Mockito, resuelve exactamente eso: crear dobles al vuelo, programar sus respuestas, forzar los escenarios difíciles —la bicicleta no disponible, la estación llena, el fallo del repositorio— y verificar que AlquilerService publicó el evento AlquilerIniciado que debía. Con eso, la clase más importante de CicloUrbana quedará bajo prueba.