Weird title, but it'll get clear by the end of the post, I promise!

Mocking is something that is associated with developers more than it is with testers, especially if one is dealing with Unit Tests.

That is not to say that testers don't use it. Mocking is helpful when testers have API specifications but don't have the actual API itself and they have to develop API Automation (because Agile).

In my current project, we are migrating over a legacy ticketing platform (standard .NET stuff & a lot of confused applications) to a new platform comprised of a SaaS based Incident Management system that is supported by multiple "new" microservices with every new age technology stuffed into the architecture somehow (I could fill up a couple of blog posts with snark aimed at the overall thinking in doing something like this, but I digress. Maybe later).

So, the overall system when tested for performance (by yours truly) was doing extremely poor in terms of the lofty expectations set by people who were good at setting expectations :)

So a few "war" rooms with much yelling and panicky reactions, the performance issue was narrowed down to some faulty API calls that were setting databases on fire in the third party ticketing system (imagine 30-40 second response times on good calls and 62 seconds about 70% of the times, where the expected value was sub-second). Perfectly legal, good API calls, mind you. This in turn dragged down the performance of our "victim" microservice to abysmal levels.

After much wringing of hands, late night builds & some more panicked conference calls, we ran performance tests that absolved the Third Party SaaS Incident Management System of any wrongdoing. This caused a lot of frayed tempers to be soothed and the hand-wringing moved down to just twitching of fingers. What it did though was give us pause to think.

What was the actual throughput of our "victim" service?

Now that we knew that the service's performance was tied to how the SaaS API performed, will we ever know its true performance given how flaky the API was turning out to be?

We decided to setup a performance lab, abstract out the rest of the stuff and just keep the microservice, its common infra and have a mock do the work of the SaaS API.

And that is how we gave birth to our MockingBird - thats what I call the mock API that I built.

The next post will be about how exactly that was accomplished.