There we go again. I couldn’t help but to (re)write my own. Unlike my previous attempt, I managed to keep implementation neat and tidy with a solid test coverage. Since all the details are on the project page, I will only focus on a few quick highlights.
Dependencies on 3rd party APIs can have a serious impact on productivity. Downtimes, lack of representative data etc. You know how it goes. Quite some time ago I came across an interesting post on coderwall.
I was astonished to find out how much can be achieved with just a few lines of code. Before long I found myself writing a tool of my very own. And it worked. I was using it in my job for a while and it was of a great help, especially when it came to test automation. But eventually, I felt the cost of maintenance was too high for what I was getting in turn.
Ultimately I decided to drop it and start from scratch. As I tend to overcommit, I set myself a fixed deadline restricting the overall effort to a single week (5 days, no cheating).
I ended up with an implementation comprising an entry point, two modules and a utility class. The largest of these items doesn’t take much more than 100 lines of code, whereas the rest fits within 50 – 80 lines. And that all includes imports, formatting and comments.
It’s fair to admit that the range of features is a bit limited, but definitely not smaller than in the previous case. I surely do have plans to add more on the stack, but let’s see what I have got so far.
- Ability to capture, easily modify and replay API responses.
- Nicely organised data with relatively short file names for a high level of distinction among similar requests.
- Ability to replay the responses along with the original status code and headers. Unless, of course, I go and change whatever I feel like.
- POSTs and PUTs uniquely distinguished by their body content. Simply put, URL-encoded form params are turned into a query string, which then takes a substantial part of the resulting file name.
- A very straightforward configuration.
Here are some of the features I am thinking to add in the near future:
- Enhance the API calls interceptor with regular expressions.
- Possibility to play a group of relevant responses in an endless loop. This might be useful for simulation of live data (WebSockets, long polling etc.).
- Ability to work around changing request values, such as a one-time security token.
If I was to change anything I would probably try to reduce a number of dependencies on other npm modules. Just to make the installation a bit smoother.
That’s about it, I hope you found this post inspirational. If that’s not the case, well, then thanks for reading it anyway and have a Happy New Year!
My project is called scrapit. I know it’s not the best name, but all the great names addressing API, mock or scrub seem to have been taken (surprise, surprise).
Check it out on github, feedback highly appreciated.