Allow intercepting only specified requests

[ianwsperber]

As a developer, I would like to be able to intercept only specified network requests.

Today YesNo takes an "all or nothing" approach to HTTP interception. Such an approach works well in a context where all outbound HTTP requests are deterministic and bounded. However if the numbers of requests is unknown or the requests may occur in an unknown order, this approach breaks down when we attempt to use mocks. Consider the below example:

const itRecorded = yesno.test({ it, dir: `${__dirname}/mocks` });

itRecorded('should make at least 1 request to Formidable', () => {
  await myApi.getUsers();

  expect(yesno.matching(/formidable/).intercepted().length). toBeGreaterThanOrEqual(1);
});

In this test, all we care is that at least 1 request was made to formidable. This works fine when spying on requests. However when running against mocks, the test will fail if the requests made by getUsers do not not match the mocks, which could happen either because:

1. The number of requests made exceed the number of mocks
2. The requests made occur in a different order than the mocks

There are 2 solutions I'm considering for this use case, the first of which is the subject of this issue:

1. Allow specifying what specific requests you wish to intercept using matching().
2. Add some sort of "smart" mode to mocking, where YesNo will attempt to find a best match from your mocks, regardless of order.

For the first, I'd propose adding roughly the following functionality to the YesNo API:

it('should make at least 1 request to Formidable', () => {
  // Order determines precedence; requests to formidable match first, everything else matches second
  yesno.matching(/formidable/).mock({ statusCode: 200, body: { foo: 'bar' }  });
  // Allow providing a function to drive the response off the request
  yesno.matching().mock((request) => 
    request.header['x-fizbaz'] ? { statusCode: 500 } : { statusCode: 200, body: { fiz: 'baz' } }); 

  await myApi.getUsers();

  expect(yesno.matching(/formidable/).intercepted().length). toBeGreaterThanOrEqual(1);
});

Note that this essentially adds the core functionality of nock, which is to provide a mock response for a specified path. To further allow providing a custom response, it may make sense to

I believe this should greatly increase the usability of the library for those new to this testing approach, and will make it easier to recommend this library over nock. I believe @samwhale encountered a use case for this recently and may be able to weigh on whether it'd address his need.

[keithcom]

@ianwsperber was this issue addressed with #66 or is there still something that needs to be done? Can you explain the remaining tasks if there are any?

[ianwsperber]

Hey @keithcom! I believe this issue was resolved by #66, it just needs to be documented at this point :)