TransactionStartException will always be throwed in tests with RefreshDatabase trait

[ibrunotome]

Describe your task
The test suite in laravel are always executed inside a database transaction if you're using the LazilyRefreshDatabase trait. After v8.2, all tests that has a wallet transaction are broken

To Reproduce
Steps to reproduce the behavior:

1. write an action that has a app(DatabaseServiceInterface::class)->transaction.
2. write a test with LazilyRefreshDatabase trait.

Expected behavior
The test will broke with "Bavix\Wallet\Internal\Exceptions\TransactionStartException : Working inside an embedded transaction is not possible", but this transaction was started by the framework itself, not in userland.

Server:

• php version: 8.1
• database: postgres 14
• wallet version 8.2
• cache lock: redis
• cache wallets: redis

[rez1dent3]

Hello. Prior to laravel-wallet 8.2, there was no such error, but the tests did not work correctly either. The fact is that the wallet stores the state inside, and upon completion of the transaction, it updates the data. This is necessary to improve performance. I'll think of some testing tools that might help.

More details can be read here: #412 #455 https://bavix.github.io/laravel-wallet/#/transaction

[rez1dent3]

@ibrunotome Hello. Today I took the time and immersed myself in your problem. The error is correct, it says that it is not possible to start the package's internal transaction, since the framework transaction has already been opened above, as a result of which there will be an error in updating the data.
Right now, the only thing that can be done is to close the transaction in setUp.

laravel-wallet/tests/Infra/TestCase.php

Lines 22 to 28 in 88913b5

	use RefreshDatabase;
	protected function setUp(): void
	{
	parent::setUp();
	DB::transactionLevel() && DB::rollBack();
	}

It may not be convenient, but this is a correct check of the package. The fact is that at the end of the transaction, the package updates the data in the cache, sends events and does a bunch of other useful things that are not in the framework transactions. It's a compromise between performance and convenience.

[ibrunotome]

Tested, the error remains the same after rollback in setup:

The test is written with pest, but I think that this doesn't affect anything, right? Or I'm missing something here?

[rez1dent3]

This package is tested with phpunit, RefreshDatabase and it works. Can you make an example?
@ibrunotome

[ibrunotome]

You mean create a new repo or just post some examples like below?

TestCase.php

<?php

namespace Tests;

use Illuminate\Foundation\Testing\LazilyRefreshDatabase;
use Illuminate\Foundation\Testing\TestCase as BaseTestCase;
use Illuminate\Support\Facades\DB;

abstract class TestCase extends BaseTestCase
{
    use CreatesApplication;
    use LazilyRefreshDatabase;

    protected function setUp(): void
    {
        parent::setUp();
        DB::transactionLevel() && DB::rollBack();
    }
}

Pest.php

<?php

/*
|--------------------------------------------------------------------------
| Test Case
|--------------------------------------------------------------------------
|
| The closure you provide to your test functions is always bound to a specific PHPUnit test
| case class. By default, that class is "PHPUnit\Framework\TestCase". Of course, you may
| need to change it using the "uses()" function to bind a different classes or traits.
|
*/

uses(Tests\TestCase::class)->in(__DIR__);

TestExample.php (the usage of package transaction occurs in RateContractAsSatisfiedAction)

<?php

use App\Actions\Quests\RateContractAsSatisfiedAction;
use App\Enums\QuestContractStatus;
use App\Models\Quest;
use App\Models\User;

it('successfully rate quest contract as super satisfied', function () {
    /** @var \App\Models\Quest $quest */
    $quest = Quest::factory()->create();

    /** @var User $user */
    $user = User::factory()->create();

    $user->tasks()->attach($quest->id, [
        'days_to_rate' => $quest->days_to_rate,
        'workers_earn' => $quest->workers_earn,
        'completed_at' => now(),
    ]);

    app(RateContractAsSatisfiedAction::class)->execute($quest, [
        'bonus'         => '0.10',
        'contracts'     => [
            $user->contracts->first()->id,
        ],
    ]);

    $contract = $user->refresh()->contracts->first();

    $amountEarnedWithBonus = bcadd($quest->workers_earn, '0.10', 8);
    expect($contract->status)->toBe(QuestContractStatus::SuperSatisfied);
    expect(number_format($contract->worker_earned, 8))->toBe($amountEarnedWithBonus);
});

[rez1dent3]

@ibrunotome Well thank you. In the near future I will try to make a project with Pest.

We have an overly twisted example with a bunch of services that I don't have. It would be nice to get a clean example from you, without wrappers.

[ibrunotome]

Here is an example: https://github.com/ibrunotome/laravel-wallet-transaction-exception-example

[rez1dent3]

@ibrunotome hello. I found the problem. Thanks for your example, very detailed. The problem is precisely in the trait LazilyRefreshDatabase, which is what you said. If you replace it with Illuminate\Foundation\Testing\RefreshDatabase in your project, then everything starts working.

The problem is that the transaction starts inside the Factory when using this trait and it does not finish its work. This can be checked like this:

    dump(\Illuminate\Support\Facades\DB::transactionLevel()); // 0
    /** @var User $user */
    $user = User::factory()->create();
    dd(\Illuminate\Support\Facades\DB::transactionLevel()); // 1

[rez1dent3]

If you really need to use LazilyRefreshDatabase, then you will have to apply the commit after the Factory.

    $user = User::factory()->create();
    \Illuminate\Support\Facades\DB::commit();

I don't have any other solution.