█
LastWrite
  • > Curriculum
  • > Pricing
  • > For Educators
  • > About
  • > Contact
Log InGet Started

Questions, concerns, bug reports, or suggestions? We read every message, write to us at [email protected].

More ways to reach us →
LastWrite

Structured computer science lessons for aspiring developers and security professionals.

[email protected]

(201) 785-7951

Mon–Fri, 9 AM–5 PM EST

Learn

  • Curriculum
  • Pricing

Company

  • About
  • For Educators & Schools
  • Contact Us

Legal

  • Terms of Service
  • Privacy Policy
© 2026 LastWrite. All rights reserved.
Curriculum/Software Engineering/Testing/Passion Project: Add a Real Test Suite
90 minAdvanced

Passion Project: Add a Real Test Suite

After this lesson, you will be able to: Take an untested project and build a full pyramid of tests wired into CI with a coverage gate, the way a professional codebase is protected.

This is the capstone that turns the subtrack into a portfolio piece. You will take a real project (yours or a provided sample) that has little or no testing and bring it up to professional standard: unit, integration, and e2e tests, all running in CI, with a coverage threshold that blocks regressions.

Prerequisites:Running Tests in CI

The project

Pick a project with real logic and a real user flow. Good options: a small full-stack app (auth + a CRUD resource), an API with a database, or a CLI/library with non-trivial functions. If you do not have one, fork a small open-source app. The deliverable is the same: a test suite a hiring manager would respect, visible in your GitHub with a green CI badge.

Build it in milestones

Work bottom-up through the pyramid, committing at each stage so the history shows the progression.

  1. 1

    Audit: list the riskiest logic (money, auth, data integrity) and the critical user journeys. That list is your test plan.

  2. 2

    Unit layer: test the pure logic and edge cases with Vitest or pytest. Aim for the risky code first, not 100 percent.

  3. 3

    Integration layer: test the API routes against a real test database (Docker/Testcontainers); reset state between tests.

  4. 4

    E2e layer: write 2-4 Playwright tests for the critical journeys (sign up, log in, the core action).

  5. 5

    CI: a GitHub Actions workflow runs all three layers on every push and pull request, with a postgres service for integration tests.

  6. 6

    Gate: turn on branch protection, require the test check, and set a coverage threshold (e.g. vitest --coverage with a minimum) so regressions block the merge.

  7. 7

    Document: a README section explaining how to run the tests and what each layer covers, plus a CI badge.

💡 What makes this resume-worthy

Anyone can claim they 'know testing.' A public repo with a layered suite, a green CI badge, and a coverage gate is proof. In interviews you can walk through a real decision you made (what you chose to mock, why you kept e2e tests few, how you stopped a flaky test) which is exactly the conversation senior engineers want to have.

How to talk about it

Interview framing: 'I took an untested app to a full test pyramid in CI. I wrote unit tests for the billing logic, integration tests for the API against a real Postgres via Testcontainers, and four Playwright e2e tests for the auth and checkout journeys. CI runs all three on every PR and a coverage gate blocks regressions.' Resume bullet: 'Built a layered automated test suite (unit/integration/e2e) with CI gating and coverage thresholds, eliminating a recurring class of regressions.'

Sign in and purchase access to unlock this lesson.

Sign in to purchase
←Running Tests in CI
Back to Testing
Testing Job Readiness→