Testing: is RefreshDatabase efficient enough? Got a proposal.

[pabloelcolombiano]

Hi @people,

you know the Illuminate\Foundation\Testing\RefreshDatabase trait, and what is does. Correct me if I am wrong, but the workflow is as follows:

• drop the test DB's tables
• run the migrations once
• start a transaction
• run TestA
• revert the transaction
• start a transaction
• run TestB
• revert the transaction
• etc...

A question: does this work if I use transactions in my tests, or will that collide with the test suite transactions?

A remark: running the migrations can take up to 10s of seconds. It is a lot of time at the end of the say, if I run my tests say every 5 minutes.

A proposal: CakePHP has a test suite light, that cleans up the dirty tables before each test, without dropping the tables at any times. And without using transactions. So the migrations get run once and for all. Would it be of the interest of Laravel to propose an adapter? Or do you think there is no chance a PR will make its way through?

Here is a bit of material on that approach: https://www.youtube.com/watch?v=PNA1Ck2-nVc&t=1100s

[LastDragon-ru]

A question: does this work if I use transactions in my tests, or will that collide with the test suite transactions?

It depends... + AFAIK it conflicts with #35422 (not yet tested)

A proposal: CakePHP has a test suite light, that cleans up the dirty tables before each test, without dropping the tables at any times.

You can extend RefreshDatabase to make it smarter, eg https://github.com/LastDragon-ru/lara-asp/blob/master/packages/testing/src/Database/RefreshDatabaseIfEmpty.php 😀

[pabloelcolombiano]

Thanks for the reply @LastDragon-ru

If I get you well, the transactions of the RefreshDatabase trait collide with even other things than transactions, which speaks against it.

I'll propose a solution that gets rid of the RefreshDatabase, which introduces transactions. I'll also write in #35422 that it might be better in the long term to simply get rid of transactions.