Mocking APIs Made Easy with Mockaco

Transcript

External APIs can be annoying to write integration tests against. Let's take a look at how to mock out these external dependencies using Mockaco so we can write more robust integration tests. Mockaco is an HTTP server that can respond to requests either with a completely static response or a partially dynamic response. To do this, Mockaco uses JSON files to map a request to a response. It also runs as a container, so we can use Testcontainers to spin this up in our tests and make them more robust.

Let's take a quick look around the project before I show you three of my favorite features with Mockaco. Here I've simulated two different external dependencies: a simple Weather Service and a simple ping-pong service. Looking at our ping-pong service, I have two different tests, one for the successful path and another for the unsuccessful path. Both pass and verify the results using the amazing Verify library. This mimics the setup that I would normally have in my integration tests.

For all the magic, I've got a Mockaco container abstract base class that does the heavy lifting with Testcontainers. This helps it to start and stop the container at the right time. This includes loading the request and response files from disk based on the parameter in the constructor. If you want to see a more detailed version of how to set up Testcontainers, I recently did a video on how to set up Testcontainers with xUnit and LocalStack. You can find this somewhere up here or in the description down below.

The Ping service container itself is an implementation of our Mockaco container class that loads the request and response files from the Ping folder on disk. We have a similar setup for the Weather Service tests, just to prove that we can run multiple instances at once with a different API response. There's only one real thing that we need to pay attention to here with Mockaco, and this is the fact that there is potentially a timing issue between the startup of Mockaco and when the scripts are ready for consumption. The simple fix for this is to add a delay to the container startup like I have here.

So let's break down one of these JSON files and see what we can do with them. As a minimum, each file is a JSON object that contains two child objects: a request object and a response object. The request object is responsible for matching an incoming request to a corresponding response. Here we can set up the HTTP method and the route the request will be made to. The route can be templated with any valid ASP.

NET route template, so our tests can vary by ID for example. The response object is where we set the response that we want to give back to the requester. Here we can set things like the status code, response body, and how long the request should take. The response body may also contain some small scripted sections, which we'll look at in the next section.

So let's take a look at my three favorite features of Mockaco. First up, we have Bogus data. If you've not heard of Bogus before, it's a great library for generating realistic data for your entities. To use it, we create a scripted section that then calls the right method on Bogus. So for example, we can pick a random item from a list using Faker.PickRandom. The built-in Faker can also generate localized data so long as we set the accept language header.

My next favorite feature is setting conditions on requests. Inside of a request object, we can set the condition property and then use the built-in scripting functionality to determine whether Mockaco should process the request. For example, we may want to use details inside of the request to determine whether or not we want to process it.

And the last feature I'm going to show you today is the callback system. Alongside the request and response object, we can define a new one called callback. When the request is matched, Mockaco takes the callback section and sends a new request to the endpoint that you defined. This includes the standard bells and whistles like headers and request body. We can also simulate a webhook style system by setting the delay parameter of the callback.

So if you're still curious about that Testcontainers setup, click the video that's on screen now and watch me go through a detailed version of setting up Testcontainers with LocalStack utilizing seed data.

If you enjoyed this video, consider subscribing to the YouTube channel for more content like this.