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.

My unit tests used to look something like this:

require_once dirname(__FILE__) . '/../TestHelper.php';
 
class FooTest extends \PHPUnit_Framework_TestCase { ... }

This allowed me to run the tests as part of a suite or run them individually. This worked fine, but it was annoying to always have to make sure the require_once statement was correct. As I create tests in sub-directories I would often forget this. I can now remove the require statement and run the unit test with the following command:

phpunit --bootstrap TestHelper.php crimsontest/FooTest.php

I create a runtests.sh script so I don't have to manually type the phpunit command plus the required flag:

#!/bin/bash
DIR=`dirname $0`
phpunit --bootstrap $DIR/TestHelper.php $DIR/crimsontest/AllTests.php

I already updated all the unit tests in the Crimson framework to use a the bootstrap strategy.

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.