This file provides guidance to Claude Code (claude.ai/code) when working with code in this repository.
Hoverfly is an HTTP/HTTPS proxy for simulating APIs and services. It can capture, simulate, modify, synthesize, spy on, or diff HTTP traffic. It ships two binaries: hoverfly (the proxy server) and hoverctl (the CLI to manage it).
# Build both binaries to target/
make build
# Run all tests (unit + functional + vet)
make test
# Hoverfly unit tests only
make hoverfly-test
# Hoverctl unit tests only
make hoverctl-test
# Functional tests (requires built binaries)
make hoverfly-functional-test
make hoverctl-functional-test
# Run a single test (from the relevant package directory)
cd core && go test -v ./... -run TestFunctionName
# Format and vet
make fmt
make vetTests use the Ginkgo/Gomega BDD framework. Functional tests in functional-tests/ spin up actual hoverfly instances.
core/cmd/hoverfly/main.go— parses 50+ flags, wires up Hoverfly, starts proxy + admin APIhoverctl/main.go— Cobra-based CLI; communicates with a running hoverfly instance via HTTP API
- goproxy intercepts incoming HTTP(S) requests (
core/proxy.go) - The active Mode processes the request (
core/modes/) - Matching finds a recorded response against the simulation store (
core/matching/) - Templating renders dynamic response bodies if configured (
core/templating/) - Middleware optionally transforms request/response (local binary or remote HTTP) (
core/middleware/) - Delay is applied (
core/delay/) - Post-serve actions fire (webhooks, scripts) (
core/action/) - Journal records the exchange (
core/journal/)
Six modes implement the Mode interface with a Process() method (core/modes/):
| Mode | Behavior |
|---|---|
| Simulate | Return recorded responses from simulation store |
| Capture | Forward requests and record request/response pairs |
| Spy | Simulate if matched, else pass through |
| Modify | Pass through but run middleware on traffic |
| Synthesize | Generate responses entirely via middleware |
| Diff | Forward requests and diff responses against simulation |
Mode can be switched dynamically at runtime via the admin API.
core/hoverfly.go—Hoverflystruct, the central coordinator; holds references to all subsystemscore/models/—Simulation,RequestResponsePair,RequestMatcher,ResponseDetails— the core data modelcore/matching/— two strategies:StrongestMatchStrategy(weighted field scoring) andFirstMatchStrategy; wrapped byCacheMatcher(LRU)core/handlers/v2/— 54 REST handler files for the admin API (v1 is legacy)core/templating/— Handlebars templating viaraymond; supports CSV/SQL data sources and journal variable injectioncore/middleware/— executes local binaries or calls remote HTTP endpoints; passes JSON request/response payloadscore/authentication/— opt-in JWT/basic auth; disabled by defaulthoverctl/wrapper/— HTTP client wrapper that hoverctl uses to call the admin API
The canonical data format is the Simulation JSON structure (core/models/simulation.go). It contains an array of RequestResponsePair entries, each with a RequestMatcher (supporting exact, regex, glob, xpath, jsonpath matchers per field) and a ResponseDetails. Test fixtures are in functional-tests/testdata/.
Matchers operate per HTTP field (method, path, query, headers, body, scheme, destination). Multiple matchers on the same field are ANDed. StrongestMatchStrategy picks the most specific match; FirstMatchStrategy picks the first. The CacheMatcher wraps either strategy with an LRU cache keyed on the request fingerprint.
- Go 1.26.1, modules in
go.mod - Proxy:
github.com/SpectoLabs/goproxy(custom MITM fork) - CLI:
cobra+viper - Routing (admin API):
gorilla/mux,go-zoo/bone - Testing:
ginkgo+gomega - Logging:
logrus - Templating:
github.com/SpectoLabs/raymond(Handlebars) - Fake data:
gofakeit/v6