Testing Profesional en Java Puro: JUnit 5 y AssertJ

Arrange-Act-Assert (o Given-When-Then) divide cada test en tres bloques separados por una línea en blanco. En el primero preparas los datos y colaboradores, en el segundo ejecutas exactamente una acción del código bajo prueba y en el tercero compruebas el resultado. Si necesitas varias acciones, probablemente estás probando más de un comportamiento y conviene partir el test.

El nombre del test es documentación: debe decir qué se espera y en qué situación (deberiaRechazarTituloVacio, devuelve404CuandoLaTareaNoExiste). Con @DisplayName puedes escribir frases completas que aparecen en el informe. Cuando un test falla, el nombre y la aserción deberían bastar para saber qué se rompió sin abrir el código.

Un buen test unitario es rápido (milisegundos), determinista (mismo resultado siempre), independiente (no depende de otros tests) y prueba comportamiento observable, no detalles de implementación. Si refactorizas sin cambiar el comportamiento y el test se rompe, el test estaba acoplado a la implementación.

AssertJ sustituye las aserciones de JUnit por una API fluida que empieza siempre con assertThat(valorReal). El autocompletado del IDE te ofrece solo las comprobaciones que tienen sentido para ese tipo: para una lista verás hasSize, contains, containsExactly; para un Optional, isPresent o contains; para un String, startsWith o matches.

La ventaja real aparece cuando el test falla. En lugar de «expected true but was false», AssertJ muestra qué contenía la colección, qué elemento faltaba o qué campo era distinto. Con extracting comparas solo los campos que te interesan de una lista de objetos, y con usingRecursiveComparison comparas objetos campo a campo sin necesidad de equals.

Con SoftAssertions puedes acumular varios fallos y verlos todos de una vez, útil cuando compruebas varios campos de un mismo resultado.

@ParameterizedTest sustituye a @Test y recibe los datos de una o varias fuentes. @ValueSource da una lista de valores simples; @CsvSource da filas con varias columnas, convertidas automáticamente al tipo de cada parámetro (números, enums, fechas); @EnumSource recorre las constantes de un enum; y @MethodSource llama a un método estático que devuelve un Stream de Arguments cuando los datos son objetos complejos. @NullAndEmptySource añade los casos null y vacío.

Cada combinación se ejecuta como un test independiente, con su propio resultado en el informe. Con el atributo name controlas cómo aparece (name = "{0} es válido"), y así un fallo dice exactamente qué entrada lo provocó.

Son ideales para tablas de decisión y casos límite: valores frontera, formatos válidos e inválidos, combinaciones de estado. Lo que no conviene es meter lógica condicional en el cuerpo para comportarse distinto según el caso: si los casos válidos y los inválidos se comprueban de forma diferente, son dos tests.

JUnit 5 crea una instancia nueva de la clase de test para cada método (Lifecycle.PER_METHOD). Por eso los campos de instancia empiezan limpios en cada test y no hace falta resetearlos. @BeforeEach y @AfterEach se ejecutan alrededor de cada método; @BeforeAll y @AfterAll una vez por clase y, por defecto, deben ser static.

Los problemas aparecen con el estado que vive fuera de la instancia: campos static, singletons, ficheros temporales compartidos, una base de datos que no se limpia o el reloj del sistema. Un test que pasa solo cuando se ejecuta después de otro es una bomba de relojería: el orden de ejecución no está garantizado y cambiará al añadir tests o paralelizar.

Para detectarlo, puedes forzar un orden aleatorio con junit.jupiter.testmethod.order.default=org.junit.jupiter.api.MethodOrderer$Random en junit-platform.properties. Para ficheros, @TempDir te da un directorio limpio por test.

Hay tres formas habituales de comprobar que un código lanza una excepción. assertThrows de JUnit devuelve la excepción para que la inspecciones. assertThatThrownBy de AssertJ encadena comprobaciones sobre tipo, mensaje y causa en una sola expresión. assertThatExceptionOfType(X.class).isThrownBy(...) pone el tipo esperado delante, lo que se lee mejor cuando el tipo es lo importante.

Comprueba algo más que el tipo: el mensaje o un campo de la excepción te protegen de falsos positivos, por ejemplo un IllegalArgumentException lanzado por otra validación distinta de la que querías probar. Y verifica también que el estado no ha cambiado tras el error: si una operación falla a medias, el objeto debería seguir siendo válido.

Para el caso contrario, assertThatNoException().isThrownBy(...) deja explícito que el código debe terminar sin error.