Patrones y antipatrones en pruebas unitarias con JUnit y Mockito

Escribir pruebas unitarias no consiste únicamente en verificar que el código funcione hoy, sino en garantizar que siga funcionando mañana cuando otro desarrollador (o tú mismo) realice un cambio. Sin embargo, un código de prueba mal estructurado, frágil y difícil de leer puede convertirse en una carga mayor que el propio código de producción.

Cuando los tests fallan constantemente por razones ajenas a la lógica de negocio, los equipos pierden confianza en ellos y, eventualmente, dejan de mantenerlos. En este artículo, analizaremos los antipatrones más comunes al escribir pruebas en Java utilizando JUnit y Mockito, y aplicaremos patrones de diseño para transformarlos en tests limpios, mantenibles y confiables.

¿Qué define a un Test Limpio?

Antes de corregir los errores, hay que entender el objetivo. Un test limpio suele adherirse a los principios FIRST:

• Fast (Rápido): Deben ejecutarse en milisegundos. Si son lentos, los desarrolladores evitarán correrlos.

• Independent (Independiente): Un test no debe depender del resultado ni del estado de otro test.

• Repeatable (Repetible): Deben dar el mismo resultado en la máquina local, en el servidor de CI/CD y en cualquier entorno.

• Self-Validating (Autovalidado): El resultado debe ser un claro éxito (verde) o fracaso (rojo), sin requerir inspección manual de logs.

• Timely (Oportuno): Deben escribirse en el momento adecuado, idealmente junto con (o antes de) el código de producción.

A continuación se plantean test con malos hábitos que rompen estas reglas y cómo solucionarlos.

Antipatrón 1: Test Gigante (The God Test / Giant Test) vs. Patrón: Arrange-Act-Assert (AAA)

El Problema

El God Test es una prueba monolítica de cientos de líneas que intenta verificar múltiples escenarios a la vez. Mezcla la creación de datos, la ejecución y decenas de aserciones (assertEquals, assertTrue) sin ningún orden. Si este test falla, es casi imposible saber qué funcionalidad específica se rompió sin usar el depurador.

La Solución: Patrón: Arrange-Act-Assert (AAA)

El patrón Arrange-Act-Assert (Preparar-Actuar-Afirmar) divide cada prueba en tres bloques lógicos y visuales muy claros. Un test debe probar un solo comportamiento.

En el siguiente ejemplo vemos que el test evalúa de forma sobrecargada el flujo completo de procesamiento de una orden, ya que en una sola prueba prepara los datos del usuario y la orden, ejecuta el servicio y valida múltiples efectos secundarios simultáneos: la actualización del estado a "PROCESADA", el registro del sello de tiempo y la notificación al usuario. Por esto, al incluir múltiples aserciones adicionales sobre distintos flujos, rompe el principio de responsabilidad única de un test unitario (Assertion Roulette), haciendo que verifique varios comportamientos independientes en lugar de centrarse en un solo caso de uso.

El Antipatrón en acción:

Java

@Test
void testProcesarOrden() {
    // Setup confuso mezclado con validaciones
    Orden orden = new Orden(1L, "Laptop");
    orden.setEstado("PENDIENTE");
    Usuario user = new Usuario("juan@test.com");
    orden.setUsuario(user);
    
    OrdenService service = new OrdenService(new NotificacionMock());
    service.procesar(orden);
    
    assertEquals("PROCESADA", orden.getEstado());
    assertNotNull(orden.getFechaProcesamiento());
    assertTrue(user.isNotificado());
    // ... 15 aserciones más de diferentes flujos
}

En el siguiente código se muestra cómo el test verifica de forma específica que, al procesar una orden en estado "PENDIENTE", su estado cambie a "PROCESADA" y se envíe una notificación al usuario; en el Arrange prepara el usuario, la orden y simula el servicio de notificación; en Act ejecuta el método de procesamiento; y en Assert verifica únicamente que el estado sea "PROCESADA" y que la notificación se haya enviado.

Aplicando el Patrón AAA:

Java

@Test
@DisplayName("Debe cambiar el estado de la orden a procesada y notificar al usuario")
void shouldProcessOrderAndNotifyUser() {
    // Arrange (Preparar)
    Usuario usuario = new Usuario("juan@test.com");
    Orden orden = new Orden(1L, "Laptop", usuario, "PENDIENTE");
    NotificacionService notificacionMock = mock(NotificacionService.class);
    OrdenService ordenService = new OrdenService(notificacionMock);

    // Act (Actuar)
    ordenService.procesar(orden);

    // Assert (Afirmar)
    assertEquals("PROCESADA", orden.getEstado());
    verify(notificacionMock, times(1)).enviar(usuario);
}

Nota: Usar @DisplayName en JUnit 5 o nombres de métodos descriptivos mejora enormemente la legibilidad cuando el test falla en la consola.

Antipatrón 2: Fuga de Configuración (Configuration Leakage) vs Patrón: Aislamiento de Configuración

El Problema

Un escenario sumamente frustrante (muy común en aplicaciones Spring Boot) ocurre cuando los tests pasan en tu máquina, pero fallan en el entorno de otro desarrollador o en el pipeline. A menudo, esto sucede porque las pruebas están leyendo el archivo application.properties de la carpeta principal (src/main/resources). Si alguien cambia una URL de base de datos, un token o un timeout en producción, los tests se rompen misteriosamente. Esto viola el principio Repeatable.

La Solución: Aislamiento con Test Resources

Para que las pruebas sean deterministas, deben tener su propio entorno aislado. En proyectos Java (Maven/Gradle), la carpeta src/test/resources tiene prioridad sobre src/main/resources durante la fase de testing.

Buenas prácticas de implementación:

1. Duplicación controlada: Crea un archivo application.properties o application.yml exclusivo en src/test/resources.

2. Uso de perfiles: Utiliza perfiles específicos para pruebas mediante la anotación @ActiveProfiles("test").

Java

@SpringBootTest
@ActiveProfiles("test") // Forzará a Spring a leer application-test.yml
class FacturacionServiceTest {
    
    @Value("${api.external.timeout}")
    private int timeout; // En test siempre será fijo, independientemente de producción

    @Test
    void shouldCalculateInvoiceCorrectly() {
        // Lógica de prueba con configuración predecible
    }
}

Con este patrón, te aseguras de que el entorno de pruebas sea inmutable frente a los ajustes operativos del código principal.

Antipatrón 3: Exceso de Mocks (Over-mocking / Mocking the World) vs. Patrón: Mocking Estratégico (Boundary Mocking)

El Problema

Con herramientas tan potentes como Mockito, es tentador usar @Mock para absolutamente todo. El antipatrón Over-mocking ocurre cuando el desarrollador falsea no solo las dependencias externas, sino también objetos de dominio (DTOs, Entidades) y lógica interna. El resultado es un test que "pasa" pero no prueba nada real; está probando la configuración del propio mock.

La Solución: Mocking Estratégico

El patrón dicta una regla clara: Mockea las dependencias, pero usa instancias reales para los datos.
Solo debes usar Mocks para aislar la clase bajo prueba de componentes externos lentos o volátiles (bases de datos, APIs de terceros, colas de mensajes).

El Antipatrón:

Java

@Test
void calcularTotalEnDolares_antipatron() {
    // MAL: Mockeando una estructura de datos simple
    Pedido pedidoMock = mock(Pedido.class);
    when(pedidoMock.getTotalLocal()).thenReturn(50000.0);
    when(pedidoMock.getMonedaOriginal()).thenReturn("COP");

    // BIEN: Mockear EXCLUSIVAMENTE dependencias externas o procesos pesados

    ServicioDeCambio servicioCambioMock = mock(ServicioDeCambio.class);
    when(servicioCambioMock.obtenerTasaDolar("COP")).thenReturn(0.00025);
    
    ProcesadorDePagos procesador = new ProcesadorDePagos(servicioCambioMock);
    
    double totalDolares = procesador.calcularTotalEnDolares(pedidoMock);
    
    assertEquals(12.5, totalDolares);
}

El patrón:

Aquí aplicamos la buena práctica. Instanciamos el Pedido real porque su estado es predecible y reside en memoria. Solo creamos un mock del ServicioDeCambio porque no queremos que nuestra prueba unitaria dependa de una conexión a internet o de una API de terceros.

Java

@Test
void calcularTotalEnDolares_patron() {
    // BIEN: Usar el objeto real para estructuras de datos y entidades
    Pedido pedido = new Pedido(50000.0, "COP"); 
    
    // BIEN: Mockear EXCLUSIVAMENTE dependencias externas o procesos pesados
    ServicioDeCambio servicioCambioMock = mock(ServicioDeCambio.class);
    when(servicioCambioMock.obtenerTasaDolar("COP")).thenReturn(0.00025);
    
    ProcesadorDePagos procesador = new ProcesadorDePagos(servicioCambioMock);
    
    double totalDolares = procesador.calcularTotalEnDolares(pedido);
    
    assertEquals(12.5, totalDolares); 
}

Antipatrón 4: Obsesión por las Métricas (Coverage Obsession / Metric Tyranny) vs. Patrón: Supresión Intencional (Intentional Suppression)

El Problema

Los linters y herramientas de análisis estático de código (como SonarQube o Checkstyle) son excelentes para mantener la calidad en src/main/java. Sin embargo, aplicar exactamente las mismas reglas inflexibles al código de pruebas suele generar problemas.
Por ejemplo, SonarQube podría fallar el pipeline quejándose de Magic Numbers (números quemados en el código) o cadenas de texto duplicadas en los asserts. Para evitar que el pipeline falle, los desarrolladores a veces caen en el antipatrón de colocar un desastroso @SuppressWarnings("all") en toda la clase de prueba, apagando por completo las validaciones.

La Solución: Supresión Consciente

El código de prueba tiene estándares diferentes al código de producción. En un test, la duplicación de literales de texto (cadenas esperadas) o el uso de números específicos (IDs de prueba) a menudo mejora la legibilidad, porque permite ver el valor exacto sin tener que navegar a constantes en otros archivos.

El patrón consiste en entender los límites y usar la supresión de forma quirúrgica.

Java

// Supresión específica solo para lo que es aceptable en un contexto de prueba
@SuppressWarnings("java:S1192") // String literals should not be duplicated (SonarQube)
class UsuarioValidacionTest {

    @Test
    void shouldRejectEmptyEmail() {
        Usuario user = new Usuario("");
        Exception error = assertThrows(ValidationException.class, () -> service.validar(user));
        // Duplicar "El email es requerido" aquí es preferible a una constante genérica porque hace el test explícito y fácil de leer.
        assertEquals("El email es requerido", error.getMessage()); 
    }
}

Nota: Se debe silenciar de forma específica las alertas que restan claridad al test (como la visibilidad de paquetes, literales duplicados o magic numbers), pero prestar atención cuando la herramienta advierte sobre aserciones faltantes, excepciones ignoradas o una complejidad ciclomática excesiva en la prueba.

Consideraciones Finales

Un error recurrente al hablar de pruebas unitarias es obsesionarse con la métrica de cobertura (Code Coverage). Herramientas como JaCoCo pueden indicarte que tienes un 100% de cobertura de líneas, pero eso solo significa que el código fue ejecutado durante la prueba, no que fue verificado. Un test con 100% de cobertura y sin ninguna aserción (assert o verify) es un test inútil.

Es mejor priorizar siempre la calidad y el diseño arquitectónico de la prueba sobre el simple cumplimiento de una métrica de porcentaje.

Conclusión

El código de pruebas debe ser tratado como código de primera clase, exigiendo el mismo nivel de cuidado, refactorización y diseño que el código destinado a producción. La implementación de patrones como el AAA, la gestión adecuada de los recursos de configuración, el uso responsable de mocks y el manejo estratégico de las herramientas de análisis estático, permiten transformar las pruebas unitarias de un mero requisito administrativo a una red de seguridad verdaderamente confiable. En consecuencia, la inversión de tiempo en la estructuración y limpieza de las pruebas constituye una práctica que beneficia profundamente a los equipos de desarrollo durante las futuras sesiones de depuración y resolución de incidentes.