Project
Mock Server v1: A Tool for Simulating API Responses
A self-hosted Spring Boot tool for stubbing APIs without code — codeless mocks with configurable status, delay, and failure scenarios.
Key highlights
- 🛠️ Codeless stubbing — create a mock API from a dashboard, no code required
- ⚙️ Per-mock controls for status code, response body, headers, and artificial delay
- 🔀 One-click switch between success and failure response scenarios
- 🔄 Upgraded from an EOL 2020 release straight to a currently-supported one — case study below
Description#
Mock Server v1 is a self-hosted tool for stubbing API responses without writing code: define a mock’s status code, headers, body, and an optional artificial delay from a dashboard, and it’s immediately servable. Built to unblock frontend and backend development from real backend availability, and to make negative-path testing (failures, slow responses, timeouts) a config toggle instead of a hand-written test double.
Key Features#
- Codeless stub creation — add, edit, or delete a mock from the dashboard; nothing to redeploy.
- Success/failure switch per mock — flip a single mock between its success and failure response without touching its definition.
- Configurable artificial delay — simulate slow or timing-out backends on a per-mock basis.
- Persisted configuration — mocks are stored in a real database (H2 or MySQL), not files that need to be passed around a team.
Case Study: Upgrading a 6-Year-Stale Dependency Tree#
I originally built this in 2020, on Spring Boot 2.3.4 — a release that’s been end-of-life for years. Rather than upgrade it by hand, I used it as the first real test case for dependency-upgrade-agent, a Claude Code skill I built specifically to automate this kind of migration.
Three verified hops later:
2.3.4.RELEASE (2020, EOL) → 2.7.18 → 3.0.13 (javax→jakarta, Java 17) → 3.5.16 (current)The run surfaced two real bugs that had been sitting in the codebase unnoticed: an H2 2.x reserved-keyword collision that silently broke a table at boot, and a JPQL query that referenced a database column name instead of an entity field — which had been passing silently on the old Hibernate version and only failed loudly once Hibernate 6 started validating queries eagerly. Both are now fixed, with a characterization-snapshot verification pass (9 request/response pairs, replayed and diffed after every hop) confirming no behavioral regressions.
Full before/after, commit links, and what the tool found: see the dependency-upgrade-agent case study.
Usage Scenarios#
- Frontend development — build against a stable mock API contract independent of backend progress.
- Backend development — stand in for a downstream service that doesn’t exist yet.
- QA / negative testing — toggle failure responses and delays to exercise error handling without breaking a shared environment.