Question 1

A team is building an Express.js API and sets up Supertest for integration testing. They notice their test suite frequently crashes with `Error: listen EADDRINUSE: address already in use :::3000`. What is the fundamental architectural mistake causing this error during tests?

Accepted Answer

The `app.listen()` method is being executed directly within the main `app.js` file, meaning every time a test imports the app, it attempts to bind to a real network port. The fix is to export the `app` instance separately from the `listen` call. — Supertest is incredibly powerful because it can test your Express routes entirely in-memory without needing to bind to a physical network port. However, if your main `app.js` file unconditionally calls `app.listen(3000)`, then merely importing that file into your test suite will start a real server. If multiple test files run concurrently, they will all try to bind to port 3000, causing `EADDRINUSE` errors. The architectural fix is to export the Express app itself (`module.exports = app;`) and keep the `listen` call in a separate entry point (like `server.js`).

Question 2

You are implementing integration tests for an API using a real PostgreSQL test database via Docker. Your test suite runs 500 tests, and you need to ensure the database is reset to a clean state before every single test. Which approach provides the best balance of data isolation and test execution speed?

Accepted Answer

Run `BEGIN` (start transaction) in a `beforeEach` block, perform the test, and then run `ROLLBACK` in an `afterEach` block. — Using database transactions (`BEGIN` and `ROLLBACK`) is the most efficient and robust way to manage state in integration tests. Every test inserts, updates, or deletes data within its own isolated transaction. At the end of the test, rolling back the transaction instantly undoes all changes, guaranteeing a clean slate for the next test without actually writing the changes permanently to disk. Option A and B are extremely slow (dropping/creating databases or truncating tables takes significant time when multiplied by 500 tests). Option C turns the test into a unit test, defeating the purpose of database integration testing.

Question 3

You have been assigned to maintain a legacy Node.js backend. The controllers are tightly coupled to the database driver, containing raw SQL queries inline: `await db.query('SELECT * FROM users WHERE email = ?', [req.body.email])`. Writing unit tests for these controllers is painful because you have to mock the entire database driver. What architectural pattern should you introduce to make mocking simpler and separate the data logic from the HTTP logic?

Accepted Answer

The Repository Pattern — The Repository Pattern abstracts the database access logic behind a dedicated service (e.g., `UserRepository.findByEmail(email)`). By injecting this repository into your controller, your controller no longer knows or cares whether the data comes from PostgreSQL, MongoDB, or a third-party API. When writing a unit test for the controller, you simply mock the repository's `findByEmail` method to return a hardcoded object. This isolates the HTTP testing logic (status codes, request bodies) from the database layer entirely.

Module 3 — Backend Testing with Node.js

Learning Objectives

The Backend Testing Challenge

Supertest Fundamentals

Setup

Writing an API Test

Database Testing Strategies

1. The Mocking Approach (Unit Testing)

2. In-Memory Databases

3. Test Containers / Real Databases (Integration Testing)

Mocking Repositories and Services

Sinon: Spies, Stubs, and Mocks

Mocha & Chai for Legacy Projects

Key Takeaways

Test your knowledge with more question sets

Sign in to keep reading

Discussion