It seems like you're experiencing a change in the way Laravel handles exception reporting in tests between Laravel 10 and Laravel 11. In Laravel 11, the detailed exception message might not be shown by default, which can make debugging more difficult.
To address this, you can use the withoutExceptionHandling method in your test to disable Laravel's exception handling and get more detailed error messages. However, as you mentioned, doing this manually for each test can be cumbersome.
A more efficient approach is to disable exception handling globally for all your tests. You can achieve this by adding the withoutExceptionHandling call in the setUp method of your test class or in a base test class that other test classes extend.
Here's how you can do it:
- Create a Base Test Class (if you don't already have one):
<?php
namespace Tests;
use Illuminate\Foundation\Testing\TestCase as BaseTestCase;
abstract class TestCase extends BaseTestCase
{
use CreatesApplication;
protected function setUp(): void
{
parent::setUp();
// Disable exception handling for all tests
$this->withoutExceptionHandling();
}
}
- Ensure Your Test Classes Extend the Base Test Class:
<?php
namespace Tests\Feature;
use Tests\TestCase;
class QuoteFeatureTest extends TestCase
{
public function test_it_can_mark_a_quote_as_paused()
{
// Arrange
$customer = Customer::factory()->create([
'seller_id' => $this->user->id,
]);
$quote = Quote::factory()->create([
'customer_id' => $customer->id,
]);
// Act
$response = $this->json('POST', route('api.quotes.mark', $quote), [
'accepted' => false,
'declined' => false,
'paused' => true,
]);
// Assert
$response->assertOk();
$this->assertDatabaseHas('quotes', [
'id' => $quote->id,
'status' => QuoteStatus::PAUSED,
]);
$this->assertDatabaseHas('quotes', [
'id' => $quote->id,
'accepted_at' => null,
]);
}
}
By adding the withoutExceptionHandling call in the setUp method of your base test class, you ensure that all your tests will have exception handling disabled by default, providing you with more detailed error messages.
This approach should help you get the detailed error output you need without having to manually add withoutExceptionHandling to each test.