Currently, Hoverfly uses JSON for storing simulations. This works well when using the tool directly, but as a Java developer who wants to quickly set up some stubs for an external API or a microservice, it might be easier to do everything in code.

As you can see, the DSL is hierarchical, even down to how it is formatted by your IDE. This structure draws inspiration from the specification YML used by Swagger. You specify a host, followed by a method, followed by a path etc. The aim is to make the code expressive and human readable.

The DSL is also fluent, so building requests and responses after hitting the entrypoint of HoverflyDSL.service(host) should be self-explanatory.

Assuming you are using an HTTP client that respects JVM proxy settings, then this is literally all you need to do. If you make a request which is satisfied by a matcher declared in the DSL, Hoverfly will respond pretending to be the real service.

Response Creators

When generating responses, it’s nice to have wrappers to build things that would be commonly be returned by an API. That’s why we have the ResponseCreators class, which generates common responses:

Unfortunately, a lot of the APIs we deal with are “legacy”. That’s why these helper methods return a ResponseBuilder that allows us to generate any response we want. You can also just instantiate it directly if you like:

.willReturn(response().status(100))

HTTP Body Converters

One problem with Java is lack of “first class citizenship” for JSON. When you want to specify JSON inline you have to deal with the mess of escape characters:

The main advantage of MockRestServiceServer is that it reduces the overhead of spinning up an actual web server, and instead works with RestTemplate in order to return mock responses. This means that no HTTP traffic takes place, which can speed things up a fair amount. However, this tight coupling to Spring testing means that if you’re using something other than RestTemplate you can’t use it (although I’ll take it over a clunky JAX-RS client).

Besides, when using Hoverfly Java there is automatic unused port selection, a shared instance across tests, and a startup time of less than one second. Because of this I don’t see an issue (or real overhead) with using real HTTP. HTTP will be used in production, so why not test it as early on as possible?

Wiremock is also great tool and like Hoverfly Java, it uses real HTTP. The main difference is that it acts as a web server as opposed to a proxy, meaning you need to point your client to localhost instead of the real URL. Making a property file change may not be a huge issue, but as the proxy configuration can be inferred it removes any configuration boilerplate; all you need to do is instantiate Hoverfly.

You also have to consider that because Wiremock is a web server (or a virtual reverse-proxy more accurately), you need one Wiremock instance per stubbed API. This means as you add more services, startup time will increase, and so will the complexity of your configuration.

SSL is also slightly easier to set-up, as the self-signed certificate for Hoverfly is automatically trusted at runtime, meaning you don’t have to add it to the keystore yourself.

Other Trade-offs

There are other trade-offs, of course. Hoverfly uses Golang regex, which can be a confusing if you’re used to the standard Java regex in Wiremock. That’s why we’re planning to build a matcher interface to act as an abstraction around it (who enjoys regex anyway, really?).

Another missing feature is request verification, something that is currently on the roadmap for Hoverfly, but is already well-supported by Wiremock. Finally, the proxy design is not a magic bullet: there may be some (rare) cases where it’s difficult to get your code to work with a proxy. There are other differences as well, so please check out all the options if you are evaluating which one to use.

Conclusion

The Hoverfly Java DSL provides a really quick way of setting up a stub API or microservice. The proxy approach taken by Hoverfly means that you don’t really need to do anything other than declare a rule at the top of your test.

And remember that this is just a Java binding for Hoverfly. We have recently released a Python binding for Hoverfly and a JavaScript binding is on the roadmap. Hoverfly itself is a single binary that can be deployed easily on any OS and managed through its CLI. The aim is to make it easy to use Hoverfly in different environments throughout the software delivery pipeline.

If you have questions or suggestions on how we could improve Hoverfly Java, please use the comments below or raise an issue on the GitHub repository.