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 testing something that you wouldn't even dream of doing on the system you're working on? performance If any of the above questions apply to your reality, and I may have a solution to your problems. Henrique Souza Do you know how we usually create for unit and integration tests, when we don't really want to test a specific part of the application? , or mocks stubs spies 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 . 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. Mountebank Mountebank 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. First things first: Mountebank. You can also install it using: install 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' --data '{"port": 6569,"protocol": "http","name": "proxyOnce","stubs": [{"responses": [{"proxy": {"to": " ","mode": "proxyOnce","predicateGenerators": [{"matches": {"method": true,"path": true,"query": true,"body": true}}]}}]}]}' http://127.0.0.1:2525/imposters http://localhost:8080 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 ), use , define the actual service's address ( ) and say that the stubbed requests should match method, path, query and body to return the stored result. For more information, . proxyOnce http http://localhost:8080 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! :) is how hackers start their afternoons. We’re a part of the family. We are now and happy to opportunities. Hacker Noon @AMI accepting submissions discuss advertising &sponsorship To learn more, , , or simply, read our about page like/message us on Facebook tweet/DM @HackerNoon. If you enjoyed this story, we recommend reading our and . Until next time, don’t take the realities of the world for granted! latest tech stories trending tech stories
