Tutorial SpringBoot: Testing de repositorios Spring Data JPA y acceso a datos con Spring Test

Testing de repositorio con @DataJpaTest y H2 en memoria para testing

La anotación @DataJpaTest es una herramienta esencial en Spring Boot para realizar pruebas enfocadas en la capa de persistencia. Esta anotación configura un entorno de prueba que incluye el soporte de JPA, los repositorios de Spring Data JPA y una base de datos en memoria, generalmente H2, para facilitar el testing aislado de los repositorios.

Al utilizar @DataJpaTest, se beneficia de un contexto de aplicación minimalista, lo que mejora el rendimiento de las pruebas. Además, permite aprovechar características como el EntityManager y los mecanismos de transacción para garantizar que cada test se ejecute en un estado consistente.

A continuación, se presenta un ejemplo de cómo configurar una prueba de repositorio utilizando @DataJpaTest y JUnit 5:

@DataJpaTest
class ProductoRepositoryTest {

    @Autowired
    private ProductoRepository productoRepository;

    @Test
    void cuandoSeGuardaUnProducto_entoncesSePuedeEncontrarPorId() {
        // Crear una instancia de Producto
        Producto producto = new Producto();
        producto.setNombre("Laptop");
        producto.setPrecio(BigDecimal.valueOf(1200));

        // Guardar el producto en la base de datos
        Producto productoGuardado = productoRepository.save(producto);

        // Verificar que el producto se ha guardado correctamente
        Optional<Producto> productoEncontrado = productoRepository.findById(productoGuardado.getId());
        assertTrue(productoEncontrado.isPresent());
        assertEquals("Laptop", productoEncontrado.get().getNombre());
    }
}

En este ejemplo, se inyecta el ProductoRepository y se utiliza para realizar operaciones de persistencia sobre la entidad Producto. La base de datos H2 en memoria permite que estas operaciones sean rápidas y no afecten a un entorno de producción.

Es recomendable configurar las propiedades específicas para las pruebas en un archivo dedicado, como application-test.properties, para aislar la configuración. Por ejemplo:

spring.datasource.url=jdbc:h2:mem:testdb;DB_CLOSE_DELAY=-1
spring.datasource.driver-class-name=org.h2.Driver
spring.jpa.hibernate.ddl-auto=update

Estas propiedades aseguran que la base de datos H2 se inicialice correctamente y esté disponible durante la ejecución de los tests. El parámetro DB_CLOSE_DELAY=-1 evita que la base de datos se cierre al finalizar cada conexión, lo que es útil en entornos de testing.

Es posible inicializar datos de prueba utilizando scripts SQL o el esquema de Data JPA. Si se requiere cargar datos iniciales, se puede colocar un archivo data.sql en el directorio src/test/resources:

INSERT INTO producto (id, nombre, precio) VALUES (1, 'Teléfono', 500);
INSERT INTO producto (id, nombre, precio) VALUES (2, 'Tablet', 800);

Este enfoque facilita tener un conjunto de datos consistente para todas las pruebas, evitando la necesidad de crear objetos manualmente en cada test.

Para probar consultas personalizadas, se puede utilizar Query Methods o anotaciones @Query en el repositorio. Por ejemplo:

public interface ProductoRepository extends JpaRepository<Producto, Long> {
    List<Producto> findByPrecioLessThan(BigDecimal precio);
}

El test correspondiente podría ser:

@Test
void cuandoSeBuscaPorPrecioMenor_entoncesSeObtienenProductosCorrectos() {
    // Datos precargados en data.sql

    // Ejecutar el método a probar
    List<Producto> productos = productoRepository.findByPrecioLessThan(BigDecimal.valueOf(800));

    // Verificaciones
    assertFalse(productos.isEmpty());
    assertEquals(1, productos.size());
    assertEquals("Teléfono", productos.get(0).getNombre());
}

La anotación @DataJpaTest también configura automáticamente el manejo de transacciones, causando un rollback al finalizar cada test. Esto implica que los cambios realizados en la base de datos durante una prueba no afectan a las siguientes, manteniendo la integridad del entorno de testing.

Para depurar las pruebas y ver las consultas SQL generadas, se pueden habilitar las siguientes propiedades:

spring.jpa.show-sql=true
spring.jpa.properties.hibernate.format_sql=true

Estas propiedades permiten visualizar en la consola las sentencias SQL ejecutadas por Hibernate, lo que es útil para verificar que las consultas se comportan como se espera.

En caso de necesitar personalizar aún más el contexto de pruebas, es posible utilizar la anotación @AutoConfigureTestDatabase. Por ejemplo, para reemplazar la base de datos en memoria por otra configuración:

@DataJpaTest
@AutoConfigureTestDatabase(replace = AutoConfigureTestDatabase.Replace.NONE)
class ProductoRepositoryTest {
    // ...
}

Con esta configuración, Spring Boot respetará la base de datos definida en las propiedades, lo que es útil si se desea utilizar una base de datos diferente para pruebas más integradas.

Finalmente, es importante recordar la importancia de las pruebas en la capa de persistencia para asegurar la calidad y fiabilidad de las aplicaciones. Las herramientas proporcionadas por Spring Boot y JPA facilitan la creación de tests efectivos y mantenibles, contribuyendo al desarrollo de software robusto.

Testing con TestContainers

Para realizar pruebas integradas que involucren bases de datos reales en Spring Boot 3, es recomendable utilizar Testcontainers. Esta herramienta permite ejecutar contenedores de Docker durante los tests, proporcionando entornos aislados y reproducibles.

Para integrar Testcontainers con JUnit 5 en un proyecto Maven de Spring Boot 3, es necesario agregar las dependencias correspondientes. En el archivo pom.xml, incorpora las siguientes dependencias:

<dependencies>
    <!-- Otras dependencias -->
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-testcontainers</artifactId>
        <scope>test</scope>
    </dependency>
    <dependency>
        <groupId>org.testcontainers</groupId>
        <artifactId>junit-jupiter</artifactId>
        <version>${testcontainers.version}</version>
        <scope>test</scope>
    </dependency>
    <!-- Dependencia específica para la base de datos -->
    <dependency>
        <groupId>org.testcontainers</groupId>
        <artifactId>postgresql</artifactId>
        <version>${testcontainers.version}</version>
        <scope>test</scope>
    </dependency>
</dependencies>

Asegúrate de definir la versión de Testcontainers en la sección de propiedades:

<properties>
    <!-- Otras propiedades -->
    <testcontainers.version>1.20.4</testcontainers.version>
</properties>

Con las dependencias agregadas, puedes configurar tu clase de test utilizando las anotaciones @Testcontainers y @Container. La anotación @Testcontainers indica que la clase utilizará contenedores de Testcontainers, mientras que @Container se utiliza para definir y gestionar la vida del contenedor dentro de los tests.

Aquí tienes un ejemplo de una clase de test para un repositorio de Spring Data JPA que utiliza una base de datos PostgreSQL en un contenedor Docker:

package com.ejemplo.test;

import org.springframework.boot.test.autoconfigure.orm.jpa.DataJpaTest;
import org.springframework.test.context.ActiveProfiles;
import org.testcontainers.junit.jupiter.Container;
import org.testcontainers.junit.jupiter.Testcontainers;
import org.testcontainers.containers.PostgreSQLContainer;

@DataJpaTest
@Testcontainers
@ActiveProfiles("test")
public class UsuarioRepositoryTest {

    @Container
    private static final PostgreSQLContainer<?> postgresContainer =
        new PostgreSQLContainer<>("postgres:15.2")
            .withDatabaseName("testdb")
            .withUsername("postgres")
            .withPassword("postgres");

    // Tests ...
}

En este ejemplo, se define un contenedor estático de PostgreSQL utilizando @Container. La versión de PostgreSQL especificada es la 15.2, y se configuran el nombre de la base de datos, el usuario y la contraseña.

Es importante resaltar que, al utilizar @DataJpaTest, Spring Boot auto-configura la capa de persistencia para los tests. Sin embargo, necesitamos asegurarnos de que la aplicación utilice la base de datos proporcionada por Testcontainers y no una base de datos en memoria como H2. Para ello, configura el perfil de test (application-test.properties) con las propiedades de conexión:

spring.datasource.url=jdbc:tc:postgresql:15.2:///testdb
spring.datasource.username=postgres
spring.datasource.password=postgres
spring.datasource.driver-class-name=org.testcontainers.jdbc.ContainerDatabaseDriver
spring.jpa.hibernate.ddl-auto=create-drop

La URL jdbc:tc:postgresql:15.2:///testdb es una característica de Testcontainers JDBC que permite iniciar automáticamente un contenedor de la base de datos especificada cuando se establece la conexión.

Sin embargo, dado que ya estamos gestionando el contenedor con @Container, podemos reutilizar la URL proporcionada por el contenedor. Para ello, en la clase de test, sobrescribe las propiedades de conexión utilizando @DynamicPropertySource:

import org.springframework.test.context.DynamicPropertyRegistry;
import org.springframework.test.context.DynamicPropertySource;

// ...

public class UsuarioRepositoryTest {

    // Contenedor definido previamente

    @DynamicPropertySource
    static void configureProperties(DynamicPropertyRegistry registry) {
        registry.add("spring.datasource.url", postgresContainer::getJdbcUrl);
        registry.add("spring.datasource.username", postgresContainer::getUsername);
        registry.add("spring.datasource.password", postgresContainer::getPassword);
    }

    // Tests ...
}

Con este método, Spring Boot utilizará las propiedades proporcionadas por el contenedor de Testcontainers al inicializar el contexto de aplicación para los tests.

A continuación, puedes escribir tus tests uniendo todo lo anterior. Por ejemplo:

import static org.assertj.core.api.Assertions.assertThat;

import com.ejemplo.entidad.Usuario;
import com.ejemplo.repositorio.UsuarioRepository;
import org.junit.jupiter.api.Test;
import org.springframework.beans.factory.annotation.Autowired;

// ...

public class UsuarioRepositoryTest {

    // Configuración anterior

    @Autowired
    private UsuarioRepository usuarioRepository;

    @Test
    void cuandoGuardoUsuario_entoncesSePuedeEncontrarPorId() {
        Usuario usuario = new Usuario();
        usuario.setNombre("Juan");
        usuario.setEmail("juan@example.com");

        usuarioRepository.save(usuario);

        var usuarioEncontrado = usuarioRepository.findById(usuario.getId());

        assertThat(usuarioEncontrado).isPresent();
        assertThat(usuarioEncontrado.get().getNombre()).isEqualTo("Juan");
    }
}

En este test, se guarda un usuario en la base de datos y se verifica que posteriormente se puede recuperar correctamente. Se utilizan las assertions de AssertJ para realizar las comprobaciones.

Utilizar Testcontainers en los tests permite ejecutar pruebas contra una base de datos real, lo que aumenta la fiabilidad de las mismas. Además, al utilizar contenedores Docker, se garantiza que las pruebas son reproducibles en cualquier entorno, siempre que se disponga de Docker.

Es importante recordar que, al usar contenedores, los tiempos de inicio de los tests pueden incrementarse ligeramente debido al arranque de los contenedores. Sin embargo, Testcontainers optimiza este proceso reutilizando contenedores en pruebas sucesivas siempre que sea posible.

Para finalizar, asegúrate de que Docker está funcionando en tu entorno de desarrollo, ya que Testcontainers depende de él para ejecutar los contenedores. Si Docker no está disponible, los tests que utilizan Testcontainers no podrán ejecutarse correctamente.

Carga de datos con @Sql y @SqlGroup

La anotación @Sql es una herramienta esencial en Spring Boot para cargar scripts SQL antes o después de la ejecución de los tests. Permite preparar la base de datos con datos específicos o realizar operaciones de limpieza, facilitando la creación de pruebas reproducibles y aisladas en aplicaciones que utilizan Spring Data JPA.

Al aplicar @Sql sobre una clase o método de prueba, se pueden especificar uno o varios scripts SQL que se ejecutarán en determinada fase de la prueba. Por defecto, los scripts indicados se ejecutan antes del método de prueba. Un ejemplo sencillo sería:

@DataJpaTest
@Sql("/sql/insertar_productos.sql")
class ProductoRepositoryTest {

    @Autowired
    private ProductoRepository productoRepository;

    @Test
    void cuandoSeCuentaElNumeroDeProductos_entoncesEsElEsperado() {
        long conteo = productoRepository.count();
        assertEquals(3, conteo);
    }
}

En este ejemplo, el script insertar_productos.sql inserta tres registros en la tabla producto, y se ejecuta antes de que se ejecute el método de prueba. El script podría estar ubicado en src/test/resources/sql/insertar_productos.sql y contener:

INSERT INTO producto (id, nombre, precio) VALUES (1, 'Portátil', 1200);
INSERT INTO producto (id, nombre, precio) VALUES (2, 'Smartphone', 800);
INSERT INTO producto (id, nombre, precio) VALUES (3, 'Tablet', 500);

Es fundamental asegurarse de que la ubicación de los scripts sea correcta y que estén incluidos en el classpath del proyecto. De este modo, Spring Test los encontrará y los ejecutará sin problemas.

La anotación @Sql también permite especificar la fase en la que se ejecutará el script mediante el atributo executionPhase. Las opciones disponibles son BEFORE_TEST_METHOD, que es la predeterminada, y AFTER_TEST_METHOD. Por ejemplo, para ejecutar un script después del método de prueba:

@Sql(scripts = "/sql/limpiar_productos.sql", executionPhase = Sql.ExecutionPhase.AFTER_TEST_METHOD)

Esto es útil para limpiar la base de datos y dejarla en un estado consistente tras la ejecución de cada test.

Cuando se requiere ejecutar múltiples scripts o es necesario una configuración más compleja, se puede utilizar la anotación @SqlGroup. Esta anotación agrupa varias @Sql, permitiendo una organización más clara. Un ejemplo sería:

@SqlGroup({
    @Sql("/sql/resetear_secuencias.sql"),
    @Sql("/sql/insertar_productos.sql")
})

De esta forma, primero se ejecutará el script resetear_secuencias.sql y luego insertar_productos.sql, ambos antes del método de prueba si no se especifica lo contrario.

Además, es posible aplicar @Sql a nivel de clase y método simultáneamente. Los scripts definidos en la clase se ejecutarán para todos los métodos de prueba, mientras que los definidos en cada método afectarán solo a ese test en particular. Por ejemplo:

@DataJpaTest
@Sql("/sql/datos_generales.sql")
class ProductoRepositoryTest {

    @Test
    @Sql("/sql/datos_especificos_test1.sql")
    void testBuscarProductosDisponibles() {
        // Código del test
    }

    @Test
    @Sql("/sql/datos_especificos_test2.sql")
    void testCalcularTotalInventario() {
        // Código del test
    }
}

En este caso, datos_generales.sql se ejecuta antes de cada test, y adicionalmente, cada método ejecuta su propio script específico. Esto permite una mayor flexibilidad en la preparación de los datos necesarios para cada escenario de prueba.

Es relevante mencionar que @Sql puede manejar scripts de diferentes tipos de recursos, como archivos locales o ubicaciones remotas, siempre que sean accesibles desde el classpath. También se pueden utilizar rutas relativas o absolutas según convenga.

Otra característica útil es la posibilidad de configurar aspectos adicionales mediante la anotación @SqlConfig. Por ejemplo, para definir el separador de sentencias SQL o el modo de comentarios, se puede hacer lo siguiente:

@Sql(
    scripts = "/sql/insertar_productos.sql",
    config = @SqlConfig(separator = "#", commentPrefix = "--")
)

En este caso, el separador de sentencias será #, y los comentarios en los scripts iniciarán con --.

Al trabajar con diferentes motores de base de datos, es importante que los scripts SQL sean compatibles con el dialecto utilizado en las pruebas. Si se utiliza una base de datos en memoria como H2 para testing, se debe adaptar la sintaxis de los scripts en consecuencia. Por ejemplo, para restablecer la secuencia de una tabla en H2, se podría utilizar:

ALTER TABLE producto ALTER COLUMN id RESTART WITH 1;

Mientras que en MySQL sería diferente. Es esencial tener en cuenta estas diferencias para evitar errores durante la ejecución de los tests.

La combinación de @DataJpaTest con @Sql permite realizar pruebas más completas y realistas de los repositorios JPA. Al cargar datos específicos en la base de datos, se pueden simular escenarios complejos y verificar que las consultas y operaciones funcionan correctamente bajo distintas condiciones.

Además, gracias a que Spring Test gestiona las transacciones de los tests, todos los cambios realizados en la base de datos durante una prueba se revertirán al finalizar el método de prueba. Esto garantiza que cada test se ejecute en un entorno aislado y que los datos no persistan entre pruebas.

Es posible también parametrizar los scripts SQL utilizando placeholders y proporcionar los valores desde las propiedades del contexto. Sin embargo, en la mayoría de los casos, incluir los valores directamente en los scripts es suficiente y más sencillo de mantener.

Por último, aunque menos común, se puede utilizar @Sql para ejecutar sentencias DDL (Data Definition Language), como la creación o modificación de tablas. Esto puede ser útil en situaciones donde se necesita ajustar el esquema de la base de datos específicamente para ciertas pruebas.

En conclusión, el uso de @Sql y @SqlGroup en las pruebas con Spring Boot es una práctica recomendada para gestionar datos de prueba de manera eficiente y organizada. Estas anotaciones ofrecen una forma elegante de preparar el entorno de base de datos necesario para validar el comportamiento de los repositorios, contribuyendo así a la calidad y robustez del código.

Testing con TestEntityManager

El TestEntityManager es una herramienta proporcionada por Spring Boot para simplificar las pruebas de integración en la capa de persistencia. A diferencia del EntityManager estándar de JPA, el TestEntityManager ofrece métodos adicionales y simplificados que facilitan la interacción con el contexto de persistencia durante los tests.

Al utilizar la anotación @DataJpaTest, Spring Boot configura automáticamente un TestEntityManager disponible para inyección. Este componente es especialmente útil cuando se necesita un control más preciso sobre las operaciones de persistencia en las pruebas, permitiendo manipular el estado de las entidades y el contexto de persistencia de manera sencilla.

A continuación, se muestra cómo inyectar el TestEntityManager en una clase de prueba:

@DataJpaTest
class ClienteRepositoryTest {

    @Autowired
    private TestEntityManager entityManager;

    @Autowired
    private ClienteRepository clienteRepository;

    // Métodos de prueba...
}

Una de las ventajas del TestEntityManager es que proporciona métodos como persist(), flush() y clear(), que permiten manejar el ciclo de vida de las entidades durante la prueba. Esto es útil para preparar los datos necesarios y garantizar que el estado del contexto de persistencia es el esperado.

Por ejemplo, para persistir una entidad y asegurarse de que está sincronizada con la base de datos:

Cliente cliente = new Cliente();
cliente.setNombre("Ana Pérez");
cliente.setEmail("ana.perez@example.com");
entityManager.persist(cliente);
entityManager.flush();

La llamada a flush() fuerza la sincronización del estado del contexto de persistencia con la base de datos subyacente, lo que es esencial para ciertos escenarios de prueba donde se necesita que los datos estén realmente guardados antes de continuar.

Supongamos que se desea probar un método del repositorio que encuentra un cliente por su email. Se puede preparar la prueba de la siguiente manera:

@Test
void cuandoSeBuscaPorEmail_entoncesSeEncuentraElCliente() {
    // Crear y persistir la entidad
    Cliente cliente = new Cliente();
    cliente.setNombre("Luis García");
    cliente.setEmail("luis.garcia@example.com");
    entityManager.persist(cliente);
    entityManager.flush();

    // Ejecutar la acción de prueba
    Optional<Cliente> clienteEncontrado = clienteRepository.findByEmail("luis.garcia@example.com");

    // Verificar el resultado
    assertTrue(clienteEncontrado.isPresent());
    assertEquals("Luis García", clienteEncontrado.get().getNombre());
}

En este ejemplo, se utiliza entityManager.persist() para guardar el cliente en el contexto de persistencia, y entityManager.flush() para asegurarse de que los cambios se reflejan en la base de datos. Luego, se utiliza el repositorio para buscar el cliente por email y se verifican los resultados.

El TestEntityManager también permite despejar el contexto de persistencia utilizando entityManager.clear(). Esto es útil cuando se quiere aislar el estado de las entidades y evitar que objetos en memoria afecten a las operaciones de la prueba. Por ejemplo:

entityManager.clear();

Esta llamada desvincula todas las entidades gestionadas, obligando a que futuras operaciones las carguen nuevamente desde la base de datos. Esto puede ser esencial para probar comportamientos relacionados con el lazy loading o la sincronización de estados.

Además, el TestEntityManager proporciona el método find(), similar al del EntityManager, que permite recuperar entidades por su clave primaria:

Cliente clienteRecuperado = entityManager.find(Cliente.class, cliente.getId());
assertNotNull(clienteRecuperado);

Al igual que en el caso anterior, se pueden realizar verificaciones sobre el objeto recuperado para asegurar que los datos son correctos.

Es importante destacar que el TestEntityManager opera dentro de la transacción gestionada por @DataJpaTest. Por lo tanto, cualquier cambio realizado se revertirá al final de cada método de prueba, gracias al comportamiento de rollback automático. Esto garantiza que cada test es independiente y no afecta al estado de la base de datos para otros tests.

Cuando se trabaja con entidades que tienen relaciones, el TestEntityManager facilita la persistencia de grafos de entidades. Por ejemplo, si se tiene una entidad Pedido que está relacionada con Cliente, se puede hacer lo siguiente:

Cliente cliente = new Cliente();
cliente.setNombre("María López");
cliente.setEmail("maria.lopez@example.com");
entityManager.persist(cliente);

Pedido pedido = new Pedido();
pedido.setFecha(LocalDate.now());
pedido.setCliente(cliente);
entityManager.persist(pedido);
entityManager.flush();

Aquí, se persiste primero el Cliente y luego el Pedido, estableciendo la relación entre ellos. El TestEntityManager se encarga de gestionar las operaciones necesarias para mantener la integridad de las relaciones.

Otro caso de uso común es el testing de eventos o callbacks de JPA, como @PrePersist o @PostLoad. El TestEntityManager permite verificar que estos eventos se disparan adecuadamente. Por ejemplo:

@Test
void cuandoSePersisteCliente_entoncesSeEstableceFechaRegistro() {
    Cliente cliente = new Cliente();
    cliente.setNombre("José Martínez");
    cliente.setEmail("jose.martinez@example.com");
    entityManager.persist(cliente);
    entityManager.flush();

    assertNotNull(cliente.getFechaRegistro());
}

En este ejemplo, se verifica que la propiedad fechaRegistro se establece durante la persistencia, posiblemente mediante un método anotado con @PrePersist en la entidad Cliente.

El uso del TestEntityManager también es beneficioso para probar consultas nativas o personalizadas. Al poder preparar el estado de la base de datos de forma controlada, se pueden ejecutar consultas y verificar sus resultados con precisión. Un ejemplo sería:

@Test
void cuandoSeUsaConsultaNativa_entoncesSeObtienenResultadosEsperados() {
    Cliente cliente1 = new Cliente();
    cliente1.setNombre("Laura Sánchez");
    cliente1.setEmail("laura.sanchez@example.com");
    entityManager.persist(cliente1);

    Cliente cliente2 = new Cliente();
    cliente2.setNombre("Carlos Ruiz");
    cliente2.setEmail("carlos.ruiz@example.com");
    entityManager.persist(cliente2);

    entityManager.flush();

    List<Cliente> clientes = entityManager.getEntityManager()
        .createNativeQuery("SELECT * FROM cliente WHERE nombre LIKE 'L%'", Cliente.class)
        .getResultList();

    assertEquals(1, clientes.size());
    assertEquals("Laura Sánchez", clientes.get(0).getNombre());
}

En este caso, se utiliza el método createNativeQuery() del EntityManager obtenido a través del TestEntityManager para ejecutar una consulta SQL nativa y verificar los resultados.

Es relevante mencionar que, aunque el TestEntityManager hereda de EntityManager, ofrece una interfaz más adecuada para pruebas, con métodos simplificados que facilitan las operaciones más comunes durante el testing. Esto contribuye a escribir pruebas más legibles y mantenibles.

Para situaciones donde se necesita verificar el estado de las entidades en diferentes puntos del ciclo de vida, el TestEntityManager proporciona métodos como refresh(). Por ejemplo:

entityManager.refresh(cliente);

Esta llamada actualiza el estado de la instancia cliente con los datos actuales de la base de datos, lo que es útil si se han realizado cambios que no están sincronizados con el contexto actual.

En resumen, el TestEntityManager es una herramienta poderosa que mejora la eficiencia y claridad de las pruebas en la capa de persistencia. Su integración con @DataJpaTest y el ecosistema de Spring Boot 3 facilita a los desarrolladores la realización de tests exhaustivos y precisos, asegurando la correcta funcionalidad de los repositorios y el acceso a datos.

Además, al combinar el TestEntityManager con otras herramientas de testing, como @Sql para la carga de datos o TestContainers para entornos de base de datos reales, se puede lograr una suite de pruebas robusta que cubra múltiples escenarios y condiciones.

Es recomendable familiarizarse con las capacidades del TestEntityManager y aprovechar sus funcionalidades para mejorar la calidad y confiabilidad del código en aplicaciones que utilizan Spring Data JPA y Spring Boot 3.