Test database strategies in NestJS - Step-by-Step Execution

Concept Flow - Test database strategies

Start Test Setup

↓

Choose Test DB Strategy

↓

In-Memory

↓

Initialize DB

↓

Run Tests Using DB

↓

Clean Up DB

↓

End Test

This flow shows how tests start by choosing a database strategy, then initialize or mock the database, run tests, clean up, and finish.

Execution Sample

NestJS

beforeAll(async () => {
  await testContainer.start();
  await app.init();
});

afterAll(async () => {
  await testContainer.stop();
});

This code starts a test database container before tests and stops it after all tests finish.

Execution Table

Step	Action	Evaluation	Result
1	Start test setup	N/A	Test environment initialized
2	Choose test DB strategy	Using Test Container	Docker container for DB started
3	Initialize DB connection	Connect to container DB	DB connection established
4	Run tests	Execute queries and mutations	Tests run against container DB
5	Clean up DB	Drop test data	DB cleaned for next test
6	Stop test container	Shutdown container	Container stopped
7	End test	N/A	Test suite finished

💡 Test container stopped and test suite finished

Variable Tracker

Variable	Start	After Step 2	After Step 3	After Step 4	After Step 5	Final
testContainer	undefined	started	started	started	started	stopped
dbConnection	undefined	undefined	connected	connected	connected	closed
testData	empty	empty	empty	populated	cleared	empty

Key Moments - 3 Insights

Why do we need to clean up the database after each test?

Cleaning up ensures tests do not affect each other by leaving data behind, as shown in step 5 of the execution_table.

What happens if the test container is not stopped after tests?

The container keeps running, wasting resources and possibly causing conflicts, as indicated in step 6 where the container is stopped.

Why choose a test container over a real database?

Test containers provide isolated, fresh environments for tests, avoiding side effects on real databases, as shown in step 2 choosing the test container strategy.

Visual Quiz - 3 Questions

Look at the execution_table, what is the state of testContainer after Step 3?

A undefined

B started

C stopped

D paused

💡 Hint

Check variable_tracker row for testContainer after Step 3

At which step does the database get cleaned?

A Step 5

B Step 3

C Step 4

D Step 6

💡 Hint

Look at the execution_table action column for cleaning

If we skip stopping the test container, what is the likely final state of testContainer?

A undefined

B stopped

C started

D cleaned

💡 Hint

Refer to variable_tracker final state for testContainer and step 6 in execution_table

Concept Snapshot

Test database strategies in NestJS:
- Choose strategy: In-memory, Test Container, Mock, or Real DB
- Initialize DB before tests
- Run tests using DB connection
- Clean DB after each test
- Stop/cleanup resources after all tests
Use test containers for isolated, fresh DB environments.

Full Transcript

This visual execution shows how to manage test database strategies in NestJS. First, the test setup starts and selects a database strategy like a test container. The container starts, and the app connects to it. Tests run using this database. After tests, the database is cleaned to remove test data. Finally, the test container is stopped to free resources. Variables like testContainer and dbConnection change states accordingly. Cleaning the database prevents tests from interfering with each other. Stopping the container avoids resource waste. Choosing the right strategy helps keep tests reliable and isolated.

Practice

1.

Why do we use a separate test database in NestJS applications?

easy

A. To store user passwords securely

B. To keep real data safe and avoid accidental changes during tests

C. To make the application run faster in production

D. To reduce the size of the main database

Solution

1. Step 1: Understand the purpose of test databases

   Test databases are used to isolate testing data from real data to prevent accidental data loss or corruption.

2. Step 2: Identify the main reason for using test databases in NestJS

   Using a separate test database ensures tests do not affect production data, keeping it safe.

3. Final Answer:

   To keep real data safe and avoid accidental changes during tests -> Option B

4. Quick Check:

   Test database = Protect real data [OK]

Hint: Test DB isolates test data from real data [OK]

Common Mistakes:

• Thinking test DB improves production speed
• Confusing test DB with security for passwords
• Assuming test DB reduces main DB size

2.

Which of the following is the correct way to configure an in-memory SQLite database for testing in a NestJS TypeOrmModule?

TypeOrmModule.forRoot({
  type: 'sqlite',
  database: ???,
  entities: [User],
  synchronize: true,
})

easy

A. 'test.db'

B. 'memory.db'

C. ':disk:'

D. ':memory:'

Solution

1. Step 1: Recall SQLite in-memory database syntax

   SQLite uses ':memory:' as the special name to create a temporary in-memory database.

2. Step 2: Match the correct database name in the config

   Using ':memory:' tells TypeORM to use an in-memory DB for fast, isolated tests.

3. Final Answer:

   ':memory:' -> Option D

4. Quick Check:

   SQLite in-memory DB = ':memory:' [OK]

Hint: SQLite in-memory DB uses ':memory:' string [OK]

Common Mistakes:

• Using a file name instead of ':memory:'
• Confusing ':disk:' as valid SQLite option
• Using arbitrary file names like 'memory.db'

3.

Given this NestJS test setup snippet, what will be the output of console.log(users.length) inside the test?

beforeEach(async () => {
  await connection.synchronize(true); // resets DB
  await userRepository.save([{ name: 'Alice' }, { name: 'Bob' }]);
});

test('users count', async () => {
  const users = await userRepository.find();
  console.log(users.length);
});

medium

A. 1

B. 0

C. 2

D. undefined

Solution

1. Step 1: Understand what synchronize(true) does

   Calling synchronize(true) resets the database, clearing all data before each test.

2. Step 2: Analyze the data saved before the test

   After reset, two users 'Alice' and 'Bob' are saved, so the DB has 2 users.

3. Step 3: Check the find() result

   Finding all users returns an array of length 2.

4. Final Answer:

   2 -> Option C

5. Quick Check:

   Reset + save 2 users = 2 users found [OK]

Hint: Reset DB then save 2 users means find() returns 2 [OK]

Common Mistakes:

• Assuming DB is not reset and counting old data
• Thinking synchronize(true) deletes data after save
• Expecting undefined because of async confusion

4.

What is the main problem with this test database setup code snippet?

beforeAll(async () => {
  await connection.synchronize(true);
});

afterAll(async () => {
  await connection.close();
});

test('should save user', async () => {
  await userRepository.save({ name: 'Charlie' });
  const users = await userRepository.find();
  expect(users.length).toBe(1);
});

test('should find no users initially', async () => {
  const users = await userRepository.find();
  expect(users.length).toBe(0);
});

medium

A. Database is reset only once before all tests, causing data to persist between tests

B. Connection is closed before tests run

C. User repository is not defined

D. Tests run synchronously causing race conditions

Solution

1. Step 1: Analyze when the database reset happens

   Database reset with synchronize(true) is done only once before all tests, not before each test.

2. Step 2: Understand test data persistence

   Data saved in the first test remains in the DB during the second test, causing unexpected results.

3. Final Answer:

   Database is reset only once before all tests, causing data to persist between tests -> Option A

4. Quick Check:

   Reset once beforeAll causes data carryover [OK]

Hint: Reset DB before each test to avoid data carryover [OK]

Common Mistakes:

• Thinking connection closes too early
• Assuming userRepository is undefined
• Believing tests run in parallel causing race

5.

You want to ensure each test in your NestJS app runs with a clean database state using an in-memory SQLite DB. Which strategy best achieves this?

1. Use TypeOrmModule.forRoot with database: ':memory:'
2. Reset the database schema before each test
3. Close and reopen the connection before each test
4. Seed only required test data inside each test

Which combination of these steps is best practice?

hard

A. All steps 1, 2, 3, and 4

B. 1 and 3 only

C. 2, 3, and 4 only

D. 1, 2, and 4 only

Solution

1. Step 1: Use in-memory DB for fast isolated tests

   Setting database to ':memory:' creates a fresh DB in memory for each connection.

2. Step 2: Reset schema before each test

   Resetting schema ensures no leftover data or schema changes affect tests.

3. Step 3: Close and reopen connection before each test

   Reopening connection resets the in-memory DB state fully.

4. Step 4: Seed only needed data per test

   Seeding minimal data keeps tests independent and fast.

5. Final Answer:

   All steps 1, 2, 3, and 4 -> Option A

6. Quick Check:

   Full reset + seed per test = reliable tests [OK]

Hint: Combine in-memory DB, reset, reconnect, and seed per test [OK]

Common Mistakes:

• Skipping connection reopen causing stale DB
• Not resetting schema before tests
• Seeding too much data globally