Pruebas Unitarias — Spring Boot

✓ Configuración de la clase de prueba

Cada clase de pruebas requiere anotaciones específicas para integrarse con el contexto de Spring y JPA.

CompanyServiceTest.java — anotaciones
@DataJpaTest
@Transactional
@Import(CompanyService.class)
public class CompanyServiceTest
{
  @Autowired
  private CompanyService companyService;

  @Autowired
  private TestEntityManager entityManager;

  private PodamFactory factory =
      new PodamFactoryImpl();

  private List<CompanyEntity> companyList =
      new ArrayList<>();
}

¿Qué hace cada anotación?

@DataJpaTest — Carga solo la configuración necesaria para pruebas de JPA. Desactiva el servidor web y carga solo las capas de BD.
@Transactional — Cada prueba se ejecuta en una transacción que se revierte al terminar, dejando la BD limpia.
@Import(CompanyService.class) — Importa el servicio bajo prueba al contexto de Spring para que pueda ser inyectado.
@Autowired — Spring inyecta automáticamente las dependencias marcadas (servicio, entityManager).

🗄 ¿Qué es TestEntityManager?

Es una herramienta proporcionada por Spring Test que permite interactuar con la base de datos de pruebas de forma manual. Se usa para:

Insertar datos de prueba: entityManager.persist(entity) — Guarda datos en la BD antes de ejecutar el test.
Buscar datos: entityManager.find(Class, id) — Obtiene una entidad de la BD para verificar que se persistió correctamente.
Ejecutar queries: entityManager.createQuery("DELETE FROM...") — Ejecuta consultas SQL directo.
Limpiar datos: Elimina registros de la BD entre pruebas para garantizar aislamiento.

Diferencia clave: El CompanyService que probamos usa CompanyRepository (interfaz de persistencia). El TestEntityManager es nuestro acceso directo a la BD para preparar datos o validar resultados sin pasar por el servicio.

🔄 ¿Qué es el setUp y por qué lo necesitamos?

El setUp es un método especial que se ejecuta automáticamente antes de cada test. Su propósito es preparar un estado inicial conocido y consistente para que cada test comience bajo las mismas condiciones.

¿Por qué es necesario? Sin setUp, los tests podrían interferir entre sí:

Un test podría dejar datos en la BD que afecten al siguiente test
El orden de ejecución de los tests es impredecible (JUnit no garantiza un orden)
Un test que funciona solo podría fallar cuando se ejecuta con otros

Solución: El setUp limpia la BD y carga datos frescos antes de cada test, garantizando aislamiento total.

⏱ Ciclo de Vida de un Test

JUnit ejecuta cada test siguiendo este ciclo:

@BeforeEach — setUp(): Se ejecuta ANTES de cada método @Test. Limpia la BD y carga datos iniciales.

@Test — testCreateCompany(): Se ejecuta el test específico. Usa los datos que setUp() preparó.

@AfterEach (opcional): Se ejecuta DESPUÉS del test. Generalmente no es necesario porque @Transactional revierte los cambios automáticamente.

Repetir: El ciclo se repite para cada método @Test en la clase.

Ejemplo: Si tienes 5 métodos @Test, el setUp() se ejecutará 5 veces (una antes de cada test). Esto garantiza que cada test empiece con la BD en el mismo estado limpio.

💻 Implementación del setUp

El método setUp típicamente hace dos cosas: limpiar la BD y luego insertar datos de prueba.

CompanyServiceTest.java — setUp completo
@BeforeEach
void setUp()
{
  // 1. Limpiar todos los datos existentes
  clearData();
  
  // 2. Insertar datos frescos para las pruebas
  insertData();
}

// ──────────────────────────────────────
// Método auxiliar: Limpiar la base de datos
// ──────────────────────────────────────
private void clearData()
{
  entityManager.getEntityManager()
      .createQuery("delete from CompanyEntity")
      .executeUpdate();
}

// ──────────────────────────────────────
// Método auxiliar: Insertar datos de prueba
// ──────────────────────────────────────
private void insertData()
{
  for (int i = 0; i < 3; i++)
  {
    CompanyEntity entity =
        factory.manufacturePojo(CompanyEntity.class);
    entityManager.persist(entity);
    companyList.add(entity);
  }
}

Desglose paso a paso:

📌 clearData() — Limpieza de la BD

entityManager.getEntityManager() — Obtiene el EntityManager de JPA que maneja la conexión a la BD de pruebas (H2 en memoria).

.createQuery("delete from CompanyEntity") — Crea una query JPQL (no SQL nativo) que elimina TODAS las filas de la tabla CompanyEntity.

.executeUpdate() — Ejecuta la query de eliminación. Retorna el número de filas eliminadas (pero no lo usamos).

📌 insertData() — Carga de datos de prueba

for (int i = 0; i < 3; i++) — Inserta exactamente 3 compañías. ¿Por qué 3? Para tener suficientes datos para tests negativos (ej: intentar crear una con nombre duplicado).

factory.manufacturePojo(...) — Usa Podam para generar una CompanyEntity con datos aleatorios válidos (nombre, descripción, etc.).

entityManager.persist(entity) — Guarda la compañía en la base de datos de pruebas usando TestEntityManager.

companyList.add(entity) — Guarda la compañía en una lista en memoria (companyList es una variable de instancia de la clase de test). Esto permite que los tests accedan fácilmente a las compañías existentes.

Variable companyList: Es una List<CompanyEntity> declarada en la clase de test. Después del setUp(), contiene las 3 compañías que acabamos de insertar. Los tests pueden usar companyList.get(0) para acceder a una compañía existente (ej: para tests de nombre duplicado).

❓ Preguntas Frecuentes

¿Es necesario clearData() si @Transactional revierte los cambios?

Buena pregunta. Técnicamente, cada test se revierte automáticamente por @Transactional (la BD vuelve al estado previo después de cada test). Sin embargo, clearData() sigue siendo importante porque:

Garantiza un estado limpio explícito al inicio de cada test
Protege contra cambios futuros en la configuración transaccional
Hace visible la intención: "empezar con BD vacía"
Si usas datos desde data.sql u otros orígenes, asegura que se limpien correctamente

En resumen: No es estrictamente necesario técnicamente, pero es una buena práctica de limpieza explícita que hace los tests más robustos y fáciles de entender.

¿Por qué insertamos 3 compañías y no solo 1?

Insertar múltiples registros (típicamente 3-5) es útil porque:

Tests de búsqueda: Puedes verificar que findAll() retorna todos los elementos
Tests de filtrado: Puedes buscar uno específico entre varios
Tests negativos: Necesitas datos existentes para probar duplicados o violaciones de unicidad
Realismo: Una BD con varios registros es más representativo del mundo real

Regla práctica: Inserta entre 3 y 5 elementos. No demasiados (lentitud) ni muy pocos (tests poco realistas).

¿Dónde se declara companyList?

La variable companyList se declara como variable de instancia en la clase de test:

Variables de instancia en CompanyServiceTest
public class CompanyServiceTest
{
  @Autowired
  private CompanyService companyService;

  @Autowired
  private TestEntityManager entityManager;

  private PodamFactory factory =
      new PodamFactoryImpl();

  // Lista que almacena las compañías insertadas en setUp()
  private List<CompanyEntity> companyList =
      new ArrayList<>();
}

Esta lista se limpia automáticamente en cada setUp() porque se crea como new ArrayList<>(), pero puedes también hacer companyList.clear() al inicio de insertData() para ser más explícito.

Resumen: El setUp() con @BeforeEach garantiza que cada test empiece con un estado conocido y consistente. Limpia la BD (clearData()), inserta datos frescos (insertData()), y permite que los tests sean independientes y repetibles. Esto es fundamental para tener pruebas confiables que no dependan del orden de ejecución.

⚙ ¿Qué es Podam?

Podam (POjo DAta Maker) es una librería Java que genera automáticamente instancias de clases con datos aleatorios válidos. Es especialmente útil en pruebas unitarias porque elimina la necesidad de crear manualmente objetos de prueba con todos sus atributos.

¿Cómo funciona? Podam usa reflexión para inspeccionar la clase, identificar sus atributos (String, Long, Date, etc.) y generar valores aleatorios apropiados para cada tipo.

✓ Ejemplo Simple — Generar una entidad

Supongamos que tienes esta entidad:

BookEntity.java
@Entity
public class BookEntity
{
  @Id
  @GeneratedValue
  private Long id;

  private String name;
  private String isbn;
  private Date publishDate;
  private Integer pages;

  // getters y setters...
}

En lugar de crear manualmente el objeto así:

❌ Forma manual (tedioso y repetitivo)
BookEntity book = new BookEntity();
book.setName("El Quijote");
book.setIsbn("978-1234567890");
book.setPublishDate(new Date());
book.setPages(863);
// Repetir esto para cada test...

Con Podam, lo haces en una línea:

✅ Con Podam (automático)
PodamFactory factory = new PodamFactoryImpl();
BookEntity book = factory.manufacturePojo(BookEntity.class);

// book ya tiene todos los campos inicializados con valores aleatorios
// name = "algún texto aleatorio"
// isbn = "otro texto aleatorio"
// publishDate = alguna fecha aleatoria
// pages = algún número aleatorio

Ventaja: Cada vez que ejecutas el test, Podam genera datos diferentes. Esto prueba que tu código funciona con diversos valores, no solo con datos específicos hardcodeados.

⚠ Problema: Loop Infinito con Relaciones Bidireccionales

Cuando tienes entidades con relaciones bidireccionales (donde A conoce a B y B conoce a A), Podam puede entrar en un loop infinito al intentar generar los objetos.

Ejemplo del problema:

BookEntity.java — con relación bidireccional
@Entity
public class BookEntity
{
  @Id
  private Long id;
  private String name;

  // Relación: un libro tiene un autor
  @ManyToOne
  private AuthorEntity author;
}

AuthorEntity.java — relación inversa
@Entity
public class AuthorEntity
{
  @Id
  private Long id;
  private String name;

  // Relación inversa: un autor tiene muchos libros
  @OneToMany(mappedBy = "author")
  private List<BookEntity> books;
}

¿Qué pasa si intentas generar un BookEntity con Podam?

Podam crea un BookEntity
Ve que tiene un atributo author, así que crea un AuthorEntity
Ve que AuthorEntity tiene una lista books, así que crea libros
Cada libro necesita un author, así que crea más autores
Cada autor tiene books, así que crea más libros...
Loop infinito → StackOverflowError 💥

🔧 Solución: @PodamExclude

La anotación @PodamExclude le indica a Podam que ignore ese atributo y no intente generar datos para él. Se coloca sobre el atributo que queremos excluir (típicamente el lado inverso de la relación).

AuthorEntity.java — con @PodamExclude
import uk.co.jemos.podam.common.PodamExclude;

@Entity
public class AuthorEntity
{
  @Id
  private Long id;
  private String name;
  private Date birthDate;

  // ✅ Excluir esta colección para evitar loop infinito
  @PodamExclude
  @OneToMany(mappedBy = "author")
  private List<BookEntity> books;

  // getters y setters...
}

Ahora al generar un BookEntity:

Uso en pruebas
PodamFactory factory = new PodamFactoryImpl();
BookEntity book = factory.manufacturePojo(BookEntity.class);

// ✅ book tiene:
//   - id, name, isbn, publishDate → valores aleatorios
//   - author → un AuthorEntity con id, name, birthDate aleatorios
//   - author.books → null (porque está excluido con @PodamExclude)

// ✅ No hay loop infinito

Regla práctica: En relaciones bidireccionales, agrega @PodamExclude al lado que tiene la colección (@OneToMany o @ManyToMany). Así Podam puede generar el lado "muchos" sin problemas, pero no intenta llenar la colección del lado "uno".

📋 Buenas Prácticas con Podam

Usa @PodamExclude en colecciones de relaciones inversas: Evita loops infinitos en relaciones bidireccionales.
Declara el factory como variable de instancia: private PodamFactory factory = new PodamFactoryImpl(); para reutilizarlo en todos los tests.
Modifica solo lo necesario: Genera el objeto con Podam y luego sobrescribe solo los atributos específicos que necesites para el test (ej: book.setIsbn("specific-value")).
No confíes en valores específicos: Como Podam genera datos aleatorios, no hagas aserciones sobre valores concretos (ej: no asumas que name será "algo específico"). En su lugar, verifica que el objeto exista y tenga la estructura correcta.

Resumen: Podam ahorra tiempo al generar objetos de prueba automáticamente. Cuando trabajas con entidades relacionadas, usa @PodamExclude en las colecciones inversas para evitar loops infinitos. Esto es especialmente importante en arquitecturas con múltiples entidades interconectadas como las que usamos en Spring Boot con JPA.

📝 ¿Qué son los Escenarios de Prueba?

Los escenarios de prueba son casos de uso específicos que verifican que tu código se comporta correctamente. Cada escenario es un método anotado con @Test que ejecuta el servicio bajo condiciones específicas y valida el resultado.

Hay dos tipos principales de escenarios:

Escenarios positivos (caso feliz): Verifican que el código funciona cuando todo está correcto.
Escenarios negativos: Verifican que el código maneja correctamente los errores y violaciones de reglas de negocio.

Por cada método del servicio necesitas al menos un test positivo y un test negativo por cada regla de negocio. Si createCompany() valida 2 reglas, necesitas 1 positivo + 2 negativos = 3 tests mínimo.

✓ Escenario Positivo — Crear compañía válida

Este test verifica que el método createCompany() funciona correctamente cuando se proporciona una compañía válida (sin violaciones de reglas).

CompanyServiceTest.java — testCreateCompany()
@Test
void testCreateCompany()
{
  // Paso 1: Generar datos de prueba
  CompanyEntity newEntity =
      factory.manufacturePojo(CompanyEntity.class);

  // Paso 2: Invocar el método bajo prueba
  CompanyEntity result =
      companyService.createCompany(newEntity);

  // Paso 3: Verificar que retornó un resultado
  assertNotNull(result);

  // Paso 4: Buscar en BD usando TestEntityManager
  CompanyEntity entity = entityManager
      .find(CompanyEntity.class, result.getId());

  // Paso 5: Verificar que se persistió correctamente
  assertEquals(newEntity.getName(), entity.getName());
  assertEquals(newEntity.getDescription(),
                      entity.getDescription());
}

Desglose paso a paso:

Generar datos de prueba: Usamos Podam para crear una CompanyEntity con datos aleatorios válidos. Esto simula una compañía nueva que queremos guardar.

Invocar el servicio: Llamamos al método companyService.createCompany(newEntity) que es el código que estamos probando. Este método debería validar las reglas y guardar la compañía en la base de datos.

Verificar que no retorna null: assertNotNull(result) confirma que el método retornó algo (no null). Si retorna null, el test falla inmediatamente.

Buscar en BD independientemente: Usamos entityManager.find() para buscar la compañía directamente en la base de datos. No usamos el servicio porque queremos verificar que realmente se persistió, no solo que el método retornó algo.

Validar los datos: assertEquals() compara los valores originales con los que están en la BD. Si coinciden, significa que la compañía se guardó correctamente con todos sus datos intactos.

Concepto clave: Siempre verifica la persistencia usando TestEntityManager, no llamando de nuevo al servicio. Esto asegura que realmente se guardó en la base de datos, no solo que el servicio dice que lo hizo.

✗ Escenario Negativo — Nombre duplicado

Este test verifica que el método createCompany() rechaza correctamente una compañía cuando se viola la regla de negocio "no puede haber dos compañías con el mismo nombre".

CompanyServiceTest.java — testCreateInvalidCompany()
@Test
void testCreateInvalidCompany()
{
  // assertThrows: verifica que el código lanza una excepción
  assertThrows(IllegalOperationException.class, () ->
  {
    // Paso 1: Generar una compañía nueva
    CompanyEntity newEntity =
        factory.manufacturePojo(CompanyEntity.class);

    // Paso 2: Cambiar el nombre para que sea igual a una existente
    // companyList tiene datos cargados en setUp()
    newEntity.setName(companyList.get(0).getName());

    // Paso 3: Intentar crear (debería fallar)
    companyService.createCompany(newEntity);
  });
}

Desglose paso a paso:

assertThrows: Esta aserción especial de JUnit 5 ejecuta el código dentro del lambda () -> {...} y verifica que lance la excepción indicada. Si el código NO lanza la excepción, el test falla.

Generar datos base: Creamos una compañía con Podam, pero luego modificaremos su nombre para violar la regla de negocio.

Forzar la violación: Cambiamos el nombre de la nueva compañía para que sea igual al de una existente (que fue cargada en setUp()). Esto garantiza que se viole la regla "nombres únicos".

Invocar y esperar fallo: Llamamos a createCompany(). El servicio debería detectar el nombre duplicado y lanzar IllegalOperationException. Si lanza la excepción, el test pasa ✓. Si NO lanza excepción, el test falla ✗.

Importante: En escenarios negativos, el éxito del test significa que el código falló correctamente. Es decir, queremos que lance la excepción. Si el código permite la operación inválida, entonces el test falla porque el servicio no está validando bien.

📊 Estrategia General de Pruebas

Para cada método del servicio, sigue esta estrategia:

1. Identifica qué pruebas necesitas:

1 test positivo que verifique el caso feliz (todo funciona bien)
1 test negativo por cada regla de negocio que el método valide

2. Ejemplo con createBook():

Regla 1: El ISBN no puede ser vacío
Regla 2: La fecha de publicación debe ser posterior al nacimiento del autor
Tests necesarios: 1 positivo + 2 negativos = 3 tests

3. Nombres descriptivos:

testCreateBook() — caso feliz
testCreateBookWithEmptyIsbn() — valida regla 1
testCreateBookWithInvalidPublishDate() — valida regla 2

💡 Tabla de cobertura de pruebas

Método del Servicio	Reglas de Negocio	Tests Positivos	Tests Negativos	Total Tests
createCompany()	1	1	1	2
createBook()	2	1	2	3
createDepartment()	1	1	1	2

Resumen: Los escenarios de prueba verifican que tu servicio funciona correctamente (positivo) y rechaza operaciones inválidas (negativo). Cada test sigue el patrón: preparar datos → ejecutar → validar resultado. Usa Podam para datos aleatorios, TestEntityManager para verificar persistencia, y assertThrows para validar que las excepciones se lanzan cuando deben.