We should refactor the test to mock retrieve and introduce an integration test for retrieve that asserts the correct url is being created in combination with https://httpbin.org/
Note that sinon would not support mocking retrieve as is because we are exporting a function rather than an object. https://github.com/testdouble/testdouble.js (TD) supports mocking local imports, which would allow us to get around the problem of not being able to export functions and mock them in tests.
However, I gave a cursory attempt to refactor pixabay-spec using TD and ran into issues (which may be due to my inexperience with the lib).
How to refactor this? TD doesn't allow partial mocks, and the point of the test is to assert that the correct url is being used. Is the test itself flawed in design? Maybe it would be better to assert that the ResultList's properties (which are private) have the correct url. Maybe the test shouldn't exist at all. I tried mocking the client except for the function under test as well as mocking the ResultList constructor. The latter seems like a dead end due to https://github.com/testdouble/testdouble.js/issues/54.
While result-list-spec is a good test file, it is wrongly mocking the underlying XHR responses via Mockagent rather than mocking the in-lib boundary [retrieve[(https://github.com/yola/pixabayjs/blob/6f8e22aa36209204f33bf2cfadb1b28d37e7c3bb/src/retrieve.js).
We should refactor the test to mock retrieve and introduce an integration test for retrieve that asserts the correct url is being created in combination with https://httpbin.org/
Note that sinon would not support mocking retrieve as is because we are exporting a function rather than an object. https://github.com/testdouble/testdouble.js (TD) supports mocking local imports, which would allow us to get around the problem of not being able to export functions and mock them in tests.
However, I gave a cursory attempt to refactor pixabay-spec using TD and ran into issues (which may be due to my inexperience with the lib).
How to refactor this? TD doesn't allow partial mocks, and the point of the test is to assert that the correct url is being used. Is the test itself flawed in design? Maybe it would be better to assert that the ResultList's properties (which are private) have the correct url. Maybe the test shouldn't exist at all. I tried mocking the client except for the function under test as well as mocking the ResultList constructor. The latter seems like a dead end due to https://github.com/testdouble/testdouble.js/issues/54.