This PR improves exception handling int spectator code base, especially in the tests.
All decisions I made can be discussed and revert as needed
What is done and why :
Tests are now run withoutExceptionHandling which allows us to be informed of internal issues during the request, especially during request and response validation in the middleware. Without that, any error occurring there will be catched by the exception handler and transformed to a 500 response. The error can be hidden if the assertion made is an assertInvalidResponse for example. The tests requiring Laravel to handle some exceptions (ValidationException for example) explicitly exclude the exception during setup.
InvalidPathException, MalformedSpecException, MissingSpecException, TypeErrorException, UnresolvableReferenceException are now set in captureResponseValidation($exception). This way, a test like
will now fail. Previously, it passed because no exception was set in responseException.
assertInvalidRequest and assertInvalidResponse now require the specification to exist, to be well formatted and the route to exist. IMO, if the developer wants to check that a request is invalid accordingly to the openapi contract, they will want to know that some of the setup they did is not correct : invalid openapi, missing route, ...
content-type resolution was buggy and now fixed (the exception was hidden by the fact that the tests were run with laravel exception handling)
This PR improves exception handling int spectator code base, especially in the tests.
All decisions I made can be discussed and revert as needed
What is done and why :
withoutExceptionHandling
which allows us to be informed of internal issues during the request, especially during request and response validation in the middleware. Without that, any error occurring there will be catched by the exception handler and transformed to a 500 response. The error can be hidden if the assertion made is anassertInvalidResponse
for example. The tests requiring Laravel to handle some exceptions (ValidationException for example) explicitly exclude the exception during setup.captureResponseValidation($exception)
. This way, a test likewill now fail. Previously, it passed because no exception was set in
responseException
.assertInvalidRequest
andassertInvalidResponse
now require the specification to exist, to be well formatted and the route to exist. IMO, if the developer wants to check that a request is invalid accordingly to the openapi contract, they will want to know that some of the setup they did is not correct : invalid openapi, missing route, ...