[9.x] Allow forcing requests made via the Http client to be faked #42230
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Purpose
This PR aims to bring the ability for developers to force any requests made via the Http client to be faked. If a request is not faked, an exception will be thrown.
Why this feature is useful
This feature it useful really only in a test suite.
I've often wanted the ability to throw an exception when a request made via the Http client was not faked. This serves as a high fidelity signal to the developer that they have missed something.
I've seen it be common place in a test suite that real requests are still being made to services that should have been faked. I'm sure I've been guilty of this myself on more than one occasion.
These are often only detected when then service API is down, you hit rate limits (due to the test suite), or you notice that a specific test hangs while making the request. Or sometimes they are not "detected" and instead just retried and left to live on.
Usage
This new feature could be used in any
TestCase::setUp()
method.Any request made that is not "faked" will now throw an exception.
Once this feature has been turned on it is still possible to disable it for a specific test...
Naming
I'm not in love the naming here tbh. I went with "fake" rather than stub as that is mostly the wording used for the current developer facing things. Feedback welcomed.
Using existing features
Unfortunately we are unable to utilise the existing faking functionality to achieve this due to precedence.
Http::fake(Closure);
Http::fake(array);
Further considerations
Provide a handler
It is possible to allow the developer to "handle" requests that have not been faked. I did not add this feature as I'm not sure of a use-case other than to throw an exception and didn't see any value in allowing the developer to adjust the exception thrown in the test suite.
This is why I landed on a simple "flag" approach rather than a handler approach. Would love feedback from everyone on this though.
"without" style method
A lot of the testing helpers in Laravel are provided via the
$this->withoutWhatever()
style methods on the TestCase. I did not add this as I think that most of the Facade faking is usually achieved on the Facade itself. Happy to add one if we feel this would be a nice addition.Shout out to @jessarcher for all the feedback on this one.