Floating Dangers in PHP on Medium.

Primitive obsession anti-pattern on Medium.

Today it’s time to test it. There’s an excellent helper class called IntegrationTestCase in the Twig package. This class expects a directory containing Twig test cases called “fixtures”.

final class CheckoutStepsExtensionTest extends IntegrationTestCase
{
    /**
     * The directory with test cases
     */
    protected function getFixturesDir(): string
    {
        return __DIR__ . '/Fixtures';
    }
    
    /**
     * Unit tested extensions
     */
    protected function getExtensions(): array
    {
        return [new CheckoutStepsExtension()];
    }
    
    /**
     * Called functions expects an "Order" object.
     * Lets create a helper function will will return an Order.
     */
    protected function getTwigFunctions(): array
    {
        return [
            new TwigFunction('get_test_order', function (): OrderInterface {
                return new Order();
            }),
        ];
    }

    /**
     * Since the runtime depends on its dependencies when created
     * we need to register custom runtime loader which will spawn called runtime.
     * For the sake of simplicity, we will mock the actual helper.
     */
    protected function getRuntimeLoaders(): array
    {
        return [new FactoryRuntimeLoader([
            CheckoutStepsHelperRuntime::class => function (): CheckoutStepsHelperRuntime {
                $helper = $this->prophesize(CheckoutStepsHelper::class);
                $helper->isShippingRequired(Argument::type(Order::class))->willReturn(true);
                $helper->isPaymentRequired(Argument::type(Order::class))->willReturn(true);

                return new CheckoutStepsHelperRuntime($helper->reveal());
            }
        ])];
    }
}

The test is complete, lets create some tests inside the “fixtures” directory:

The fixtures/functions/sylius_is_shipping_required.test file:

--TEST--
"sylius_is_shipping_required" function
--TEMPLATE--

--DATA--
return []
--EXPECT--
yes

Finally the fixtures/functions/sylius_is_payment_required.test file:

--TEST--
"sylius_is_payment_required" function
--TEMPLATE--

--DATA--
return []
--EXPECT--
yes

Run the suite vendor/bin/phpunit and we should be GREEN OK! We are yellow OK though since the test case runs some weird testLegacyIntegration test which gets skipped.

However if we were to change the expectation to “no” we would end up with:

Failed asserting that two strings are equal.
--- Expected
+++ Actual
@@ @@
-'no'
+'yes'

/var/www/html/vendor/twig/twig/src/Test/IntegrationTestCase.php:251
/var/www/html/vendor/twig/twig/src/Test/IntegrationTestCase.php:82

One has to be aware that to create the Twig environment, every extension has to be instantiated. Now multiply that by the number of extensions in your app, some of them with possibly large dependency tree.

For instance, take a look at Sylius – popular e-commerce platform based on Symfony and its CheckoutStepsExtension – it depends on a helper, which depends on two services, both depending on composite resolvers, which in turn load another set of their dependencies.

This extension has to be instantiated every single time Twig is used, even though it’s not needed.

So instead of:

final class CheckoutStepsExtension extends \Twig_Extension
{
    private $checkoutStepsHelper;

    public function __construct(CheckoutStepsHelper $checkoutStepsHelper)
    {
        $this->checkoutStepsHelper = $checkoutStepsHelper;
    }

    public function getFunctions(): array
    {
        return [
            new \Twig_Function('sylius_is_shipping_required', [$this->checkoutStepsHelper, 'isShippingRequired']),
            new \Twig_Function('sylius_is_payment_required', [$this->checkoutStepsHelper, 'isPaymentRequired']),
        ];
    }
}

we could move dependencies from the extension to a Twig Runtime:

final class CheckoutStepsExtension extends \Twig_Extension
{
    public function getFunctions(): array
    {
        return [
            new \Twig_Function('sylius_is_shipping_required', [CheckoutStepsHelperRuntime::class, 'isShippingRequired']),
            new \Twig_Function('sylius_is_payment_required', [CheckoutStepsHelperRuntime::class, 'isPaymentRequired']),
        ];
    }
}

and the Runtime proxy:

final class CheckoutStepsHelperRuntime implements RuntimeExtensionInterface
{
    private $checkoutStepsHelper;

    public function __construct(CheckoutStepsHelper $checkoutStepsHelper)
    {
        $this->checkoutStepsHelper = $checkoutStepsHelper;
    }
    
    public function isShippingRequired(OrderInterface $order): bool
    {
        return $this->checkoutStepsHelper->isShippingRequired($order);
    }

    public function isPaymentRequired(OrderInterface $order): bool
    {
        return $this->checkoutStepsHelper->isPaymentRequired($order);
    }
}

The RuntimeExtensionInterface interface is just for convenience. It enables Symfony DI’s autoconfiguration feature to tag the class with the twig.runtime tag.

Last, but not least I hope, remember to test your Twig extensions. In the next post I’ll show you how to do that properly.

The workaround is very simple, one just has to add the missing directory to the list of known Twig paths:

That’s all, enjoy:

Imagine YourDomain\Customer\Customer domain object:

<?php declare(strict_types=1);

namespace YourDomain\Customer;

class Customer
{
    private $id;
    private $email;
    private $password;

    public function __construct(string $email)
    {
        $this->setEmail($email);
    }

    public function getId(): ?int
    {
        return $this->id;
    }

    public function getEmail(): string
    {
        return $this->email;
    }

    public function setEmail(string $email): void
    {
        if (!filter_var($email, FILTER_VALIDATE_EMAIL)) {
            throw new \InvalidArgumentException('Not a valid e-mail address');
        }

        $this->email = $email;
    }

    public function getPassword(): string
    {
        return (string)$this->password;
    }

    public function setPassword(string $password): void
    {
        $this->password = $password;
    }
}

Define your own mapping first:

orm:
  mappings:
    YourDomain\Customer:
      is_bundle: false
      type: xml
      // this is the location where xml files are located, mutatis mutandis
      dir: '%kernel.project_dir%/../src/Infrastructure/ORM/Mapping'
      prefix: 'YourDomain\Customer'
      alias: Customer

File name has to match the pattern [class_name].orm.xml, in your case Customer.orm.xml. If you have sub-namespaces inside, eg. value object YourDomain\Customer\ValueObject\Email, the file has to be named ValueObject.Email.orm.xml.

Example mapping:

<doctrine-mapping xmlns="http://doctrine-project.org/schemas/orm/doctrine-mapping"
                  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
                  xsi:schemaLocation="http://doctrine-project.org/schemas/orm/doctrine-mapping
                   https://raw.github.com/doctrine/doctrine2/master/doctrine-mapping.xsd">
    <entity name="YourDomain\Customer\Customer" table="customer">
        <id name="id" type="integer" column="id">
            <generator strategy="AUTO"/>
        </id>
        <field name="email" type="email" unique="true"/>
        <field name="password" length="72"/>
    </entity>
</doctrine-mapping>

Well, that times are over now, thanks to phpStorm and its conditional breakpoints! Why didn’t I know that fancy functionality exists? I feel really pity for myself.

Just add a breakpoint, right click on it and add your condition. And yes, those are pure PHP conditions, go bananas!

Run your code and let the magic happen.

Brad Peabody proposed Version 6:

TL;DR: ‘Version 6’ UUIDs have the date/time encoded from high to low bytes (bit-shifting around the version field in order to preserve its location) and thus sort correctly by time when treated as an opaque bunch of bytes; the clock sequence can be used to avoid duplicates generated at the same time; it’s okay to use random data from a good PRNG in place of the MAC address; the rest is the same as RFC 4122.

Pity I didn’t found any PHP implementation, needed to write one myself. Go and grab it from Packagist as mikemix/php-uuid-v6. Hope it helps someone!

Hopefully this proposal will make its way through the IETF process some day! Ben Ramsey already pledged his help.

Docker image / GitHub repository

Just mount your cloud bucket to the filesystem, one docker command to run the tool and don’t worry about your database anymore.

It’s a simple algorithm, just 3 rules honestly, developed by John Conway almost 40 years ago now. I’m not going to cover the topic thoroughly here though.

The results can be found at GitHub. Should you have Docker installed, the whole can be run with just one command.

I’m going to develop this from time to time for sure. I really hope that :)