Nevermind, seems the test focus is on infrastructure instead of the actual tests.

if the infrastructure doesn't work as it should, and that's a topic we are working on, it hard to upgrade the tests.
@Hackwar if you have time could you look at this?

I'm actually working on exactly that right now. The unit tests don't work with the database anyway and we currently have no integration tests in our testing setup. With that being the case for nearly 2 years, the old tests of 3.x are pretty much useless right now and thus we have to start over anyway. So I'm looking into how to setup these integration tests properly. Hopefully in the next few days.

In the hopes that nobody decides to re-invent the wheel yet again (doubtful), I have extracted the DatabaseTestCase I am using for the stats server into the Framework's Test package and updated its master branch for the Framework 2.0 requirements. The relevant bits are the DatabaseTestCase and the DatabaseManager with some of the high level functions that would be needed in basic tests interfacing with a database. Do what you want for the CMS, but since depending on DbUnit is a blocker for upgrading to PHPUnit 8 I'm using that code in the Framework package tests.

Do what you want for the CMS, but since depending on DbUnit is a blocker for upgrading to PHPUnit 8 I'm using that code in the Framework package tests.

Any example how to convert or use the dbunit code to the testing package? You extracted it from the statistic server the relevant commit is joomla/statistics-server@7cb7ba8 ?
I didn't looked at dbunit but should the replacement straight forward?

It's not a 1-for-1 swap unfortunately, nor am I trying to write a DbUnit replacement.

Right now the DatabaseManager only has logic for a few high level operations:

• Create a database
• Drop a database
• Truncate all tables in a database

Between the CMS and the various Framework apps floating around out there, there are a lot of differing database schemas and differing ways to manage seeding a database (the Joomla\CMS\Schema library for the CMS, or the Joomla\StatsServer\Database\Migrations class for the stats server app, or the use of Phinx in the Framework website app). So the manager doesn't have anything to explicitly load a schema, the extended DatabaseManager in the stats server app has some code to help with getting the database schema loaded and dropping in some test data for cases that need it (demonstrating the whole "extend this to add your app specific logic" bit).

The DatabaseTestCase right now basically makes sure the database is in a clean state before starting the tests for a class (dropping the test database if it already exists, then creating it) and cleaning up after that class' tests are done (dropping the database). If you need to load schema or anything, you need to do that in your extended classes.

Note right now this is only practically tested on MySQL as that's what the stats server is running. Once the Framework's Authentication and Session package tests get updated to use this newer code, should be able to work out what kind of issues may exist and adapt the test case and manager as needed.

The intent really is to keep those base classes as the high level logic needed to manage params and manage the database state, it's not intended to be as fully featured as DbUnit because there is a lot of app specific logic that needs to exist in a base database test case that DbUnit couldn't cover.

ok thx for the explanation.

As far as I can tell this issue has been addressed and dbuint is no longer used.

@Hackwar if you can confirm please then this can be closed

It's addressed for 4

Thanks for confirming @rdeutz