testomatic - thinking about building things

SessionRecord for demonstrating persistence

2010-03-20T00:00:00+00:00

I recently needed a simple model type object with CRUD operations and persistence to demonstrate some new PHP controller and routing software. Setting up the persistence layer in a database seemed to involve a lot of overhead, assuming that anyone wanting to run the demo has the time and privileges involved. It is also a shared repository of data - the demo will allow people to create, update and delete whatever they like - which may cause some issues.

Instead of using a database for the persistence I instead decided to store the data in a session variable. This mitigates any setup required and allows users to add and edit the data in their own personal sandbox. SessionRecord is a simple wrapper around storing data in the user’s session, it provides familiar methods for CRUD operations on your models.

It requires PHP 5.3 as it makes use of late static binding and a few lambdas here and there. It provides …

Simple data fixture set up
Per user persistence of data
Usual record type model finders, getters, setters, save, delete functionality

The code is on Github at http://github.com/testomatic/examples/tree/master/php/SessionRecord/

Creating a model with SessionRecord

<?php 
    
    require 'SessionRecord.php';
    
    /**
     * Create a Book model type, $_namespace is used to store data in the session, 
     * think of it as an SQL table name :)
     */
    class Book extends SessionRecord
    {
        protected static $_namespace = 'books';
    }
    
    /** 
     * You can init some data, this will happen the first time 
     * the $_SESSION object is created
     */
    Book::init(
        array(
            array(
                'title'  => 'Cider with Rosie',
                'author' => 'Laurie Lee',
                'id'     => 1,
            ),
            array(
                'title'  => 'Lord of the Flies',
                'author' => 'William Golding',  
                'id'     => 2,                              
            )                           
        )   
    );
    
    /**
     * We then have some of the usual finder type functionality 
     */
    $books = Book::findAll();                         // array() of objects
    $books = Book::findAllBy('author', 'Laurie Lee'); // array() of objects by Laurie Lee
    $book  = Book::findFirstBy('id', '1');            // object with id 1 or false
        
    /**
     * You can create a new Book which gets stored to $_SESSION and assigned an ID
     */
    $book = Book::create(array('title' => 'A Moment of War', 'author' => 'Laurie Lee'));
    $book->id // 3
    
    /**
     * You can modify and save a Book
     */
    $book->title = 'As I Walked Out One Midsummer Morning';
    $book->save();
    
    /**
     * Or delete it from the storage 
     */
    $book->delete();
    
    /**
     * And if you want to clear all the data in $_SESSION
     */
    Book::reset();
    
?>

Useful UNIX shell commands

2010-03-17T00:00:00+00:00

It’s great to be able to harnessing the power of the unix shell, here’s some favourite commands …

`uptime`

How long has your system been running for? If you hate the power switch as much as me there’s a perverse enjoyment in this one. Currently on 24 days as I type, good old macbook!

`history`

List all your recent command history. This is great if you pipe to grep also, can’t remember the exact arguments you typed last time?

$: history | grep some-command
32  some-command

Notice the number next to the output, that’s the number of the entry in your history log. Want to re-run some-command just type !32.

`svn diff | mate`

It’s really useful to do an SVN diff before you commit but if you just run it in the terminal the output can be hard to read. Textmate (Mac only sorry) has excellent highlighting and folding features for diff files and you can pipe the output from your SVN client straight into it.

`pushd`, `popd`, `dirs`

These three are really useful. Suppose your in one directory and want to jump out and have a root around elsewhere, you can use pushd to jump to a new directory stack, if you want to go back to the previous stack just pushd again. As you might expect popd drops the current stack and puts you back on the previous one whilst dirs lists all the directory stacks you’ve created.

`ps -ax`

Firefox locked up and crashed again? Can’t be bothered to wait 15 minutes for eclipse to shut down? You can find out the process id of any running program with the ps command. Again it’s useful to use grep here to search the output, next time you’ve had enough of eclipse try this …

$ ps -ax | grep eclipse
81404 ??         0:16.92 /Applications/.../MacOS/eclipse
$ kill 81404

Rake tasks, options and arguments

2010-03-04T00:00:00+00:00

I’ve been starting to use rake more and more recently. I find it to be a little more flexible than my old favourite build tool ant. The ability to use all existing ruby gems and jump straight into ruby code is very flexible, but it still maintains the structure necessary for a practical build file. And hey, if it’s good enough for Martin Fowler then it’s good enough for me right?

Here’s a few tips I found out whilst working on a recent build file, namely setting options via the command line and passing arguments to your tasks.

Passing command line options to rake

This one is useful for setting global options, a little bit analogous to -Dproperty=value for those of us from an ant background.

rake mytask foo=bar

You can then pick up these options from the ENV hash in your rake file.

task :mytask do
    puts ENV["foo"]
end

Passing an argument to a rake task via the command line

Passing arguments to specific commands allows you a bit more control over your build files. In the below example we pass two arguments with the values foo and bar through to our task.

rake mytask[foo, bar]

These can be picked up like this

task :mytask, :arg1, :arg2 do |t, args|
    puts args[:arg1]
    puts args[:arg2]	
end

Or if you have dependancies associated with your task the syntax is slightly different.

task :mytask, [:arg1, :arg2] => [:task, :another_task] do |t, args|
    puts args[:arg1]
    puts args[:arg2]	
end

And if you need some defaults you can add those too …

task :mytask, [:arg1, :arg2] => [:task, :another_task] do |t, args|
    args.with_defaults(:arg1 => 'some value', :arg2 => 'another value')
    puts args[:arg1]
    puts args[:arg2]	
end

Dependency injection in ZF controllers

2010-02-26T00:00:00+00:00

Following on from our recent article on writing testable PHP code, it seems sensible to point out Ian Barber’s article on dependency injection for Zend Framework controllers over at the iBuildings site.

The article outlines three approaches to injecting objects into your controllers. The first is via the Zend_Registry object, which should not be your preferred technique. Zend_Registry is just an over hyped singleton object and a perfect way of adding the dreaded global state to your application. Also, with this technique you mitigate and dependancy on your chosen objects for a dependency on the registry object itself, so your classes are still tightly coupled in a way.

The second technique is via Zend_Controller_Front params. This has the benefit of decoupling your objects but still feels a little clunky in practice.

The third and most interesting technique is to inject your objects via an action helper. This technique works by taking advantage of the action helpers hooks into the dispatch loop. It’s rather neat and provides a complete decoupling of your objects.

<?php
/**
 * An action helper for injecting objects
 */
class MyApp_Helpers_SomeObjectInjector extends Zend_Controller_Action_Helper_Abstract {
    
    protected $_someObject;
    
    public function init() {
        $this->_someObject = new MyApp_SomeObject();
    }

    public function preDispatch() {
        $this->getActionController()->setSomeObject($this->_someObject);
    }
}
?>

You can then set this up as a helper in your bootstrap file so it gets hooked into the dispatch loop. Of course your controller will also need the method setSomeObject().

<?php
Zend_Controller_Action_HelperBroker::addHelper(new MyApp_Helpers_SomeObjectInjector());
?>

Whilst this method is one of the neatest I’ve found so far it does still seem a little hacky. Some of the comments on the original post raise the question of a need for a proper dependency injection container in the framework.

Writing testable PHP code

2010-02-20T00:00:00+00:00

Here at the testomatic we’ve been using PHP 5 and the Zend Framework for a while now. Moving into the area of enterprise PHP development has presented some new challenges and differences in the area of testing. Of particular interest has been how to write code so that is unit testable using PHPUnit.

It’s all about dependencies

Unit testing is the process of ensuring that the code you have written behaves in the expected manner. The “unit” part means that we should only be testing the smallest possible feature of our codebase, isolating our tests around the individual concerns of a particular class or method.

In practice it is rare that we will write a class or method that in exists in isolation. More often it will rely on some other classes or methods to provide it’s functionality, these are what we call dependencies. Dependencies can come in various shapes and sizes, but a good rule of thumb to follow is the more complex functionality a dependency provides, the more important it is to remove it from the test equation.

Let’s look at a code example to illustrate this point further. The fictional class below acts as a gateway to a web service for sending emails.

<?php 

class Email_Gateway {

    protected $webService = 'https://mywebservice.com/email';

    /**
     * Sends an email 
     */
    public function sendEmail($to, $subject, $message) {

        $httpClient = new Zend_Http_Client();
        $httpClient->setUri($this->webService);
        $httpClient->setParameterPost(array(
            'to' => $to,
            'subject' => $subject,
            'message' => $message,
        ));
    
        $response = $httpClient->request('POST');
    
        if ($response->isError()) {
            throw new Exception(
                        $response->getStatus() 
                        . ' ' 
                        . $response->getMessage()
                    );
        } else {
            return true;
        }

    }

}

?>

This class adds a basic wrapper around a HTTP call to our service and throws an exception if it fails for some reason. In practice you might want a class such as this to do much more, such as validating that parameter is actualy an email, but it illustrates the point as is. The error handling part is the main piece of functionality given here, but because of the way we have written the code testing that our error handling works correctly becomes a bit cumbersome.

When testing this class in it’s current state we would have to be making HTTP calls and sending out emails, as well as ensuring the web service responded in the manner which we wanted to test against. That’s some pretty big external dependencies, and at the moment we are quite far away from testing our code in isolation.

Dependency injection

One solution would be use a test fixture to represent our call to the web service. This means writing a fake HTTP client for use in our tests, it would pretend to talk to the web service and respond in the manner we want to test against. The current implementation of this class does not give us access to the Zend_Http_Client though, so in order to use our test with a fixture we need to refactor our code.

<?php

class Email_Gateway {

    protected $webService = 'https://mywebservice.com/email';

    protected Zend_Http_Client $httpClient;

    /**
     * Set our http client
     */
    public function setHttpClient(Zend_Http_Client $httpClient) {
        $this->httpClient = $httpClient;
    }

    /**
     * Get our http client
     */ 
    public function getHttpClient() {
        if (!isset($this->httpClient)) {
            $this->httpClient = new Zend_Http_Client();
        }
        return $this->httpClient;
    }

    /**
     * Sends an email 
     */
    public function sendEmail($to, $subject, $message) {

        $httpClient = $this->getHttpClient();
        $httpClient->setUri($this->webService);
        $httpClient->setParameterPost(array(
            'to' => $to,
            'subject' => $subject,
            'message' => $message,
        ));
    
        $response = $httpClient->request('POST');
    
        if ($response->isError()) {
            throw new Exception(
                        $response->getStatus() 
                        . ' ' 
                        . $response->getMessage()
                    );
        } else {
            return true;
        }

    }

}

?>

In the revised class we have added some new methods, getters and setters for the http client. This allows us to replace our http client with a fixture object during our tests. I could have also inserted the http client via a constructor, but in this example I have gone for a setter and ‘lazy intialisation’ via the getter as it has minimal impact on the interface to the class.

This technique is a very basic example of what is know as dependency injection, and allows us to write our classes in a way that they become easily testable in isolation. A typical PHPUnit test for this class might now look like this:

<?php

public function testSendEmailSuccess() {
    
    $mockHttpClient = $this->getMock('Zend_Http_Client');
    $mockHttpClient->expects($this->any())
                   ->method('isError')
                   ->will($this->returnValue(false));

    $emailGateway = new Email_Gateway();
    $emailGateway->setHttpClient($mockHttpClient);
    
    $result = $emailGateway->sendEmail('matt@foo.com', 
                                       'Hello', 
                                       'Hello Matt!'
                                       );

    $this->assertTrue($result);
    
}

?>

Here I have used one of PHPUnit’s mock objects, but a similar effect can be achieved by writing your own version of the HTTP client and injecting that instead. Martin Fowler describes the philosophical differences of these two approaches in quite a lot of detail, but in my so far limited experience I have found PHPUnit’s mock objects a convenient way to stub out dependencies in my tests.

Looking for dependency injection patterns in the Zend Framework

The more I have come to use these coding practices in my own work, the more I have come to recognise them in the Zend Framework. Using the Zend_View_Helper component as an example, here’s my take on what the Zend developers might have been thinking when they designed some of it’s implementation.

Let’s say we’ve created a blog using the framework and in the side bar of each page would like to dynamically pull in a list of our recent flickr uploads as thumbnail images. This functionality might well be implemented as a view helper so in our templates all we need to do is:

<?php
echo $this->flickrImages();
?>

That keeps our view templates nice and clean and means we can share the flickr code across them. Behind the scenes the view helper would probably need to connect to the flickr API, find the recent uploads and return a list of image URLs. Then the helper might format them into a nice HTML list.

So here we have introduced a pretty big dependency in the view on a HTTP call to the flickr API and all the associated classes that go with it. This might become a bit of a problem when writing some unit tests for our controller using Zend_Test_PHPUnit_ControllerTestCase, as we don’t necessarily want to talk to flickr each time the tests are ran.

However, because we have implemented this functionality as a view helper, as opposed to something like $flickrImages = new FlickrImages(); we have already mitigated the dependency. By using the same tools the Zend Framework gives us for creating normal view helpers, we can inject a test fixture into our application when we are unit testing.

We can create a fixture view helper somewhere in our tests directory.

<?php
/**
 * A test fixture for the flickr images view helper
 */
class MyApp_Test_View_Helper_FlickrImages {
    public function flickrImages() {
        return '<ul><li>Fake stuff</li></ul>';
    }
}
?>

And load that when we bootstrap our controller unit tests.

<?php
$view = new Zend_View();
$view->addHelperPath('/path/to/real/helpers', 'MyApp_View_Helper');
$view->addHelperPath('/path/to/test/helpers', 'MyApp_Test_View_Helper');
?>

Because Zend View looks first in the most recently added path for the requested helper class it will find the fixture helper before the real one. A similar technique can be employed with action helpers to inject dependencies into your controllers. Dependency injection patterns such as this are interspersed throughout the Zend Framework and once realised can make unit testing your application’s components a lot easier.

What are your thoughts? Have you found any interesting dependency injection patterns or techniques in the Zend Framework? Why not share your thoughts below.