BDD working together with Hexagonal architecture

Olivier Lechevalier — Sun, 25 Aug 2019 00:02:36 +0000

Behaviour driven development is a development methodology that aims to create a good communication between the development team and the business. It also focus the testing on the actual behaviour of the system rather than focusing too much on low level details.

Sadly over the years cucumber (and behat) was used as an user acceptance testing tool or solely to write end to end tools. The creator of cucumber actually made a blog post titled "The training wheels came off" trying to explain why using cucumber as a web test automation was just a bad idea. He made a point that by doing so you would not reap any of the benefits that BDD should provide you.

Now let's hope you are not writing anymore scenarios like this one:

Scenario: Successful login
  Given a user "Aslak" with password "xyz"
  And I am on the login page
  And I fill in "User name" with "Aslak"
  And I fill in "Password" with "xyz"
  When I press "Log in"
  Then I should see "Welcome, Aslak"

Moving on to hexagonal architecture, A.K.A. ports and adapters. This architecture was coined by a gentleman named Alistair Cockburn in June 2005. It aims to write highly testable applications. It does so by providing clean layers and pushing all the technical bits to "adapters". The application core has to provide contracts (interfaces) "ports" that the infrastructure layers should implement (adapters).

In case you want to read more into the subject, I highly recommend Chris Fidao (fideloper) post.

Now what these two things can do for us.

Basically usually if use BDD tool but you are testing using the UI of your application (web testing, end to end), it means there is a big chance that these tests are slow and flaky. On the other hand, if you follow the hexagonal architecture motto:

Allow an application to equally be driven by users, programs, automated test or batch scripts, and to be developed and tested in isolation from its eventual run-time devices and databases.

It means that your should be able to write tests that bypass your web interface and go talk directly to the application layer. This bring two major benefits.

you can't write scenarios that are too focused on the UI (there is no more UI involved)
it will be super fast!!!

Just to prove my point here the output from a real application:

93 scenarios (93 passed)
384 steps (384 passed)
0m5.31s (58.20Mb)

Enjoy clean testable applications with up-to-date documentation written in Gherkin.

Bonus: these scenarios could be maintained by business analysis or domain expert.

Doctrine: HOW TO recover from rolled back transaction

Olivier Lechevalier — Sun, 21 Jul 2019 09:40:18 +0000

We all wish we would have to deal only with the happy paths, sadly in reality errors happen and we have to handle them.

One way to clean the mess after an error happened is database transactions and particularly rollbacks. Transaction is a powerful tool to prevent our application to leave the database in an unknown or broken state.

Sadly most of ORMs are not really well equipped to deal with rollbacks.

Let's take a look at a small real world example. Our application needs to send some email to customers and record that the email was sent. The processing is done in batch by doing the action on one customer at a time.




public function sendWeeklyNewsletter(): void
{
    $customers = $repository->findAll();

    foreach ($customers as $customer) {
        try {
            $entityManager->transactional(
                function () use ($customer) {
                    $this->sendWeeklyNewsletter($customer);
                    $this->recordEmailNotification($customer);
                }
            );
        } catch (EmailNotTransmittedException $e) {

        }
    }
}

Let's say the first email could not be sent (random outages, incorrect email, etc), you would think it should work, transactional would rollback the transaction and it would continue processing the next customer.

Unfortunately, it's not the case, you would be rewarded with this exception PHP Fatal error: Uncaught Doctrine\ORM\ORMException: The EntityManager is closed..

Taking a look at the code of EntityManager::transactional would explain why.



    /**
     * {@inheritDoc}
     */
    public function transactional($func)
    {
        if (!is_callable($func)) {
            throw new \InvalidArgumentException('Expected argument of type "callable", got "' . gettype($func) . '"');
        }

        $this->conn->beginTransaction();

        try {
            $return = call_user_func($func, $this);

            $this->flush();
            $this->conn->commit();

            return $return ?: true;
        } catch (Throwable $e) {
            $this->close();
            $this->conn->rollBack();

            throw $e;
        }
    }

Basically because dealing with rollback is complicated. The doctrine maintainers choose to close the entity manager as soon a rollback happens. The documentation includes such warning:

As a result of this procedure, all previously managed or removed instances of the EntityManager become detached. The state of the detached objects will be the state at the point at which the transaction was rolled back. The state of the objects is in no way rolled back and thus the objects are now out of synch with the database. The application can continue to use the detached objects, knowing that their state is potentially no longer accurate.
If you intend to start another unit of work after an exception has occurred you should do that with a new EntityManager.

TD;LR you can't use an entity manager after a rollback happened.

Now how do we do our batch processing if we can't recover from errors!?!?

We need to create a new entity manager every time a rollback happens. This could get complicated if you are using a container because it would share the same instance of entity manager everywhere.

Behold the AbstractManagerRegistry, this registry has a resetManager method that allow to create a new entity manager.

Anyway if you are using symfony framework, the doctrine bridge bundle provides an implementation of the doctrine registry and allow you to reset the entity manager. I am pretty sure other frameworks integration should provide the same feature.

So our code becomes:




public function sendWeeklyNewsletter(): void
{
    $customers = $repository->findAll();

    foreach ($customers as $customer) {
        try {
            $entityManager->transactional(
                function () use ($customer) {
                    $this->sendWeeklyNewsletter($customer);
                    $this->recordEmailNotification($customer);
                }
            );
        } catch (EmailNotTransmittedException $e) {
            $this->registry->resetManager();
        }
    }
}

The attentive reader might have caught a problem in our logic. The entity manager was already passed to our class so it can't be swapped. In fact the symfony doctrine bundle rely on the wonderful proxy manager library written by Ocramius to wrap the EntityManager object so it can be swapped dynamically.

Anyway you can take a look at the implementation of the registry.

Happy batch processing!

DEV Community: Olivier Lechevalier

BDD working together with Hexagonal architecture

Doctrine: HOW TO recover from rolled back transaction