alexrfan03's avatar

PHPUnit mysql test database Laravel 5.2

I'm trying to setup a testing environment with the latest Laravel. Is there a way to create a .env.test file and have phpunit use that file? All the examples I have seen, is to use sqlite for your test database. That doesn't feel like a best practice to me, and wanted to know why this was standard.

0 likes
15 replies
ChristopherSFSD's avatar

Yes in your TestCase's createApplication method you could load a different environment like this ...

    Dotenv::load(__DIR__ . '/../', '.env.testing');
alexrfan03's avatar

@ChristopherRaymond After doing that it says that load shouldn't be called statically. I found $app->loadEnvironmentFrom('.env.test'). Will that work?

alexrfan03's avatar

@toniperic I am setting the environment, but it isn't using the .env.test file. It is still using the .env file. So where would you set which environment file it uses?

bobbybouwmann's avatar

You need to add the env stuff for tests in the phpunit.xml file like toni said!

<php>
    <env name="APP_ENV" value="testing"/>
    <env name="CACHE_DRIVER" value="array"/>
    <env name="SESSION_DRIVER" value="array"/>
    <env name="QUEUE_DRIVER" value="sync"/>
    <env name="DB_NAME" value="mydatabasename"/>
</php>
1 like
ChristopherSFSD's avatar
Level 4

You can do what @bobbybouwmann said or you can modify your PHPUnit TestCase createApplication method like so ...

    public function createApplication()
    {
        $app = require __DIR__ . '/../bootstrap/app.php';

        Dotenv::load(__DIR__ . '/../', '.env.testing');

        $app->make(Illuminate\Contracts\Console\Kernel::class)->bootstrap();

        return $app;
    }

I would anticipate that the placement of the Dotenv::load call is super-important.

toniperic's avatar

@ChristopherRaymond that's a bad way to go about it.

PHPUnit's TestCase doesn't have a createApplication method, but rather Laravel's TestCase does. Still, a bad way to go about it.

1 like
toniperic's avatar

@ChristopherRaymond because overwriting Laravel's TestCase::createApplication() method just for the sake of loading a different dotenv file is an overkill, considering there are framework-agnostic/PHPUnit approaches, that are way easier.

Over-complicating simple stuff (even when it comes to testing) can work fine, but it's not necessarily the best way to go.

1 like
ChristopherSFSD's avatar

@toniperic You may be right if you are only using PHPUnit. I'm also using Behat with Selenium so to keep my configuration for testing sane, I chose to use a .env.testing file for both test suites.

And the question was about how to get PHPUnit to use a .env file.

toniperic's avatar

@ChristopherRaymond failed asserting testing frameworks other than PHPUnit are matched in the thread title "PHPUnit mysql test database Laravel 5.2" :)

Nice catch though, might be a useful tip to some. Cheers

alexrfan03's avatar
public function createApplication()
    {
        $app = require __DIR__.'/../bootstrap/app.php';

        // Dotenv::load(__DIR__ . '/../', '.env.test');

        $app->loadEnvironmentFrom('.env.test');

        $app->make(Illuminate\Contracts\Console\Kernel::class)->bootstrap();

        return $app;
    }

The Dotenv::load call was telling me that it wasn't able to be called statically. I was able to use the loadEnvironmentFrom to pull in the values.

I didn't want to put the environment variables in the phpunit.xml, because they would be checked into source control. I thought that would defeat the purpose of having an environment file.

1 like
toniperic's avatar

@alexrfan03 what's wrong with testing environment variables being in source control?

You don't use them in production, so I'd like to know what's the harm.

ChristopherSFSD's avatar

I'm still using Laravel 5.1 so perhaps you can't use the Dotenv facade in 5.2, IDK

1 like
ifpingram's avatar

@toniperic - it depends upon what the environment variables are for. I have some test suites which hit live external dependencies (albeit test accounts), and I do not check in these to source control. The reason is that if they are ever compromised from source control (unlikely I know), then the accounts can then be used. If it is something like a mail service (Mailgun, Mandrill etc.), then it could end up quite expensive if the test accounts were to be used for nefarious purposes... OTOH if the variables are just for local dependencies (database connections etc.) then I just leave them in phpunit.xml and commit to source control.

1 like

Please or to participate in this conversation.