Mocks vs Real Objects: changing perspectives
Test the functionality, not the direct output of self-defined dependencies
Disclaimer: I am a Mockist at heart, not Classical, I care about system behaviour more than specific returned data. Understand the differences here and sit tight because this is a nuanced one.
First things first, let’s define some terms here:
Mocks – Loosely speaking, the term is used in this article to mean anything that isn’t real data or objects.
Real (.*) – Fragments that return real data in the system.
Admittedly, I caught myself doing what I’m about to call out (but corrected myself swiftly). This is because when testing at any level, but more so at integration or above, mocking objects becomes more tricky as there are more moving parts. This can confuse the objective of the test.
When people talk about mocks (or test doubles), it’s usually in the context of unit tests. This is where they’re mostly used but that’s not the whole story.
Mike Cohn’s original (and now slightly outdated) concept of The Test Pyramid is a good visual aid for the next section:
Unit Tests
Should be deterministic so you supply test data, behaviour driven testing is the aim here – testing mocked data being returned wouldn’t make much sense.
Integration Tests
Depending on how you define this i.e. backend integration with API testing or component/service-to-service testing can have mocked dependencies too.
I hear some saying that integration testing and mocks don’t go in the same sentence. Well how would they deal with an integration test which depends on the response of an external service? You mock the response. Okay, strictly speaking, you stub in out.
This example of doing an integration test via mock calls to our own test endpoints to simulate calling an external API directly is an appropriate use case for a mock at this tier.
Health check: are you testing the endpoint responses or the stubbed JSON (third party or locally stored) responses?
System/UI Tests
Data is tested as it’s pulled from the A/SUT (application/system under test) and matched against expected values.
Mocking objects for testing needs to be done properly to make testing hermetic. This is the process of minimising test flakiness to remove dependencies that, if not handled correctly, can interrupt the test execution.
However, there’s a balance to be had, overuse of mocking can occur in a way where you’re actually testing the mocks rather than testing the actual functionality. Mockist, at this point, start to isolate their testing efforts until it’s completely void of context.
As I briefly touched on earlier, testing the data, in many ways, can show that the functionality is working in terms of expected and actual outcomes. But this becomes somewhat redundant when the data being verified is coming from the same source i.e. mocking data in a test and verifying it in that very same test. Rather than getting data from an A/SUT and matching it against local values.
Testing the functionality is different to testing the data when mocking so we don’t need to care about what exactly is in there.
What we should care about is that this performs the function correctly hence why we can replace the real data with dummy data.
We are passing in temporary values and stubs to enable us to see whether the responses are what they should be — not the data output but the true or false responses from the functions.
For instance, in Android automation, we can use libraries to mock HTTP requests and in those instances testing the UI with mocked responses is good because it’s simulating the API calls in a controlled environment but at the same time if those requests are malformed then you won’t be able to build the UI at all so it works out better.
Hopefully, I’ve explained myself clearly. If you have comments or questions, let’s discuss more on Twitter!
Signing out,
Will.
