Dusk Automation Database

[MaxHarrisonGit]

What you would like to change/add

Would like to get a standard for Dusk Automation Database Handling, On one project, We clear the database for each test and seed it with the relevant information. however on another project , it appears it does not, Would like a consensus on what should be the standard.

Why you would like to change/add this

To start implementing a standard for dusk and so we would have uniformed testing environments

Examples TestCase Setup -

protected function setUp()
    {
        parent::setUp();

        $this->setUpDatabase();

        $this->seed(\UserTypesSeeder::class);
        $this->seed(\OutletsSeeder::class);

        $this->adminUser = $this->generateTestUser(1, env('DUSK_TEST_ADMIN_EMAIL'));
        $this->agentUser = $this->generateTestUser(2);
        $this->operativeUser = $this->generateTestUser(3);
        $this->customerUser = $this->generateTestUser(4);

        foreach (static::$browsers as $browser) {
            $browser->driver->manage()->deleteAllCookies();
        }
    }

protected function setUp()
    {
        parent::setUp();
        foreach (static::$browsers as $browser) {
            $browser->driver->manage()->deleteAllCookies();
        }
    }

Checklist

• [ x] I have checked that this is not a duplicate issue.

Sources

• Langley Foxall - The Langley Foxall website

[DivineOmega]

I am for:

1. Migrating the database once, then truncating all tables for each test.
2. Only seeding what is required to run the test.

These can dramatically improve the time it takes to run tests.

When point 1 was implemented into Oly..., we saw a ~75% reduction in the time it took for Travis to run tests.

Point 2 ensures that as more seeders are added, the time for each test is not increasing at the same time.

[ash123456789]

I believe the fastest way would be to just rollback the changes rather than re-migrating or re-seeding anything. However, we had issues getting this to work as intended in one or two projects so it could be worth exploring that again if possible.

• Run migrations
• Runs seeders
• Execute test
• Rollback changes performed in test
• Proceed onto next test without re-migrating or re-seeding.

This will potentially cause an issue with nested transactions as MySQL does not support them (PostgreSQL when).

[DivineOmega]

@ash123456789 Unfortunately, it is not possible to use database transactions to rollback changes when running end to end (Dusk) tests.

[ash123456789]

@ash123456789 Unfortunately, it is not possible to use database transactions to rollback changes when running end to end (Dusk) tests.

Damn, that sucks 😞

We could alternatively do it ourselves after every test so we wouldn't have to re-migrate and re-seed. So, after we've performed the test, we rollback whatever we've done to the database manually? This would increase the time it takes to create tests though.

[dextermb]

I am for:

1. Migrating the database once, then truncating all tables for each test.
2. Only seeding what is required to run the test.

These can dramatically improve the time it takes to run tests.

Definitely. We implemented this, based on your suggestion, into another project for unit tests. It's a noticeable difference.

---

Going slightly off topic:

In the current project I am working we've also created interfaces for different types of phpunit tests, for example a CRUDTestInterface which has methods for all things related to CRUD.

This makes sure that everything runs the same tests so nothing would be missed. Something similar can be done for browser tests (which will probably also get implemented into this project).

[ash123456789]

I just came across this blog post about speeding up Dusk tests, he essentially migrated and seeded once then dumped the structure to an SQL file.

He even made a package for quick migrations: https://github.com/mnabialek/laravel-quick-migrations