Migrate only once with Laravel dusk

Question

According to the "Database Testing" documentation I can reset the database after each test (first option). Second option is to run test using Transactions. It seems a better approach to me, but if I want to run with transaction, the migration does not run.

Is there any way to run the migration once for all the test process?

In other words, I want to run the migration, run every tests with transaction, then rollback. I tried with what the documentation says, but I think something is missing.

If you have multiple Dusk classes and only want to run your database seeding once before all of the Dusk classes are run, I think this approach will lead to the actual answer you're looking for: https://stackoverflow.com/a/35457334/470749 — Ryan, Feb 28 '19 at 13:02

score 2 · Accepted Answer · answered Feb 06 '17 at 22:36

Wrangled with this for a while today and running migrations in conjunction with migrations seems to do the trick. A snapshot of my test is as follows:

<?php

namespace Tests\Browser;

use App\User;
use Tests\DuskTestCase;

use Illuminate\Foundation\Testing\DatabaseMigrations;
use Illuminate\Foundation\Testing\DatabaseTransactions;

class DefaultTest extends DuskTestCase
{
    use DatabaseMigrations, DatabaseTransactions;

    /**
     * A Dusk test example.
     *
     * @return void
     */
    public function test_something()
    {
        //Add test stuff here
    }
}

I've got a couple of factories in my actual test and they seem to run through the migrations with the data destroyed after the test as expected.

This just runs the Database Migrations . Transactions are not supported in dusk because it is run in a browser. — Christophvh, Apr 11 '17 at 07:43

score 2 · Answer 2 · answered Apr 11 '17 at 07:48

It is not possible to run DatabaseTransactions in combination with dusk for the moment.

https://github.com/laravel/dusk/issues/110

The creation of the user record and the use of it in the browser are done in two different processes. This means the created user is part of a database transaction which is not committed and thus not accessible by the browser process.

Database migrations work. So you should use those. Also make sure you run a seperate testing database so you don't mess with your production/development database.

https://laravel.com/docs/5.4/dusk#environment-handling

To force Dusk to use its own environment file when running tests, create a .env.dusk.{environment} file in the root of your project. For example, if you will be initiating the dusk command from your local environment, you should create a .env.dusk.local file.

When running tests, Dusk will back-up your .env file and rename your Dusk environment to .env. Once the tests have completed, your .env file will be restored.

The provided answer works because DatabaseMigrations work. The use DatabaseTransactions is not relevant.

score 1 · Answer 3 · answered Jun 23 '17 at 08:58

From what I understand, I don't think transactions can ever work when using dusk, as each browser request in dusk creates a separate instance of your laravel app.

Previously, phpunit would create a new application in memory as part of the process (in the setUp / createApplication method), then test against that testing application, then destroy it and set up the next one. As such, the transactions can be wrapped around (or just inside) the create and destroy parts of that application before it starts up a new database connection for the next test.

With dusk, it's real end-to-end testing (including a browser, faked user interaction, the routing on your local machine, etc.), which means it is not all contained within the environment that your tests are running in, like they usually are in phpunit.

Dusk does the following:

Copies your .env.dusk.* and launches the chromedriver (or whatever selenium-like thing you use)
Triggers a phpunit shell command (ie. new command, new process)
The phpunit command runs your dusk tests, which each open a browser window and makes requests (each request starting a new php-fpm and php process (for nginx)) - just as though you were making those requests yourself. Each of them have separate connections to the db, and so cannot interact with each others' transactions.

It's also worth noting that the DatabaseTransactions trait is in the Foundation package, not the Dusk package, so it's not build / packaged with Dusk in mind.

This also explains why in-memory sqlite doesn't work with dusk, as one process does not have access to another process' memory.

score 0 · Answer 4 · answered Feb 28 '19 at 20:11

Here is a very portable and reusable way:

abstract class DuskTestCase extends BaseTestCase {

   ...

    /**
     * @param int $batchCounter
     * @param string $className
     * @param int $threshold
     */
    public function refreshDb(&$batchCounter, $className = '', $threshold = 0) {
        if ($batchCounter <= $threshold) {
            //TODO: Here is where you'll want to run migrations and seeds and whatnot.
            $batchCounter++;
            $this->consoleOutput(trim($className . ' called refreshAndSeedTestingDb and $batchCounter++. $batchCounter=' . $batchCounter));
        }
    }

   /**
    * @param string $msg
    */
   public function consoleOutput($msg) {
       Log::debug($msg);
       $output = new \Symfony\Component\Console\Output\ConsoleOutput();
       $output->writeln($msg);
   }

Then in each test file:

class ExampleBrowserTest extends DuskTestCase {

    protected static $countDbRefreshed = 0;

    public function setUp() {//runs before every test function in this class
        parent::setUp();
        $this->refreshDb(self::$countDbRefreshed, __CLASS__); //inside uses a property to run only once per class
    }
...

Migrate only once with Laravel dusk

4 Answers4

Linked