Hoverfly: A Local Hive Mock for Testing Without a Testnet

I have been working on a small project called Hoverfly, and it is finally at the point where I am comfortable showing it to other Hive developers.

The short version is this:

Hoverfly is a single-binary local mock Hive server for testing apps, scripts, bots, and SDK integrations without depending on a live node or a stable testnet.

Testnets are not always available when you need them, and using mainnet as a test fixture is a terrible habit.

Why I Built It

Hoverflies look like bees, but they are not.

When you are writing a Hive application, a lot of the early testing does not actually require consensus, P2P networking, or a real witness network.

You usually need to answer simpler questions first:

• Can my client connect?
• Does it understand the JSON-RPC shape?
• Can it read account data?
• Can it build and broadcast a transaction?
• Does the app behave correctly after a transfer?
• Can it create a post and read it back?
• Does the block and history logic do what I expect?

Hoverfly is meant to handle that layer.

It gives you a local Hive-shaped environment that starts quickly, resets easily, and does not touch the real chain.

What It Does

Hoverfly is written in Go and uses BadgerDB for its local state.

By default, it runs in-memory, so stopping the process gives you a clean slate. If you want a longer-lived sandbox, you can point it at a local database directory.

It starts with seeded test accounts, including Alice and Bob, and generates local keys for them. It also simulates block production so applications that expect the head block and dynamic global properties to move forward have something realistic enough to work with.

The server currently includes explicit handlers for important account, block, content, broadcast, history, and debug flows, along with generated OpenAPI-shaped responses for the wider documented method surface.

This is not a consensus node.

It does not do P2P networking, witness scheduling, or real economics. It is a developer tool for the part of the workflow where a fast local target is more useful than a live blockchain.

Transactions Are Stateful

The useful part is that this is not just a collection of static JSON examples.

Supported local transaction flows can mutate the sandbox:

• transfers update balances
• savings transfers update savings balances
• account creation creates local accounts
• comments create local posts and replies
• transactions become available through transaction and history calls

There is also transaction serialization and signature recovery work in the project, so the goal is to catch more than just HTTP mistakes.

The default mode is intentionally permissive for quick scripts. A strict mode is available when you want selected transaction-state validation instead.

The Readiness Pass

Before announcing Hoverfly, I did a pass focused less on adding shiny features and more on making the project safer to hand to somebody else.

That included fixing a standalone build problem caused by a local development dependency replacement. The public hive-anther module already has tagged releases, so Hoverfly now resolves it normally instead of assuming another repository exists beside it on disk.

I also tightened up the server itself:

• it binds to localhost by default
• the host can be overridden explicitly
• HTTP read, write, header, and idle timeouts are configured
• the server handles normal shutdown signals
• the block ticker stops cleanly
• oversized request bodies are rejected

The documentation also needed some honesty work. The API surface is broad, but not every endpoint is a stateful consensus-accurate implementation. The README now distinguishes explicit stateful routes from generated fixtures and fallback responses.

A mock should be useful without pretending to be something it is not.

The Current Results

The project currently has:

• 43 passing Go tests
• passing race-detector tests
• passing go vet
• no reachable vulnerabilities reported by govulncheck
• a clean build from an archived checkout
• a live smoke run with 287 of 287 executed cases passing

Two malformed cases in the curl fixture are skipped by the smoke tool, so I am not pretending that number is a perfect 289/289. This is still an early project and there is more semantic compatibility testing to do.

But it is now in a much better place for early adopters to try it.

Try It Out

The repository is here:

github.com/srbde/hoverfly

If you have a client that assumes it is talking to a Hive node, Hoverfly is an invitation to point it at localhost instead and see what breaks before the real chain gets involved.

Nothing fancy, just a local sandbox that should make testing less annoying.

As always,
Michael Garcia a.k.a. TheCrazyGM