Testing, CI/CD, and Deploy

You have written more tests in this track than most tutorials ship in total, and almost none of them are unit tests. That is deliberate, and it is the opposite of the testing advice you absorbed from a decade of pyramids-with-a-wide-unit-base diagrams. For an agent-built solo SaaS, the tests that catch real defects are the ones that check whether tenants are isolated, whether billing survives a failed payment, whether a job dead-letters instead of vanishing. Those are integration and policy tests. This lesson names the pyramid worth having, adds the one browser test that proves the product works end to end, and turns the whole suite into a wall that unreviewed code cannot climb over.

The pyramid worth having, solo

The classic pyramid says: many unit tests, fewer integration tests, a handful of end-to-end tests. For this kind of project, invert your attention. Here is the position: the defects that will actually hurt a solo SaaS live at the seams, so weight the suite toward the seams.

Policy and integration tests (the heavy layer). These you already have: the RLS tenancy suite (4.5), the unauthorized-access suite (4.6), the billing lifecycle test (4.7), the job lifecycle test (4.8). Each exercises a real boundary with a real database, and each was written as a merge gate, not an afterthought. These catch the failures an agent actually ships: the missing where org_id, the client-side-only check, the redirect-as-truth, the silently-lost job. This is where your testing time goes.

A thin layer of unit tests, only where logic is genuinely tricky. Pure functions with real branching earn a unit test: the digest's "did anything happen worth emailing" predicate, the subscription-status-to-access mapping, a date-window calculation. Do not write unit tests for glue, for framework behavior, or for code with no branches; those tests assert that the code is the code, cost maintenance, and catch nothing. An agent will happily generate two hundred of them if you let it, and they will all pass forever while a tenancy leak sails through.

One critical-path smoke test (the tip). A single Playwright test that walks the product's spine: sign up, create a project, upload a deliverable, approve it, confirm the audit record. If that passes, the product's core promise works; if it breaks, something structural did. You want one or a few of these, not a hundred; end-to-end tests are slow and brittle in bulk, and their value is proving the whole thing hangs together, which one good path does.

The through-line: test behavior at boundaries heavily, test tricky logic in isolation lightly, prove the spine end to end once. A hundred unit tests on getters plus zero policy tests is precisely the suite that feels thorough and ships a data leak.

The critical-path smoke test

Playwright is the tool, installed via npm init playwright@latest, which offers to drop in the GitHub Actions workflow for you. The one test that matters:

import { test, expect } from '@playwright/test'

test('the spine: signup to approved deliverable with audit', async ({
page,
}) => {
// Sign up and land in a fresh org.
await page.goto('/signup')
await page.getByLabel('Email').fill('owner@studio.test')
await page.getByLabel('Password').fill('correct-horse-staple')
await page.getByRole('button', { name: 'Create account' }).click()
await expect(page).toHaveURL(/\/dashboard/)

// Create a project and upload a deliverable.
await page.getByRole('button', { name: 'New project' }).click()
await page.getByLabel('Project name').fill('Acme rebrand')
await page.getByRole('button', { name: 'Create' }).click()
await page.getByRole('button', { name: 'Upload deliverable' }).click()
await page.getByLabel('File').setInputFiles('tests/fixtures/logo.png')
await page.getByRole('button', { name: 'Upload' }).click()
await expect(page.getByText('logo.png')).toBeVisible()

// Move to review, then approve, and check the audit trail exists.
await page.getByRole('button', { name: 'Send for review' }).click()
await page.getByRole('button', { name: 'Approve' }).click()
await expect(page.getByText('Approved by owner@studio.test'))
  .toBeVisible()
// The approval is the product's core value: an audit record that
// holds up in a dispute. Assert it is shown, dated, attributed.
})

The Playwright config points at a dev server so CI can boot the app and drive it:

import { defineConfig } from '@playwright/test'

export default defineConfig({
testDir: './tests',
use: { baseURL: 'http://localhost:3000' },
// CI boots the app, then runs the specs against it.
webServer: {
  command: 'npm run build && npm run start',
  url: 'http://localhost:3000',
  reuseExistingServer: !process.env.CI,
},
})

CI as merge protection

The 4.4 skeleton ran typecheck, lint, and build. Now it grows the teeth that make it a gate: it runs every suite, spins up a database for the policy and integration tests, and (this is the part that matters) is set as a required status check on the main branch so a red run blocks the merge. A gate that reports but does not block is a suggestion, and 3.2 was clear that a gate you can merge past is not a gate.

name: CI
on:
push: { branches: [main] }
pull_request: { branches: [main] }
jobs:
verify:
  runs-on: ubuntu-latest
  steps:
    - uses: actions/checkout@v5
    - uses: actions/setup-node@v5
      with: { node-version: lts/*, cache: npm }
    - run: npm ci
    - run: npm run typecheck
    - run: npm run lint
    - run: npm run build
    # Policy + integration tests need a database.
    - run: supabase start
    - run: supabase db reset          # migrations apply cleanly
    - run: supabase test db           # RLS/tenancy policy suite
    - run: npm test                   # billing + jobs + auth suites
    - name: Install Playwright browsers
      run: npx playwright install --with-deps
    - run: npx playwright test        # the critical-path smoke
    - uses: actions/upload-artifact@v4
      if: ${{ !cancelled() }}
      with:
        name: playwright-report
        path: playwright-report/
        retention-days: 7

Then, in GitHub branch protection settings, mark the verify job a required check and require a PR to merge. Now the path to main is: branch, push, CI runs every gate, red blocks. This is where all the per-feature gates from 4.5 through 4.8 stop being local rituals and become an enforced property of the repository. An agent can no longer produce a green-looking "done" that merges a tenancy leak, because the merge itself is gated on the tenancy suite.

Deploy: previews as review artifacts, production on merge

Connect the GitHub repo to Vercel once. From then on Vercel's git integration gives you two behaviors straight from its environments model. A push to any non-production branch, or opening a PR, creates a preview deployment at a generated URL: a live, running copy of that exact change, which is the best review artifact there is, since you can click the actual feature instead of imagining it from a diff. A merge to main (the production branch) triggers a production deployment that updates your live domain. Environment variables are set per environment in Vercel (production keys for production, test keys for preview), and vercel env pull brings them down for local dev.

The crons from 4.8 (vercel.json) activate on the production deployment; Vercel reads that file and schedules the GETs against your production URL. Nothing else is required to turn the jobs on in production, which is the payoff of having designed them as plain route handlers.

The critical operational rule: preview deployments run against non-production data, production against production data, and the two never share credentials. A preview that can write your production database is a loaded gun in every PR.

The dispatch

Where it breaks

The first failure is the inverted-effort suite: two hundred unit tests, zero policy tests, green forever, and a live data leak. Coverage percentage is the seductive lie here, because getters and glue are easy to cover and boundaries are not, so a high number often means the easy code is tested and the dangerous code is not. Judge the suite by what it would catch, not by its coverage bar: if deleting your where org_id clause does not turn something red, the suite is decorative where it matters.

The second is the reporting gate that does not block. CI that runs on PRs but is not a required check lets a red build merge, and under deadline someone (you, at 1am) will. The fix is one settings toggle, branch protection requiring the check, and it is the difference between a gate and a dashboard.

The third is the preview that touches production. The convenience path, one set of env vars for everything, means every preview deployment and every local test run can mutate live customer data. Keep production credentials in the production environment only; previews and local get test credentials. This is not paranoia, it is the same failure-domain discipline from 4.2 applied to your own deploy pipeline.

Knowledge check

Sources

• Playwright Setting up CI (npm init playwright, GitHub Actions workflow with checkout@v5 / setup-node@v5, install --with-deps, upload-artifact report): https://playwright.dev/docs/ci-intro (fetched July 2026)
• Vercel Environments (preview deployments on non-production branches and PRs, production deploy on merge to the production branch, per-environment env vars, vercel env pull): https://vercel.com/docs/deployments/environments (fetched July 2026)
• Vercel Cron Jobs (vercel.json crons scheduled against the production deployment): https://vercel.com/docs/cron-jobs (fetched July 2026)
• Best practices for Claude Code (verification-first, do-not-weaken-assertions discipline the dispatch enforces): https://code.claude.com/docs/en/best-practices (fetched July 2026)
• The Briefcase test config, e2e spine test, and CI gate are this course's reference artifacts, authored against the fetched Playwright and Vercel docs.