`toSatisfyApiSpec` lacks functionality to handle "overlapping" endpoint definitions

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:

Implement a server which serves the above spec
Get response: let res = await request({ host: '...', method: 'GET', path: '/a/k/b' });
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?

openapi-library / OpenAPIValidators

`toSatisfyApiSpec` lacks functionality to handle "overlapping" endpoint definitions #295