At a certain point in my career I was tasked with maintaining an Angular 1.x app that was a tangled mess of technical debt. The core issue with it wasn't even strictly technical - over the three years since it's been in development there was so much staff rotation, that most of the code was written by people who were assigned to this project only briefly, and then left the company.

On top of that some bugs required an elaborate procedure to reproduce. One could of course play around with database dumps and re-create the desired state in the testing environment, but that would quickly become tedious. Running the backend locally was also an option, although not overly desirable, since that would slow my laptop down considerably.

I needed a simple and convenient way to reproduce issues. This called for a mock backend, but the ones that usually filled this role lacked one crucial feature, namely the ability to serve responses to a given request in sequence - something required in certain scenarios.

The problem at hand

To illustrate the problem: say we have an authentication system based on JWT. When the access token expires, a login request is made to obtain a new one. Given that the app is what it is, when the token is expired there may occur a race condition which breaks the whole thing to the point of requiring a logout. To make matters worse this bug occurs in a place unreachable directly via URL, so in order to reproduce it again one has to go over all the elaborate steps that originally led to it.

In this case a static mock backend isn't of much help, because it can only serve one specific response to a given request. Ok, but how does one work around this problem short of using the actual backend?

The solution

I knew that I could count on the test team to provide me any kind of log I wished for (within reason), so I asked them to include, apart from the standard video clip reproducing the issue, the associated HAR file.

Having all this data I only needed to serve it, so over a weekend I wrote a simple server that would replay backend responses in the order they came, grouped by request URL. This helped me tremendously, as I only needed to take the exact same steps as the tester to reproduce most if not all bugs - especially those which were the result of a sequence of steps.

Unfortunately my little tool didn't survive past my resignation from that company since it only existed on my work laptop.

Re-implentation

No matter though, because recently I figured I would rewrite it from scratch to handle situations where the backend environment doesn't respond or its database is wiped clean during a nightly build.

Introducing Emergency Poncho - a HTTP Archive replayer for your backend's rainy days. While it's still at a very early stage of development and not really production-ready, it has already proved useful in a number of situations.

I have a few ideas how to expand its functionality and once I'm done with implementing them I'm planning on publishing this as an npm module.