Formación corporativa en JUnit

Las aserciones son la columna vertebral de cualquier test: determinan si el comportamiento observado cumple el contrato esperado. JUnit 6 (Jupiter) ofrece un conjunto enriquecido en la clase Assertions: comparaciones de igualdad (assertEquals, assertNotEquals), comprobaciones de nulidad (assertNull, assertNotNull), verificación de excepciones con assertThrows y assertDoesNotThrow, y aserciones de tiempo con assertTimeout y assertTimeoutPreemptively.

La agrupación de aserciones con assertAll permite verificar varios puntos de un objeto en un único test y reportar todos los fallos en lugar de detenerse en el primero. La integración con AssertJ proporciona una API fluida y legible (assertThat(lista).hasSize(3).contains("elemento")) especialmente valorada en revisiones de código y en equipos con experiencia en BDD. Hamcrest complementa con matchers componibles para condiciones más expresivas en tests de integración.

JUnit 6 crea por defecto una nueva instancia de la clase de test para cada método, lo que garantiza el aislamiento entre tests. Las anotaciones de ciclo de vida permiten ejecutar código antes o después de cada test (@BeforeEach, @AfterEach) o una única vez por clase (@BeforeAll, @AfterAll). Con @TestInstance(Lifecycle.PER_CLASS) se puede usar una única instancia compartida, lo que permite que @BeforeAll y @AfterAll sean métodos de instancia en lugar de estáticos.

El control del orden de ejecución con @TestMethodOrder (MethodOrderer.OrderAnnotation, MethodOrderer.Random o MethodOrderer.DisplayName) es útil en tests de integración donde el estado persiste entre pasos. El módulo también cubre el uso de @TempDir para directorios temporales limpiados automáticamente, el cierre limpio de recursos con AutoCloseable y las mejores prácticas para mantener tests rápidos y deterministas en entornos de integración continua.

Los tests parametrizados eliminan la duplicación de código de test al ejecutar la misma lógica de verificación con múltiples conjuntos de datos declarados de forma externa. JUnit 6 ofrece @ParameterizedTest combinado con distintas fuentes: @ValueSource para tipos primitivos y cadenas, @NullSource y @EmptySource para valores especiales, @EnumSource para recorrer enumerados, @CsvSource y @CsvFileSource para tablas de datos inline o desde fichero, y @MethodSource para casos de prueba complejos generados mediante factory methods.

@ArgumentsSource permite implementar un ArgumentsProvider personalizado que cargue datos desde cualquier origen externo (base de datos, API, ficheros YAML). El módulo cubre también la conversión implícita y explícita de argumentos con @ConvertWith, la personalización de nombres de test con {index} y {arguments} para mejorar la legibilidad de los informes de Surefire y Gradle, y la integración con generadores de datos aleatorios para property-based testing ligero.

La organización del código de test afecta directamente a la mantenibilidad de una suite grande. @Nested permite agrupar tests relacionados en clases internas con su propio ciclo de vida, lo que facilita representar escenarios Given/When/Then de forma jerárquica. @DisplayName personaliza el nombre que aparece en los informes de ejecución para que sea legible por analistas y responsables de calidad. @Tag habilita la selección de tests en función de etiquetas (integration, slow, smoke) en la configuración de Maven Surefire o Gradle.

El sistema de extensiones de JUnit 6 es el mecanismo de personalización oficial y reemplaza a los runners de JUnit 4. Una extensión implementa una o varias interfaces del ciclo de vida (BeforeEachCallback, AfterAllCallback, ParameterResolver, TestExecutionExceptionHandler) y se registra con @ExtendWith o @RegisterExtension. El módulo cubre la extensión MockitoExtension para dobles de prueba, extensiones para gestión de transacciones y el diseño de extensiones propias para necesidades de proyectos específicos.

Test-Driven Development (TDD) invierte el orden habitual de desarrollo: primero se escribe el test que falla (red), luego el código mínimo que lo hace pasar (green) y finalmente se mejora el diseño sin romper los tests (refactor). Este módulo explica el ciclo red-green-refactor en detalle, sus beneficios para el diseño emergente y los casos donde aplicarlo aporta más valor (lógica de negocio compleja, algoritmos, cálculos financieros o de facturación).

La pirámide de testing guía la distribución entre tests unitarios rápidos, de integración (con @SpringBootTest, @WebMvcTest y @DataJpaTest) y end-to-end. Testcontainers permite levantar bases de datos reales (PostgreSQL, MySQL) y brokers (Kafka, RabbitMQ) en Docker durante los tests de integración, eliminando la necesidad de bases de datos H2 en memoria que no replican el comportamiento del proveedor real. JaCoCo mide la cobertura de líneas y ramas y permite imponer umbrales mínimos en Maven o Gradle que bloquean el build en CI cuando la cobertura cae por debajo del umbral acordado por el equipo.