toSatisfyApiSpec lacks functionality to handle "overlapping" endpoint definitions

[GershyRbi]

Are you using jest or chai?

Jest

Are you using OpenAPI 2, 3.0.X, or 3.1.0?

3.0.0

Describe the bug clearly

Consider this yaml schema:

openapi: 3.0.0

...

paths:
  /a/{x}/b:
    get:
      ...
  /a/{x}/{y}:
    post:
      ...

This is a tricky schema; a client request for /a/k/b could arguably correspond to either of the of the paths - the server needs an explicit rule ensuring /a/k/b is handled by /a/{x}/b. Unfortunately toSatisfyApiSpec fails for GET /a/k/b, saying the endpoint shouldn't support GET, because it thinks /a/k/b corresponds to /a/{x}/{y}, which only supports POST.

Steps to reproduce the bug:

1. Implement a server which serves the above spec
2. Get response: let res = await request({ host: '...', method: 'GET', path: '/a/k/b' });
3. Perform expect(res).toSatisfyApiSpec()

This causes toSatisfyApiSpec to fail, saying GET is not a supported method.

What did you expect to happen instead?

I expected toSatisfyApiSpec to succeed, as GET /a/k/b is supported under the /a/{x}/b path.

Perhaps toSatisfyApiSpec could, after trying and failing for the /a/{x}/{y} endpoint, look for any additional paths which also match the path for res. In this case it would find /a/{x}/b, which supports GET.

Or another possibility may be to allow toSatisfyApiSpec to be further qualified with an explicit path:

expect(res).toSatisfyApiSpec({ specificPath: '/a/{x}/b' });

Are you going to resolve the issue?

No

[GershyRbi]

Woops - duplicate of #164