Mocking of http requests

[alexander-veit]

Description

What was changed in this pull request?

This PR enables the automatic mocking of http requests made during running the tests. Instead of going to the server (defined in the view config of a test), we are now looking first if the data already exists in 'test/mocked-responses'. If it does exists, we take the data from there and don't request it from the server. If the data is not there, we make the original http request and store the received data in a file. Therefore, the actual http request should always only happen on the local machine. Travis should always have persisted data and does no longer depend on the availability of a server.

This also enables the use of artificial test data that only exists on a local server.

The procedure of adding new tests and view configs will not change. We can just add view configs as usual. Storing the data in local files and using the data from there happens automatically.

Note, that this PR activates the request mocking only for the DenseDataExtremaTests. Other (or new) tests can be added on an as-needed basis.

Why is it necessary?

To make the tests more resilient.

Fixes #___

Checklist

• Set proper GitHub labels (e.g. v1.6+, ignore if you don't know)
• Unit tests added or updated
• Documentation added or updated
• Example(s) added or updated
• Update schema.json if there are changes to the viewconf JSON structure format
• Screenshot for visual changes (e.g. new tracks or UI changes)
• Updated CHANGELOG.md

[alexander-veit]

I tried activating this for all tests, but ran into issues with the HiGlassComponentTests. There seem to be strange sync/async issues that result from loading tiles from the file system. Therefore I only activated this for the DenseDataExtremaTest for now. I still think it is useful to provide the functionality especially for new tests. It is more automatic than the local tile fetcher and mocks all http requests (not only the tile data).

[alexpreynolds]

If I wanted to write a mock test for, say, a plug-in to render a bigBed file, what would be the most relevant parts of the code to look at?

[alexander-veit]

You can have a look here how existing tests have to be modified:
https://github.com/higlass/higlass/pull/917/files#diff-e9a48450c1b0320e5fc850428a633470
Basically you have to activate the FetchMockHelper in the beforeAll function and store the mocked responses in afterAll. I assume you want to serve your data from a local Higlass server? Then, this should be all you have to do.
Does this answer your question?

[alexpreynolds]

The idea is to make a bigBed renderer available in a future version of the official higlass plugin, using a dataset served from a public S3 bucket (https://areynolds.s3.amazonaws.com/public/masterlist_DHSs_733samples_WM20180608_all_mean_signal_colorsMax.bed.bb). A test would point to this dataset and compare the tile data that comes back with what is expected.

The bigBed renderer is written, but the tests are the last piece needed to complete the PR (#805).

[alexander-veit]

I see. The FetchMockHelper doesn't care where the http request points to. Loading (and persisting data) from a S3 bucket shouldn't be a problem.