Spring Data JPA Repository Testing | Java Fresher Interview
Fast recall
Quick revision
Core answer
@DataJpaTest to test entity mappings, repository queries, and persistence behavior in a JPA-focused Spring context. Tests are transactional and normally roll back, and Boot commonly replaces the configured data source with an available embedded database. That replacement is not guaranteed to behave like production; use the production database through Testcontainers and disable replacement when dialect-specific behavior matters.Interview-ready guide
Interview answer
I use @DataJpaTest when I want to test entities, mappings, and repository queries with real JPA behavior.
The test is transactional and normally rolls back after each method. Spring Boot commonly replaces the data source with an embedded database if one is available, but the annotation does not guarantee H2. For a simple portable JPQL query, an embedded database may be enough.
For PostgreSQL JSON columns, locking, native SQL, collation, or generated-value behavior, I use a PostgreSQL Testcontainer and disable replacement with @AutoConfigureTestDatabase(replace = NONE). I also call flush() and clear the persistence context when I need to prove SQL was executed and the row can be read back, not just returned from the first-level cache. A mocked repository would not test any of those JPA contracts.
Spring Data JPA Repository Testing | Java Fresher Interview
Direct Answer
Use @DataJpaTest to test entity mappings, repository queries, and persistence behavior in a JPA-focused Spring context. Tests are transactional and normally roll back, and Boot commonly replaces the configured data source with an available embedded database. That replacement is not guaranteed to behave like production; use the production database through Testcontainers and disable replacement when dialect-specific behavior matters.
Code Example
@DataJpaTest
class OrderRepositoryTest {
@Autowired
private OrderRepository orderRepository;
@Autowired
private TestEntityManager entityManager;
@Test
void shouldFindOrdersByCustomerEmail() {
var customer = new Customer(null, "alice@example.com");
entityManager.persist(customer);
var order1 = new Order(null, "Laptop", 1500.00, customer);
var order2 = new Order(null, "Mouse", 25.00, customer);
entityManager.persistAndFlush(order1);
entityManager.persistAndFlush(order2);
var orders = orderRepository.findByCustomerEmail("alice@example.com");
assertEquals(2, orders.size());
assertTrue(orders.stream().anyMatch(o -> o.getItem().equals("Laptop")));
}
}
Common Mistakes & Pitfalls
- Assuming H2 is automatic: Boot needs an embedded database dependency or an explicitly configured data source.
- Treating database products as interchangeable: H2 success does not prove PostgreSQL or MySQL behavior.
- Testing only the persistence cache: use
flush()andclear()when a real database round trip matters. - Expecting every side effect to roll back: independent transactions and external threads are outside the test transaction.
- Mocking the repository: that tests service logic, not JPA mappings or queries.
Check your understanding
Answer these without looking back at the article.
- How do you load test data with @Sql in @DataJpaTest?
- What is TestEntityManager?
- How do you test against a real PostgreSQL database in tests?
Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.