[8.x] Adds withoutDeprecationHandling

[nunomaduro]

This pull request adds withoutDeprecationHandling to the base Laravel's Test Case class so people can opt-in to have deprecations as exceptions in their test suites. Here is an example:

// routes/web.php
Route::get('/', function () {
    str_contains(null, null);

    return view('welcome');
});

// Test A
it('has a home page', function () {
    $response = $this->get('/');

    $response->assertStatus(200); // passes ✅
});

// Test B
it('has a home page', function () {
    $this->withoutDeprecationHandling();

    $response = $this->get('/');

    $response->assertStatus(200); // 🛑 Expected response status code [200] but received 500. The following exception occurred during the request: ErrorException: str_contains(): Passing null to parameter #1 ($haystack) of type string is deprecated in /Users/nunomaduro/code/laravel/laravel/routes/web.php:17
});

@taylorotwell If this pull request gets merged, let me know if this deserves a section on the docs.

[taylorotwell]

The naming feels a bit confusing? withoutDeprecationHandling makes it sound like I won't get exceptions, but this enables exceptions.

[nunomaduro]

@taylorotwell Well, when you use existing withoutExceptionHandling in your tests, the exception does not get caught by the framework and the bubbles up to the test case. Here is the same, when you use withoutDeprecationHandling in your tests, the deprecation does not get caught by the framework and the bubbles up (after being converted to exception) to the test case.

One thing that could be discussed thought, is the fact that this code converts the deprecation to exception. We could eventually do not convert the deprecation to exception, only bubble up a real deprecation to using https://www.php.net/manual/en/function.trigger-error.php. I prefer the former, as we don't have to add the "convertDeprecationsToExceptions" to phpunit.xml.

[taylorotwell]

Yeah I guess that's a good point. 👍