A few days ago Hudson began emailing alerts that a freight calculation unit test was failing in production. I emailed the developers responsible for the code and asked them to investigate this right away. The funny thing about unit tests failing in production is that developers can fall into a mindset of "the code is working on production, so there must not be a problem". The freight calculations did appear to be working correctly on production. Because we are so busy, no further investigation was done until yesterday.

Yesterday afternoon two developers realized that this failing unit test was the result of a serious regression in our "premium" freight calculation. This freight calculation type is most commonly used for furniture items and can easily calculate a shipping cost well over $100. This particular bug was calculating the "premium" freight costs as free. Now HauteLook's business model is flash sales. This means new sales events start at 8:00 am PT each morning and most of the business is done within the first few hours of the event. If there had been a furniture sale event within the past couple of days, HauteLook would have given away thousands of dollars worth of free shipping (or even tens of thousands if the event was large enough) before we would have noticed and fixed the issue. Shipping costs were not the only thing we saved either. The amount of time, energy and stress that it would have taken for the various departments to address this issue would have been high.

I saw an immediate change in the way my colleagues view unit tests. This was a clear indication that our investment has paid off. In this case we had well written unit tests that quickly alerted us to a problem before it costs us anything. I know next time a unit tests fails on production, HauteLook developers will not assume everything is working.

I first attempted to mock Zend_Db_Table_Row using PHPUnit's _getMock method.  This proved to be an exercise in futility.  I did not want the class to connect to the database to verify whether or not the columns were valid.  After a few frustrating hours, I started to wonder how Zend was unit testing Zend_Db_Table_Row.  So I downloaded the full version of the latest Zend Framwork and started poking around.  I stumbled upon My_ZendDbTable_Row_TestMockRow hiding away in ZendFramework-1.9.5/tests/Zend/Db/Table/_files/My/ZendDbTable/Row/TestMockRow.php.  I will not go into what was done to make it a usable mock, but I will show you how to use it.

<?php
 
require_once 'PHPUnit/Framework/TestCase.php';
require_once 'tests/Zend/Db/Table/_files/My/ZendDbTable/Row/TestMockRow.php';
 
class TestMockRowTest extends PHPUnit_Framework_TestCase
{
    public function testRowHasIdValue()
    {
        $data = array(
            'data' => array(
                'first_name' => 'Herman',
                'last_name' => 'Radtke',
                'email' => 'herman@example.com'
            )
        );
 
        $row = new My_ZendDbTable_Row_TestMockRow($data);
        $this->assertEquals('Herman', $row->first_name);
        $this->assertEquals('Radtke', $row->last_name);
        $this->assertEquals('herman@example.com', $row->email);
    }
}

Creating a mock row object is much like hardcoding an array.   Define an array that has a single key 'data' that contains an array as a value.  Inside this array, the database column name is the array key and the database column value is the array value.

That class works great for mocking a single row object, but I still needed a solution for multiple row objects.  I expected to find a class similar to My_ZendDbTable_Row_TestMockRow for the purposes of testing Zend_Db_Table_Rowset, but none existed.  Fortunately, it took only a few minutes to create my own.  All one has to do is specify the name of the row class for the rowset class to use.

<?php
 
require_once 'PHPUnit/Framework/TestCase.php';
require_once 'library/Zend/Db/Table/Rowset/Abstract.php';
require_once 'tests/Zend/Db/Table/_files/My/ZendDbTable/Row/TestMockRow.php';
 
class ZendDbTableMockRowset extends Zend_Db_Table_Rowset_Abstract
{
    protected $_rowClass = 'My_ZendDbTable_Row_TestMockRow';
}
 
class RowsetTest extends PHPUnit_Framework_TestCase
{
    public function testConstructor()
    {
        $rowset = new ZendDbTableMockRowset(array(
            'data'=> array(
                array(
                    'id' => 123456
                ),
                array(
                    'id' => 123457
                ),
                array(
                    'id' => 123458
                ),
                array(
                    'id' => 123459
                ),
                array(
                    'id' => 123460
                )
            )
        ));
 
        $id = 123456;
        foreach ($rowset as $row) {
            $this->assertTrue(($row instanceof My_ZendDbTable_Row_TestMockRow));
            $this->assertEquals($id, $row->id);
            $id++;
        }
    }
}

The array passed to the mock rowset has a similar structure to the one we used above.  The only difference is that we have multiple arrays, inside the 'data' array, each representing one row.   For testing purposes, I created an 'id' field.   I normally would not ever use an artificial key field inside a business logic class since that value is very dependent on the database.

I created a ZendDbTableMockRowset class in my projects test/mocks directory so I can use it in multiple test files.  I also copied My_ZendDbTable_Row_TestMockRow into the test/mocks directory so I would not be dependent on the external tests from Zend Framework.  Now mocking Row or Rowset objects is just as fast as mocking arrays.

Assume we have a person class.  The class constructor takes the persons full name and we have a getter and setter for the full name.

<?php
class Person
{
    protected $fullName;
 
    public function __construct($fullName)
    {
        $this->setFullName($fullName);
    }
 
    public function setFullName($fullName)
    {
        $this->_fullName = $fullName;
    }
 
    public function getFullName()
    {
        return $this->_fullName;
    }
}

There is also a method that parses apart the persons full name into separate parts. The naive approach:

    public function parseFullName()
    {
        $nameParts = explode(' ', $this->getFullName());
        ...
    }

This code works fine, but think about how we will write a test for this function.  We have to first set the full name using a setter so the parseFullName method can retrieve that value with a getter.  This violates one of the principle rules of unit testing: testing individual units of code.  If there is a bug in the getter or setter functions, they may inadvertently affect my test.  This is a very real issue when using the magic __get and __set methods. It also means more work to setup your tests because you have to keep in mind an order of operations when testing.

The better approach:

    public function parseFullName($fullName)
    {
        $nameParts = explode(' ', $fullName);
        ...
    }

Notice how the parseFullName function is being told what to parse rather than asking what to parse.  This subtle change now allows us to truly test this individual unit of code with the least amount of outside environment interaction.