To use database transactions in Laravel tests, apply the RefreshDatabase trait for automatic transaction handling, manually manage transactions with the DB facade for more control, combine with factories and seeders for efficient data setup, and be cautious with async jobs and multiple databases. Laravel’s RefreshDatabase trait wraps tests in a transaction, rolling back changes automatically, while manual transactions via DB::beginTransaction() and DB::rollBack() offer finer control. Factories and seeders work seamlessly within transactions, ensuring clean test data, but setUp() should run seeders only once. However, queued or asynchronous jobs may execute outside the transaction, requiring mocking or fake queues, and transactions don’t span multiple database connections without manual intervention.

When writing tests in Laravel, using database transactions is a smart way to keep your test suite fast and your database clean. Instead of truncating or re-seeding tables between each test, wrapping your tests in a transaction rolls everything back automatically after the test finishes — no cleanup needed.

Here are some practical ways to use database transactions in Laravel tests.

Use RefreshDatabase Trait for Automated Transactions

Laravel provides a built-in trait called RefreshDatabase, which intelligently wraps your tests in a transaction when using an in-memory database (like SQLite), or migrates and rolls back changes for databases like MySQL or PostgreSQL.

Just add this at the top of your test class:

use Illuminate\Foundation\Testing\RefreshDatabase;

Then include it in your test class:

class ExampleTest extends TestCase
{
    use RefreshDatabase;

    // Your tests here
}

This ensures that any data created during the test is rolled back afterward, so your next test starts with a clean slate without running migrations repeatedly.

Manually Start and Rollback Transactions

If you want more control over how transactions work, especially in specific test methods, you can manually handle them using Laravel’s DB facade.

For example:

use Illuminate\Support\Facades\DB;

public function test_example()
{
    DB::beginTransaction();

    // Perform test operations here

    DB::rollBack();
}

This is useful if you only want certain tests wrapped in a transaction or need to test rollback behavior explicitly. Just be careful not to forget the rollback — otherwise, your database might end up with leftover test data.

Combine with Factories and Seeders

Using transactions works well alongside Laravel factories and seeders. Since transactions roll back, you don’t have to worry about duplicate entries or leaving behind test records.

You can do something like:

$user = User::factory()->create();

Inside a transaction, this user will be deleted automatically once the test ends.

If you’re using seeders, make sure they’re only run once per test file — ideally in the setUp() method — to avoid slowing things down.

Watch Out for Async or Queue Jobs

One thing to be aware of: if your code dispatches jobs or events that run asynchronously, those may execute outside the transaction. That means even though your test rolls back, the job might still write to the database after the fact.

In such cases, consider mocking external interactions or using fake queues during testing to prevent side effects.

Also, if you're testing with multiple database connections, transactions won't apply across all of them unless handled manually.

So, basically, Laravel makes it pretty easy to test with transactions through the RefreshDatabase trait or manual handling. Just remember to structure your test setup correctly and watch out for edge cases like queued jobs or multi-database usage.

The above is the detailed content of How do I use database transactions in Laravel tests?. For more information, please follow other related articles on the PHP Chinese website!