Test database strategies in NestJS - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ component_behavior

intermediate

What happens when using an in-memory database for NestJS tests?

You configure your NestJS tests to use an in-memory database like SQLite in memory mode. What is the main behavior you will observe during test runs?

A Data from previous test runs remains in the database, causing tests to share state.

B Each test run starts with a fresh empty database, so no data persists between tests.

C The database runs on disk and requires manual cleanup after tests.

D The in-memory database automatically syncs with the production database.

💡 Hint

Think about what 'in-memory' means for data persistence.

In-memory databases store data only during the test run in RAM. When the test ends, all data is lost, so each test run starts fresh.

📝 Syntax

intermediate

Which NestJS testing setup correctly resets the test database before each test?

Given the following NestJS test setup, which option correctly resets the database before each test?

NestJS

beforeEach(async () => {
  // reset database here
});

A await connection.synchronize(true);

B await connection.clear();

C await connection.dropDatabase(); await connection.synchronize();

D await connection.close();

💡 Hint

Resetting means removing all tables and recreating them.

Calling dropDatabase() removes all tables, and synchronize() recreates them based on the entities, ensuring a clean database state before each test.

🔧 Debug

advanced

Why does the NestJS test suite fail when using a shared test database without cleanup?

You run your NestJS tests using a shared test database but do not clean data between tests. Tests start failing with unique constraint errors. What is the cause?

A The test runner does not support parallel execution.

B The database connection is closed too early causing errors.

C The test database schema is not synchronized with entities.

D Tests share data causing conflicts because previous test data remains in the database.

💡 Hint

Think about what happens if data is not cleared between tests.

Without cleaning, data from one test remains and can cause conflicts like duplicate keys in the next test.

🧠 Conceptual

advanced

What is the advantage of using transactions in NestJS test database strategies?

Why might you wrap each NestJS test in a database transaction that is rolled back after the test?

A It isolates test data changes and automatically reverts them, keeping the database clean.

B It speeds up tests by caching database queries.

C It permanently saves test data for debugging after tests finish.

D It allows tests to share data between each other for faster setup.

💡 Hint

Think about how transactions can undo changes.

Transactions let you group changes and then roll them back, so tests do not leave data behind.

❓ state_output

expert

What is the final count of users in the test database after running this NestJS test code?

Consider this NestJS test code using TypeORM with an in-memory SQLite database. What is the number of users in the database after the test completes?

NestJS

it('adds users and rolls back', async () => {
  await connection.transaction(async manager => {
    await manager.save(User, { name: 'Alice' });
    await manager.save(User, { name: 'Bob' });
    const countInside = await manager.count(User);
    expect(countInside).toBe(2);
    throw new Error('Rollback');
  }).catch(() => {});
  const countAfter = await connection.manager.count(User);
  expect(countAfter).toBe(0);
});

A 0 users, because the transaction was rolled back.

B 1 user, because only the first save succeeded.

C 2 users, because the users were saved before the error.

D Test fails with an unhandled error.

💡 Hint

What happens to data inside a transaction if an error is thrown?

The transaction rolls back all changes when an error occurs, so no users remain after the test.