Kamil Kokot

SymfonyExtension 2.1: Behat with Symfony 5

Sun, 05 Apr 2020 00:00:00 GMT

Friends of Behat’s SymfonyExtension becomes more and more popular as the downloads rose almost fivefold in the last year. I’m happy to announce the new release bringing support for Symfony 5 and PHP 7.4, together with functional improvements.

If you haven’t got to know it before, I’d recommend reading the last release announcement.

Symfony 5 and PHP 7.4 support

With Symfony 5 and PHP 7.4 released in late November 2019, adding support for it was only a matter of time. Behat officially started supporting those in early February 2020 and SymfonyExtension was ready for it shortly after.

Unfortunately, Mink ecosystem was lagging behind. Since most of the projects rely on both Behat and Mink, I’ve decided to fork those libraries to Friends of Behat organisation. This way, I could quickly release drop-in replacements for problematic libraries, having Symfony 5 support as my only objective - any other improvements or changes are currently not accepted.

The mentioned packages are behat/mink, behat/mink-extension and behat/mink-browserkit-driver. To use the forked versions, replace behat with friends-of-behat in their name, ending up with friends-of-behat/mink, friends-of-behat/mink-extension and friends-of-behat/mink-browserkit-driver respectively.

SymfonyExtension 2.1 removes support for Symfony 3.4, leaving Symfony ^4.4 and ^5.0 as the only supported versions. As for PHP, all versions between 7.1 and 7.4 are currently supported.

Learn more: Symfony 5, PHP 7.4.

Mink’s driver service container exposed

Raised multiple times in issues on the repository, the 2.0 release removed the possibility of getting into Mink’s driver service container easily. Getting it is especially helpful when you want to assert emails sent or messages dispatched during the last HTTP request.

Starting from SymfonyExtension 2.1, you only need to inject behat.driver.service_container service or ask for ContainerInterface $driverContainer to get access to your services within the tested application, both private and public.

final class SomeContext implements Context {
    /** @var Session */
    private $minkSession;
    
    /** @var ContainerInterface */
    private $driverContainer;

    public function __construct(Session $minkSession, ContainerInterface $driverContainer)
    {
        $this->minkSession = $minkSession;
        $this->driverContainer = $driverContainer;
    }

    /** @When I visit the page :page */
    public function visitPage(string $page): void
    {
        $this->minkSession->visit($page);
    }

    /** @Then the counter service should return :number */
    public function counterServiceShouldReturn(int $number): void
    {
        assert($number === $this->driverContainer->get('App\Counter')->getCount());
    }
}

Learn more: Driver service container exposed.

Simple BrowserKit integration

If you don’t need Mink’s flexibility, the latest release contains a simple integration with BrowserKit. Whenever you require Symfony\Bundle\FrameworkBundle\KernelBrowser or Symfony\Component\HttpKernel\HttpKernelBrowser in your context, it’ll be autowired to test.client service.

final class SomeContext implements Context 
{
    /** @var KernelBrowser */
    private $browser;

    public function __construct(KernelBrowser $browser)
    {
        $this->browser = $browser;
    }

    /** @When I visit the page :page */
    public function visitPage(string $page): void
    {
        $this->browser->request('GET', $page);
    }
}

Learn more: BrowserKit integration.

Mink service exposed

As 2.0 has only supported exposing Mink’s default session, 2.1 brings more flexibility in that manner. It is possible to both inject and autowire the whole Mink service to your context now.

final class SomeContext implements Context
{
    /** @var Mink */
    private $mink;

    public function __construct(Mink $mink)
    {
        $this->mink = $mink;
    }

    /** @When I visit the page :page */
    public function visitPage(string $page): void
    {
        $this->mink->getSession()->visit($page);
    }
}

Learn more: Mink.

FOB’s PageObjectExtension integration

Friends of Behat’s PageObjectExtension is a Behat extension inspired by SensioLabs’ PageObjectExtension, that is used by Sylius to abstract away pages and elements details from Behat contexts. Unfortunately, the latter could not be supported by SymfonyExtension, due to using Mink’s Element classes which breaks lazy-loading for Mink integration.

Within this integration, all the pages and elements are autowired and autoconfigured, which reduces the need to write boring infrastructure code. When in doubt, take a look at the feature file in SymfonyExtension or its usage in Sylius.

final class LoginContext implements Context
{
    /** @var LoginPageInterface */
    private $loginPage;

    public function __construct(LoginPageInterface $loginPage)
    {
        $this->loginPage = $loginPage;
    }

    /** @When I log in as :username */
    public function iWantToLogIn(string $username): void
    {
        $this->loginPage->open();
        $this->loginPage->login($username, 'password');
    }
}

Learn more: FOB’s PageObjectExtension, SensionLabs’ PageObjectExtension.

Conclusion

SymfonyExtension is on its way to surpass one million downloads in the next month. I’m pleased to create a library that is useful and removes friction when adopting BDD and automatizing scenarios.

As for the future developments, I’d like to replace Mink with a dedicated, Symfony-based alternative API. Publishing a tutorial on making use of BDD within Symfony 5 application context is also an interesting idea. Feel free to let me know what would you like to see first!

Seven Commands to Bulletproof Your Symfony Application CI Build

Sun, 12 Jan 2020 00:00:00 GMT

Over the course of years, I noticed there are more and more checks that are usually performed in our Symfony applications’ CI environment. This is my attempt at writing down the most useful ones.

Table of contents:

Checking for security vulnerabilities
Validating package configuration
Linting Symfony container
Linting Twig templates
Linting YAML files
Testing Doctrine migrations
Validating Doctrine mappings

1. Checking for security vulnerabilities

Security should be the most critical concern while developing any application. It should come as no surprise that there are multiple solutions for ensuring that our application does not rely on dependencies with known vulnerabilities. Although they differ in usage, they are all based on the same source - FriendsOfPHP/security-advisories.

Symfony CLI

It is provided together with the Symfony binary, which is a recommended way to create new Symfony projects and includes a convenient local web server, which comes handy during development.

If you already use it as a web server in your CI build, I would recommend using it also for security checks.

symfony security:check

If you do not have it in your CI build yet, the following .travis.yml configuration does the job:

cache:
    directories:
        - ~/.symfony

before_install:
    - |
        if [ ! -f ~/.symfony/bin/symfony ]; then
            wget https://get.symfony.com/cli/installer -O - | bash
        fi

script:
    - ~/.symfony/bin/symfony security:check

SensioLabs Security Checker

SensioLabs/SecurityChecker is what I’ve been using before switching to Symfony CLI. It uses security.symfony.com API to perform the check, which means your composer.lock will be uploaded there.

To use it, add sensiolabs/security-checker to your require-dev section in composer.json and then run the following command:

vendor/bin/security-checker security:check

Roave Security Advisories

While the previous two tools work in a similar way, Roave/SecurityAdvisories takes a different approach.

It is a Composer package which defines vulnerable packages as its conflicts, preventing them from being installed and resulting in irresolvable dependencies. This behaviour is a double-edged sword - it does not trigger when packages dependencies are installed from the lock file.

My recommendation is to require this package only in the CI build:

composer install
composer require --dev roave/security-advisories

However, resolving dependencies in complex projects takes a lot of time, which makes me prefer the other solutions.

2. Validating package configuration

Composer provides a command to validate your composer.json and composer.lock files. It checks whether your lock file is up-to-date, whether used constraints are not too loose or too strict and whether the package is valid to be published on Packagist.

composer validate --strict

There are a few switches available for this command:

--strict

Makes the command return non-zero code for warnings as well as errors. For example, having overly strict dependency (1.0.0 instead of ^1.0) in require section will trigger a warning.
--no-check-all

Disables checking for overly strict or unbound dependencies in require section. Even without this switch, it does not check the dependencies defined in require-dev section.
--no-check-lock

Disables checking whether the lock file is up-to-date.
--no-check-publish

Ignores errors which prevent the package from be published on Packagist. Useful for internal applications that will not be published, but required for open source packages.

I would recommend you starting with the most strict check and ignoring some parts later if needed.

3. Linting Symfony container

Introduced with Symfony 4.4, linting the container might help in finding dead services configurations. We found a few in Sylius and decided to add it to the build to prevent us from introducing them anymore.

bin/console lint:container

4. Linting Twig templates

Linting your Twig templates checks their syntax and might detect unused templates if an unexisting filter or function is used in those. After running it on Sylius codebase, it has found a template calling parent blocks while not extending any template itself and another template calling an unexisting filter.

bin/console lint:twig templates

Starting from Symfony 4.4, this command also includes a way to report usages of deprecated Twig features. It helped greatly with the upgrade to Twig 3.

bin/console lint:twig templates--show-deprecations

I would not recommend adding deprecation checks to your CI build as it would make it more unstable - any deprecation in next Twig version would make it fail.

5. Linting YAML files

It is easy to make errors writing YAML files compared to XML. Therefore, it is essential to get feedback on those as fast as possible.

bin/console lint:yaml config src translations

6. Testing Doctrine migrations

If you provide Doctrine migrations in your application, it is desirable to test them. Most applications include the following line in their CI builds:

bin/console doctrine:migrations:migrate --no-interaction

While this covers the most common path, it does not test reverting these migrations.

bin/console doctrine:migrations:migrate --no-interaction
bin/console doctrine:migrations:migrate first --no-interaction
bin/console doctrine:migrations:migrate --no-interaction

These three commands will first create the schema in the database, then revert the changes and create it once again.

7. Validating Doctrine mappings

After the migrations have been run or the database schema has been synchronised in any other way, it’s worth to validate your Doctrine mappings and whether they’re correctly synchronised with the database schema.

It can be done with the following command:

bin/console doctrine:schema:validate

Conclusion

Surely, this list is non-exhaustive: it completely misses static analysers, testing frameworks, coding standard fixers and automation tools, which I would like to include in another blog post in this series.

What it mainly focuses on are commands that can be added with little effort but might be often overlooked. If you use one of those, but it wasn’t mentioned above, let me know in the comments!

Tame Behat with the Brand New Symfony Extension

Mon, 11 Feb 2019 00:00:00 GMT

Over two years after the first release of this Friends of Behat’s Symfony Extension, I’m happy to announce the availability of the second major version and write more about it.

It is the already battle-tested solution with Sylius on 1300+ scenarios containing 14000+ steps, getting traction in projects like Akeneo or Monofony.

The mission behind it is to simplify the process of implementing Behat contexts so that you can focus on the communication with stakeholders and writing down business features instead of figuring out low-level testing infrastructure details.

TL;DR

Support for Symfony’s autowiring and autoconfiguration
Symfony Flex contrib recipe to make installation easier
Zero-configuration for most Symfony 3 and 4 based apps
Unified application configuration and dotenv file handling (similar to the PHPUnit one)
Integration with Mink, available out of the box
Simplified usage, reduced the number of extensions from three to one
Improved developer experience with more descriptive exceptions and more predictable overall behaviour

If you want to try it first, dive straight into the documentation.

Support for Symfony’s autowiring and autoconfiguration

Ever since I have started working with Behat and Symfony on more complex projects, the number of configuration changes needed to implement even simple steps was an issue and it was going worse and worse.

Whether it was Behat/Symfony2Extension or FriendsOfBehat/SymfonyExtension, injecting a dependency into a context required too much hassle and pulled me away from the domain being modelled.

The common use case is to have a context which implements a step like Given I am a logged in customer that is used in every suite which does web acceptance testing.

Let’s assume we need two Behat suites using the same context depending on kernel service and compare the required configuration for every Symfony extension for Behat out there.

Behat/Symfony2Extension

# behat.yml
first_suite:
    contexts:        - FeatureContext:            kernel: '@kernel'            
second_suite:
    contexts:        - FeatureContext:            kernel: '@kernel'

This snippet does not look that bad, mostly because of its size. It gets longer and longer with every new dependency or suite though. Adding a new dependency to a context requires changing the configuration of every suite.

FriendsOfBehat/SymfonyExtension v1

Finding all places where a context is used and modifying its dependencies is a boring work, which I wanted to avoid in the first version of FOB’s SymfonyExtension.

It was possible by registering contexts as services, which fundamentally changes the way you use them in Behat. This is why I decided to write my own extension to integrate Behat with Symfony.

# behat.yml
first_suite:
    contexts_services:        - FeatureContext            
second_suite:
    contexts_services:        - FeatureContext

# Symfony services file loaded by the extension
services:
    FeatureContext:
        arguments:
            - '@__symfony__.kernel'        tags: ['fob.context_service']

The duplication is removed, but it has introduced more boilerplate code and own conventions which are hard to get at first:

__symfony__ prefix when referencing service from Symfony application container prevented autocomplete in IDEs from working correctly
fob.context_service tag was required by the internal infrastructure to be able to use a service as a context, but it caused bugs quite often as it was so easy to forget it
contexts_services instead of default contexts has not introduced any measurable benefit, it was supposed to prevent conflicts with the default configuration if one does not use context services in every suite

The whole process of registering contexts manually was far from pleasant.

FriendsOfBehat/SymfonyExtension v2

The newest version reduces required boilerplate code by incorporating autowiring and autoconfiguration as first-class mechanisms and sticking to the already known conventions.

# behat.yml
first_suite:
    contexts:        - App\Tests\Behat\FeatureContext            
second_suite:
    contexts:        - App\Tests\Behat\FeatureContext

If your context constructor has kernel argument type-hinted, this is all you need to make it work.

No need to worry about duplicated configuration, weird conventions, tagging contexts or using prefixes when referring to services. And you can inject private services as well!

The extension provides a dependency injection configuration which automatically finds your contexts and autowires them:

# config/services_test.yaml
services:
    _defaults:
        autowire: true
        autoconfigure: true

    App\Tests\Behat\:
        resource: '../tests/Behat/*'

The following file is loaded only in the test environment. Your production and development environments are not affected with any performance loss. However, if you prefer not to rely on autowiring, you can define the context as a service on your own - remember to make it public though:

# config/services_test.yaml
services:
    App\Tests\Behat\FeatureContext:
        arguments:
            - '@kernel'
        public: true

Symfony Flex recipe

If you use Symfony Flex to manage your Symfony application, installation and configuration of the extension could not be easier.

All you need to do is to install the extension and agree for installing a contrib recipe for it:

composer install friends-of-behat/symfony-extension:^2.0 --dev
composer exec behat

In less than a minute you have a working setup of Behat with SymfonyExtension and you are ready to write your features.

If you do not use Symfony Flex, follow the installation documentation.

Zero-configuration for most Symfony 3 and 4 based apps

Whether you use Symfony 3 or Symfony 4, the new extension got you covered.

It will try to guess the sensible default configuration and in most cases, you will not need to write any more configuration than the following (assuming Flex have not done it for you):

# behat.yml
default:
    extensions:
        FriendsOfBehat\SymfonyExtension: ~

Learn more about the default settings.

Mink integration

This extension provides a driver for Mink based on BrowserKit called symfony.

If you switch from Behat\Symfony2Extension, the behaviour stays mostly the same. There is only one minor implementation detail that is worth to know.

symfony2 driver from the former extension uses the same kernel for both fetching application services and handling requests. This might lead to unexpected results if your code is not idempotent and relies on services state.

Given the following scenario and its implementation:

# Please do not write scenarios like this
# It is just for demonstration purposes
Given the service state is set to 42
Then I should get 42 from the API
And I should get 42 from the API

# Context implementation
/**
 * @Given the service state is set to :state
 */
public function serviceStateIs(string $state): void
{
    $this->service->setState($state);
}

/**
 * @Then I should get :state from the API
 */
public function iShouldGetFromAPI(string $state): void
{
    $this->minkSession->visit('/api/');
    assert($state === $this->minkSession->getPage()->getContent());
}

# Symfony controller
public function __invoke(): Response
{
    return new Response($this->service->getState());
}

This scenario would fail on the second Then step when using Behat\Symfony2Extension.

It happens because the kernel is rebooted after each request, so that the first Then step one uses the same container that is used in Behat Given step before, but the second Then step uses a rebooted container which does not share the same state. This might make your tests fragile, eg. when you change assertions order.

When run with FriendsOfBehat\SymfonyExtension, the scenario would fail on the first Then step because the service state is not shared between Behat and HTTP application.

If you want to learn more, check out the documentation about differences between Symfony extensions or the documenation about Mink integration.

What’s next?

With all those new, shiny features mentioned above, there are still a few ideas in my mind that would be great to see in the future:

I made a GitHub project which is used as a roadmap for this project.