Module 6, Lesson 2: Testing the API Scaffold

How do you test an API scaffold that Claude Code generated? Start a fresh session on your feature branch, launched with your locked flags. Spin up the local database with Docker Compose, run the API, and read a real endpoint response.

You want a working health check and an expected 401 on a protected route. Fix any breakage here, before you build features on a shaky base. The Product Path shows the flags and checks.

Why test the API scaffold before building features?

You test the API scaffold to confirm the code Claude Code generated actually runs the way it claims, before you build features on top of it. That means starting the API with its database (via Docker Compose) and hitting real endpoints, checking that a health check returns cleanly and a protected route returns an expected 401.

Catching and fixing problems at the scaffold stage is far cheaper than discovering them after feature work is layered on, so you only commit the API to your branch once it is confirmed working.

Before We Start

From previous lessons:

• You've scaffolded your monorepo: API/data layer and mobile app shell, both created by Claude Code. Module 6, Lesson 1
• You have a CLAUDE.md file guiding Claude Code's behavior on your project. Module 6, Lesson 1
• That scaffolding work is sitting on a feature branch, not yet merged to main. Module 6, Lesson 1

Tools / setup you'll need:

• WebStorm, open to your project, with a terminal available
• Claude Code, plus your .mcp.json if you use one
• Docker, for the local database

By the end of this lesson, you'll:

• Have started a fresh Claude Code session on your feature branch with a locked MCP config and autonomous permissions
• Have confirmed your API scaffold actually runs locally, database included
• Have hit and read a real endpoint response, including an expected 401 on a protected route
• Have committed the confirmed, working API to your branch