Testing NestJS: modules, overrides and a real database

A video service's playlist suite runs on Postgres 17. POST /playlists inserts the playlist through the app's Db provider, then writes an audit row through AuditLog, a provider that holds a pg.Pool of its own. The suite overrides Db with the test's own connection and wraps each test in a transaction on it:

The test passes.

On this lesson's model of two workers' scheduling, a video service's e2e suite has two files, titles.e2e-spec.ts and playlists.e2e-spec.ts, each with one test. Jest runs them in two parallel workers against one test database and sets JEST_WORKER_ID to 1 in one worker and 2 in the other; both workers run inside one CI job, whose GITHUB_RUN_ID and GITHUB_REF_NAME they share. Each file begins its test with beforeEach(() => db.query('TRUNCATE titles, playlists')). In one CI run, the titles test's GET /titles/:id returned 404 right after its POST /titles had returned 201.

A video service's GET /playlists/:id/summary returns, as it is, the row of the second statement below:

CREATE TABLE playlists (id int PRIMARY KEY, name text NOT NULL);
SELECT p.id, p.name, count(i.title_id) AS items FROM playlists p LEFT JOIN playlist_items i ON i.playlist_id = p.id WHERE p.id = $1 GROUP BY p.id, p.name

Its e2e test overrides Db with an in-memory SQLite database, adds three titles to playlist 1 over HTTP, then calls .expect(200, { id: 1, name: 'Favourites', items: 3 }). It passes. The team runs the same test with Db left on a Postgres 17 database, through node-postgres 8.23.0.

A video service's POST /titles/:id/rating saves a viewer's thumbs up or down through RatingsRepository, counts the view through HistoryRepository, and tells a recommender service through RecommenderClient. The deployed tables and the two repositories' statements:

CREATE TABLE ratings (viewer_id int NOT NULL, title_id int NOT NULL, thumbs_up boolean NOT NULL, UNIQUE (viewer_id, title_id));
CREATE TABLE history (viewer_id int NOT NULL, title_id int NOT NULL, views int NOT NULL DEFAULT 1, UNIQUE (viewer_id, title_id));
-- RatingsRepository.save
INSERT INTO ratings (viewer_id, title_id, thumbs_up) VALUES ($1, $2, $3)
-- HistoryRepository.add
INSERT INTO history (viewer_id, title_id) VALUES ($1, $2) ON CONFLICT (viewer_id, title_id) DO UPDATE SET views = history.views + 1

Its e2e suite replaces all three with in-memory fakes:

Its one test rates title 7 thumbs up, then thumbs down, each expecting 201. It passes.

A box office's hold service runs its own transaction:

Its e2e suite overrides Db with { query: async (sql, params) => (await client.query(sql, params)).rows }, on the test's own client, and runs on Postgres 17:

beforeEach(() => client.query('BEGIN'));
afterEach(() => client.query('ROLLBACK'));

it('holds seat A1', () =>
  request(app.getHttpServer()).post('/holds').send({ seat: 'A1' }).expect(201));

it('starts with no holds', async () => {
  const { rows } = await client.query('SELECT count(*)::int AS n FROM holds');
  expect(rows[0].n).toBe(0);
});

The two tests run in the order shown.

A ledger service lists entries:

The test database holds 50 entries, and Postgres treats LIMIT NULL as no limit. A teammate is about to change the default to DefaultValuePipe(200) by mistake.