Bootstrapping a Test Suite

Keep on Learning!

If you liked what you've learned so far, dive in!
Subscribe to get access to this tutorial plus
video, code and script downloads.

Start your All-Access Pass
Buy just this tutorial for $12.00

With a Subscription, click any sentence in the script to jump to that part of the video!

Login Subscribe

Our security requirements are about to get... pretty complicated. And so, instead of testing all of that manually and hoping we don't break anything, I think it's time to take a few minutes to get a nice functional testing system set up.

Spin over to your terminal and run:

composer require test --dev

This will download Symfony's test-pack, which most importantly comes with the PHPUnit bridge: a small Symfony component that wraps around PHPUnit.

When that finishes... yep - we'll put our tests in the tests/ directory and run PHPUnit via php bin/phpunit. That's a bit different than if you installed PHPUnit directly and you'll see why in a minute. That file - bin/phpunit was added by the recipe. And... if you run git status, you'll see that the recipe also added a phpunit.xml.dist file, which holds sensible default config for PHPUnit itself.

Configuring the PHPUnit Version

Open that file up. One of the keys here is called SYMFONY_PHPUNIT_VERSION, which at the time I recorded this is set to 7.5 in the recipe. You can leave this or change it to the latest version of PHPUnit, which for me is 8.2


PHPUnit 8.2 requires PHP 7.2. If you're using PHP 7.1, stay with PHPUnit 7.5.

34 lines phpunit.xml.dist
... lines 1 - 3
<phpunit xmlns:xsi=""
... lines 5 - 8
<ini name="error_reporting" value="-1" />
<server name="APP_ENV" value="test" force="true" />
<server name="SHELL_VERBOSITY" value="-1" />
<server name="SYMFONY_PHPUNIT_REMOVE" value="" />
<server name="SYMFONY_PHPUNIT_VERSION" value="8.2" />
... lines 17 - 32

But wait... why are we controlling the version of PHPUnit via some variable in an XML file? Isn't PHPUnit a dependency in our composer.json file? Actually... no! When you use Symfony's PHPUnit bridge, you don't require PHPUnit directly. Instead, you tell it which version you want, and it downloads it in the background.

Check it out. Run:

php bin/phpunit

This downloads PHPUnit in the background and installs its dependencies. That's not really an important detail... but it might surprise you the first time you run this. Where did it download PHPUnit? Again, that's not an important detail... but I do like to know what's going on. In your bin/ directory, you'll now find a .phpunit/ directory.

Customizing the test Database

After downloading PHPUnit, that bin/phpunit script does then execute our tests... except that we don't have any yet. Before we write our first one, let's tweak a few other things.

The recipe added another interesting file: .env.test. Thanks to its name, this file will only be loaded in the test environment... which allows us to create test-specific settings. For example, I like to use a different database for my tests so that running them doesn't mess with my development database.

6 lines .env.test
# define your env variables for the test env here
... lines 5 - 6

Inside .env, copy the DATABASE_URL key, paste it in .env.test and add a little _test at the end.

6 lines .env.test
... lines 1 - 4

Cool, right? One of the gotchas of the .env system is that the .env.local file is normally loaded last and allows us to override settings for our local computer. That happens in every environment... except for test. In the test environment, .env & .env.test are read, but not .env.local. That little inconsistency exists so that everyone's test environment behaves the same way.

Anyways, now that our test environment knows to use a different database, let's create that database! Run bin/console doctrine:database:create. But since we want this command to execute in the test environment, also add --env=test:

php bin/console doctrine:database:create --env=test

Repeat that same thing with the doctrine:schema:create command:

php bin/console doctrine:schema:create --env=test

Perfect! Next, Api Platform has some really nice testing tools which... aren't released yet. Boo! Well... because I'm impatient, let's backport those new tools into our app and get our first test running.

Leave a comment!

  • 2019-12-16 Diego Aguiar

    Sounds like the behavior I would expect :)

  • 2019-12-13 Дилян Траянов

    BTW. If you install PHPUnit and then change the version to 8.2 and run bin/phpunit again, it will install the new version in another directory with the version postfix.
    Happy coding!

  • 2019-12-09 Vladimir Sadicov

    Ha! No problem!)) Anyways feel free to ask question! We are here to help!

    Cheers! Have a great development!

  • 2019-12-09 Cristian Antohe

    Hey, I though I didn't post this :)

    Turned out I was in the incorrect folder. I should have been inside /api, but instead tried to install it in the root. After that it worked as expected.

  • 2019-12-09 Vladimir Sadicov

    Hey Cristian Antohe

    This shortcuts depends on symfon/flex package probably you can't use test shortcut because flex is outdated or not installed. What is your situation?


  • 2019-12-09 Cristian Antohe

    Hi, I'm jumping in in the middle of this screencast and composer require --dev test doesn't find any packages (trying to setup a dev env first and I want to have tests enabled before moving forward).

    I'm guessing it's referring to:
    composer require symfony/test-pack

  • 2019-09-25 weaverryan

    Hey Sung Lee!

    Yea, XDebug is a huge problem for Composer - that will definitely kill performance. And Composer will never be as fast/responsible as "npm", unfortunately. Part of that I think is due to how sophisticated its dependency algorithm is, but also I think that algorithm could be improved (but very complex systems take a lot of effort to optimize!).

    But the fact that composer update is fast, but updating PHPUnit is is still slow doesn't make sense to me. When you execute the phpunit file, ultimately it is loading vendor/symfony/phpunit-bridge/bin/simple-phpunit.php ( You can see that it's ultimately just running some composer commands -

    And, of course, these commands should be running as the same terminal user as normal. It's possible (but unlikely) that the script is using a different PHP binary or Composer executable... you could check by hacking into that file and dumping $COMPOSER and $PHP. But mostly, this is a bit of a mystery...

    If you found out anything else, let me know!


  • 2019-09-23 Sung Lee

    First, I had XDebug installed recently and I noticed it makes composer require test --dev command super slow. Waited more than 20 min and still no response so I killed the process. After removing XDebug, installing test pack gets faster, but not as fast/responsive as "npm" install. composer update is fast when I running it. However, updating PHPUnit is still slow.

  • 2019-09-23 weaverryan

    Hey Sung Lee!

    Ah, you're right - I should have made a point of that. We'll add a note! About the updating, that *is* strange. Internally, the script is basically doing a "composer create-project" on PHPUnit itself (which is sort of like doing a composer update) then, depending on your config, possibly also a few other composer commands. So, it shouldn't be *super* quick, but it shouldn't take more than 1 minute. Do you also see equally slow times if you run, for example, a composer update on your project?


  • 2019-09-23 Sung Lee

    FYI, you need to have PHP 7.2+ to use PHPUnit 8.2. Also installing phpunit and updating dependencies takes some time. For me, it took more than 10 min.
    If you know how to make it faster, please share with us.