Over the last few weeks we have been busy on the next iteration of Hoverfly Cloud. The theme of this iteration is adding features that teams need to take their API Simulations and re-use them in integration, end-to-end and performance testing. These are all features that teams need to bring a complex layered service architecture into production.
The initial screen (or home page) is also a Dashboard - initially you also get a Welcome screen which will take you to this document and the Quick start guide. Alongside the screen are 4 icons that take you to:
The dashboard allows you to manage Simulations and Scenarios (described below), quickly start and stop them.
Note that there is a Welcome message with short-cuts to the features we think you need the most. Please explore. You can remove the Welcome message but we suggest leaving it until you comfortable with the new features.
Our users told us that to create meaningful integration, end-to-end and performance tests they needed to be able to run many services at a time. That was possible with the old Hoverfly Cloud but we provided no means of saving the state of those services. Hence Scenarios. Scenarios are simply a way of gathering one or more Simulations when you need to emulate many services.
Instances have been replaced by Services as they are intended as a complete replacement for your real services or APIs. Unlike your real services they are predictable and always available! A Hoverfly Cloud Service will behave the same today as it will next week and forever more.
Simulations have to be discovered so they have a URL and to make them more memorable they also have a Service Name. They also can have Behaviors.
In our open source tool Hoverfly and Hoverfly Cloud a Simulation is simply a collection of request/response pairs that have been previously captured by monitoring traffic to and from a real service. You can see what a simulation looks like by using the Simulation Builder in Hoverfly Cloud.
The journal logs every request and response that Hoverfly Cloud sees so it is useful for troubleshooting, analysis and monitoring. As you can create thousands of entries in the journal it provides a number of filters to allow you to home in on errors and particular entries.
Swagger is the best known method for defining and developing API specifications. We now allow you to import a Swagger definition and create a simulation. From there you may create more request/response pairs in the Simulation Builder so you can quickly provide simulations for more test cases.
This feature is intended to for situations when services need to be prototyped. We would like to understand how users are developing their services using Swagger and what other features would be useful.
Behaviors aren’t new but are worth mentioning again as they allow you to do many things quickly - including making your service simulations badly behaved - except in a predictable way which is what you need for testing!
Behaviors are used to predictably create specific error conditions to support testing. A wide range of Behaviors is supported including HTTP header errors, data errors, latency simulations and more. This is very useful for understanding how your application behaves under stress or in unpredictable production environments. We recently had a case where customers were struggling to reproduce a problem seen in production in their test environment. Using Hoverfly Cloud they quickly replicated the problem using behaviors and fixed the problem.