The SymfonyExtension & Clearing Data Between Scenarios

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

Change the user and pass back to match the original user in the database: "admin" and "admin":

... lines 1 - 6
Given there is an admin user "admin" with password "admin"
... lines 8 - 14

Now rerun the scenario:

./vendor/bin/behat features/web/authentication.feature

Boom! This time it explodes!

Integrity constraint violation: UNIQUE constraint failed: user.username

We already have a user called "admin" in the database... and since I made that a unique column, creating another user in Given is putting a stop to our party.

Clearing the Database Before each Scenario

Important point: you should start every scenario with a blank database. Well, that's not 100% true. What I want to say is: you should start every scenario with a predictable database. Some projects have look-up tables - like a "product status" table with rows for in stock, out of stock, back ordered, etc. I really hate these, but anyways, sometimes there are tables that need to be filled in for anything to work. You'll want to empty the database before each scenario... except for any lookup tables.

Since we don't have any of these pesky look-up guys, we can empty everything before every scenario. To do this, we'll of course, use hooks.

Create a new public function clearData():

... lines 1 - 13
class FeatureContext extends RawMinkContext implements Context, SnippetAcceptingContext
... lines 16 - 44
public function clearData()
... lines 47 - 49
... lines 51 - 95

Clearing data now is pretty easy, since we have access to the entity manager via self::container->get('doctrine')->getManager();:

... lines 1 - 46
$em = self::$container->get('doctrine')->getManager();
... lines 48 - 97

Now we can issue DELETE queries on the two entities that we care about so far: product and user. I'll use $em->createQuery('DELETE FROM AppBundle:Product')->execute();:

... lines 1 - 47
$em->createQuery('DELETE FROM AppBundle:Product')->execute();
... lines 49 - 97

Copy and paste that line and change "Product" to "User":

... lines 1 - 48
$em->createQuery('DELETE FROM AppBundle:User')->execute();
... lines 50 - 97

Oh and make sure that says "Product" and not "Products". Activate all of this with the @BeforeScenario annotation:

... lines 1 - 41
* @BeforeScenario
public function clearData()
... lines 46 - 97

Try it all again:

./vendor/bin/behat features/web/authentication.feature

Perfect! We can run this over and over because it's clearing out the data first.

The Symfony2Extension

And, surprise! There's an easier way to bootstrap Symfony and clear out the database. I always like taking the long way first so we can see how things work.

First, install a new library called behat/symfony2-extension with --dev so it goes into my require dev section:

composer require behat/symfony2-extension --dev

An extension in Behat is a plugin. We're already using the MinkExtension:

19 lines behat.yml
... lines 2 - 12
base_url: http://localhost:8000
... lines 16 - 19

Activate the new plugin in behat.yml: Behat\Symfony2Extension::

20 lines behat.yml
... lines 2 - 12
... lines 15 - 18
Behat\Symfony2Extension: ~

And as luck would have it, it doesn't need any configuration. It looks like we still need to wait for it to finish installing in the terminal... there we go!

The most important thing the Symfony2 Extension gives you is, access to Symfony's container... but wait, we already have that? Well, this just makes it easier.

Remove the private static $container; property and the bootstrapSymfony() function. Instead of these, we'll use a PHP 5.4 trait called KernelDictionary:

... lines 1 - 13
class FeatureContext extends RawMinkContext implements Context, SnippetAcceptingContext
use \Behat\Symfony2Extension\Context\KernelDictionary;
... lines 17 - 82

This gives us two new functions, getKernel(), but more importantly getContainer():

... lines 1 - 21
trait KernelDictionary
... lines 24 - 40
public function getKernel()
return $this->kernel;
... lines 45 - 50
public function getContainer()
return $this->kernel->getContainer();

It takes care of all of the booting of the kernel stuff for us, and it even reboots the kernel between each scenario so they don't run into each other. That's important because remember, each scenario should be completely independent of the others.

Search for the old self::$container code. Change it to $this->getContainer():

... lines 1 - 31
public function clearData()
$em = $this->getContainer()->get('doctrine')->getManager();
... lines 35 - 36
... lines 38 - 41
public function thereIsAnAdminUserWithPassword($username, $password)
... lines 44 - 48
$em = $this->getContainer()->get('doctrine')->getManager();
... lines 50 - 51
... lines 53 - 84

You see that PhpStorm all of a sudden auto-completes the methods on the services we fetch because it recognizes this as the container and so knows that this returns the entity manager.

Let's try things again!

./vendor/bin/behat features/web/authentication.feature

Still works! But now with less effort. If you have multiple context classes, you can use the KernelDictionary on all of them to get access to the container.

Clearing the Database Easily

OK, so what about clearing the database? It'll be a huge pain to add more and more manual queries. Fortunately Doctrine gives us a better way: a Purger. Create a new variable called $purger and set it to a new ORMPurger(). Pass it the entity manager:

... lines 1 - 32
public function clearData()
$purger = new ORMPurger($this->getContainer()->get('doctrine')->getManager());
... line 36
... lines 38 - 84

After that, type $purger->purge();, and that's it:

... lines 1 - 35
... lines 37 - 84

This will go through each entity and clear out all of your data. If it's working, then our tests should pass:

./vendor/bin/behat features/web/authentication.feature

And they do! Same functionality and a lot less code. For bigger databases with lots of lookup tables, it may be too much to clear every table and re-add all the data you need. In those cases, trying experimenting with creating a SQL file that populates the database and executing that before each scenario. Or, populate an SQLite file with whatever you want to start with, then copy this and use it as your database before each test. That's a super-fast way to roll back to your known data set.

Leave a comment!

  • 2019-01-22 weaverryan

    This is great! Nice work and thanks for sharing!!!

  • 2019-01-17 Diego Aguiar

    As far as I know, the only piece of config that changed is the location of your AppKernel file, just adjust it and Behat should run without problems

  • 2019-01-16 Sergiu Popa


    use App\Kernel;
    use Behat\Behat\Context\Context;
    use Doctrine\Common\DataFixtures\Executor\ORMExecutor;
    use Doctrine\Common\DataFixtures\Purger\ORMPurger;

    class FeatureContext implements Context
    /** @var \Symfony\Component\DependencyInjection\ContainerInterface|null */
    private static $container;

    * @BeforeSuite
    public static function bootstrapSymfony()
    require_once __DIR__.'/../../features/bootstrap/bootstrap.php';
    require_once __DIR__.'/../../src/Kernel.php';

    $kernel = new Kernel('test', true);

    $container = $kernel->getContainer();
    static::$container = $container->has('test.service_container') ?
    $container->get('test.service_container') : $container;

    $em = self::$container->get('doctrine.orm.default_entity_manager');
    $fixturesLoader = self::$container->get('doctrine.fixtures.loader');

    $purger = new ORMPurger($em);
    $executor = new ORMExecutor($em, $purger);

    The container has all the private services as public:

  • 2019-01-15 Murad

    Hi @weaverryan

    Could you add some instructions about configuration required to Symfony 4?

  • 2019-01-14 weaverryan

    Hey murad!

    This tutorial was made for Symfony 3, which has a different directory structure than Symfony 4. In Symfony 4, the class is known as just "Kernel" and it lives in your src/directory. A few things will work differently if you're using Behat on Symfony 4. But, we're happy to answer any questions.


  • 2019-01-14 weaverryan

    Hey Sergiu Popa!

    With the approach you currently have (the Symfony2Exentension way of doing things. I don't think it's possible to do what you want. BeforeSuite or BeforeFeature because, by definition, need to be executed before your context class is instantiated and so need to be static. You would need to follow an approach that's more similar to what we do in this tutorial *before* introducing the Symfony2Extension: manually instantiate the kernel in a static method and set it on a static property. I do this all the time with integration tests in PhpUnit anyways - I think it's a fine approach. Honestly, I think the Symfony2Extension has less and less uses - as we don't build things in bundles anymore (so we don't need it to discover features in bundles) and instantiating a kernel to get the container is just an easy thing to do.

    Let me know if that makes sense!


  • 2019-01-14 Murad

    Hi Viktor,
    How can I add AppKernel class to my project? Is it mentioned in tutorial? Thank you

  • 2019-01-14 Victor Bocharsky

    Hey Murad,

    But do you have AppKernel class in your project? Does it have namespace?


  • 2019-01-11 Murad

    Class AppKernel does not exist

    Why am I have this error in console?

  • 2019-01-11 Sergiu Popa

    For Symfony 4.2 with Doctrine Fixtures 3.1:


    - FeatureContext:
    kernel: '@kernel'
    fixturesLoader: '@doctrine.fixtures.loader'
    - Behat\MinkExtension\Context\MinkContext


    public function __construct(KernelInterface $kernel, SymfonyFixturesLoader $fixturesLoader)
    $this->container = $kernel->getContainer();
    $this->fixturesLoader = $fixturesLoader;

    * @BeforeScenario
    public function clearData(): void
    $purger = new ORMPurger($this->em);
    $executor = new ORMExecutor($this->em, $purger);

    For a login scenario to work, I also had to comment the session config lines in config/packages/test/frameworl.yaml:

    test: true

    However, I'd like to load the fixtures @BeforeFeature or @BeforeSuite, but these are static methods. Any ideas?

  • 2018-12-09 weaverryan

    Ha! Glad you figured it out! And thanks for the nice words :). I both love and hate SoftDeleteable for this reason - it works too well ;)


  • 2018-12-05 Julien Quintiao

    Hi Ryan,
    First of all, thank you for all your screencasts ! You tought me a lot with fun !

    I found the reason of my issue. I was totally going crazy :D

    The reason was this, at the top of my Account entity :

    * @Gedmo\SoftDeleteable(fieldName="deletedAt")

    The entity was not "really" deleted, but apparently i asked Doctrine to think it is...

    My bad, i totally forgot about that annotation.
    Thank you for your investigations :)

    Keep up the good and fun work guys !

  • 2018-12-03 weaverryan

    Hey Julien Quintiao!

    Let's see if we can figure this out :). A few things:

    A) Don't worry about the Proxy object - that will look and act just like a normal Account object. If it does NOT, then it's probably a different issue.

    B) Speaking of "a different issue", this error should never occur:

    > Entity of type 'VRZ\Bundle\AccountBundle\Entity\Account' for IDs id(48)

    This basically means that the following happened:

    1) You queried for some account AccountAgent and, in the database, this was linked to an Account object with id 48
    2) You tried to access the Account from the AccountAgent (e.g. $agent->getAccount()->getId()), but suddenly, when Doctrine tried to query for the Account object with id 48 (because it only does this query lazily, when you actually need the data - and I think it also does the query when you try to delete), it was gone! That doesn't make any sense, right? You haven't actually deleted it yet - so it should be there!

    Here's what I think is going on. Suppose you query for some object in Behat (e.g. an Account) that has (e.g.) a name of "foo". Now you execute a scenario that changes the Account's name to "Bar" by browsing to some form and filling in "Bar". After the scenario, if you run $account->getName(), what value will it be? foo or bar? It will most likely be "foo" (but it actually depends on how you're running your tests). The problem is that (unless you're using the symfony2extension as your driver for making the web requests), you query for the object in Behat, but when you make the web requests, those happen in a totally difference process (maybe even by opening a real browser), and so the Doctrine objects inside of your Behat process have no idea that data changed in the database. So, you get stale data. I believe that's what's happening to you (but I could be wrong and writing this wall of text for nothing!). You're querying for an AccountAgent (whose linked Account is 48), but it's somehow changed later by running a scenario, and then when you try to access it again in Behat, the id is now wrong.

    The fix for this (and we DO do this in our app in real life) is to refresh the object when you think this is a problem. So, something like:


    That should be it! That will then go get fresh data and (hopefully) solve your issue.

    But, let me know! Cheers!

  • 2018-11-30 Julien Quintiao

    Hi guys,

    I'm trying to delete some entities in a custom function in my context.
    Unfortunately, i have some troubles to delete a entity related to another one.

    Basically, i have a first entity called Agent with an attribute :

    * @ORM\ManyToOne(targetEntity="VRZ\Bundle\AccountBundle\Entity\Account", inversedBy="agents")
    * @ORM\JoinColumn(onDelete="SET NULL")
    private $account;

    In my Context, using Symfony2Extension, i can get my agent like this :

    $em = $this->getContainer()->get('doctrine.orm.entity_manager');
    $agent = $em->getRepository('VRZAccountBundle:AccountAgent')->findOneBy(array('email' => $email));

    When i try to get the account by Relationship, $agent->getAccount(), a proxyObject is returned :

    Proxies\__CG__\VRZ\Bundle\AccountBundle\Entity\Account {#5344
    +__isInitialized__: false
    -id: 48

    But when i try to delete those 2 entities, doctrine can't find the Account Entity and give this error :
    Entity of type 'VRZ\Bundle\AccountBundle\Entity\Account' for IDs id(48) was not found (Doctrine\ORM\EntityNotFoundException)

    This is the code of the function in my Context :

    * @Given There is no email with :email
    public function thereIsNoEmailWith($email)

    $em = $this->getContainer()->get('doctrine.orm.entity_manager');
    $agent = $em->getRepository('VRZAccountBundle:AccountAgent')->findOneBy(array('email' => $email));

    if ($agent) {
    $account = $agent->getAccount();
    if ($account) {



    Any ideas ?
    Thank you !

  • 2018-08-28 Diego Aguiar

    Hey Sergiu Popa

    I see your problem, the thing is that you are using Goutte's driver, what Goutte does is to make requests to your app using Guzzle (something very similar as opening a website in a browser), so you will be always hitting your front controller public/index.php and hence, you will hit the environment specified in your ".env" file. What you can do is to use behat/symfony2-extension library, but I just noticed that you also use "Selenium", so the problem will remain for that session.
    I'm afraid that there is no other option than creating a test front controller as you just did, just don't forget to delete it after every deploy, or add some security checks for not allowing to be hitted from the outside (only your localhost)


  • 2018-08-26 Sergiu Popa

    I'm trying to setup Behat for Symfony 4. I managed to clear the data between scenarios and it's working fine for the test database, but the requests are being made for DEV environment, even if I run in the terminal: APP_ENV=test vendor/bin/behat.

    This is my behat.yml:

    - FeatureContext:
    kernel: '@kernel'
    - Behat\MinkExtension\Context\MinkContext

    bootstrap: features/bootstrap/bootstrap.php
    class: App\Kernel

    base_url: http://expenses.local
    browser_name: chrome
    goutte: ~
    selenium2: ~

    And my bootstrap.php inside features/bootstrap:

    use Symfony\Component\Dotenv\Dotenv;

    // The check is to ensure we don't use .env in production
    if (!isset($_SERVER['APP_ENV'])) {
    if (!class_exists(Dotenv::class)) {
    throw new \RuntimeException('APP_ENV environment variable is not defined. You need to define environment variables for configuration or add "symfony/dotenv" as a Composer dependency to load variables from a .env file.');
    (new Dotenv())->load(__DIR__.'/.env');

    Basically the .env file inside features/boostrap specified that the environment is test.

    At the moment the only solution I found is to create index_test.php inside /public and use it in the base url.

    Any thoughts?

    Thank you

  • 2017-07-26 Diego Aguiar

    Hey Gianni Obiglio

    Yes exactly, you first generate your test.db file with everything you would need, then make a backup of it, so before running next scenario you can restore it

    Also you might want to give a glance to this bundle
    it can be configured to work with SQLite and it allows you to load only the fixtures you need


  • 2017-07-26 Gianni Obiglio

    Hi, i am in a middle of isolating each of my test with a SQlite database, could you elaborate on "then copy this and use it as your database before each test" ? my current solution is load fixture just one time in a sqlite db, for exemple test.db, then i copy this file into a test_main.db, and after each test, to "restore my database" i replace test.db content by test_main.db content, is that what you had in mind ?

  • 2017-07-11 weaverryan

    Excellent link! Yes, lookup tables DO have a use-case - and that's a GREAT response describing when that is the case. They seem to be over-used, which is the reason for my opinion. In systems like Magento or Drupal, where so many things need to be able to expand and hook into logic and the database, they make a lot more sense :).


  • 2017-07-10 thedotwriter

    Thanks you two, that's one thorough answer : ).

    I did not dig that much deeper into the subject but for people that might read this, lookup tables are still useful in some cases, just need to know when it's appropriate:

    1. Where you have a finite, yet expandable set of data in a column
    2. Where it isn't self describing
    3. To avoid data modification anomalies
    source: https://dba.stackexchange.c...

    That's mostly for point 3 that I was asking the question (and because I usually work with tools like Drupal or Magento which take care of creating complex database schemas themselves so I'm not used to doing it myself and I suck at it!).

    Back to learning Behat now...

  • 2017-07-05 weaverryan

    And to add a bit more:

    * typically you write code that references the specific values in a lookup table... so why not just put everything in code?
    * because of this, you usually can't just add a new row to a lookup table in the database and expect something to happen. You also need to push code that uses that new value (so again, keeping it in code would just make that simpler)
    * I don't like the idea of having a situation where if I delete a row in a table, the entire app breaks (because code is looking for a specific value in the lookup table that doesn't exist).

    So.... it adds some complexity... and I don't often see any benefit :). Good question though!

  • 2017-07-03 Victor Bocharsky

    Hey thedotwriter ,

    Because of extra joins. For example, you can have a User table and you need to store a subscription status, i.e. is user subscription "active", "canceled", "past_due", etc. So you can create a lookup table "subscription_status" and fill it in with those statuses. but in User table you will have something like:

    id | username | subscription_status_id |
    1 | edgar | 3 |
    2 | victor | 1 |

    So it's not so readable in the database, i.e. you have no idea what is the 3 or 1 IDs mean until you find them in subscritpion_status table. And if you want to fetch the actual status name - you need to perform an extra join, i.e. "User JOIN subscription_status".

    So the next example is much readable in DB and avoid any extra joins:

    id | username | subscription_status |
    1 | edgar | canceled |
    2 | victor | active |

    And in your code you can create a class constants to help referring those statuses:

    User {
    const SUBSCRIPTION_STATUS_ACTIVE = 'active';
    const SUBSCRIPTION_STATUS_CANCELED = 'canceled';


  • 2017-07-02 thedotwriter

    Hey, can you tell me why you hate lookup tables? I'd love to know. Is their any kind of design flaw with this practice?


  • 2016-12-08 Victor Bocharsky

    Hey Adam,

    I suppose you can get container with "$em = self::$container->get('doctrine')->getManager();" as in example here: . The `self` keywords actually the same as `$this` but for a static context. But I think keeping ability to call "$this->getContainer()->get('doctrine')->getManager();" was the reason why we don't make this method static.


  • 2016-12-07 Adam

    for now I have used @beforeScenario instead of @beforeSuite

  • 2016-12-07 Adam

    Suite hook callback: FeatureContext::clearData() must be a static method
    Making it a static method then means that $this is not available.
    How do we then get the container? as can not use $this->getContainer()->get('doctrine')->getManager();

  • 2016-11-22 Victor Bocharsky

    Yes, looks great! Thanks for sharing it


  • 2016-11-21 Sergiu Popa

    Thanks. I'm posting here the final code:

    $em = $this->getContainer()->get('doctrine')->getManager();
    $em->getConnection()->exec('SET foreign_key_checks=0');
    $purger = new ORMPurger($this->getContainer()->get('doctrine')->getManager());
    $em->getConnection()->exec('SET foreign_key_checks=1');

  • 2016-11-21 Victor Bocharsky

    Hey Sergiu,

    Yes, you're right, but DELETE queries might throw exception too due to foreign keys, so you should use the correct order of DELETE queries. One more hack here is SET foreign_key_checks=0 before DELETE queries and then set it back.


  • 2016-11-20 Sergiu Popa

    Cleaning the database using DETELE queries is better sometimes, as the purges can throw error because of foreign constrains, e.g.: deleting categories before deleting articles_categories entries.