Testing, Review & Deployment

AI-Generated Test Suite

AI can quickly draft test cases, but a generated suite is only useful after you review its assertions and run it against the actual code. Give AI the implementation to test, then inspect failures and missing coverage.

Backend API Tests

// test/helpers.ts
import { app } from '../src/index';
import request from 'supertest';

export async function createTestUser(overrides = {}) {
  const userData = {
    email: `test-${crypto.randomUUID()}@taskflow.app`,
    password: 'testpassword123',
    name: 'Test User',
    ...overrides,
  };

  const res = await request(app)
    .post('/auth/register')
    .send(userData);

  return {
    user: res.body.user,
    token: res.body.token,
    ...userData,
  };
}

export async function createTestProject(token: string, name = 'Test Project') {
  const res = await request(app)
    .post('/projects')
    .set('Authorization', `Bearer ${token}`)
    .send({ name });

  return res.body.project;
}

Run the test suite. The terminal block below is an example of the target shape of a successful run; your counts and duration will vary:

Treat the displayed 28 passing tests as a tutorial target, not a recorded benchmark. If tests fail, determine whether the implementation or the assertion is wrong, make the appropriate fix, and re-run.

Security Audit

Before deploying anything, run a security-focused review. This is the checklist from Chapter 11 of the manual, applied to our specific codebase.

If your audit confirms the critical example finding — password_hash exposed in API responses — fix it immediately: add a sanitizeUser function that strips password_hash before returning any user object.

// utils/sanitize.ts
import type { User } from '@taskflow/shared';

export function sanitizeUser(row: Record<string, unknown>): User {
  const { password_hash, ...user } = row;
  return user as User;
}

// Apply in auth routes:
// Before: res.json({ token, user })
// After:  res.json({ token, user: sanitizeUser(user) })

Deployment

For a weekend build, we want the simplest possible deployment. Two options, both prompt-driven:

Option A: Railway (Recommended)

// server/src/index.ts — production static serving
import path from 'path';

if (process.env.NODE_ENV === 'production') {
  app.use(express.static(path.join(__dirname, '../public')));

  // SPA fallback: serve index.html for all non-API routes
  app.get('*', (req, res, next) => {
    if (req.path.startsWith('/auth') || req.path.startsWith('/projects') || req.path.startsWith('/tasks')) {
      return next();
    }
    res.sendFile(path.join(__dirname, '../public/index.html'));
  });
}

Option B: VPS with Docker

If you prefer a VPS, ask AI to generate a Dockerfile and docker-compose.yml. The same build process applies — client builds to static files, server serves them. Add a reverse proxy (Caddy is simplest) for HTTPS.

The following deployment output is illustrative. Run the equivalent build and deploy commands for your chosen host, then record your own URL and checks.

Demo vs Production: Draw the Line

A weekend build can be deployable without being production-grade in every dimension. Make the boundary explicit so you know what is "good enough for demo" versus what is required before real customer traffic.

The Retrospective

Once you have completed and verified your build, take time for the Meta Loop from Chapter 19: what worked, what did not, and what you would do differently.

Jump to Any Part