Behat Hooks Background
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.
Behat experts coming through! Seriously, we've covered it: Behat reads the steps, finds a function using this nice little pattern, calls that function, and then goes out to lunch. That's all that Behat does, plus a few nice extras.
Let's dive into some of those extras! This scenario creates the "john" and "hammond" files inside this directory but doesn't even clean up afterwards. What a terrible roommate.
Let's first put these into a temporary directory. We'll use the __construct function
because that's called before each scenario. Type mkdir('test'); and chdir('test');:
| // ... lines 1 - 11 | |
| class FeatureContext extends MinkContext implements Context, SnippetAcceptingContext | |
| { | |
| // ... lines 14 - 22 | |
| public function __construct() | |
| { | |
| mkdir('test'); | |
| chdir('test'); | |
| } | |
| // ... lines 28 - 53 | |
| } |
Over in the terminal, delete the "john" and "hammond" files so we can have a fresh start at this. Rerun Behat for our ls scenario:
vendor/bin/behat features/ls.feature
Everything still passes and hey look there's a little test/ directory and
the "john" and "hammond" are inside of that. Cool.
Ready for the problem? Rerun that test one more time. Now, errors show up that say:
mkdir(): file exists.
This error didn't break our test but it does highlight the problem that we don't have any cleanup. After our tests run these files stick around.
We need to run some code after every scenario. Behat has a system called "hooks" where you can make a function inside of your context and tell Behat to call it before or after your scenario, entire test suite or individual steps.
Create a new public function inside called public function moveOutOfTestDir():
| // ... lines 1 - 11 | |
| class FeatureContext extends MinkContext implements Context, SnippetAcceptingContext | |
| { | |
| // ... lines 14 - 66 | |
| public function moveOutOfTestDir() | |
| { | |
| // ... lines 69 - 72 | |
| } | |
| } |
This will be our cleanup function. Use chdir('..'); to go up one directory. Then,
if the test/ directory exists - which it should - then we'll run a command to remove that:
| // ... lines 1 - 68 | |
| chdir('..'); | |
| if (is_dir('test')) { | |
| system('rm -r '.realpath('test')); | |
| } | |
| // ... lines 73 - 75 |
To get Behat to actually call this after every scenario, add an @AfterScenario annotation
above the method:
| // ... lines 1 - 63 | |
| /** | |
| * @AfterScenario | |
| */ | |
| public function moveOutOfTestDir() | |
| // ... lines 68 - 75 |
That's it!
Let's give this a try:
vendor/bin/behat features/ls.feature
The first time we run this we still get the warning since our
clean up function hasn't been called yet. But when we run it again, the warnings
are gone! And if we run ls, we see that there is no test directory.
We can do this same thing with the mkdir(); and chdir(); stuff. Create a new
public function moveIntoTestDir():
| // ... lines 1 - 11 | |
| class FeatureContext extends MinkContext implements Context, SnippetAcceptingContext | |
| { | |
| // ... lines 14 - 55 | |
| public function moveIntoTestDir() | |
| { | |
| // ... lines 58 - 61 | |
| } | |
| // ... lines 63 - 73 | |
| } |
And we can make it even a bit more resistant by checking to see if the test directory
is already there and only create it if we need to. Above this, add @BeforeScenario:
| // ... lines 1 - 52 | |
| /** | |
| * @BeforeScenario | |
| */ | |
| public function moveIntoTestDir() | |
| { | |
| if (!is_dir('test')) { | |
| mkdir('test'); | |
| } | |
| chdir('test'); | |
| } | |
| // ... lines 63 - 75 |
This is basically the same as putting the code in __construct(), but with some
subtle differences. @BeforeScenario is the proper way to do this.
When we run things now, everything looks really nice. I think this ls command
is going to be a success!
PHPUnit Assert Functions
So bonus feature #1 is the hook system. And bonus feature #2, has nothing to do
with Behat at all. It actually comes from PHPUnit. Our first step will be to install
PHPUnit with composer require phpunit/phpunit --dev. That will add it under a new
require-dev section in composer.json:
| { | |
| // ... lines 2 - 21 | |
| "require-dev": { | |
| // ... lines 23 - 25 | |
| "phpunit/phpunit": "^4.8" | |
| } | |
| } |
Full disclosure, I should have put all the Behat and Mink stuff inside of the require-dev too:
it is a better place for it since we only need them while we're developing.
I installed PHPUnit because it has really nice assert functions that we can get
a hold of. To get access to them we just need to add a require statement in our
FeatureContext.php file, require_once then count up a couple of directories and find
vendor/phpunit/phpunit/src/Framework/Assert/Functions.php:
| // ... lines 1 - 8 | |
| require_once __DIR__.'/../../vendor/phpunit/phpunit/src/Framework/Assert/Functions.php'; | |
| // ... lines 10 - 79 |
Tip
This is a redundant step if you use Symfony 5 or higher. Read more about how to configure Behat & PHPUnit properly with Symfony 5+ here
Requiring this file gives you access to all of PHPUnit's assert functions as flat functions.
Down in the iShouldSeeInTheOutput() method, use assertContains(), give it the needle
which is $string and the haystack which is $this->output. Finally, add our helpful message
which I'll just cut and paste. Remove the rest of the original if statement:
| // ... lines 1 - 13 | |
| class FeatureContext extends MinkContext implements Context, SnippetAcceptingContext | |
| { | |
| // ... lines 16 - 44 | |
| /** | |
| * @Then I should see :string in the output | |
| */ | |
| public function iShouldSeeInTheOutput($string) | |
| { | |
| assertContains( | |
| $string, | |
| $this->output, | |
| sprintf('Did not see "%s" in output "%s"', $string, $this->output) | |
| ); | |
| } | |
| // ... lines 56 - 77 | |
| } |
Run the test again!
vendor/bin/behat features/ls.feature
Beautiful, it looks just like it did before.
Using Background
To show you the final important extra for Behat, create another scenario for Linus' ls feature.
This time we'll say:
| // ... lines 1 - 12 | |
| Scenario: List 1 file and 1 directory | |
| // ... lines 14 - 19 |
I'll copy all the steps from our first scenario and just edit the second line to:
| // ... lines 1 - 13 | |
| Given I have a file named "john" | |
| And I have a dir named "ingen" | |
| When I run "ls" | |
| Then I should see "john" in the output | |
| // ... lines 18 - 19 |
And update the final line to:
| // ... lines 1 - 17 | |
| And I should see "ingen" in the output |
Man what a great looking scenario, let's run it!
vendor/bin/behat features/ls.feature
As expected it now says there's one missing step definition. Copy the PHP code that prints
out into FeatureContext. Remove the throw exception line, and update the arg1's to dir:
| // ... lines 1 - 13 | |
| class FeatureContext extends MinkContext implements Context, SnippetAcceptingContext | |
| { | |
| // ... lines 16 - 78 | |
| /** | |
| * @Given I have a dir named :dir | |
| */ | |
| public function iHaveADirNamed($dir) | |
| { | |
| // ... line 84 | |
| } | |
| } |
Inside the function use mkdir($dir) to actually make that directory:
| // ... lines 1 - 83 | |
| mkdir($dir); | |
| // ... lines 85 - 87 |
Simple!
Back to the terminal to rerun the tests. It works! And that was easy. Once you're
done celebrating you may start to notice the duplication we have in the scenarios.
There are two ways to clean this up. The most important way is with Background::
| // ... lines 1 - 5 | |
| Background: | |
| Given I have a file named "john" | |
| // ... lines 8 - 20 |
If every single scenario in your feature starts with the same lines then you should
move that up into a new Background section.
Now, I'll change the first line of And in each of these scenarios to Given:
| // ... lines 1 - 8 | |
| Scenario: List 2 files in a directory | |
| Given I have a file named "hammond" | |
| // ... lines 11 - 13 | |
| Scenario: List 1 file and 1 directory | |
| Given I have a dir named "ingen" | |
| // ... lines 17 - 20 |
I don't have to do this, but it reads better to me. Now Behat will run that
Background line before each individual scenario and you'll even see that:
vendor/bin/behat features/ls.feature
The Background is read up here, but it actually is running before the top scenario and the
bottom one. We know this because if it didn't, these tests wouldn't be passing.
Second, when you have duplication that's not on the first line of all of your scenarios like the "Then I should see...." you may want to use scenario outlines. It's a little less commonly used but we'll dive into that a bit later.
Ok, not only do you know how Behat works but you even know all of its top extra features -- check you out!
You should really put some quotes around that
realpathcall, I got far too close to accidentally wiping something important because I have spaces in my path