In part 1 we saw how to write a behat test. It's now time to use this knowledge to test our real-world application! Please notice that this tutorial will work with most versions of Symfony since behat is compatible with Symfony 4, 5, and 6.

The project we are going to test

The point is not to teach you how to build a Symfony project, so we are not going to do it. Instead, Symfony provides a demo app that does not contain any behat test. I suggest you take this as a base and add a functional behat test!

Let's take a new demo Symfony project:

$ symfony new --demo AppToTest
$ cd AppToTest
$ symfony serve

If you have SQLite installed, everything should be setup and running with those 3 commands. If you prefer to use MySQL or PostgreSQL, there's actually no problem, I will let you tweak the configuration the way you want.

Go to https://localhost:8000/ and you should see something like this:

It's the homepage of the demo application of Symfony.
Something we can test with behat!
You can now shutdown the Symfony server, we don't need it to test our app for now!

The Symfony extension

To work with behat and Symfony, some tooling exists: the organization friends of behat got your back, they are maintaining this nice extension that helps to integrate behat with Symfony. Let's install it on our project:

$ composer require --dev behat/behat friends-of-behat/symfony-extension

If you have Symfony Flex installed, this command triggered the installation of behat and the Symfony plugin but also added a bunch of config files.

• behat.yml.dist is the behat config file where you configure your test suite, we already had the first contact in part 1;
• tests/Behat/ is the folder where you are going to put your behat contexts - classes that behat will execute to run your tests;
• config/services_test.yaml is loading the behat configuration in the test environment;
• features is the folder where you put your user stories, the actual tests.

This configuration is almost ready to go, the only thing you need to do is to configure the bootstrap.php test file (already existing in the tests folder).

# behat.yaml.dist
default:
    suites:
        default:
            contexts:
                - App\Tests\Behat\DemoContext
    extensions:
        FriendsOfBehat\SymfonyExtension:
            # Add this configuration :
            bootstrap: tests/bootstrap.php

Then you can run the command:

This does not test much. Open the DemoContext.php file to see how it works. This is the only actual "test" we have here:

if ($this->response === null) {
    throw new \RuntimeException('No response received');
}

Testing for real

Now that we have behat running, the point will be to really test something. We are going to improve the method theResponseShouldBeReceived and create a new one.

I suggest you to change our feature for something like this:

# features/demo.feature

Feature:
    In order to prove I can write a behat test
    As a user
    I want to test the homepage

    Scenario: I go to the homepage
        When a demo scenario sends a request to "/"
        Then the response should be received
        Then I should see the text "Welcome to the Symfony Demo application"

Tweaking the response checker to actually check

Something not done by the previous test is verifying that the page is not an error, and we can do that by simply checking if we have a 200 error or not.

It's simple, this code will do the job:

/**
 * @Then the response should be received
 */
public function theResponseShouldBeReceived(): void
{
    if ($this->response === null) {
        throw new \RuntimeException('No response received');
    }

    assert($this->response->getStatusCode() === 200);
}

I keep the previous code because why not? But it actually does not make a lot of sense and could be removed.

Testing text is on the page

Before to start, we need a new method, don't try too hard, just run behat and let it generate the code for us:

Let's make this simple:

/**
 * @Then I should see the text :text
 */
public function iShouldSeeTheText($text)
{
    // We are getting a whole HTML page and our text may have tags inside
    // strip_tags has issues, but for this example it will do the job
    $requestContentWithoutTags = strip_tags($this->response->getContent());

    if (!str_contains($requestContentWithoutTags, $text)) {
        throw new \RuntimeException("Cannot find expected text '$text'");
    }
}

Using a browser

This was definitely real-life testing. But you may want to do more, and furthermore, more easily. This is why it's possible to use a browser, I suggest you to use the Symfony default browserkit.

Rewrite our previous test with browserkit

First of all, we need to create our browser... Luckily Symfony has our back! Modify the constructor of your class to inject the client:

use Symfony\Bundle\FrameworkBundle\KernelBrowser;
use Symfony\Component\HttpKernel\KernelInterface;

final class DemoContext implements Context
{
    public function __construct(private KernelBrowser $client) {}
}

You can now rewrite tests using browserkit (use the documentation!).

/**
 * @When a demo scenario sends a request to :path
 */
public function aDemoScenarioSendsARequestTo(string $path): void
{
    // Notice that response is now an instance
    // of \Symfony\Component\DomCrawler\Crawler
    $this->response = $this->client->request('GET', $path);
}

/**
 * @Then the response should be received
 */
public function theResponseShouldBeReceived(): void
{
    assert($this->client->getResponse()->getStatusCode() === 200);
}

/**
 * @Then I should see the text :text
 */
public function iShouldSeeTheText($text)
{
    if (!str_contains($this->response->text(), $text)) {
        throw new \RuntimeException("Cannot find expected text '$text'");
    }
}

Some things to notice here:

• The response is now a Crawler;
• The last actual response is stored inside the client;
• We do not need to make any trick to retrieve the text, the crawler does it for us!

Update your tests, run the test suite, and see how it works well. 🙂

Use the browser to navigate

We have a (fake) browser! We can now navigate throw pages! Let's start by clicking the first link. I suggest you the following scenario (which already exists in the Symfony demo project):

    Scenario: I navigate to Symfony demo
        Given I navigate to "/"
        When I click on "Browse application"
        Then I should see the text "Symfony Demo"

You may notice here that I reuse an old sentence (so nothing to do with the last one), and another one is really similar to another. Let's reuse our previous function:

/**
 * @Given I navigate to :path
 * @When a demo scenario sends a request to :path
 */
public function aDemoScenarioSendsARequestTo(string $path): void
{
    // Notice that response is now an instance
    // of \Symfony\Component\DomCrawler\Crawler
    $this->response = $this->client->request('GET', $path);
}

After this modification:

• I run behat
• I copy/paste the code behat generates to my behat context
• I use the method clickLink of the crawler

/**
 * @When I click on :link
 */
public function iClickOn($link)
{
    $this->response = $this->client->clickLink($link);
}

This is it! You navigate through pages with a behat test!

Testing forms: manage data with behat

The crawler we saw previously fills forms easily and it's documented by Symfony. But this also means that we will start to mess with data... And in the Symfony demo project also with login!

ℹ️ There are many ways to achieve a good database test. I want my test suite to be fast and reliable so I clear my database at each test and in the most efficient way regarding tools I can use. Here I will use directly the database file but with PostgreSQL or MariaDB I use the ORMPurger of Doctrine. Feel free to do it your way.

So let's consider that scenario:

    @database
    Scenario: I comment a post
        Given I am logged in as a user
        And I navigate on a post
        When I fill a comment with "Some random words"
        Then the post should have a new comment
        And I should see the text "Some random words"

We have never seen the tag syntax until now, it's used to add a special action on several tests.

Reset and restore database

Behat allows you to use special methods that hook before and after any scenario. I will use this feature to:

1. Save the database in a special location before the test suite;
2. Reset data on each scenario;
3. Drop the fake database after the test suite is done.

For this, I will use a new behat context, let's call it DataManagementContext. Behat read annotations such as BeforeSuite, AfterScenario or AfterSuite to know when to run our methods. Beware some methods are static or not depending on the type of the event.

class DataManagementContext implements Context
{
    private static ?Filesystem $filesystem = null;
    private const DATABASE_LOCATION = __DIR__ . '/../../data/database_test.sqlite';
    private const DATABASE_LOCATION_COPY = __DIR__ . '/../../data/database_test.sqlite.original';

    public function __construct(private KernelInterface $kernel) {}

    /**
     * @BeforeSuite
     */
    public static function saveTestDatabase(BeforeSuiteScope $scope): void
    {
        $filesystem = self::getFilesystem();
        $filesystem->copy(
            self::DATABASE_LOCATION,
            self::DATABASE_LOCATION_COPY
        );
    }

    /**
     * @AfterSuite
     */
    public static function removeCopiedDatabase(AfterSuiteScope $scope): void
    {
        $filesystem = self::getFilesystem();
        $filesystem->copy(
            self::DATABASE_LOCATION,
            self::DATABASE_LOCATION_COPY
        );
    }

    /**
     * @AfterScenario @database
     */
    public function resetDatabase(): void
    {
        $filesystem = self::getFilesystem();
        $filesystem->remove(self::DATABASE_LOCATION);
        $filesystem->copy(
            self::DATABASE_LOCATION_COPY,
            self::DATABASE_LOCATION
        );
    }

    private static function getFilesystem(): Filesystem
    {
        if (self::$filesystem !== null) {
            return self::$filesystem;
        }

        return self::$filesystem = new Filesystem();
    }
}

In this code, you may see I specified that this hook will execute only on @database tagged scenarios.

Do not forget to add the context to the behat configuration:

default:
    suites:
        default:
            contexts:
                - App\Tests\Behat\DemoContext
                - App\Tests\Behat\DataManagementContext

Faking a connection

Is it possible to log in manually via the login form? Yes.
But as I told you just before, I want my tests to be fast. Login manually on each scenario is not an option.

Luckily the client has a feature allowing us to log in easily. We just need to get the user, and for that, I will use the user repository.

public function __construct(
    private KernelBrowser $client,
    private UserRepository $userRepository
) {}

/**
 * @Given I am logged in as a user
 */
public function iAmLoggedInAsAUser()
{
    $user = $this->userRepository->findOneBy(['username' => 'john_user']);
    $this->client->loginUser($user);
}

ℹ️️ You can use the UserRepository directly from the constructor because it's defined as a service in this project and because the service_test.yaml file generated at install time registers our contexts in the DIC, nothing is magic, it's just great stuff.

Getting a post and go on its page

It's not the case here so I could just select an article and go on its page, but you may have fixture-generated data for your test. So the article slug may change on each test execution. The following code will work no matter the data are different on each new test or not:

/**
 * @Given I navigate on a post
 */
public function iNavigateOnAPost()
{
    $this->post = $this->postRepository->findAll()[0];
    $this->aDemoScenarioSendsARequestTo(
        '/en/blog/posts/'.$this->post->getSlug()
    );
}

Filling the form

It's actually well documented and super easy:

/**
 * @When I fill a comment with :content
 */
public function iFillACommentWith($content)
{
    $this->response = $this->client->submitForm('Publish comment', [
        'comment[content]' => $content,
    ]);
    $this->response = $this->client->followRedirect();
}

There is however a redirection to follow after the comment is posted.

Count the difference in comments before/after

It's maybe the most tricky part. We need to store the number of comments before and verify after. But in the meantime, we need to refresh the data we gather from the database previously.

An update of the previous method is required :

/**
 * @Given I navigate on a post
 */
public function iNavigateOnAPost()
{
    $this->post = $this->postRepository->findAll()[0];

    // Not storing it is fine, we just need to load the data
    $this->post->getComments()->count();

    $this->aDemoScenarioSendsARequestTo('/en/blog/posts/'.$this->post->getSlug());
}

Once again, there are many ways to do it, but I choose here to just load the result in the first step and then to compare:

/**
 * @Then the post should have a new comment
 */
public function theArticleShouldHaveANewComment()
{
    $previousCount = $this->post->getComments()->count();
    
    // Re-loading the post with fresh data
    $this->post = $this->postRepository->findAll()[0];
    
    $currentCount = $this->post->getComments()->count();
    
    assert($previousCount+1 === $currentCount);
}

That's all for now!

You may now feel that the DemoContext contains too much code, and you are right! Feel free to add as many contexts as you need.

Do you want to write tests in your own language? Some of you probably think about sharing features with the rest of your team. And I can already tell you some of us are already using features directly from the product owner since the gherkin language is super-similar to user stories format.
So yes, you can absolutely write features in your language if you want to. It's documented on the website of behat.

One last thing: behat is often used to make documentation because it tests and explains the case at the same time. For example, you may want to read features of Sylius or simply features of the Symfony Extension of behat. 😉

Follow us on Twitter! https://twitter.com/swagdotind

TL;DR: we are going to functionally test the ls command, the code is here.

Behat is a testing tool for PHP. But before understanding what behat is used for, you need to understand that different types of testing exist.

⚠️ I will try to explain here the differences between the types of tests, but let me warn you: each of us has its own vision of what is each type of test, don't be shocked to have another interpretation of the terms, here you will get mine only.

1. Unit testing: this is the most obvious, but what you should know is that a pure unit test is not using any other thing than the class it tests, any interaction with another object should be mocked.
2. Integration testing: this is basically unit testing, but by using a set of classes. Your test may reflect better the real world but may miss some cases.
3. Functional testing: this is it! That's what behat is about. It's about running your application, giving inputs, getting results, and verifying results. Please note that you can use PHPUnit or PestPHP to build a functional test, behat is better (to me) because it allows the functional test to be readable for people of the business.

But before getting into our first test. You have to know one last thing: behat is special by the syntax it suggests to use. It's called Gherkin, and it comes from... Cucumber: the equivalent of behat for many other languages.

Testing ls

In its documentation, behat shows an example of a test of the command ls. But no code associated with the test. I suggest you to start with testing the ls command of your terminal.

Here is how looks a behat test, it's formatted with gherkin syntax. This test is copy/pasted from the documentation of behat:

Feature: Listing command
  In order to change the structure of the folder I am currently in
  As a UNIX user
  I need to be able see the currently available files and folders there

  Scenario: Listing two files in a directory
    Given I am in a directory "test"
    And I have a file named "foo"
    And I have a file named "bar"
    When I run "ls"
    Then I should get:
      """
      bar
      foo
      """

Let's make this file actually test something!

Creating a project

To test something with behat, it's (obviously) require to have a project up and running. Well, we are not going to code ls, so our project will only contain the test, but we need it anyway!
Start by running those commands in a new folder:

$ composer init --name "acme/test-ls" --description "testing ls with behat" --author "Nek <nek@swag.industries>" --type=project -n
$ composer require --dev behat/behat

At this stage, you have a new PHP project, with behat installed locally. Let's init the project with the behat cli:

vendor/bin/behat --init

Behat generates the following directory structure:

.
├── (composer.json)
├── (composer.lock)
|
|
├── features
│   └── bootstrap
│       └── FeatureContext.php
|
|
└── (vendor)

Behat generates the following directory structure for its tests: you should write the tests in the features directory and the bootstrap directory should contain the code related to your tests.

You may want to run the following command to learn how to use the gherkin language:

$ vendor/bin/behat --story-syntax

Writing the gherkin

This is the easy part, you should describe what you want to test and how in a file that will have the extension .feature, and this file should be located in the features directory.

I suggest you to create this file by taking the example we saw previously:

# features/ls.feature
Feature: Listing command
  In order to change the structure of the folder I am currently in
  As a UNIX user
  I need to be able see the currently available files and folders there

  Scenario: Listing two files in a directory
    Given I am in a directory "test"
    And I have a file named "foo"
    And I have a file named "bar"
    When I run "ls"
    Then I should get:
      """
      bar
      foo
      """

The first lines (2-5) have no actual meaning for our test, it's just some information you'd be glad to find if you have to read a behat test, you can see this as a comment, but here it's part of the language.
The Scenario: keyword starts an actual test. Each line will trigger a function that we will need to define.

Let's run the tests so behat help us with the functions! The option --append-snippets will fill our Context file.

$ vendor/bin/behat --append-snippets

The result should be something like this:

[...]
1 scenario (1 undefined)
5 steps (5 undefined)
0m0.01s (8.37Mb)

 >> default suite has undefined steps. Please choose the context to generate snippets:

  [0] None
  [1] FeatureContext
 >

Just type 1 to tell behat to fill our Context file (we have only one!).

The result should look like this:

<?php

use Behat\Behat\Tester\Exception\PendingException;
use Behat\Behat\Context\Context;
use Behat\Gherkin\Node\PyStringNode;
use Behat\Gherkin\Node\TableNode;

/**
 * Defines application features from the specific context.
 */
class FeatureContext implements Context
{
    /**
     * Initializes context.
     *
     * Every scenario gets its own context instance.
     * You can also pass arbitrary arguments to the
     * context constructor through behat.yml.
     */
    public function __construct()
    {
    }

    /**
     * @Given I am in a directory :arg1
     */
    public function iAmInADirectory($arg1)
    {
        throw new PendingException();
    }

    /**
     * @Given I have a file named :arg1
     */
    public function iHaveAFileNamed($arg1)
    {
        throw new PendingException();
    }

    /**
     * @When I run :arg1
     */
    public function iRun($arg1)
    {
        throw new PendingException();
    }

    /**
     * @Then I should get:
     */
    public function iShouldGet(PyStringNode $string)
    {
        throw new PendingException();
    }
}

Notice how behat created annotations that will be read to match functions to sentences. You can see text in quote is transformed into an argument for the function. You can use many of them and change their name as well.

The actual test

Sentence 1: « I'm in a directory »

We just need to create a directory in a location of our choice.

    private string $directory;

    /**
     * @Given I am in a directory :directoryName
     */
    public function iAmInADirectory($directoryName)
    {
        $this->directory = __DIR__ . '/../../tmp/'.$directoryName;
        if (file_exists($this->directory)) {
            exec("rm -r {$this->directory}");
        }
        mkdir($this->directory, recursive: true);
        chdir($this->directory);
    }

As you can see, this is straightforward. I'm using basic PHP to create just what I need, this is fine, we're in a testing environment, locally or in a specific environment.

I take the time to add a property directory to my context so I can reuse it in other steps.

Sentence 2: « I have a file named »

The code will be super-simple here, we do not need any specific file:

    /**
     * @Given I have a file named :filename
     */
    public function iHaveAFileNamed($filename)
    {
        touch($filename);
    }

Sentence 3: « I run »

This may be the hardest one!

    private string $output;

    /**
     * @When I run :commandName
     */
    public function iRun($commandName)
    {
        exec("$commandName", $output);
        // PHP store array lines in an array
        // we need to make it a string to compare
        $this->output = implode("\n", $output);
    }

Sentence 4: « I should get »

Finally, we are going to verify that the output of our ls execution returned the expected output.

    /**
     * @Then I should get:
     */
    public function iShouldGet(PyStringNode $expectedOutput)
    {
        assert($this->output === $expectedOutput->getRaw());
    }

I use here the standard assertion of PHP, but you can also use PHPUnit assertions or the package from webmozart that helps you write assertions. Feel free to use what you used to!

This is it!

If you run the test now, you should see something like this :

And congratulation for your first behat test 🙌 !

This is obviously not testing your PHP application, but you really have all the basics here. You need an HTTP server to test your app? Just run one! You need a WebSocket server to run your app? Just start it! It's really just how you should do.

Of course, some tasks may become repetitive, this is why we are going to cover some tooling you can use with behat in 2 more articles focused on real-world PHP application testing.

See you next week for the next article! 🤘

Follow us on Twitter! https://twitter.com/swagdotind

Java has jar files. PHP has phar files.

Those files are PHP projects packaged. You may know them through usages like composer or PHPUnit. But phar files were designed by taking into consideration the nature of PHP: the web.
Therefore, we're going to try to show how to build a phar either "classic" or "web" oriented in this tutorial.

What is a phar exactly?

A phar is basically many files assembled in only one. But it is composed of the following content:

• A stub: this is the very first piece of code that will be executed when you run your phar. It can be either automatically generated or entirely customized.
  This part in the file usually starts with <?php and ends with __HALT_COMPILER();.
  The stub is some kind of pre-front-controller. It will drive PHP to get the correct thing depending on the "entry". For that to work, it uses the Phar API.
• Some binary containing metadata of the package: filenames, their start/end in the current file, some information about the entry point...
• The concatenation of all your files (potentially compressed)

To generate the phar, we will need to make a builder script (in PHP) and we will use the Phar API.

Making a phar for the cli

Before you begin, you may need to enable a special capability in your php.ini file. The following configuration may be set on your installation:

[Phar]
; http://php.net/phar.readonly
phar.readonly = On
; Set it to Off

It is required to set the option readonly to Off.

The goal will be to generate a file app.phar that is executable from the cli directly. On my side I create a folder named app that contains the two following files:

<?php
// app/index.php

// This will be the entry point

echo "<h1>Hello from PHP</h1>";

<?php
// app/vendor.php

function hello() {
    echo "Im a function part of whatever vendor you may think.";
}

I will then create my builder that uses the class Phar. Here is how to process, I let you go to the documentation to learn more.

<?php
// builder.php

$pharFile = 'app.phar';

// clean up
if (file_exists($pharFile)) 
{
    unlink($pharFile);
}

$phar = new Phar($pharFile);

// First thing to do is to start the buffering
// otherwise no other action will be possible.
$phar->startBuffering();

// Here I get get the default stub for .phar files
// it's allowed to customize it entirely, but it's
// recommended only for advanced usage.
// I also specify my entry point (the front controller)
$defaultStub = $phar->createDefaultStub('index.php');

// Let's all the rest of the files
$phar->buildFromDirectory(__DIR__ . '\\app');

// Customizing the stub
// What we add here allow to execute the file
// without a call to PHP with an unix OS
// *it will not work on windows* (but will not be a problem either)
$stub = "#!/usr/bin/env php \n" . $defaultStub;

// Add the stub
$phar->setStub($stub);

// Generating the file
$phar->stopBuffering();

// Some compression option are available.
// Most common are GZ and ZIP. (for many obvious reason)
// And yes, PHP do it afterwards so it must be at the end.
$phar->compressFiles(Phar::GZ);

# Make the file executable
chmod(__DIR__ . '/app.phar', 0770);

If you run this script, you should see a file app.phar generated. Success!

Let's use this app.phar. Under Linux, as stated in the comments you should be able to use it this way:

./app.phar

If you use Windows, you need to call directly PHP this way:

php app.phar

And finally, if you want to use this phar as a library, you can use the following code:

<?php

require_once 'phar://app.phar/vendor.php';

hello();

Making a phar file for the web

That was easy, isn't it? Let's take this to the next level. If you want to make a phar file ready for the web it's possible.

If you take the last example, just remove the custom stub and execute the phar file with the following command:

php -S localhost:8000 app.phar

Then go to https://localhost:8000, the magic should happen. But there's more!

What is a website without assets? Yes, you can add them into your archive, but everything will pass through your front controller (in my case, index.php). So your code must require the assets when PHP asks for them. Here is an example of support for PNG.

<?php

// current file is index.php, the entry point

function index() {
	echo "<h1>Hello from PHP</h1>";
	echo '<img src="/images/some-image.png" />';
}


// index.php is now mostly a router (a real front controller if you prefer)
switch ($_SERVER['REQUEST_URI'] ?? '/') {
	case '/':
	case '/index.php':
		index();
		break;
	default:
		// PHP will look inside the phar!
		if (file_exists(__DIR__ . $_SERVER['REQUEST_URI'])) {
			// This simple example is crap, but you got the idea.
			if (str_ends_with($_SERVER['REQUEST_URI'], 'png')) {
				header('Content-Type: image/png');
			}
			require __DIR__ . $_SERVER['REQUEST_URI'];
			exit;
		}
		http_response_code(404);
		echo "<h1>The content does not exists";
}

If you really want to do something like this, I suggest you to use the component HttpFoundation of Symfony with its router or some vendor that will do the job for you. (yes, you can add vendors to your folder, it's PHP, it will just work fine)

Finally, I wanted to introduce you to something you can't do: edit a file inside the phar. For example, the following code will actually work:

file_put_contents(__DIR__ . DIRECTORY_SEPARATOR . 'tmp.txt', 'yolo');

But it modifies the phar file itself and corrupts it definitely. Thus you simply can't write a file in the current directory.

Other ways to generate a phar

Let me add one last thing. In every test until now, I suggested you to create a folder and add this one to a file. But there are actually 2 other methods to make a phar.

A phar based on an archive

If you have a zip (or gz or whatever) file, no problem. PHP can create a phar from it. You just need to tell PHP at the instantiation of the phar:

<?php

@unlink('app.phar');
copy('app.tar.gz', 'app.phar');
$phar = new Phar('app.phar');

A phar based on nothing

You can generate the phar file entirely from your script, here is an example:

<?php

$phar = new Phar('app.phar');
$phar->startBuffering();
$phar['index.php'] = '<?php include "config.php"; echo $username;';
$phar['config.php'] = '<?php $username = "Nek";';
// ... You already know the end

You can also combine all the methods and finally override some files with this last one.

Hope you liked it! Find out something missing? Feel free to comment!

Follow us on Twitter! https://twitter.com/swagdotind

Symfony 4 brought us the awesome Mailer Component. Something that you may not know about it, is how to test if an email has been sent. This is something not well known, but actually easy!

Let's see together how to do it with PHPUnit, but also with Behat - since it's about functional testing more than unit testing, doing it with Behat makes more sense to me.

Here is the controller that we are going to test in the following sections:

/**
 * @Route(path="/sendmail", name="sendmail")
 */
public function index(MailerInterface $mailer): Response
{
    $email = (new Email())
        ->from('hello@example.com')
        ->to('you@example.com')
        ->subject('I use Symfony mailer woohoooooo')
        ->text('This is the content of the email')
        ->html('<p>Simple HTML will be ok for this example, but you can obviously use twig for it.</p>');

    $mailer->send($email);

    return $this->json(['message' => 'Simple response that we dont really care here']);
}

Testing Symfony emails with PHPUnit

Even if it's not documented; testing emails is really super easy. But before getting into the actual test, you may be interested about how to not send emails for real. And here again, it is simple: you just have to change the value of the environment variable MAILER_DSN, and here is how:

# file .env.test
MAILER_DSN=null://null

And here is the code that allows us to test it:

public function testSomething()
{
    $client = static::createClient();
    $client->request('GET', '/sendmail');
    $this->assertEmailCount(1);
}

This test only verifies that an email has been sent, but you have many possibilities of assertions thanks to the MailerAssertionsTrait trait.

Testing with Behat tests (using the kernel)

⚠ This approach assumes that you are testing by using the kernel directly, you can do it very easily by using the Symfony extension. It means that it cannot work with selenium, in this case you may be interested by the last section of this article.

In the previous section I told you about the MailerAssertionsTrait, and you can use it on your behat context under 2 conditions:

1. You must extend PHPUnit\Framework\Assert from PHPUnit
2. You must have a static variable with your container

I personally think those 2 conditions are extremely restrictive so I decided to use another approach: I copied/pasted the code of this trait, and modified it. The most important method to redefine is getMessageMailerEvents, and here my version of it (beware, it is static in the original trait):

private function getMessageMailerEvents(): MessageEvents
{
    if (!$this->container()->has('mailer.logger_message_listener')) {
    	Assert::fail('A client must have Mailer enabled to make email assertions. Did you forget to require symfony/mailer?');
    }

    return $this->container()->get('mailer.logger_message_listener')->getEvents();
}

This approach is very helpful if you want to add your own methods. Here is one I use in my test (you may like it or not, here it is), this method returns a link contained in the HTML version of your mail:

public function getLinkInEmail(string $containing = '', int $index = 0, string $transport = null): string
{
    $message = $this->getMailerMessage($index, $transport);

    if (null === $message) {
        Assert::fail('There is no email');
    }
    if (RawMessage::class === \get_class($message)) {
        throw new \LogicException('Unable to test a message HTML body on a RawMessage.');
    }

    preg_match_all('/"(https?:\/\/[a-zA-Z0-9\-.]+\.[a-zA-Z]{2,3}(\/\S*)?)"/', $message->getHtmlBody(), $urls);

    foreach ($urls[1] as $url) {
        if (StringTools::contains($url, $containing)) {
            return $url;
        }
    }

    Assert::fail('No URL found for the pattern '.$containing);
}

Now by using your trait inside your behat contexts, you can easily test emails.

Testing emails with Behat/Mink and Selenium (or external approach)

Here you can't use the tooling that Symfony provides, so you will need to be a little bit more creative. The following example is something that works and that you can customize to fit your needs (or for better code quality, this is super-raw here).

I suggest you to use a redis instance. For this test to work I used a redis docker with no special configuration: it just works.

First step: a custom Symfony Mailer transport

Defining a custom transport for Symfony Mailer is really simple: you need a factory that instantiate a transport, and this factory should be tagged as transport factory in the dependency injection, it's basically 3 files.

In the transport we will just store inside redis that we sent a mail.

<?php

namespace App\Test;

use Symfony\Component\Mailer\Exception\UnsupportedSchemeException;
use Symfony\Component\Mailer\Transport\AbstractTransportFactory;
use Symfony\Component\Mailer\Transport\Dsn;
use Symfony\Component\Mailer\Transport\TransportInterface;

class BehatMailerFactory extends AbstractTransportFactory
{
    public function create(Dsn $dsn): TransportInterface
    {
        if (!\in_array($dsn->getScheme(), $this->getSupportedSchemes(), true)) {
            throw new UnsupportedSchemeException($dsn, 'behat', $this->getSupportedSchemes());
        }

        return new FakeRedisMailerTransport();
    }

    protected function getSupportedSchemes(): array
    {
    	// This is important for the Symfony to find the related
        // transport for the DSN we provide
        return ['behat'];
    }
}

<?php

namespace App\Test;

use Predis\Client;
use Symfony\Component\Mailer\Envelope;
use Symfony\Component\Mailer\SentMessage;
use Symfony\Component\Mailer\Transport\TransportInterface;
use Symfony\Component\Mime\Address;
use Symfony\Component\Mime\Email;
use Symfony\Component\Mime\RawMessage;

class FakeRedisMailerTransport implements TransportInterface
{
    /**
     * @param Email $message
     */
    public function send(RawMessage $message, Envelope $envelope = null): ?SentMessage
    {
        // Instantiating predis here is not awesome, in real usage
        // I suggest you to use the redis bundle
        $client = new Client();
        
        // If you get the original value, you can just increment it
        $client->set('email_count', 1);

        // Oh yes I know. This part really sucks.
        // I just wanted to have the simplest example
        // But you have all you want inside the $message object
        // which is an Email instance, not just a RawMessage.
        return new SentMessage(
            $message,
            new Envelope(
                new Address('foo@bar.com'),
                [new Address('bar@foo.com')]
            )
        );
    }

    public function __toString(): string
    {
        return 'behat';
    }
}

# services.yaml
services:
    App\Test\BehatMailerFactory:
        tags:
            - {name: 'mailer.transport_factory'}

And we can now use the following DSN for our tests: behat://null

Second step: the behat context

Let's start this part with the actual feature we want to test:

# my-feature.feature
Feature:
  As a user
  blah blah blah (you should say a lot here)

  @email
  Scenario: It sends email
    Given I send an email
    Then an email has been sent

So we need to have 2 step, here is an example of how you can do it:

/**
 * @Given I send an email
 */
public function iSendAnEmail()
{
    $client = \Symfony\Component\HttpClient\HttpClient::create();
    $response = $client->request('GET', 'http://localhost:8001/sendmail');

    Assert::eq($response->getStatusCode(), 200);
}

/**
 * @Then an email has been sent
 */
public function anEmailHasBeenSent()
{
    $client = new Predis\Client();
    $value = $client->get('email_count');
    Assert::greaterThan($value, 0);
}

And here we are, you have a test that passes on the CI!

Bonus part: cleaning redis

After the test is executed, if the mail is no more sent, the test will pass: that's because the first test added data to redis and didn't clean it.

You may have notice that I used the tag @email in the feature file, nothing innocent here. It's because I use a behat hook to clean my email data in redis. Here is how to do it for our current example:

/**
 * @AfterScenario email
 */
public function cleanEmail()
{
    $client = new Predis\Client();
    $client->set('email_count', 0);
}

This concludes this little tutorial. I hope you liked it.

Follow us on Twitter! https://twitter.com/swagdotind

PHP provides the function memory_get_usage(), this is very helpful whenever you find your code using a lot of RAM. But this method has a significant limitation: it only counts memory used by your code directly and nothing out of the zend engine.

The problem is that you may use external libraries, a typical example is using libxml to parse any XML file. And you may want to know how much memory it uses. On linux it's pretty simple since you can parse the file /proc/{pid}/status but on macOS it's more complicated as this file does not exist.

And it looks like there is no easy solution. In my use case, as I wanted to monitor a single process, I decided to use top directly. So here is my solution:

$pid = getmypid();

echo exec("top -pid $pid -l 1 | grep $pid | awk '{print $8}'") . "\n";

Here are the details for what it does:

• It runs top in log mode with only 1 iteration (-l 1) and only for your pid
• It grep the line with your pid since top outputs a lot more
• It finally get the 8th column using awk

This did the trick for me. It even shows human format for the memory size used. If you have any better/easiest/more reliable idea, feel free to comment!

Follow us on Twitter! https://twitter.com/swagdotind

The strategy pattern is a very easy implementation with the DIC from Symfony. Here is how:

First let's define an interface for our strategies:

namespace App\Domain\CustomProcess;

interface MyStrategyInterface
{
    public function execute(Whatever $input);
    public function supports(Whatever $input);
}

Then, we will add the tag app.my_strategy in our services.yaml file, so every service which implements the previous interface will automatically receive the tag.

services:
    _instanceof:
        App\Domain\CustomProcess\MyStrategyInterface:
            tags: ['app.my_strategy']

Still in our services.yaml file you can then use the following syntax:

services:
    App\Domain\Doer:
        arguments:
            $strategies: !tagged_iterator app.my_strategy

An example for a Doer class could be the following:

class Doer
{
    private iterable $strategies;
    
    public function __construct(iterable $strategies)
    {
        $this->strategies = $strategies;
    }
    
    public function doSomeWorkOnInput(Whatever $input)
    {
        // In here, you could imagine an algorithm that will try to guess
        // what is the best strategy, but I added a support method
        // on the interface do we will use it.
        foreach ($this->strategies as $strategy) {
            if ($strategy->support($input)) {
                return $strategy->execute($input);
            }
        }
        
        throw new ApplicationLogicException('The given input is not supported.');
    }
}

Hope you'll like it!

Bonus!

If you do not want to manually define your service for the Doer class or if you want to inject the strategy in many places, you can use the section bind of the service.yaml file to enable autowiring for your strategy!

services:
    _defaults:
        bind:
            # I would recommend a better name, but at least you get it
            iterable $strategies: !tagged_iterator app.my_strategy
    

Follow us on Twitter! https://twitter.com/swagdotind

The Symfony documentation describes quite well how locks actually work, that's why this article will not describe why you should use a lock and how it actually works. But it says nothing about the short time installation it requires to set it up and run!

Let's see that together.

Install the lock component with composer just like any other Symfony component:

composer require lock

This component is one of the rare components that will not come with a recipe, you need to add the configuration yourself, and it's quite easy.

# In the file packages/lock.yaml
framework:
    lock: 'redis://localhost'

This is an example to configure a redis, but it could work with your database directly: lock: '%env(DATABASE_URL)%'

Here is a command that uses our lock, it's that simple!

class LockTestCommand extends Command
{
    protected static $defaultName = 'app:lock-test';

    // In Symfony 5.2 you can inject directly the lock factory
    // because the RetryTillSaveStore (see bellow) is no more required
    private PersistingStoreInterface $lockStore;

    public function __construct(PersistingStoreInterface $lockStore)
    {
        $this->lockStore = $lockStore;
        parent::__construct();
    }

    protected function configure()
    {
        $this
            ->setDescription('This is a simple lock test')
        ;
    }

    protected function execute(InputInterface $input, OutputInterface $output): int
    {
        $io = new SymfonyStyle($input, $output);

        // Depending on what store you uses, you may need to decorate the store
        // to be able to use the `BlockingStoreInterface` feature
        // and it's required for the redis store.
        $store = new RetryTillSaveStore($this->lockStore, retrySleep: 100, retryCount: 1000); // 100ms 1000 times try
        
        // In the case we decorate the store we need to create by hand the factory
        $lockFactory = new LockFactory($store);
        $lock = $this->lockFactory->createLock('test-lock');

        // Passing "true" will enforce the waiting for the lock to be available
        if (!$lock->acquire(blocking: true)) {
            $io->success("Cannot acquire the lock");
            return 1;
        }

        $io->success("Lock acquired");
        $this->task();

        $lock->release();

        return 0;
    }

    private function task()
    {
        sleep(10);
    }
}

The previous configuration only registers the default lock (and its store and factory) that will be automatically injected to your services. But you can actually define many locks (and keeping the default one!). Here is how:

framework:
    lock:
        default: '%env(DATABASE_URL)%'
        redis_high_availability: ['redis://r1.docker', 'redis://r2.docker']

This will generate a lock factory as a service named lock.redis_high_availability.factory, and you will need to specify it explicitely in your services configuration to use it.

I hope it helps! Please let us know in the comments if there's any mistake or a better way to do it.

Follow us on Twitter! https://twitter.com/swagdotind