Prologue https://dev.to/mikotian/to-birth-a-mockingbird-ep8
I began researching mocking tools and found one that seemed quick enough for my needs.
Mockoon[https://mockoon.com/] was a nice little gui based tool that I had heard of before and without giving it much thought, I started implementing my little mockingbird.
The good part about Mockoon:
*Its fairly simple to start with. Anybody who has used Postman will find this to be intuitive and easy to understand.
*You can have multiple apis running in parallel on your chosen ports
the ability to define multiple responses based on what is the incoming payload
*https support out of the box, if you need it
*Very very good templating support (e.g. generating unique ids for fields)
*Latency Simulation (this was the number 1 requirement I had)
*latency simulation on a per endpoint basis as well (this is cumulative over base path latency)
The dealbreaker(s):
*It is a localhost only application (so no intranet exposure, at least I wasn't able to get that to work)
*No commandline or gui-less invocation, so would not work on no-desktop environments without major tinkering (one way could be x11 forwarding, perhaps)
Some Screenshots from my experiment
I could simulate every API endpoint I wanted to mock and it worked flawlessly for me, except for the intranet part. Might be interesting for Devs who want to mock complex API behavior.
So I had to think of something else.
Having worked on Python for a while, and had always wanted to write an API using it. I had researched a bit on flask back in the day but had never quite got around to using it. This was my chance.
And it turned out to be quite easy.
I used the standard python installation on an AWS installation to run the following code:
It is pretty boilerplate stuff except for a few things:
*In order to introduce some latency in the responses, I used time.sleep() before sending the response
*Used the inbuilt support for json to manipulate json objects.
*Used uuid to generate a couple of different types of guids (learnt about the library too along the way!)
The instance I used to host this was a AWS t2.micro instance with 1 vCPU and 1 GB of RAM.
It was exposed on the standard 5000 port that flask uses and I decided not to use https since that would have increased setup time on the many instances of the producing microservice.
In order to expose it to the internal network, I used 0.0.0.0 as the address which means that the program will listen to all binded IPs for the machine.
There is good support for debugging in flask as well and that requires us to set the debug flag while starting the service/application.
The command I used to start the application was a fairly straightforward one:
python mockingbird.py
The application worked wonderfully for our purposes. It was giving the correct responses with the desired latency and it looked like it was absorbing all the load as well. A couple of load tests went well with parameters showing to be on expected lines.
But as it is in the world of Software Development (and especially in the world of Software Testing), the first version is never quite the finished project.
In the next post, I'll recount/explain how i killed the mockingbird (and what I did to fix it)
Top comments (0)