Getting started with mock services

Automated testing is a key part of modern software development life cycles. By writing and continually running tests, software teams ensure better quality and faster delivery. The hardest part of automated testing is making sure that your tests are comprehensive, simple, and effective. You want your tests to be simple and test a single thing so that when they fail, you know just what’s wrong. You want them to be effective, meaning that when they break, they break because some key logic has changed. And you want them to be comprehensive, testing as much as possible.

Some parts of your code base are going to be difficult to test because they rely on external dependencies or code that is difficult to configure in a test environment. That’s where mock services come in. In this post, we’re going to talk about what mock services are and how they’ll help your testing strategy.

A mock service is a block of code that serves to fill in for a software dependency when writing or executing a test

What are mock services?

A mock service is a block of code that serves to fill in for a software dependency when writing or executing a test. The easiest way to understand the concept of a mock service is by example. It’s common to write code that relies on external services through some type of networked API. Relying on that networked API during your tests poses several problems. First off, if your network interface fails or if the API goes down, your tests will fail through no fault of your own. But that’s not the only reason. Because you want your tests to comprehensively cover all code paths within your code base, you’ll write tests that test actions that might be destructive. For instance, if your code can delete users via that networked API, you should test those code flows. But you don’t want to delete a user every time you run a test!

So, you write a block of code, perhaps a class or a group of functions, that stands in for the dependency. Instead of making a call to the API or executing complicated logic, the test suite runs the code you wrote inside your test instead. You “mock” the behavior of the complicated code and configure your tests to run that code instead.

Types of mock services

There are a few different common use cases for mock services. The same basic concept applies regardless of what you’re mocking, but how you approach the mock service changes based on what you’re mocking. Let’s talk about the most common types and how they differ from each other.

External dependencies

We’ve talked about this kind of mock service previously, and this is the most common type. As we’ve discussed, you don’t want to make your tests reliant on dependencies that exist outside your code, and you don’t want your tests to cause negative outcomes on production systems. While you don’t want to ignore the importance of API testing in general, your code base shouldn’t be testing the API for other services.

Complicated dependencies

This is another common type of dependency to mock for tests. These dependencies aren’t external to your application, so you do control how you use them. You’re not mocking these services because it’s not your job to test them. Instead, you’re mocking them because they’re difficult to set up correctly within your test suite. A classic example of services with complicated dependencies is controller objects in MVC web development frameworks. These objects usually perform all sorts of peripheral functions that require configuration. They connect to databases, handle network traffic, and authenticate users. Most of those are things that you don’t want to explicitly test during unit or functional tests. Those are all classical places where a mock service will serve you well.

Mock services serve crucial roles in all three critical goals for our tests: they help make our tests simpler, more effective, and cover more code

Benefits of mock services

Mock services serve crucial roles in all three critical goals for our tests: they help make our tests simpler, more effective, and cover more code. Let’s walk through each goal and break down how mock services serve that goal.

Simpler

Mock services simplify your testing suites by eliminating complicated setup code in your test files. This is especially helpful when you’re trying to set up misconfigured or misbehaving services to test how your code responds to those. You don’t need to hunt for the exact right configuration that will both run your tests and provide the correct error behavior. Instead, you can simply provide a mock service that implements the exact behavior you want to test, and then utilize it for the tests that need it.

More effective

Effectiveness in software testing is a measurement of how well you test all the behaviors of a specific piece of code, like an object or function, and how well you test only the behaviors of that piece of code. As previously mentioned, you don’t want your tests for a controller to also test your authentication and authorization and network handling code. While you should test those systems individually, you don’t want to make your controller tests dependent on the tests for those systems. If your authentication system has a bug that’s causing a test to fail, that failure should manifest in the authentication system tests. This simplifies the debugging process when your code regresses.

Coverage

The final axis for evaluating the quality of our tests is coverage. Coverage is often the first metric that people turn to when evaluating test suites. Coverage is a pretty effective top-line metric because it serves as an approximate merger of the axes of simplicity and effectiveness. The definition of coverage is simple: how many lines of code in a file you’re testing are actually executed as part of the test suite for that file.

It’s important to understand that while coverage is a key part of your test efficacy metrics, it doesn’t tell the whole story. For instance, if you write a test that executes a particular branch of your code base without actually asserting any expected behaviors, you would have good coverage but low effectiveness.

Challenges/limitations of using mock services

The biggest challenge in using mock services within your tests is that you’re hiding the behaviors of the services that you’re mocking from your tests. For instance, if you mock a networked API call to return a specific result, your tests degrade in effectiveness if the provider of that API changes the behavior or interface they present to you. The purpose of a mock service is to fully hide the underlying behavior of the real-world code that your testing suite relies on, and that’s a double-edged sword.

A second major challenge is that overreliance on mock services may cause teams to avoid more comprehensive tests like integration tests. Mock tests can make teams overconfident in things like unit tests as the full measure of a system’s reliability.

How to implement mock services

If you’re thinking about adopting mock services for your test suites, the best first step is to research what options are supported by your current language and testing framework. One very common mistake made by developers looking to adopt mock services is that they feel like they need to seek out a dedicated library to support mocking test behaviors. That’s not true. The point of mock services is that they’re supposed to make your code simpler. Integrating a whole new library might be overkill if all you need is to provide a basic facade for a couple of simple APIs.

From there, the second best piece of advice is to experiment with what’s on offer. The best way to get better at writing tests is to write lots of tests, and the more you use mock services in your code, the better you’ll use them in the future.

Mock services are a great tool to apply where they make sense, and when you don’t need them, you never need to pick them up at all

Use mock services to make your tests simpler, more effective, and cover more

In this post, we’ve broken down how mock services improve your tests on all three major axes. If you’re thinking about adopting mock services for your tests, you should know that you’re not required to go all out from the start. Mock services are a great tool to apply where they make sense, and when you don’t need them, you never need to pick them up at all. So if you’re not sure, you can try them out in the places where you think they’ll be the most helpful, and evaluate how much they help your particular code base from there. The most important thing is to keep writing good tests for your code whenever you can.

This post was written by Eric Boersma. Eric is a software developer and development manager who’s done everything from IT security in pharmaceuticals to writing intelligence software for the US government to building international development teams for non-profits. He loves to talk about the things he’s learned along the way, and he enjoys listening to and learning from others as well.