If this package is active during features tests, the test will fail if any of these methods are called on TestResponse:
assertViewIs()
assertViewHas()
assertViewMissing()
viewData()
These methods all expect the response's $original attribute to contain a View instance, which it doesn't after the AddRequestComments middleware has called $response->setContent().
How to reproduce the bug
Enable the package during feature tests.
Call a route that returns a View and call one of the mentioned assertions on the response.
Package Version
1.3.0
PHP Version
8.3.11
Laravel Version
11.22.0
Which operating systems does with happen with?
No response
Notes
I realize that by default this package is enabled via APP_DEBUG which usually won't be true during testing. But since it's configurable, you can't assume that it will always be disabled during unit tests.
If it's not possible for AddRequestComments to prevent replacing the $original attribute, it's probably best to disable the middleware entirely during tests (maybe controlled by a separate config option).
What happened?
If this package is active during features tests, the test will fail if any of these methods are called on
TestResponse:assertViewIs()assertViewHas()assertViewMissing()viewData()These methods all expect the response's
$originalattribute to contain aViewinstance, which it doesn't after theAddRequestCommentsmiddleware has called$response->setContent().How to reproduce the bug
Viewand call one of the mentioned assertions on the response.Package Version
1.3.0
PHP Version
8.3.11
Laravel Version
11.22.0
Which operating systems does with happen with?
No response
Notes
I realize that by default this package is enabled via
APP_DEBUGwhich usually won't betrueduring testing. But since it's configurable, you can't assume that it will always be disabled during unit tests.If it's not possible for
AddRequestCommentsto prevent replacing the$originalattribute, it's probably best to disable the middleware entirely during tests (maybe controlled by a separate config option).