The SymfonyExtension & Clearing Data Between Scenarios

Hey Murad,

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

Cheers!

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

Hey Soltan!

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.

Cheers!

Hi @weaverryan

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

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

Hey MichalWilczynski

Sorry for late answer, with this new setup you just need to autowire, the key here is recipe https://github.com/symfony/... which allows to use autowiring for Context classes

Hey, thank you :) it does work but I one more problem.

Here is my <b>behat.yaml.dist</b>

default:
    extensions:
        FriendsOfBehat\SymfonyExtension: ~
        Behat\MinkExtension:
            base_url:  'http://test'
            default_session: symfony
            sessions:
                symfony:
                    symfony: ~
        SensioLabs\Behat\PageObjectExtension:
            namespaces:
                page: App\Tests\Behat\bootstrap\Features\Application\Web\Page

This is an illustrative class

class testContext extends PageObjectContext
{
   private $kernel;
   private $userRepository;
   private const $id = '1111-1111-1111-1111';

   public function __construct(KernelInterface $kernel, UserRepository $userRepository)
   {
      $this->kernel = $kernel;
      $this->userRepository = $userRepository;
   }

   protected function getContainer()
    {
        return $this->kernel->getContainer();
    }
  
     /**
     * @When I accept terms
     */
  public function IAcceptTerms($id)
  {
     $page = $this->getPage(TermsPage::class)->open();
     $page->findById('accept')->press();
  }



     /**
     * @Then terms should be accepted
     */
  public function ThenTermsShouldBeAccepted()
  {
     $user = $this->userRepository()->findById(self::MY_ID);
     if(!$user->isAcceptTerms) {
      throw new RuntimeExcepion('Terms not accepted!')
      }
 }
}

When I go to phpmyadmin I can see that there is acceptTerms set to true after firstStep but in the step ThenTermsShouldBeAccepted acceptTerms are set to false and exception is thrown. I dont'know from where is this difference between database and what userRepository returns.
Thanks in advance :)

Hey Sergiu P.!

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!

Cheers!

Totally!

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);
        $kernel->boot();


        $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);
        $executor->execute($fixturesLoader->getFixtures());
    }
}

The container has all the private services as public: https://symfony.com/blog/new-in-symfony-4-1-getting-container-parameters-as-a-service

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

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:

$em->refresh($agent);

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

But, let me know! Cheers!

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 !
Cheers.

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 ;)

Cheers!

Hey Sergiu P.

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)

Cheers!

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';
}

Cheers!

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!

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...

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 :).

Cheers!

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.

Cheers!

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());
$purger->purge();
$em->getConnection()->exec('SET foreign_key_checks=1');

Yes, looks great! Thanks for sharing it

Cheers!

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 https://github.com/liip/Lii...
it can be configured to work with SQLite and it allows you to load only the fixtures you need

Cheers!

for now I have used @beforeScenario instead of @beforeSuite

Hey Adam,

I suppose you can get container with "$em = self::$container->get('doctrine')->getManager();" as in example here: https://knpuniversity.com/s... . 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.

Cheers!