Mocks and testability

Most of the times, when we develop software, we rely on third party services to accomplish a certain outcome so that we don’t have to re-invent the wheel. However, this introduces a new level of complexity, especially around testability.

This post is based on a presentation I gave at the “Ministry of testing - Auckland” meetup. Mocking isn’t new, and there are lots of articles on the internet about it, but it is less frequent to see content about mocks in the context of a system testing or end to end testing. Hence, I am grateful for the opportunity to share my learnings about the topic.

I got the chance to learn and implement this technique from the team I was working with at ClearPoint, so I’d like to take this opportunity to thank them for always finding and implementing the best practices to deliver high quality software.

This post will be structured as follows:

• Some of the software integration problems (productivity + testability)
• List a few mocking tools - explanation about mockserver, which we will use
• Demo (implementation of mockserver as a “replacement” of an external system) — You can directly skip to this part if you are looking for the technical implementation only
• A few ideas (not new) about E2E

Let’s start…

Some software integration problems

• Teams build software in parallel, and usually there are dependencies between these systems, whether they’re all developed internally or by another company

Should we wait for the other team to finish their implementation, so that we start with the implementation of our system? this might not be an acceptable solution for the company, as software takes months and years to be delivered, and the companies would want to have extra delay and expenses.

should we ask the other teams to prioritize the implementation of our software dependency? What if that was not possible? The third party could have other clients that have a higher priority than our integration…

• Sometimes the systems we’re depending on are already in a working state. However, we might find that the systems’ APIs are rate limited, or slow, or possibly have defects.

We definitely must try to avoid exceeding the rate limit, as this would cost money (when testing or debugging an API, it’s very…