A little over a year ago I shared a screencast on my blog showing a trick I use to get better feedback about errors when writing HTTP-level feature tests in Laravel.
The TL;DR is that when an exception happens in a feature test, you'll often get a crappy error about "expected a 200 response, got a 500, here's a shit ton of HTML in your terminal from the error page."
This happens because Laravel catches exceptions and turns them into error pages for you, which means the exceptions never hit PHPUnit itself.
I wrote a little helper to disable that high-level exception handling in Laravel in my feature tests, and these days I use it by default by calling it in the setUp
method of my base TestCase
class.
Occasionally you do want exception handling to happen, because you're trying to test some behavior that depends on it, like converting a ValidationException
into a 422, or a ModelNotFoundException
into a 404.
So any time I need exception handling to actually work, I stick ->withExceptionHandling()
before the HTTP request to turn it back, effectively making it an opt-in behavior instead of opt-out like it would be by default.
I've provided my base TestCase
file below, as well as a few example tests.
Is there a reason you opted for an anonymous class versus an explicitly defined class?
I was reading that some stuck on 5.x are having to extract the class, so although I've borrowed the principle, I've separated the anon class into a regular class with Namespace loading.