🧪 Weekend Project: Implement Comprehensive Testing for a Full-Stack App

The Goal

You already have a working full-stack Task Manager: an Express + Mongoose API with user auth and task CRUD, and a React front end that talks to it. It runs. It demos fine. And it has a dangerous secret — nothing proves it still works after the next change. Every edit is a leap of faith, every deploy a held breath. This weekend you remove the faith and replace it with evidence.

By Sunday night, three commands tell the whole truth about your app. npm run test:unit checks the pure logic in milliseconds. npm run test:integration spins up a private database, fires real HTTP requests at your routes, and asserts on the responses. npm run test:e2e opens a real browser and walks through signing up and completing a task. And you never have to remember to run them: a GitHub Actions workflow runs all three on every push, so a broken change turns a pull request red before a human ever reviews it.

This is a capstone. You're not re-learning a single Jest assertion — you're learning how the layers fit together into a strategy, how to keep a database-backed suite isolated and repeatable, and how to make the machine run it all for you. That trustworthy, automated safety net is what separates a hobby project from software a team can maintain.

Prerequisites

This project ties together everything Week 12 taught, applied to an app you built earlier in the course. Before you start, make sure you're comfortable with:

You'll need Node.js 18 or newer (node --version) and a GitHub repository for the app. You do not need a local MongoDB install for the tests: the integration layer uses an in-memory Mongo, and CI uses a service container.

The Testing Pyramid Strategy

Before writing a single test, decide how many of each kind to write. The classic guide is the testing pyramid: a wide base of cheap, fast unit tests; a narrower band of integration tests; and a tiny cap of slow, expensive end-to-end tests. The shape is a rule of thumb about cost versus confidence.

Required Features Checklist

These are the non-negotiables for a passing project. Tick each off as you go.

Project & Test Structure

Keep tests discoverable and grouped by layer. A common, clean layout puts each pyramid tier in its own folder, with config and the CI workflow at the root. This is the shape you'll build toward:

task-manager/
├── package.json
├── jest.config.js              <-- Jest config + coverage thresholds
├── playwright.config.js        <-- E2E runner config
├── .github/
│   └── workflows/
│       └── ci.yml              <-- the CI pipeline
├── src/
│   ├── app.js                  <-- builds the Express app (no listen)
│   ├── server.js               <-- connects DB, then app.listen()
│   ├── models/Task.js
│   ├── controllers/taskController.js
│   ├── routes/taskRoutes.js
│   └── services/taskFilters.js <-- pure logic — the easiest thing to unit-test
└── tests/
    ├── setup/
    │   └── testDb.js           <-- connect / clear / teardown helpers
    ├── unit/
    │   └── taskFilters.test.js <-- fast, no I/O
    ├── integration/
    │   └── tasks.test.js       <-- supertest against the test DB
    └── e2e/
        └── task-journey.spec.js<-- Playwright browser flow

Stage 1 — Set Up Jest & Config

Install the toolchain, then give Jest a config it can grow into. For the API you need Jest itself, supertest for HTTP, and mongodb-memory-server to spin a real MongoDB in RAM for the integration layer.

# From the project root
npm install --save-dev jest supertest mongodb-memory-server

# The E2E runner (installs its own browsers)
npm install --save-dev @playwright/test
npx playwright install --with-deps chromium

Add scripts so each layer runs on its own and all-together in CI. Splitting them keeps your local edit-loop fast (run just the unit tests) while CI runs everything.

{
  "scripts": {
    "test": "jest",
    "test:unit": "jest tests/unit",
    "test:integration": "jest tests/integration --runInBand",
    "test:coverage": "jest --coverage",
    "test:e2e": "playwright test",
    "lint": "eslint ."
  }
}

Now the Jest config. The node test environment is right for an API (no browser DOM needed). collectCoverageFrom tells Jest which source files count toward coverage — critically including files with no tests yet, so an untested module drags the number down honestly instead of hiding.

// jest.config.js
module.exports = {
  // Node environment — no jsdom; this is a server-side API.
  testEnvironment: 'node',

  // Only Jest layers live under tests/unit and tests/integration.
  // Playwright's *.spec.js under tests/e2e is ignored by Jest.
  testMatch: ['**/tests/unit/**/*.test.js', '**/tests/integration/**/*.test.js'],

  // Measure coverage across ALL source — even files with no test yet,
  // so gaps show up instead of silently scoring 100%.
  collectCoverageFrom: [
    'src/**/*.js',
    '!src/server.js',      // the listen wrapper — nothing to unit test
  ],

  // Fail fast if a resource (like a DB connection) is left open.
  detectOpenHandles: true,

  // Coverage thresholds are added in Stage 5 — start without a gate.
};

Stage 2 — Unit Tests for Pure Logic

Start at the base of the pyramid, because it is the cheapest and highest-value place to begin. A unit test checks one small piece of logic in complete isolation — no database, no network, no framework. The ideal target is a pure function: same input, same output, no side effects. If your app doesn't have much pure logic yet, that itself is a smell — extract the decision-making out of your controllers into testable functions.

Here is exactly that kind of extraction: the filtering, sorting, and stats logic pulled out of the task controller into a plain module. No req, no res, no Mongoose — just data in, data out.

// src/services/taskFilters.js — pure logic, trivially testable

// Keep only tasks matching a completion status. 'all' returns everything.
function filterByStatus(tasks, status) {
  if (status === 'all') return [...tasks];
  const wantCompleted = status === 'completed';
  return tasks.filter((t) => t.completed === wantCompleted);
}

// Sort by due date ascending; tasks with no due date sink to the bottom.
function sortByDueDate(tasks) {
  return [...tasks].sort((a, b) => {
    if (!a.dueDate) return 1;
    if (!b.dueDate) return -1;
    return new Date(a.dueDate) - new Date(b.dueDate);
  });
}

// Summarize a task list into counts a dashboard can show.
function computeStats(tasks) {
  const total = tasks.length;
  const completed = tasks.filter((t) => t.completed).length;
  return {
    total,
    completed,
    active: total - completed,
    percentComplete: total === 0 ? 0 : Math.round((completed / total) * 100),
  };
}

module.exports = { filterByStatus, sortByDueDate, computeStats };

Now the tests. Notice the pattern: cover the happy path, the edge cases (empty list, missing fields), and the boundaries (the total === 0 branch that would otherwise divide by zero). Good unit tests chase the branches, not just the obvious case.

// tests/unit/taskFilters.test.js
const { filterByStatus, sortByDueDate, computeStats } = require('../../src/services/taskFilters');

describe('filterByStatus', () => {
  const tasks = [
    { title: 'A', completed: false },
    { title: 'B', completed: true },
    { title: 'C', completed: false },
  ];

  test('returns only active tasks', () => {
    const result = filterByStatus(tasks, 'active');
    expect(result).toHaveLength(2);
    expect(result.every((t) => t.completed === false)).toBe(true);
  });

  test('returns only completed tasks', () => {
    expect(filterByStatus(tasks, 'completed')).toEqual([{ title: 'B', completed: true }]);
  });

  test("returns everything for 'all'", () => {
    expect(filterByStatus(tasks, 'all')).toHaveLength(3);
  });

  test('does not mutate the input array', () => {
    filterByStatus(tasks, 'active');
    expect(tasks).toHaveLength(3);   // original untouched
  });
});

describe('sortByDueDate', () => {
  test('orders by ascending due date and sinks undated tasks last', () => {
    const input = [
      { title: 'later', dueDate: '2025-12-31' },
      { title: 'no date' },
      { title: 'sooner', dueDate: '2025-01-01' },
    ];
    const titles = sortByDueDate(input).map((t) => t.title);
    expect(titles).toEqual(['sooner', 'later', 'no date']);
  });
});

describe('computeStats', () => {
  test('summarizes a mixed list', () => {
    const tasks = [
      { completed: true }, { completed: false }, { completed: true }, { completed: false },
    ];
    expect(computeStats(tasks)).toEqual({
      total: 4, completed: 2, active: 2, percentComplete: 50,
    });
  });

  test('handles the empty list without dividing by zero', () => {
    expect(computeStats([])).toEqual({
      total: 0, completed: 0, active: 0, percentComplete: 0,
    });
  });
});

PASS  tests/unit/taskFilters.test.js
  filterByStatus
    ✓ returns only active tasks (2 ms)
    ✓ returns only completed tasks
    ✓ returns everything for 'all'
    ✓ does not mutate the input array
  sortByDueDate
    ✓ orders by ascending due date and sinks undated tasks last
  computeStats
    ✓ summarizes a mixed list
    ✓ handles the empty list without dividing by zero

Tests: 7 passed, 7 total   Time: 0.4 s

Stage 3 — Integration Tests & Test-DB Isolation

Unit tests prove your logic is correct in a vacuum. Integration tests prove the pieces are wired together: that a real HTTP request travels through your router, controller, and model, touches a database, and comes back with the right status code and body. The tool is supertest, which drives your Express app in memory — no port, no running server.

The hard part isn't the requests; it's the database. Tests must be isolated (one test's data never leaks into another's) and repeatable (the same result every run, on any machine). The recipe: spin up a fresh in-memory MongoDB before the suite, clear every collection before each test, and tear it all down at the end. This sequence is the beating heart of reliable database testing:

Put that lifecycle in one reusable helper so every integration file gets isolation for free:

// tests/setup/testDb.js
const mongoose = require('mongoose');
const { MongoMemoryServer } = require('mongodb-memory-server');

let mongoServer;

// Start a throwaway in-memory Mongo and connect Mongoose to it.
async function connect() {
  mongoServer = await MongoMemoryServer.create();
  await mongoose.connect(mongoServer.getUri());
}

// Wipe every collection — call before each test for a clean slate.
async function clear() {
  const { collections } = mongoose.connection;
  for (const key of Object.keys(collections)) {
    await collections[key].deleteMany({});
  }
}

// Disconnect and shut the server down so Jest can exit cleanly.
async function disconnect() {
  await mongoose.connection.dropDatabase();
  await mongoose.disconnect();
  await mongoServer.stop();
}

module.exports = { connect, clear, disconnect };

Now the integration test itself. It imports the app (not the server), wraps it in supertest, and asserts on real responses. Because auth guards the routes, we mint a JWT the same way the app does and send it in the Authorization header.

// tests/integration/tasks.test.js
const request = require('supertest');
const jwt = require('jsonwebtoken');
const app = require('../../src/app');           // the app, NOT server.js
const Task = require('../../src/models/Task');
const { connect, clear, disconnect } = require('../setup/testDb');

const userId = '507f1f77bcf86cd799439011';
const token = jwt.sign({ userId }, process.env.JWT_SECRET || 'test-secret', { expiresIn: '1h' });
const auth = (req) => req.set('Authorization', `Bearer ${token}`);

beforeAll(connect);       // one in-memory DB for the whole file
afterEach(clear);         // reset between every test — the isolation guarantee
afterAll(disconnect);     // clean shutdown so Jest exits

describe('POST /api/tasks', () => {
  test('creates a task and returns 201 with the saved document', async () => {
    const res = await auth(request(app).post('/api/tasks'))
      .send({ title: 'Write tests', description: 'Cover the API' });

    expect(res.status).toBe(201);
    expect(res.body.title).toBe('Write tests');
    expect(res.body._id).toBeDefined();

    // Prove it really persisted — read it straight from the DB.
    const inDb = await Task.findById(res.body._id);
    expect(inDb).not.toBeNull();
  });

  test('rejects a task with no title and returns 400', async () => {
    const res = await auth(request(app).post('/api/tasks')).send({ description: 'no title' });
    expect(res.status).toBe(400);
  });
});

describe('GET /api/tasks', () => {
  test('returns only the current user’s tasks', async () => {
    // Seed two of ours and one belonging to someone else.
    await Task.create([
      { title: 'Mine 1', user: userId },
      { title: 'Mine 2', user: userId },
      { title: 'Theirs', user: '507f1f77bcf86cd799439099' },
    ]);

    const res = await auth(request(app).get('/api/tasks'));
    expect(res.status).toBe(200);
    expect(res.body).toHaveLength(2);           // the other user's task is excluded
  });

  test('starts empty on a clean database', async () => {
    // Thanks to afterEach(clear), this test sees NONE of the data above.
    const res = await auth(request(app).get('/api/tasks'));
    expect(res.body).toEqual([]);
  });
});

describe('auth guard', () => {
  test('returns 401 without a token', async () => {
    const res = await request(app).get('/api/tasks');   // no auth() wrapper
    expect(res.status).toBe(401);
  });
});

Stage 4 — One End-to-End Journey

At the tip of the pyramid sits the end-to-end test: a real browser, driven by code, walking through your live app exactly as a user would. It is the only test that proves the front end, the API, and the database all work together. It is also the slowest and most brittle, so you write few of them — just the critical journeys. For a Task Manager, the crown jewel is: a new user signs up, logs in, creates a task, and marks it done. If that works, the app's reason to exist works.

We'll use Playwright. First, a small config pointing at the running app and starting it automatically:

// playwright.config.js
const { defineConfig } = require('@playwright/test');

module.exports = defineConfig({
  testDir: './tests/e2e',
  use: {
    baseURL: 'http://localhost:3000',
    trace: 'on-first-retry',        // capture a trace when a test retries
  },
  // Playwright boots the app for you, then tears it down when tests finish.
  webServer: {
    command: 'npm run start:test',  // starts API + client against a test DB
    url: 'http://localhost:3000',
    reuseExistingServer: !process.env.CI,
    timeout: 120000,
  },
});

Now the journey. Note the reliance on data-testid attributes: selecting by a stable test id rather than by CSS class or visible text keeps the test from shattering every time a designer renames a button or restyles the page.

// tests/e2e/task-journey.spec.js
const { test, expect } = require('@playwright/test');

test('a new user can register, log in, create and complete a task', async ({ page }) => {
  // Unique email per run so the test can repeat without collisions.
  const email = `e2e_${Date.now()}@example.com`;
  const password = 'testPassword123';

  // 1. Register
  await page.goto('/register');
  await page.getByTestId('name-input').fill('E2E User');
  await page.getByTestId('email-input').fill(email);
  await page.getByTestId('password-input').fill(password);
  await page.getByTestId('register-button').click();

  // 2. Log in
  await expect(page).toHaveURL(/\/login/);
  await page.getByTestId('email-input').fill(email);
  await page.getByTestId('password-input').fill(password);
  await page.getByTestId('login-button').click();

  // 3. Land on the dashboard
  await expect(page).toHaveURL(/\/dashboard/);

  // 4. Create a task
  await page.getByTestId('add-task-button').click();
  await page.getByTestId('task-title-input').fill('Ship the tests');
  await page.getByTestId('save-task-button').click();

  // The task shows up in the list.
  const taskItem = page.getByTestId('task-item').filter({ hasText: 'Ship the tests' });
  await expect(taskItem).toBeVisible();

  // 5. Complete it
  await taskItem.getByTestId('complete-button').click();
  await expect(taskItem).toHaveClass(/completed/);
});

Stage 5 — The Coverage Gate

Coverage measures how much of your code the tests actually execute — by line, by branch, by function. It is reported as a percentage, and it is a useful flashlight: it shows you the dark corners no test ever visits. The trick is to turn that flashlight into a gate — a threshold the build must clear, so coverage can only hold or climb, never quietly erode.

Add coverageThreshold to the Jest config from Stage 1. Below any number here, jest --coverage exits non-zero — which, in CI, fails the build:

// jest.config.js — add this block
module.exports = {
  // ...everything from Stage 1...

  coverageThreshold: {
    global: {
      statements: 80,
      branches: 75,
      functions: 80,
      lines: 80,
    },
  },
};

Run it locally and read the table Jest prints. The "% Branch" column and the "Uncovered Line #s" column are the ones that teach you something — they point at the exact conditionals your tests never took:

npm run test:coverage

--------------------|---------|----------|---------|---------|-------------------
File                | % Stmts | % Branch | % Funcs | % Lines | Uncovered Line #s
--------------------|---------|----------|---------|---------|-------------------
All files           |   86.2  |   78.9   |   88.0  |   86.2  |
 services           |   100   |   100    |   100   |   100   |
  taskFilters.js    |   100   |   100    |   100   |   100   |
 controllers        |   79.1  |   70.0   |   81.2  |   79.1  |
  taskController.js |   79.1  |   70.0   |   81.2  |   79.1  | 44-47, 88
--------------------|---------|----------|---------|---------|-------------------
Test Suites: 3 passed, 3 total
Tests:       14 passed, 14 total

Stage 6 — Wire GitHub Actions CI

Everything so far runs on your machine when you remember to run it. The last stage removes both caveats: a CI pipeline that runs the entire pyramid automatically, on a clean machine, on every push and pull request. If any layer goes red, the pull request is marked failing before a human reviews it.

The key CI concept for a database-backed app is the service container. GitHub Actions can start a Docker container — here, MongoDB — alongside your job and expose it on localhost. Your integration and E2E steps talk to that real database, and it vanishes when the job ends. Here is the whole workflow:

# .github/workflows/ci.yml
name: CI

# Run on every push and every pull request to main.
on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

jobs:
  test:
    runs-on: ubuntu-latest

    # A real MongoDB, started by GitHub Actions and reachable on localhost.
    services:
      mongo:
        image: mongo:7
        ports:
          - 27017:27017
        # Wait until Mongo answers before the steps run.
        options: >-
          --health-cmd "mongosh --eval 'db.runCommand({ ping: 1 })'"
          --health-interval 10s
          --health-timeout 5s
          --health-retries 5

    env:
      MONGODB_URI: mongodb://localhost:27017/task_manager_test
      JWT_SECRET: ci-test-secret
      NODE_ENV: test

    steps:
      - name: Check out the code
        uses: actions/checkout@v4

      - name: Set up Node.js
        uses: actions/setup-node@v4
        with:
          node-version: 20
          cache: npm          # cache ~/.npm between runs for speed

      - name: Install dependencies
        run: npm ci           # clean, lockfile-exact install

      - name: Lint
        run: npm run lint

      - name: Unit tests
        run: npm run test:unit

      - name: Integration tests (against the Mongo service)
        run: npm run test:integration

      - name: Coverage gate
        run: npm run test:coverage

      - name: Install Playwright browsers
        run: npx playwright install --with-deps chromium

      - name: End-to-end tests
        run: npm run test:e2e

      - name: Upload coverage report
        if: always()          # keep the report even when a step failed
        uses: actions/upload-artifact@v4
        with:
          name: coverage
          path: coverage/

Stretch Goals

Required build done with time to spare? Push the pipeline toward production quality. None of these are needed to pass the rubric — pick what excites you.

Matrix starter

A matrix is one small block that fans the job out across versions — every combination runs as its own parallel job:

# Inside the job, above "steps:"
strategy:
  fail-fast: false          # let every version finish, even if one fails
  matrix:
    node: [18, 20, 22]

steps:
  - uses: actions/checkout@v4
  - uses: actions/setup-node@v4
    with:
      node-version: ${{ matrix.node }}
      cache: npm
  # ...the rest of the steps run once per Node version...

Self-Check Rubric

Before you call this done, grade yourself against the rubric. Aim to answer "yes" to everything in the first two columns — the stretch column is bonus.

Summary

This capstone is the difference between code that happens to work and code you can prove works — and keep proving, automatically, forever. The strategy you practiced is the everyday grammar of professional teams: test the logic cheaply at the bottom, test the wiring in the middle, guard the crown-jewel journeys at the top, gate coverage so it can't slide, and let CI run all of it on a clean machine so no regression reaches main unnoticed. You didn't just write tests this weekend — you built a safety net that lets you change the app tomorrow without fear.

📚 Additional Resources

• Jest — Getting started & configuration
• supertest — HTTP assertions for Node
• mongodb-memory-server — in-memory Mongo for tests
• Playwright — end-to-end testing docs
• GitHub Actions — service containers
• Martin Fowler — The Practical Test Pyramid

🚀 What's Next?

Your app is tested and every merge is gated — it is finally ready to leave your laptop. Week 13 opens the Cloud & Deployment module, and the first lesson, AWS, Azure, and GCP compared, surveys the big three cloud platforms so you can choose where this well-tested app will actually live. The green CI pipeline you just built becomes the front half of a full deployment pipeline: test, then ship — with confidence.