Posts tagged 'php'

Missing colors for PHPUnit

published on July 20, 2016.
Heads-up! You're reading an old post and the information in it is quite probably outdated.

I ran accross a minor issue today that I never experienced before. The colors for the PHPUnit’s output were missing. I had the colors=true directive set in the phpunit.xml configuration file, but the output was just black and white.

Turns out I was missing the posix extension, which is provided by the php-process package on Fedora. After installing it:

$ sudo dnf install php-process

all was good again in the world of unit testing.

Oh well.

Happy hackin’!

Tags: phpunit, php.
Categories: Programming, Software, Development.

Using Tactician in a Zend Expressive application

published on July 13, 2016.
Heads-up! You're reading an old post and the information in it is quite probably outdated.

I spent some time connecting the dots last week, so I decided to put together an example on how to get started with using Tactician in a Zend Expressive application. The example itself is not really useful, but it does show how to setup the dependencies and get started with these two libraries.

Zend Expressive is a PSR7 compatible microframework that provides interfaces for routing, DI containers, templating and error handling. It provides a couple out of the box, so you can either use those, or write your own implementations.

Tactician is a command bus library whose goal is to make using the command pattern easy to use in your applications. It allows to have an object that represents a command, pass it on to the command bus which will figure out which command handler should take care of that command.

Let’s dive in

To get up and running quickly with Zend Expressive we can create a skeleton application. It does some basic wiring for us, like setting up the routing and the DI container.

It also comes with a dummy ping action, at /api/ping, which just gives us the current unix timestamp. This example is going to expand on that and create a Ping command that will be handled by a Ping command handler. The command handler will get some additional dependencies from the container, just to make the example a bit more interesting.

Creating the skeleton application is really easy with Composer:

$ cd /var/www
$ composer create-project zendframework/zend-expressive-skeleton tactician-example

Bring in the Tactician and the tactician-container plugin as project dependencies. The tactician-container plugin allows us to lazy load command handlers from a container-interop compatible container:

$ composer require league/tactician
$ composer require league/tactician-container

Now that we have all our libraries in, let’s change how the container creates the Ping action. Before it was being just invoked by the container, but now we want to create it through a factory:

config/autoload/routes.global.php

diff --git a/config/autoload/routes.global.php b/config/autoload/routes.global.php
index 856f5ab..8335450 100644
--- a/config/autoload/routes.global.php
+++ b/config/autoload/routes.global.php
@@ -4,10 +4,10 @@ return [
     'dependencies' => [
         'invokables' => [
             Zend\Expressive\Router\RouterInterface::class => Zend\Expressive\Router\FastRouteRouter::class,
-            App\Action\PingAction::class => App\Action\PingAction::class,
         ],
         'factories' => [
             App\Action\HomePageAction::class => App\Action\HomePageFactory::class,
+            App\Action\PingAction::class => App\Action\PingFactory::class
         ],
     ],

This will allow us to pass in dependencies to the PingAction class.

The Ping action’s factory is simple:

src/App/Action/PingFactory.php

<?php

namespace App\Action;

use Interop\Container\ContainerInterface;

class PingFactory
{
    public function __invoke(ContainerInterface $container)
    {
        $commandBus = $container->get('CommandBus');

        return new PingAction($commandBus);
    }
}

We are telling the container to get the service called CommandBus and pass it as an argument to the Ping action’s constructor.

Wiring in Tactician

We haven’t yet defined the CommandBus service, so let’s do that next by telling the service manager to create the CommandBus using the App\CommandBusFactory factory:

config/autoload/dependencies.global.php

diff --git a/config/autoload/dependencies.global.php b/config/autoload/dependencies.global.php
index b2b08f5..460c045 100644
--- a/config/autoload/dependencies.global.php
+++ b/config/autoload/dependencies.global.php
@@ -19,6 +19,7 @@ return [
         'factories' => [
             Application::class => ApplicationFactory::class,
             Helper\UrlHelper::class => Helper\UrlHelperFactory::class,
+            'CommandBus' => App\CommandBusFactory::class
         ],
     ],
 ];

This factory sets up the Tactician’s command bus and is the main point of this example:

src/App/CommandBusFactory.php

<?php

namespace App;

use League\Tactician\CommandBus;
use League\Tactician\Handler\CommandHandlerMiddleware;
use League\Tactician\Container\ContainerLocator;
use League\Tactician\Handler\CommandNameExtractor\ClassNameExtractor;
use League\Tactician\Handler\MethodNameInflector\InvokeInflector;
use Interop\Container\ContainerInterface;

class CommandBusFactory
{
    public function __invoke(ContainerInterface $container)
    {
        $inflector = new InvokeInflector();

        $commandsMapping = [];
        $locator = new ContainerLocator($container, $commandsMapping);

        $nameExtractor = new ClassNameExtractor();

        $commandHandlerMiddleware = new CommandHandlerMiddleware(
            $nameExtractor,
            $locator,
            $inflector
        );

        $commandBus = new CommandBus([
            $commandHandlerMiddleware
        ]);

        return $commandBus;
    }
}

Tactician uses a command handler middleware to handle commands. That middleware in turn uses a name extractor to get the command name out of a command, a locator to find the actual command handler and an inflector to figure out the method to call on the command handler to handle the command. Tactician’s middleware system is nicely described in the documentation.

The ClassNameExtractor will extract the command name from the class name.

The ContainerLocator will use our container-interop compatible container to find the command handler, which in this example is Zend ServiceManager.

The InvokeInflector dictates that the command handler needs to have an __invoke method which will get our Ping command as an argument and then it’s up to the Ping command handler to handle the command.

The $commandsMapping array that we are passing to the locator is going to be a map of commands and their handlers. We’ll populate that later on.

In the next step, let’s tell the PingAction’s constructor to accept the command bus:

src/App/Action/PingAction.php

diff --git a/src/App/Action/PingAction.php b/src/App/Action/PingAction.php
index ea2ae22..612fb32 100644
--- a/src/App/Action/PingAction.php
+++ b/src/App/Action/PingAction.php
@@ -5,9 +5,15 @@ namespace App\Action;
 use Zend\Diactoros\Response\JsonResponse;
 use Psr\Http\Message\ResponseInterface;
 use Psr\Http\Message\ServerRequestInterface;
+use League\Tactician\CommandBus;

 class PingAction
 {
+    public function __construct(CommandBus $commandBus)
+    {
+        $this->commandBus = $commandBus;
+    }
+
     public function __invoke(ServerRequestInterface $request, ResponseInterface $response, callable $next = null)
     {
         return new JsonResponse(['ack' => time()]);

Cool, at this point we have everything set up to start sending and handling commands.

Commands and their handlers

The command we are going to create is a simple one:

src/App/Command/Ping.php

<?php

namespace App\Command;

class Ping
{
    private $commandTime;

    public function __construct()
    {
        $this->commandTime = time();
    }

    public function getCommandTime()
    {
        return $this->commandTime;
    }
}

It just sets the command time to the current unix timestamp.

Updating the PingAction to include the creation of our Ping command and passing it on to the command bus to be handled:

src/App/Action/PingAction.php

diff --git a/src/App/Action/PingAction.php b/src/App/Action/PingAction.php
index 612fb32..6cb9334 100644
--- a/src/App/Action/PingAction.php
+++ b/src/App/Action/PingAction.php
@@ -6,6 +6,7 @@ use Zend\Diactoros\Response\JsonResponse;
 use Psr\Http\Message\ResponseInterface;
 use Psr\Http\Message\ServerRequestInterface;
 use League\Tactician\CommandBus;
+use App\Command\Ping as PingCommand;

 class PingAction
 {
@@ -16,6 +17,11 @@ class PingAction

     public function __invoke(ServerRequestInterface $request, ResponseInterface $response, callable $next = null)
     {
-        return new JsonResponse(['ack' => time()]);
+        $pingCommand = new PingCommand();
+        $time = $pingCommand->getCommandTime();
+
+        $this->commandBus->handle($pingCommand);
+
+        return new JsonResponse(['ack' => $time]);
     }
 }

Now is the time to let Tactician know about our command and command handler mapping, so it knows which handler handles which command:

src/App/CommandBusFactory.php

diff --git a/src/App/CommandBusFactory.php b/src/App/CommandBusFactory.php
index ba587f6..b79fbb1 100644
--- a/src/App/CommandBusFactory.php
+++ b/src/App/CommandBusFactory.php
@@ -9,13 +9,18 @@ use League\Tactician\Handler\CommandNameExtractor\ClassNameExtractor;
 use League\Tactician\Handler\MethodNameInflector\InvokeInflector;
 use Interop\Container\ContainerInterface;

+use App\Command\Ping as PingCommand;
+use App\CommandHandler\Ping as PingCommandHandler;
+
 class CommandBusFactory
 {
     public function __invoke(ContainerInterface $container)
     {
         $inflector = new InvokeInflector();

-        $commandsMapping = [];
+        $commandsMapping = [
+            PingCommand::class => PingCommandHandler::class
+        ];
         $locator = new ContainerLocator($container, $commandsMapping);

         $nameExtractor = new ClassNameExtractor();

We’re almost there. I promise.

The command handler is going to be created through a factory, so we can inject dependencies into it:

src/App/CommandHandler/PingFactory.php

<?php

namespace App\CommandHandler;

use Interop\Container\ContainerInterface;

class PingFactory
{
    public function __invoke(ContainerInterface $container)
    {
        $logPath = '/tmp/ping-command.log';

        return new Ping($logPath);
    }
}

It doesn’t do much, it just passes a path to a log file. Of course, in real code, you’d probably pass in some dependency gotten from the container.

The command handler won’t do much either, it’s just going to log the the ping’s command time in the log file we passed in from the command handler factory:

src/App/CommandHandler/Ping.php

<?php

namespace App\CommandHandler;

use App\Command\Ping as PingCommand;

class Ping
{
    private $logPath;

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

    public function __invoke(PingCommand $pingCommand)
    {
        $commandTime = $pingCommand->getCommandTime();

        file_put_contents($this->logPath, $commandTime . PHP_EOL, FILE_APPEND);
    }
}

And finally let the service manager know how to create the Ping command handler:

config/autoload/dependencies.global.php

diff --git a/config/autoload/dependencies.global.php b/config/autoload/dependencies.global.php
index 460c045..2c8e3ee 100644
--- a/config/autoload/dependencies.global.php
+++ b/config/autoload/dependencies.global.php
@@ -19,7 +19,8 @@ return [
         'factories' => [
             Application::class => ApplicationFactory::class,
             Helper\UrlHelper::class => Helper\UrlHelperFactory::class,
-            'CommandBus' => App\CommandBusFactory::class
+            'CommandBus' => App\CommandBusFactory::class,
+            App\CommandHandler\Ping::class => App\CommandHandler\PingFactory::class
         ],
     ],
 ];

Navigating to /api/ping should display the {“ack”:1468171544} response, and the log file at /tmp/ping-command.log should have the same timestamp logged.

That was a lot of code

I know, looks like an awful lot of code just to log a timestamp in a file somewhere. But the point is that even for more complicated commands and handlers the basic wiring stays the same — create the CommandBus factory, set up mapping of commands and handlers and the rest is pretty much the business logic of the application.

Happy hackin’!

P.S.: I’m trying out this new way of providing code samples by using diffs, so it’s easier to follow what changed where. Let me know how it looks, thanks!

Tags for PHP in Vim

published on March 09, 2016.
Heads-up! You're reading an old post and the information in it is quite probably outdated.

One thing I was missing for a long time in Vim is to be able to “jump to definition” in an easy and painless way.

The other thing I wanted to improve is to be able to tell easily where am I actually in the code base; to see the current class and method name of wherever the cursor was.

With a bit of googling and poking around, I finally came up with a perfect combo of 5 plugins (yep, five!) that enables me to do both, and a little bit of extra.

Tags made easy

Gutentags  is a brilliant Vim plugin that makes it so easy to have tags. Just install the plugin and boom! Tags! It will figure out things on it’s own and just generate the tags in the background. I use it daily for a fairly large code base and I never had any problems with the tags, or with Vim being unresponsive while the tags are being generated.

The only two settings I have set for it is what to exclude and where to store the tag files to not pollute the current project with them.

let g:gutentags_exclude = ['*.css', '*.html', '*.js']
let g:gutentags_cache_dir = '~/.vim/gutentags'

That’s it.

Jump to definition

Pair gutentags with CtrlP and it’s CtrlPTag method and we get jump to definition.

map <silent> <leader>jd :CtrlPTag<cr><c-\>w

Move to the method name we’re interested in, hit <leader>jd and it will jump to it’s definition. Tip: <C->w means “insert word under cursor”.

Where the hell am I?

My second requirement for displaying the current class and method name was a bit more difficult to fulfill. It takes the tagbar, tagbar-phpctags and lightline plugins as well as the phpctags tag generator to accomplish that.

Let the tagbar plugin know where the phpctags bin is:

let g:tagbar_phpctags_bin='~/.vim/phpctags'

This will make the tagbar plugin use phpctags to generate tags for the current file. To finally display the current tag in lightline, I wrote a simple tagbar component for it:

'tagbar': '%{tagbar#currenttag("[%s]", "", "f")}'

My complete lightline settings at the time of writing this can be found here.

Mocking hard dependencies with Mockery

published on December 23, 2014.
Heads-up! You're reading an old post and the information in it is quite probably outdated.

One problem with unit testing legacy applications is that the code has new statements all over the place, instantiating new objects in a way that doesn’t really makes it easier to test the code.

Of course, the easy answer to this is “Just refactor your application!”, but that’s almost always easier said than done.

If refactoring is an option, do it. If not, one option is to use Mockery to mock the hard dependencies.

One prerequisite to make this work is that the code we are trying to test uses autoloading.

Let’s take the following code for an example:

<?php
namespace App;
class Service
{
    function callExternalService($param)
    {
        $externalService = new Service\External();
        $externalService->sendSomething($param);
        return $externalService->getSomething();
    }
}

The way we can test this without doing any changes to the code itself is by creating instance mocks by using the overload prefix.

<?php
namespace AppTest;
use Mockery as m;
class ServiceTest extends \PHPUnit_Framework_TestCase {
    public function testCallingExternalService()
    {
        $param = 'Testing';

        $externalMock = m::mock('overload:App\Service\External');
        $externalMock->shouldReceive('sendSomething')
            ->once()
            ->with($param);
        $externalMock->shouldReceive('getSomething')
            ->once()
            ->andReturn('Tested!');

        $service = new \App\Service();

        $result = $service->callExternalService($param);

        $this->assertSame('Tested!', $result);
    }
}

If we run this test now, it should pass. Mockery does it’s job and our App\Service will use the mocked external service instead of the real one.

The problem whit this is when we want to, for example, test the App\Service\External itself, or if we use that class somewhere else in our tests.

When Mockery overloads a class, because of how PHP works with files, that overloaded class file must not be included otherwise Mockery will throw a “class already exists” exception. This is where autoloading kicks in and makes our job a lot easier.

To make this possible, we’ll tell PHPUnit to run the tests that have overloaded classes in separate processes and to not preserve global state. That way we’ll avoid having the overloaded class included more than once. Of course this has it’s downsides as these tests will run slower.

Our test example from above now becomes:

<?php
namespace AppTest;
use Mockery as m;
/**
 * @runTestsInSeparateProcesses
 * @preserveGlobalState disabled
 */
class ServiceTest extends \PHPUnit_Framework_TestCase {
    public function testCallingExternalService()
    {
        $param = 'Testing';

        $externalMock = m::mock('overload:App\Service\External');
        $externalMock->shouldReceive('sendSomething')
            ->once()
            ->with($param);
        $externalMock->shouldReceive('getSomething')
            ->once()
            ->andReturn('Tested!');

        $service = new \App\Service();

        $result = $service->callExternalService($param);

        $this->assertSame('Tested!', $result);
    }
}

And that should be pretty much it. If nothing else, it should make parts of old code easier to test.

For anyone interested, I put the example code up on Github.

Xdebug and private /tmp on Fedora

published on December 16, 2014.
Heads-up! You're reading an old post and the information in it is quite probably outdated.

This one was a bit weird and needed some figuring out. Xdebug profiler output files were not being generated in the /tmp directory.

I wanted to do some profiling with xdebug. I set all the necessary configuration settings in my php.ini, restarted apache, confirmed xdebug is present and configured correctly with php -i | grep xdebug, appended ?XDEBUG_PROFILE=1 aaaand! Nothing. Nothing in /tmp, the default profiler output directory. Double checked paths, permissions, nope, nothing. No profiler files were generated.

find /tmp -name "cachegrind*"

listed the files in

/tmp/systemd-httpd.service-X9iE20R/tmp/

What the?

Apparently systemd services in Fedora can have this setting called PrivateTmp and services with this setting set to true are started with a private /tmp directory. Something something security.

Well then. I created a /var/log/xdebug directory, changed the owner to apache and set the xdebug.profiler_output_dir to that new directory and all is well again.

Hey, I learned something new today.

Robert Basic

Robert Basic

Software engineer, consultant, open source contributor.

Let's work together!

If you require outsourcing or consulting help on your projects, I'm available!

Robert Basic © 2008 — 2019
Get the feed