MockRequests

Inspiration

The company I work at has regular intervals where the test environment is down (for builds, updates, etc.) which significantly reduced the ability to work on front-end development. Because of this, I wanted some way to use mock data for network requests, but all available solutions were either really complex (e.g. configuring and running a local server) or involved changing the source code (e.g. replacing fetch(url, options) with return Promise.resolve(mockData);). Since these options weren't sustainable nor easy to use, I made a new network-mocking system that wouldn't require any complex setup or changing source code.

What it does

MockRequests wraps XMLHttpRequest and fetch such that any URL requested will return the specified mock data instead of attempting to make a network call. It is made in such a way that allows mixing actual network requests with mock data, so if you configure a URL with a mock response, it'll return the mock, but if you don't configure a URL with a mock response, it'll make the standard network request; this way, if only some endpoints are down but others are running properly, you can mock only the broken APIs but call the others as normal. It was intentionally made to be simple, user-friendly, to not require any source code changes, and to work alongside third party libraries (e.g. Axios).

How I built it

The library was built in plain JavaScript with 0 dependencies. After analyzing the internal workings of fetch() and XMLHttpRequest, I made MockRequests wrap both such that they function normally for URLs that aren't mocked but return the desired mock responses for URLs that are mocked along with the proper field updates, headers, etc. to mimic normal network responses.

Challenges I ran into

The most difficult part of making the library was analyzing the internal workings of fetch() and XMLHttpRequest and ensuring the mocked requests behave in the same way. Since each one has its own way of showing that a network request has completed, that it was successful, and returning the network response, I had to scrupulously write the mocking system to match exactly what would be returned upon a successful network call.

Accomplishments that I'm proud of

This library worked perfectly with both Axios and the company-wide network request wrapper. After simply installing mock-requests and adding a single config.js file, multiple teams within the company were able to circumvent the common test environment network outages and continue front-end development regardless of the network conditions. Since the original release, I was also able to add multiple additional features, such as dynamic mock responses (to mimic the back-end modifications of data) and query parameter mappings (so that all requests made to the same pathname would return a dynamic mock response specified by the user based on the parameters).

What I learned

I learned many things during the creation of this library, including the specifics of how fetch() and XMLHttpRequest work, babel/webpack configurations to afford cross-browser functionality, how to parse options when running the front-end app (e.g. MOCK=true npm start), how to write jest tests for libraries (as opposed to apps), how to publish packages to npm, and how to work with CI systems to display the build/test coverage statuses for each push/pull request.

What's next for MockRequests

I continuously add minor tweaks in the library that go a long way. Most recently, I added a typings.d.ts file to allow for IDE auto-completion, and made the library work with both complete library/default imports (import MockRequests from 'mock-requests';) and individual field imports (import { configure } from 'mock-requests';). Next, I plan to add new features such as allowing the configuring of failed network requests (e.g. mocking when a network request returns a 500 error) and adding a script that runs MockRequests without the need to change the webpack.config.js file manually.

Built With

• javascript