If you liked what you've learned so far, dive in!
Subscribe to get access to this tutorial plus
video, code and script downloads.
With a Subscription, click any sentence in the script to jump to that part of the video!
Login SubscribeOur 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:1.0.6" "symfony/phpunit-bridge:4.3.3" --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.
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
Tip
PHPUnit 8.2 requires PHP 7.2. If you're using PHP 7.1, stay with PHPUnit 7.5.
... lines 1 - 3 | |
<phpunit xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" | |
... lines 5 - 8 | |
> | |
<php> | |
<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" /> | |
</php> | |
... lines 17 - 32 | |
</phpunit> |
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.
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.
# define your env variables for the test env here | |
KERNEL_CLASS='App\Kernel' | |
APP_SECRET='$ecretf0rt3st' | |
SYMFONY_DEPRECATIONS_HELPER=999999 | |
... lines 5 - 6 |
Inside .env
, copy the DATABASE_URL
key, paste it in .env.test
and add a little _test
at the end.
... lines 1 - 4 | |
DATABASE_URL=mysql://root:@127.0.0.1:3306/cheese_whiz_test |
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.
// composer.json
{
"require": {
"php": "^7.1.3, <8.0",
"ext-ctype": "*",
"ext-iconv": "*",
"api-platform/core": "^2.1", // v2.4.5
"composer/package-versions-deprecated": "^1.11", // 1.11.99
"doctrine/annotations": "^1.0", // 1.13.2
"doctrine/doctrine-bundle": "^1.6", // 1.11.2
"doctrine/doctrine-migrations-bundle": "^2.0", // v2.0.0
"doctrine/orm": "^2.4.5", // v2.7.2
"nelmio/cors-bundle": "^1.5", // 1.5.6
"nesbot/carbon": "^2.17", // 2.21.3
"phpdocumentor/reflection-docblock": "^3.0 || ^4.0", // 4.3.1
"symfony/asset": "4.3.*", // v4.3.2
"symfony/console": "4.3.*", // v4.3.2
"symfony/dotenv": "4.3.*", // v4.3.2
"symfony/expression-language": "4.3.*", // v4.3.2
"symfony/flex": "^1.1", // v1.18.7
"symfony/framework-bundle": "4.3.*", // v4.3.2
"symfony/http-client": "4.3.*", // v4.3.3
"symfony/monolog-bundle": "^3.4", // v3.4.0
"symfony/security-bundle": "4.3.*", // v4.3.2
"symfony/twig-bundle": "4.3.*", // v4.3.2
"symfony/validator": "4.3.*", // v4.3.2
"symfony/webpack-encore-bundle": "^1.6", // v1.6.2
"symfony/yaml": "4.3.*" // v4.3.2
},
"require-dev": {
"hautelook/alice-bundle": "^2.5", // 2.7.3
"symfony/browser-kit": "4.3.*", // v4.3.3
"symfony/css-selector": "4.3.*", // v4.3.3
"symfony/maker-bundle": "^1.11", // v1.12.0
"symfony/phpunit-bridge": "^4.3", // v4.3.3
"symfony/stopwatch": "4.3.*", // v4.3.2
"symfony/web-profiler-bundle": "4.3.*" // v4.3.2
}
}