Test Database for Laravel Dusk (5.4)

@justincdotme You should only specify the environment variables you wish to override in your .env.dusk.local file.

It took me a bit of trial-and-error, but I eventually got Dusk to use a SQLite database of my choice by creating another database entry in my config/database.sqlite and then setting the DB_CONNECTION value to that connection.

In your config/database.php file under the connections key:

'testing' => [
    'driver' => 'sqlite',
    'database' => database_path('testing.sqlite'),
    'prefix' => '',
],

Your .env.dusk.local file:

DB_CONNECTION=testing

So long as you use the DatabaseMigrations trait in your Dusk test cases, this should migrate and rollback the testing SQLite database on the running of your test suite.

@martinbean Thanks for the reply. I just tried your recommendation but Dusk would still only use the db connection specified in .env and not the one from .env.dusk.local. I ran the Dusk test and it passed after implementing your suggestion into database.php and .env.dusk.local. Next, I did a test where I changed DB_CONNECTION in .envto foo; the test failed immediately with the error that "Database [foo] is not configured". I then changed DB_CONNECTION in .env back to pgsql and it worked, even though I kept DB_CONNECTION=testing in .env.dusk.local.

Ok, it appears that the DB error from changing the DB_CONNECTION to an invalid value was sort of a red herring. It now seems like Dusk uses BOTH the dev DB connection (from .env) and the connection specified in .env.dusk.local. I can run the test now, using the config that @martinbean recommended BUT, I notice 3 things:

1. Dusk seems to be using DB_CONNECTION from .env for sessions AND authentication, despite the fact that I have added SESSION_DRIVER=file in .env.dusk.local. I know this because I can see new sessions being created in the sessions table of my dev DB.

2. Dusk also seems to be using the DB_CONNECTION from my .env.dusk.local. I know this because as a test, I created a user in DB using a model factory and that user does not appear in my dev db (the sessions do show up there, the user did not).

3. The login test doesn't appear to be accessing the same database that newly created test user is in. In this case, the authentication attempt for the test user fails.

class LoginTest extends DuskTestCase
{
    use DatabaseMigrations;
    /**
     * A basic browser test example.
     *
     * @test
     * @return void
     */
    public function a_user_can_log_in()
    {
        $user = factory(User::class)->create([
            'email' => '[email protected]',
            'password' => bcrypt('secret')
        ]);
        $this->browse(function (Browser $browser) use($user) {
            $browser->visit('/login')
                ->assertSee('Login')
                    ->type('email', $user->email)
                    ->type('password', 'secret')
                    ->press('Login')
                    ->assertPathIs('/');
        });
    }
}

Alright, I think I have this resolved(ish). I think the main issue was that I expected Dusk to use the test DB for all DB related actions but that won't work because the application is actually running in a different environment than Dusk. The only way that I could get Dusk to work is to use the same DB for Dusk and the Laravel app. This means abandoning the idea of using a test database in .env.dusk.local because yes, I could use model factories to create rows in that database with Dusk BUT my application would use the dev db so the application would never see the new row that was created in the Dusk test.

@justincdotme You shouldn’t have to use the same database for development and testing. You seem to have a configuration issue.

I’d get rid of any .env.dusk.* files, reset your database connection to mysql (or whatever you were using) in your .env file, and then start over.

@martinbean I have tried restarting a few times by deleting the .env.dusk* files and setting DB_CONNECTION back to pgsql in my .env. I'm wondering if my server infrastructure is causing issues. My dev server is on another physical machine and I access it via LAN from my workstation. Typical workflow is write code on local machine, PHPStorm then uploads to dev server. I run PhpUnit locally and I have also been running php artisan dusk from my local machine. I can see in the failure screenshots that Dusk is accessing my dev server. I'm wondering if maybe my issue is due to the app and Dusk being run on 2 separate machines. I suppose there would be no way for Dusk to tell the dev server that it also needs to swap .env for .env.dusk.local.

@justincdotme Well yes, that would do it. If you’re running the tests from one machine, and trying to test the application on another, it’s not going to work as they’ll be different environments. You need to test the application from the same machine you run the tests from (i.e. locally).

Alright, that makes total sense. @martinbean I really appreciate your assistance with my issue!

I managed to get around that by using php artisan serve so I thought I'd share my code for anyone else who had this problem.

We'll be using Laravel's php artisan serve command to run PHP's built in server locally.

First, add a new test connection to config/database.php

'test' => [
            'driver' => 'sqlite',
            'database' => database_path('testdb.sqlite'),
            'prefix' => '',
        ],

Next, modify the .env.dusk.local file so that it looks like this:

APP_URL=http://127.0.0.1:8000
DB_CONNECTION=test

Finally, create a blank test db in database/ by running touch database/testdb.sqlite. This file will act as a test DB during testing. Now just run php artisan serve to start the local webserver.

The only problem that I ran into was that artisan serve seemed to hang on to the initial state of the .env file, which makes sense. But now Dusk and Laravel were interacting with 2 different databases because the original DB info was in the primary .env.

I was able to get around this by setting the environment var in bash by running export DB_CONNECTION=test php artisan serve which did the trick.

@spekkie2002 Nice work, I like your technique. I didn't even know that was possible to specify the env for artisan serve. (mindblown)

For dusk to work, if you're using the standard config/database.php file, you need to explicitly overwrite the DB_DATABASE environment variable. Your .env.dusk.local file should include this:

DB_CONNECTION=sqlite
DB_DATABASE=database/bookme.sqlite