Test containers for database testing in Spring Boot - Step-by-Step Execution

Concept Flow - Test containers for database testing

Start Test

↓

Initialize Test Container

↓

Start Database Container

↓

Run Application Tests

↓

Connect to Container DB

↓

Execute DB Operations

↓

Stop Container

↓

End Test

This flow shows how a test container starts a database, runs tests using it, then stops the container after tests finish.

Execution Sample

Spring Boot

import org.testcontainers.containers.PostgreSQLContainer;

static final PostgreSQLContainer<?> postgres = new PostgreSQLContainer<>("postgres:15");

@PostConstruct
void startContainer() {
  postgres.start();
}

@Test
void testDbConnection() {
  // test logic here
  // e.g., use postgres.getJdbcUrl(), postgres.getUsername(), postgres.getPassword()
}

This code starts a PostgreSQL test container before tests and runs a test connecting to it.

Execution Table

Step	Action	Container State	DB Connection	Test Status
1	Initialize PostgreSQLContainer object	Not started	No connection	Not started
2	Call postgres.start()	Container starting	No connection	Not started
3	Container fully started	Running	Connection ready	Not started
4	Run test method	Running	Connected	Running
5	Execute DB queries	Running	Connected	Running
6	Test completes successfully	Running	Connected	Passed
7	Stop container	Stopped	No connection	Finished

💡 Test container stops after tests complete, releasing resources.

Variable Tracker

Variable	Start	After Step 2	After Step 3	After Step 6	Final
postgres	Created	Starting	Running	Running	Stopped
dbConnection	null	null	open	open	closed
testStatus	Not started	Not started	Not started	Passed	Finished

Key Moments - 3 Insights

Why do we need to start the container before running tests?

The container must be running to provide a real database for tests. See execution_table step 3 where the container is running and connection is ready.

What happens if the container is not stopped after tests?

Resources stay used and may cause conflicts or memory leaks. Step 7 shows stopping the container to clean up.

How does the test connect to the database inside the container?

The test uses connection info from the running container (step 4-5), ensuring tests run against a real isolated DB.

Visual Quiz - 3 Questions

Look at the execution_table, at which step does the database connection become ready?

A Step 2

B Step 4

C Step 3

D Step 7

💡 Hint

Check the 'DB Connection' column in execution_table rows.

According to variable_tracker, what is the state of 'postgres' after step 6?

A Created

B Running

C Starting

D Stopped

💡 Hint

Look at the 'postgres' row and the 'After Step 6' column.

If the container is not stopped, what would be the final value of 'testStatus' in variable_tracker?

A Passed

B Running

C Not started

D Finished

💡 Hint

Stopping container changes 'testStatus' to 'Finished' as per variable_tracker final column.

Concept Snapshot

Test containers start a real database in a container before tests run.
Tests connect to this isolated DB for realistic testing.
After tests, the container stops to free resources.
Use @PostConstruct or setup methods to start containers.
Use container-provided connection info in tests.
Always stop containers to avoid resource leaks.

Full Transcript

Test containers for database testing work by starting a real database inside a container before tests run. The test code connects to this database using connection details provided by the container. Tests execute queries against this isolated database, ensuring realistic and clean test environments. After tests finish, the container is stopped to release resources and avoid conflicts. This process involves initializing the container object, starting it, running tests connected to it, and stopping it after tests complete. Variables like the container state, database connection, and test status change step-by-step during this flow.

Practice

1. What is the main purpose of using Testcontainers in Spring Boot database testing?

easy

A. To run real database instances in temporary containers for reliable tests

B. To mock database calls without any real database

C. To speed up unit tests by skipping database interactions

D. To deploy databases permanently on production servers

Solution

1. Step 1: Understand Testcontainers role

   Testcontainers run real database instances inside temporary containers during tests.

2. Step 2: Compare with other options

   Mocking or skipping databases is not what Testcontainers do; they provide real environments temporarily.

3. Final Answer:

   To run real database instances in temporary containers for reliable tests -> Option A

4. Quick Check:

   Testcontainers purpose = run real temporary databases [OK]

Hint: Testcontainers run real temporary databases, not mocks [OK]

Common Mistakes:

• Confusing Testcontainers with mocking frameworks
• Thinking Testcontainers deploy permanent databases
• Assuming Testcontainers skip database usage

2. Which of the following is the correct way to start a PostgreSQL Testcontainer in a Spring Boot test class?

easy

A. static PostgreSQLContainer postgres = new PostgreSQLContainer<>("postgres:latest").start();

B. PostgreSQLContainer postgres = new PostgreSQLContainer("postgres:latest").run();

C. static PostgreSQLContainer postgres = new PostgreSQLContainer("postgres:latest").begin();

D. PostgreSQLContainer postgres = new PostgreSQLContainer().start();

Solution

1. Step 1: Check correct instantiation and start method

   The correct way is to create a static container with generic type and call start().

2. Step 2: Validate options

   static PostgreSQLContainer postgres = new PostgreSQLContainer<>("postgres:latest").start(); uses correct syntax with generic type and start(). Others use wrong method names or miss generics.

3. Final Answer:

   static PostgreSQLContainer postgres = new PostgreSQLContainer<>("postgres:latest").start(); -> Option A

4. Quick Check:

   Use start() with generic type for Testcontainers [OK]

Hint: Use start() method and generic type for containers [OK]

Common Mistakes:

• Using .run() or .begin() instead of .start()
• Omitting generic type
• Not declaring container as static when needed

3. Given this Spring Boot test snippet using Testcontainers:

 @Testcontainers
 class MyRepositoryTest {
  @Container
  static PostgreSQLContainer postgres = new PostgreSQLContainer<>("postgres:13").withDatabaseName("testdb").withUsername("user").withPassword("pass");

  @Autowired
  MyRepository repo;

  @Test
  void testCount() {
    long count = repo.count();
    System.out.println(count);
  }
}

What will System.out.println(count); print if the database is empty?

medium

A. null

B. 0

C. Throws NullPointerException

D. 1

Solution

1. Step 1: Understand repo.count() behavior

   The count() method returns the number of records in the repository's table.

2. Step 2: Database is empty so count is zero

   Since the database is fresh and empty, count() returns 0, not null or exception.

3. Final Answer:

   0 -> Option B

4. Quick Check:

   Empty DB count() = 0 [OK]

Hint: Empty database count returns zero, not null or error [OK]

Common Mistakes:

• Expecting null instead of zero
• Assuming count() throws exception on empty DB
• Confusing count() with find methods

4. You wrote this test using Testcontainers but it fails with org.testcontainers.containers.ContainerLaunchException. What is the likely cause?

 @Container
 static PostgreSQLContainer postgres = new PostgreSQLContainer<>("postgres:latest");

 @Test
 void testDb() {
   // test code
 }

medium

A. The PostgreSQL image name is incorrect

B. The container must be started manually with .start() in the test

C. Docker is not running or accessible on the test machine

D. Testcontainers do not support PostgreSQL

Solution

1. Step 1: Understand ContainerLaunchException meaning

   This exception usually means Docker cannot start the container.

2. Step 2: Check common causes

   Most common cause is Docker daemon not running or inaccessible to Testcontainers.

3. Final Answer:

   Docker is not running or accessible on the test machine -> Option C

4. Quick Check:

   ContainerLaunchException = Docker not running [OK]

Hint: Check Docker daemon is running if container launch fails [OK]

Common Mistakes:

• Thinking image name is wrong when it is correct
• Trying to start container manually when @Container does it
• Believing Testcontainers don't support PostgreSQL

5. You want to write a Spring Boot integration test using Testcontainers with a MySQL database. You want the container to start once before all tests and stop after all tests. Which setup is correct?

hard

A. Use @SpringBootTest without any container setup; rely on embedded database

B. Create a new MySQLContainer instance inside each test method and call start() manually

C. Use @BeforeEach to start a MySQLContainer and @AfterEach to stop it

D. Declare a static MySQLContainer with @Container annotation in the test class and use @Testcontainers on the class

Solution

1. Step 1: Understand lifecycle annotations

   Using static container with @Container and @Testcontainers on class starts container once before all tests and stops after all.

2. Step 2: Compare other options

   Creating container per test or starting/stopping each test is inefficient. Embedded DB is different approach.

3. Final Answer:

   Declare a static MySQLContainer with @Container annotation in the test class and use @Testcontainers on the class -> Option D

4. Quick Check:

   Static @Container + @Testcontainers = start once before all tests [OK]

Hint: Use static @Container field with @Testcontainers class annotation [OK]

Common Mistakes:

• Starting container inside each test method
• Using @BeforeEach/@AfterEach for container lifecycle
• Assuming embedded DB replaces Testcontainers