Development does not occur in isolation – it is an active, interconnected process. Because of this, one of the most important things a developer can incorporate into their development lifecycle is testing. Testing each stage of code development and deployment can ensure that services perform as expected, and have a high-quality user experience.

Unfortunately, mocking services that are in current development can be a little tricky, costly, and time-consuming. In many cases, some developers even feel that testing an ongoing codebase is impossible, instead choosing to delay testing until they build a minimum viable product.

Thankfully, that doesn’t have to be the case. Many techniques enable easy mock testing for APIs, web services, and other environments still under production. Today, we’ll look at why testing services in development can be problematic. We’ll isolate the chief concerns, and then point to some mock testing tips.

Why is Testing Difficult?

Testing is often tricky, especially when developers run tests in isolation within a single environment prone to issues. There’s a definite line between what works locally and what works at scale. This results in the familiar developer joke of, “well, it works on my machine!”

The problem here is that every environment carries bias. When you’re testing in an unstable environment, it’s hard to figure out where the error originates. It could be the result of the codebase, the transport medium, the various protocols used, or even the network used to translate the calls themselves. While teams may isolate errors by using proper error codes, they still end up with a time-consuming failure.

Adding on to this issue is that typical testing methodologies are rooted in classic software development. If a development process only uses sporadic testing, it runs the risk of missing a bug early on, or generating a codebase that simply never works. This forces countless code reviews and reworking to isolate whether the error is in code or methodology.

Finally, there is the reality that, for many developers, testing is a process only undertaken at two extremes: during pre-development, and during post-development. Essentially, this equates to validating the structure of the codebase and then validating the solutions built upon said codebase. While these both have their places, testing during development is unfortunately quite underutilized, often only used to realize whether a milestone is met or not.

Mocking

One solution to this quagmire of testing procedures is the idea of generating a mock testing environment. Mock tests isolate both the issues of environmental impact and enable testing throughout the development process. In essence, this provides a few unique benefits.

• Mocks enable pure functional testing. Creating a mock allows for testing without artificial restraints and roadblocks imposed by network health, platform constraints, or other variables. In essence, you are testing your solution, not the environment in which it is tested.
• Mocks can simulate many conditions. Working within a mock environment generated specifically for the codebase at hand allows for easier testing of scalability, resiliency, and availability. With mock environments, testing can be controlled within a wide range of behaviors and parameters to simulate conditions that the codebase may live in.
• Mocks allow for a more macroscopic view. Instead of testing isolated, singular pieces of the code framework to clear a milestone, you can test the codebase holistically, generating the API elements from specifications or “plugging in” existing solutions to make up for code not yet in production.
• Mocks allow a more comprehensive view. Controlling the environment also means that you can holistically track and log in a simpler methodology. Instead of creating a fake call, setting up an emulated server, creating different variables within a static environment, and so forth, by controlling the environment, you get almost an “x-ray vision.” You see what is going on, how everything is being ported about, and specifically how these systems either fail or succeed.

Additionally, much of this mocking is supported by powerful frameworks, implementations, and solutions that can be plugged into automated testing platforms. This allows new code commits to be automatically tested and verified before moving on to additional sections of code. Ultimately, automation improves efficiency in many workflows and can have a marked impact on code prioritization.

Mocking Options

With all this being said, let’s look at a few options for effective mocking.

Karate

Karate is an open-source testing system that boasts a lot of functionality. In the documentation, it claims to be “the only open-source tool to combine API test-automation, mocks and performance-testing into a single, unified framework”. Much of its functional testing system is based around the idea of building and storing request payloads that can then be delivered in a highly controlled environment, thereby subjecting code to standardized testing which conforms to the specific parameters needed.

Karate supports JSON and XML, and offers “scenario data” expressed in a human-readable format. This is a key feature, as surfacing issues with the codebase can often be lost in complex error codes and generalized error statements that are more hindrance than a help. To that end, there is a strong reporting standard included that allows for everything from fuzzy matching to exact reporting, allowing for more comprehensive error test reports that directly point to the problematic part of the greater system.

Additionally, and perhaps most importantly for newer developers, Karate offers a library of pre-formed mocks to allow for easy setup and testing out of the box.

Hoverfly

Hoverfly is an open-source API simulation tool developed and maintained by SpectoLabs. The key advantages of the platform are its ease of use, its scalable performance, and its cost-effectiveness. Hoverfly provides the flexibility to create and use API simulations as needed, reducing dependency on real services and speeding up the development cycle.

In addition, it can be easily integrated with continuous integration (CI) and continuous deployment (CD) pipelines, enhancing automated testing processes. Another perk is its user-friendly interface which includes a web-based interface for managing and configuring API simulations, making it accessible to both developers and testers.

Image from SpectoLabs

Mockable

Mockable is an offering that aims itself more towards collaboration and simplicity than it does to the “lean, mean testing environment” side of this conversation. In essence, Mockable is trying to take the testing environments offered throughout this list and in the industry in general, and create a user experience around it to make testing easier, more understandable, and more collaborative.

As an enterprise solution, this makes sense – Mockable almost assumes that you gave a team that requires segmentation in order to effectively test aspects of the codebase, offering containers with domains and subdomains that can be split depending on the number of people you have involved in testing.

Unfortunately, Mockable is not free or open-source, and for this reason, it might be a hard sell for non-enterprise users. While there is technically a free offering – specifically, a trial domain – it is throttled and has several limits applied. Still, it may be a good solution for certain use cases and workflows.

Image from Mockable

Postman

Postman is a more generalized development solution, but it happens to include some effective mocking solutions internally as part of its offering. This is a good example of a holistic approach – while there are services that offer specific mocking systems, having a solution that is not solely dedicated to mocking (or testing in general) can be very helpful in some workflows.

While Postman does offer a wide range of tools, we’re only going to focus on its mocking capabilities in this piece. Setting up a mock API is very simple, and only takes a few minutes to get going. From here, Postman gives users a limited amount of free calls with which to mock – this, of course, can be increased for a price.

Mock APIs leverage a system that is essentially akin to creating a bird’s eye view of the entire ecosystem at hand – by creating both the testAPI collection and the testAPIEnv collection, developers can create a very specifically crafted and nuanced environment for their testing flow.

Of course, the problem here is that not everyone needs a complete development solution – and while Postman can, in theory, only be used for its testing systems, that would be akin to using a rocket to deliver mail – absolutely too much for too little of a return.

Conclusion

Testing can be a difficult thing to contextualize. While not everyone can reap the benefits of testing often and testing early throughout development, there are more workflows that would benefit than wouldn’t; for this reason, developers should consider their current testing paradigm, and decide whether its limitations are actual, or created. The solutions proposed for mock testing in this piece are but a handful of possible choices, with the field of API testing implementations being as wide as the offerings of APIs themselves.

Do you think mock testing is effective? Does the effort required justify its usage? Let us know in the comments below!