Closed badams closed 4 years ago
I'm actually not sure about this one myself. Will need input from @taylorotwell here.
I'm not sure I would expect any middleware to run at all, so to me personally this is expected behavior. If you're faking the HTTP client you are going to specify exactly what responses should returned.
@taylorotwell @driesvints I'd really appreciate if you can reconsider this, without this working its completely impossible to test that middleware is configured and working correctly.
Perhaps my example of mutating the response was not great - this was for simplicity sake and was lifted directly from the guzzle docs.
I have a number of middleware that perform a range of actions such as:
ValidationException::withMessages(...)
, AuthorizationException
etc)Without the ability to test my middleware, the withMiddleware(...)
method is not useful to me and I've had to opt for a more procedural approach or use Guzzle directly, but honestly I much prefer the interface for Http
and Http:fake()
I'm happy to work on a PR for this if needed.
We're probably not going to reconsider this, sorry.
So, I also spent some time in this... Then found this issue.
I think there is another good use case for this. We, very often, need to log what is sent to an api and what is received.
When testing, using Mail::fake()
, Testing this logger will not be possible
$response = Http::withMiddleware(Middleware::log(
app(LogManager::class)->channel(),
new MessageFormatter()
))->{$method}($url, $payload);
just in case +1 on this
Thanks
Description:
If you provide middleware on your Http client it will never be invoked when using
Http::fake()
Steps To Reproduce:
As you can see the middleware is not applied in the second test
$client->withMiddleware(...)
Http::fake()