Hoverfly

Hoverfly lets an application call a controlled stand-in for an API it depends on. Tests can use recorded or authored responses, including delays and errors, instead of waiting for a real dependency to be available or fail in a particular way. It is useful for reproducible integration tests and hard-to-trigger failure cases. The simulation must match the real contract closely enough to be useful; a passing simulation does not certify the live service.

Current guidance

The current upstream repository identifies the API simulation project and its maintainers. The old incubator/hoverfly chart lives in the archived Helm charts repository; its retirement does not establish that the application has been retired.

Choose which dependencies are simulated and which requests should reach real systems. A simulation is useful when its request matching, response bodies and error cases reflect the contract under test. Keep simulation files under review with the application, and avoid accepting a passing simulated test as evidence that a third-party API still behaves identically.

Before putting Hoverfly behind a Kubernetes Service, separate the traffic proxy from its administration API, restrict who can change simulations, and remove credentials or personal data from captured traffic. Exercise unmatched requests, timeouts and concurrent calls so accidental passthrough or simplistic matching does not hide failures. Select a released upstream binary or image and review the chart’s manifests separately; this entry does not certify an installation or a performance result.