nonobie — Real dev skills, explained like a friend would

Warming up the neural circuits...

What you'll learn

By the end of this chapter you will:

Explain the three levels of the test pyramid and when to use each
Write a complete unit test for a service using Jest mocks
Write an integration test that runs against a real PostgreSQL database
Write an E2E test using Supertest for a full HTTP request → response
Apply the golden rule: test the sad paths harder than the happy path

The why

In fintech, bugs aren't just annoying — they move real money. "If the payment service has a bug that double-charges customers, how do you find out?" Either a test catches it before it ships, or a customer calls support after losing money.

Tests are how you prove, before every deploy, that the code does what you think it does.

The test pyramid — three levels of tests

plaintext

                ▲
               /|\
              / | \      E2E tests (few)
             /  |  \     Full HTTP → App → Real DB
            /   |   \    Slow. Run pre-deploy.
           /─────────\
          /      |    \  Integration tests (more)
         /       |     \ Service + Real DB
        /        |      \ Run on every commit.
       /──────────────────\
      /          |         \ Unit tests (lots)
     /           |          \ Pure logic, mocked deps
    /            |           \ Run on every file save.
   ───────────────────────────

Type	What it tests	Speed	When
Unit	One function/method, all deps mocked	Milliseconds	On every save
Integration	Service + real database	Seconds	On every commit
E2E	Full HTTP request → response, real app	Tens of seconds	Pre-merge, pre-deploy

Unit tests — testing logic in isolation

A unit test mocks every dependency and tests only the logic of one method.

// src/modules/orders/orders.service.spec.ts
 
describe('OrdersService', () => {
  let service: OrdersService;
  let mockOrderModel: any;
  let mockPaymentsService: any;
  let mockSequelize: any;
 
  beforeEach

Integration tests — testing against a real database

Integration tests connect to a real PostgreSQL database (spun up in for CI). They prove that your queries and constraints actually work.

describe('OrdersService (integration)', () => {
  let app: INestApplication;
  let service: OrdersService;
  let sequelize: Sequelize;
 
  beforeAll(async () => {
    const module = await Test.

E2E tests — full HTTP request → response

E2E tests use Supertest to send real HTTP requests to your NestJS app and verify the full works together.

describe('POST /api/v1/orders', () => {
  let app: INestApplication;
  let authToken: string;
 
  beforeAll(async () => {
    const module = await Test.createTestingModule({
      imports: [AppModule

What to test — and what NOT to test

✅ Always test

Every branch in a service method — "if balance < amount" has two paths: test both
Every transition — pending → approved is allowed; approved → pending is NOT
Every error path — insufficient balance, duplicate ID, not found, forbidden
DB constraints your code relies on — if you rely on a UNIQUE constraint, prove it throws
The rollback — if the second write fails, the first must also be undone

❌ Don't test

Trivial getters/setters (get id() { return this._id; })
Sequelize itself (it's already tested by the library authors)
Auto-generated code
Constructor calls with no logic

Running tests in this project

bash

npm test             # Run all unit tests
npm run test:cov     # Run with code coverage report
npm run test:e2e     # Run E2E tests
npm run test:watch   # Watch mode (re-runs on file save)

One thing to remember

Test the sad paths harder than the happy path. The happy path is: valid , enough balance, no concurrent updates. The sad paths — insufficient balance, duplicate submission, failed rollback — are exactly what happens in production. Test those first.

Chapter 13 — Testing