1. Concept library
  2. Backend with Node.js
  3. Module 9: Testing APIs

Concept

Test databases

Integration tests need a real database that starts empty and is theirs alone. A throwaway database per run, in Docker or created by the test setup, keeps tests honest and repeatable.

What a session covers

The tutor works through these with you, in conversation and code. A session ends when you have shown them, not when a video does.

  1. Explain why integration tests need a database of their own
  2. Create a throwaway database per run and reset it between tests
  3. Spot the tests pointed at the development database

In practice

A few lines that show Test databases doing its job.

Bash
# docker-compose.test.yml starts postgres on a spare port
docker compose -f docker-compose.test.yml up -d
export TEST_DATABASE_URL=postgres://app:app@localhost:5433/app_test

# the test setup runs migrations, then truncates between tests
npm test

The common mistake

Watch for

Pointing tests at the development database. A test that truncates tables wipes your local data, and leftover rows from development make tests flaky.

What to know first

Your roadmap puts these before Test databases, unless you already know them.

How it stays learned

Once a session shows you understand Test databases, it comes back for review. Each review takes a minute and tells the memory model how well you still know it.

  1. Day 3First recall, while it is fresh
  2. Day 7Second, a week on
  3. Day 18Last, when it has settled
Previous in the module← Integration tests