#Handling Implicit Commits in Test Suite

6 messages · Page 1 of 1 (latest)

torn flax
#

Looking for some general pointers on how to handle tests that trigger implicit commits in MySQL especially with the parallel testing.

I have them in a separate folder so that I can apply a different TestCase to them that doesn't apply the transactions to the connections. However, because the tests are all run in parallel, and some parts of the implicit commit tests affect the database tables that the other tests depend/use, I end up failing other tests because the table data is persisted in the implicit tests and hasn't been cleaned up by those tests.

How do other people handle these kind of tests?

Ideally I'd like to keep them in the test suite - they do prove some important functionality - and I'd like to run them in parallel too.

As I'm testing against databases that are persisted between tests (normally, or rebuilt at the start of the test suite run if they don't exist), do i need to set up additional databases that are specific to these tests so that there's no crossover?

Any pointers would be appreciated.

lyric timber
torn flax
#

thanks @lyric timber however, that doesn't help with the issue - the RefreshDatabase trait (which i'm basically using for the majority of my test suite) uses database transactions on the connection(s) to the database to ensure that the database(s) is refreshed after each test.

The problem is that in a few of my tests I'm doing actions such as create database or drop database which in MySQL lead to an implicit commit of the transaction to the database. i.e., any data "transacted" to the point of "create database" will be committed automatically. Unfortunately, Laravel doesn't know that the transaction has been "committed", and therefore throws an error because the transaction no longer exists when it tries to rollback (not to mention that partial data has been written to the database).

See https://laravel.com/docs/9.x/database#implicit-commits-in-transactions

That's why i've tried to create a second TestCase that doesn't apply the RefreshDatabase trait, but because of the parallelisation of the test run is leading to data leaking between tests.

In short: I'd like to have my cake and eat it 😄

#

N.B. this is definitely a fun "feature" of MySQL and not necessarily a fault of Laravel 😄 just looking for how others work around the "feature" 😆

lyric timber
#

Yeh if you are creating tables/dbs transactions wont help

#

Laravel kinda assumes the table structure to be set in advance so this isn't part of its scope I suppose