Using Mountebank to stub external dependencies: step by step.

Are you in a project where you deal with a lot of data fixtures?

Is it hard to test your applications flows because they depend on a lot of different external resources?

Are your structures complex enough that creating sample data is out of the question, either because it's too hard or because the fake data does not represent actual data?

Is performance testing something that you wouldn't even dream of doing on the system you're working on?

If any of the above questions apply to your reality, Henrique Souza and I may have a solution to your problems.

Do you know how we usually create mocks, stubs or spies for unit and integration tests, when we don't really want to test a specific part of the application?

There are tools out there that can do the same for external resources. In our reality, we wanted to test our system's performance without taking into consideration the time it took for external resources to return data. We wanted the test to represent an actual flow of the system, with actual data — so we don't make the mistake of testing the performance of something that is extremely simple, or so complex that would never happen in a real scenario.

For those reasons, we started taking a look at Mountebank. Mountebank is an open source tool that helps you get actual response data from actual external services, store them and start a service that replicates the external resources' endpoints returning the response data that it stored in the first place.

We created the following step-by-step tutorial to demo a simple example of this process, mainly because we found out that every time we had to explain it to new developers, we had to relearn everything from scratch — and there are not a lot of simple and complete examples in Mountebank's web page.

1. First things first: install Mountebank. You can also install it using:

npm install -g mountebank

2. Start Mountebank. (./mb at mountebank folder is fine)

3. In this example, we are deploying the external resource locally. If you have it deployed somewhere else, you can skip this step.

4. Create an impostor, like this one:

curl -i -X POST -H 'Content-Type: application/json' http://127.0.0.1:2525/imposters --data '{
  "port": 6569,
  "protocol": "http",
  "name": "proxyOnce",
  "stubs": [
    {
      "responses": [
        {
          "proxy": {
            "to": "http://localhost:8080",
            "mode": "proxyOnce",
            "predicateGenerators": [
              {
                "matches": {
                  "method": true,
                  "path": true,
                  "query": true,
                  "body": true
                }
              }
            ]
          }
        }
      ]
    }
  ]
}'

You can modify the example as you need it, just make sure that mountebank port (default 2525) and the port that will proxy (in this case, 6569) is correct.
The others options are to proxy only the first request (mode proxyOnce), use http, define the actual service's address (http://localhost:8080) and say that the stubbed requests should match method, path, query and body to return the stored result. For more information, they have a documentation on this matter.

5. Do the requests you want to stub at port 6569, and it will redirect to your 8080 in the first time.

6. Now that you have your stubbed requests, if you are running the external service locally, you can stop it and check that Mountebank is still returning data for the requests you stubbed.

7. To be able to reuse the requests you stubbed, all you have to do is tell mountebank to store them in a file. This should be done with mountebank still running.

mb save --savefile impostorsPopulated.json

8. Now you can replicate these states whenever you want, by restarting mountebank with the file you saved.

mb --configfile impostorsPopulated.json

With this approach, we were able to run performance tests for our back-end and, with little twitches, for our front-end as well, and we hope you can benefit from it too!

Was this article helpful? Did we miss anything? Let us know! :)

Hacker Noon is how hackers start their afternoons. We’re a part of the @AMIfamily. We are now accepting submissions and happy to discuss advertising &sponsorship opportunities.

To learn more, read our about page, like/message us on Facebook, or simply, tweet/DM @HackerNoon.

If you enjoyed this story, we recommend reading our latest tech stories and trending tech stories. Until next time, don’t take the realities of the world for granted!