Table of contents for Professional PHP Development

1. Professional Development with the Zend Framework: Introduction
2. Professional Development with the Zend Framework: Unit Testing

I started this serious with a very specific goal in mind. I wanted to highlight some of the qualities I find most useful and most important within the context of the Zend Framework code as a way to show developers how to look at other projects and build upon their own professionalism. One of the most important facets—in my opinion of course—of the framework's code base is something that is often overlooked: the comprehensive test suite.

Testing is most often regarded as a liability by managers because it does not provide any measurable value to a product in the eyes of anyone excepting developers. But the value is definitely measurable and quite obvious if one would take the time to observe project development through the maintenance phase and, quite possibly even more importantly, in multi-developer environments.

The Zend Framework Test Suite

In the coming sub-sections we will look at the aspects of the framework's test suite that I find most influential to its success.

Organization

The first thing to notice about the tests directory for the framework is the slim profile. These few files and directories are a testament to the organizational aspect of the suite. This is important because tests that are difficult to find or inappropriately named will not be maintained.

It is completely possible to not use the AllTests method for suite organization which in smaller projects might seem like a burden. But the use of these groupings allows different subsets of tests to be run for a given component with consistent state and configuration.

Configuration

Since there are developers working on various components, features, and bugs throughout the world it is essential that each be able to have a consistent environment in which to test. This test suite uses a configuration file, TestConfiguration.php, and a helper file, TestHelper.php, to configure the environment through PHP constants and set up include paths, etc., respectively.

Tests that can only be run on a specific machine are almost as useless as no tests at all.

Verbose Case Naming

Looking at an individual test file you will notice that the cases, or methods, are named to signify exactly what the test will assert. This is incredibly helpful when staring at code after a while. Using an IDE's outline functionality it is simple to find the test that verifies that a useful message is thrown if a class is not found by the factory because it is contained with the testStaticFactoryClassNotFound() method.

Use of Grouping Comments

PHPUnit uses comments to accomplish some meta-data and grouping functionality. Throughout  the test suite you will run across individual test methods that have a @group annotation which, most of the time, references an issue in the issue tracker. For example a comment might look as follows for a test case that reproduces the issue ZF-2724.

/**
* Handle file not found errors
*
* @group ZF-2724
* @param int $errnum
* @param string $errstr
* @return void
*/


This is another way to run specific tests. Using the command-line test runner's --group switch you can specify the group of tests to run as follows.

phpunit --group ZF-2724 .

Which tests to run and which to skip can also be configured using the phpunit.xml configuration file.

Testing For Backwards Compitability

One of the Zend Framework project's goals is to ensure that no BC breaks occur except in major releases — this should be a common goal for all projects, but that's just my opinion. Throughout the test code you will find cases that both document and expect that the "old way" and the "new and improved way" of accomplishing something are tested.

This is an area often overlooked during major improvement cycles. I know I am guilty of changing something significant or deprecating a method, etc., and then updating my client code to use the new API but leaving other team members out in the cold. I didn't do it purposely, it was just a novice mistake.

The concept to take away is to not delete or rewrite a test case because you add a new API method (unless it's supposed to be a BC break, then by all means). Instead, write a new case to test the improved method while still maintaining the functionality of the older method. You will make the developers that use your code happy.

These are just a few of the many excellent qualities of the Zend Framework test code. I encourage you to share something you found and admire.

Mise en Place is not Big Design Up Front

When thinking about this concept my first reaction was that it sounds a lot like a methodology we are trying to forget. The idea is not to get absolutely everything ready for the entire project at once, rather it is to prepare the tools, the functional requirements, the goals, etc. for an individual component before starting actual work.

A meal is composed of several "dishes" if you will. Normally you have a protein source, a vegetable, a salad, and maybe some bread. Each of these is a component of the overall meal and each can be prepared by a different cook. Now, I won't bore you with the names of each of the types of cooks — besides that is a great use for Wikipedia — but as developers we sometimes have the luxury of separating components and giving them to different team members or even to different teams.

Preparing Your Workstation

I don't mean your literal desk or even  your computer. I mean getting your project or component in order. The first part of mise en place involves building the tools used for your project. For example, getting the build system in order, or creating the test suite directories and bootstrap files. You have a better idea of the tasks that must be accomplished, but doing them all before you even start actually coding will benefit you in the long run.

After you get your high-level tools built and your environments configured you can start by gathering all the specifications for your portion of the component or project. This might be user stories, interface mock-ups, et cetera. Once you have the requirements you can create any tests, tools, or other components you need until you feel you are truly prepared to build the functional project code.

I like to break my work into small tasks. As such, I prepare my mise en place only for an individual unit of work by creating issues, bug reports, or feature requests in the issue tracker, writing the unit tests I hope to be able to pass as part of my development mise en place — which is why I employ TDD frequently, and generating some sample documentation for the individual component. Once I'm done with my work I'll go back and modify the documentation if something happened to change along the way. In this way, my documentation is as up-to-date as can be expected.

How do you practice the concept of Mise en Place?

The Literal Definition

Most people when first introduced to the concept of coding to an interface or even "design by contract" type concepts take the literal definition. At this basic level the technique means to use your programming languages OOP interface to define the behavior of the objects you will be using and accept objects that implement that interface where necessary, as illustrated in the following listing.

interface Deleteable
{
    //some methods
}

class Book implements Deleteable
{
    //implementation
}

class BookDataSource
{
    public function delete(Deleteable $book)
    {
        $this->purge($book);
    }
}

With this arrangement any methods that are necessary to prepare an object for deletion will be implemented in the Book class and the data source will only allow objects that implement the Deleteable interface to be purged from existence.

This technique is employed to allow better unit testing, for polymorphism, to ensure that objects have certain behavior, and a variety of other reasons. Coding to the contract provided by the interface is a great practice.

An Expanded Definition

While the literal definition above is definitely accurate and valuable, the interface extends into other areas. In modern software projects there are a variety of resourced one can call upon to learn about the behavior and properties of software components. Each of these resources is a part of the contract and useful as an interface to which developers should code.

Documentation

The most obvious resource for defining behavior and properties is documentation. Whether this is some sort of specification document in a wiki, in a binder, on notecards, on napkins, etc., or code comments documentation is a useful interface as long as it is maintained. Maintenance is the pitfall of using documentation as a contract because it is so often and so easily neglected.

Because documentation is most likely out of date — hey, I code in the real world — it is my last choice for an interface-defining resource. However it's better than having nothing.

Unit Tests

Thinking about it, unit tests are the ultimate supplemental contract for code. They will immediately notify the developer if the terms of the contract (the assertions) are broken. They also provide usage documentation that will help integration efforts.

In Your Code

The message I hope to get across with this post is that the concept of design by contract or coding to an interface is broader than the literal implications. Using supplemental contracts for your projects will make your projects better if only for that day in the future when you wonder why you made the decision you did.

What is My Comfort Zone?

The absolute first step in this technique for improvement is to figure out where you comfort zone is. For a lot of the people the knee-jerk answer is in whatever language they are currently using. This is not a bad answer but it will most likely lead to a shallow experience. For example, my obvious comfort zone is in PHP development. To step outside my comfort zone, then, I'd merely need to read through someone else's project written in Python or even Ruby and then pat myself on the back for each concept or technique I can extract from such projects. However, doing so doesn't really answer the question what is my comfort zone and doesn't force me to get outside of it.

My real comfort zone could be working with a relational database or even using scripting languages. I could easily follow the noSQL revolution for a sample project or work on a project written in, e.g., .NET using C#. These technologies are so different from my normal tools that I'd be forced to think about problems and solutions in a different light.

Different Technologies, Different Approaches

Working with differing technologies is not guaranteed to help at all. In fact the experience can be extremely frustrating because you will come across innovative solutions that simply won't be possible in your "home" environment because of language or technology barriers. This is natural and should be expected. If this weren't the case we wouldn't have such a deep pool of languages to chose from.

Instead of focusing on the negative, keep digging into the project. Given enough time you should be able to find a few concepts from the new environment that you can either adopt or at least adapt into projects in your preferred languages and tools. In my case I inherited a few projects that are written in .NET. Instead of immediately grumbling about how awful it is to work in that environment, I've embraced it and gone on some bug hunting/fixing expeditions through the code. As a result I've learned quite a bit about how another developer uses a different technology to accomplish some of the same tasks.

Read Other Developers' Code

This leads me to the final benefit of stepping out of your personal playground: you get to read other developer's code. I don't remember where but I recently read a comment in which the author stated that it's silly for a developer to assume he or she can continue to expand his or her knowledge without reading peer code. He or she went on to say that this is like a person deciding to become an author without ever reading other works.

At first I resisted the notion that an author must read other's work before becoming a talented author. After all, it's quite possible that a person can be naturally gifted. However, the underlying meaning became apparent. We all must learn ways that work and some ways that do not. Without seeing a variety of approaches there will be no growth. This does not mean that you must immediately adopt what you read. You should look for similarities to your own work as much as you find differences.

A Real-life Example

Like a lot of other web developers I've always held contempt for JavaScript. It's a language that was once far outside my comfort zone. However, the Dojo framework came along and converted me. Using and reading through the code led me to appreciate all the nuances I once despised about the JavaScript language. I listened to talks on the language's history, I learned some of the advanced techniques and concepts presented by Douglas Crockford, John Resig, et cetera, and then I read the specs for upcoming versions of PHP. I had unknowingly adopted some of the functional programming techniques and concepts prevalent in JavaScript and now I could apply them to my PHP projects.

Stepping out of my comfort zone was one of the most influential decisions I've made. I hope you will take some time to do the same.

I'd like to discuss some of the highlights for this past year and, for the first time ever, publicize some of my goals for 2010 and beyond.

In 2009 I

1. transitioned to a new position at Texas A&M University;
2. authored another article for php|architect;
3. participated in the LIVESTRONG Challenge charity bike ride in Austin, TX;
4. proposed to Lisa and we are planning our wedding for July 2010; and
5. started negotiations for a book I will author in 2010.

I blogged about it earlier this year, but back in August a friend of mine let me know that he was moving to a new position and this his current position would be vacant. I eagerly took the opportunity to apply for and be hired into that position effective September 1, 2009. Since moving in I've done some work on several projects including working on the so-called mobile web site for Texas A&M University. We have an iPhone and Blackberry application, but we saw a need for a more universally-accessible version of the site.

In October, I participated in Lance Armstrong's LIVESTRONG Challenge charity bike ride in Austin, TX. That is also when I proposed to my fiancé, Lisa, and she accepted. We are working diligently on coordinating all the details for a wedding ceremony — or celebration as the church calls it — on July 3, 2010. So far it's been an experience I will not soon forget.

In late 2008 I stated that I'd like to successfully pitch a book idea to a publisher in 2009. Well I was correct that it would be scary. I pitched several ideas, actually, but only one of them was accepted. I'm currently communicating with the acquisitions editor on the specifics, so I will refrain from disclosing any further information until it's appropriate. I'm glad I was able to scratch this item off my goals for 2009 list even if it's just a strike-through in pencil.

In 2010 I hope to

• Author and publish my first book;
• move into an more "adult" apartment complex;
• run my first half marathon;
• lose at least 80 pounds;
• take a photo a day — the 365 project — for the whole year; and
• author a useful blog post per week.

Obviously the book goal is sort of a carry-over from 2009, but since I'll actually be writing the book in 2010 it's a fine goal. After all, I've heard that the process is quite involved and stressful at times. Given the speed of the proposed delivery schedule I believe the friends that have already gone through this about the stress.

After we get married, Lisa and I plan to get out of the student-focused apartment complex we currently live in and move into a more "adult" complex. We are most excited about the size of the kitchen as we are both foodies and love to cook but our current galley-style kitchen leaves a lot to be desired in terms of usability — especially for more than one cook. We also hope that a garage will be available in the complex as we could definitely use the storage space. With two bicycles and the transition from two apartments into one, we'll need all the room we can get.

At one point in my life — believe it or not — I was an avid runner capable of hitting the roads for a nice 8-mile run in the wee hours of the morning before heading to class or work. These days I'm lucky to make it two miles before I need a walk break. In 2010 I want to change that. With my sister's new interest in running I thought now would be the perfect time to work up to a half marathon, and chose the Big-D Marathon in Dallas, TX on April 11. It's a somewhat realistic goal as we will both go into the race knowing that we aren't shooting for a podium spot, just a finish.

Along with the running goals I need to lose weight. I've started several times but always found excuses to put it off. Well, no more. It's time.

The 365 project is an interesting concept and I need to get back behind the lens. I've probably lost what few skills I had so I hope this endeavor will bring them back.

Finally I hope to be a better citizen by blogging more. This has always been an issue for me and I am taking inspiration from Brandon Savage's dedication to posting at least once a week. I can only hope to be able to find topics to write about and the time to crank the posts out on top of writing the book.

In the next five years I hope to

• become a parent with Lisa;
• purchase our first home;
• find two German Shepherd companions to enhance and protect our growing family; and
• kill my 1990 Acura Integra and get behind the wheel of my dream car, whatever it is.

The first two five-year goals are self explanatory. We've already talked about kids and we are in agreement of our preferences for family size and hopefully we will be able to realize those dreams. The home idea is a three-year goal. We will most likely live in the apartment we move into after marriage for two or three years before taking the plunge into home ownership. This will give us time to build up savings for the necessary investment and improvements.

I have always loved the German Shepherd breed, but, given the size of the dogs, we will need ample space for them to be happy. We know we have to wait until we purchase a home to add them to our family, but I hope to be in a position to find them within four years.

My car, as much as a love it sometimes, is on the downward spiral. Truthfully I've wanted to ditch it so many times, but it is a strong Honda car and refuses to die. The plan now is to begin looking for alternate transportation as the odometer continues to creep towards 200,000 miles. I'm thinking that for the immediate future I'll settle on either a new car or something like a Chevrolet Blazer, GMC Equinox, Ford Escape, or similar vehicle until I'm in a better position to get the four-door Jeep with enhancements I have my eye on.

Merry Christmas and Happy New Year

That about sums up my major accomplishments for 2009 and a glimpse into my planned future. Have a great two holidays!

Target Audience

As mentioned in the preface the primary audience for this book is the Zend Framework novice looking to learn about the framework and how to leverage the components to create web applications. He mentions that his secondary audience is developers that currently use the framework and would like to learn more about how to apply emerging best practices to his or her projects. In my opinion this book delivers appropriate content to provide value to both audiences.

The Basic MVC Application

The first chapter is a run through on getting a 'Hello World' application up and running. This approach can easily be so incredibly simple that it is useless or significantly complex that is leaves the novice feeling like he or she was punched in the gut. Pope did an outstanding job of combining explanation of the whys without overwhelming the reading as well as providing the simple hows to satisfy the impatient reader.

He takes careful time to walk the reader through design decision when discussing the model or domain layer which is essential to maintainable applications. I found his explanation of other approaches and the specific reason he chose a particular approach to be above what I expected from a "beginner" text, but not so theoretically-laden as to confuse or alienate the novice.

His use of some of the concepts used by more seasoned developers, such as using Front Controller Plugins and Actions Helpers, in his Storefront application is something a novice will find most valuable. While it might seem easy enough to avoid doing this by placing the code elsewhere his presentation of these elements will help curb the instinct to produce code that the developer will regret later.

Key Areas Addressed

As mentioned this book is fairly complete in the tutorial-based run through of the framework's features and how use them for a real-world application. I am particularly happy with his brief introduction to practices such as testing and some optimization hints. While it is definitely a bad idea to prematurely optimize his experience is apparent in these chapters.

Overall Opinion

Overall Keith Pope and Packt Publishing produced a quality introductory text to developing with the Zend Framework. His work will be useful to not only the complete novice but to those developers that are familiar with the framework but wish to improve his or her practices to be more in line with emerging "best practices". The only criticism I would offer on the book is, by my own admission, slightly invalid because it is not something that could be easily addressed: I yearn for a more in-depth analysis of the model layer. The model layer, being the implementation of the domain of the project, is incredibly complex and entire volumes could be written to go through implementations. In fact, there are already books that do this in the theoretical sense. I think that Pope's introduction does suffice for the target audience.

Goals of a Unit Test Suite

Other than exercising a substantial portion of your code a unit test suite must be capable of running quickly lest it be a burden on development. Having a burdensome, slow-running test suite will only encourage developers to ignore it and only run it when absolutely necessary. This, in turn, will make maintenance of the test suite more difficult and probably result in fragile or poor tests which ultimately will leave a bad taste in the developer's mouth about unit testing, and we wouldn't want that, now would we?

One sure-fire way to decrease the speed of a test suite is to make it rely on real-world data sources such as your relational database or even a web service. Imagine a test suite for an application that relies on Twitter's availability. I can assure you that I would not want to run that test suite. The fail whale is annoying enough on the web. But I digress. Being able to emulate a data storage source is paramount to the speed of a unit test. Stubbing is one technique employed to do such a thing.

A Data Source Interface

A basic data source needs the implement the standard CRUD methods and can be defined as follows:

interface ICrudDataSource
{
    public function create(array $data);

    public function read($id);

    public function update($id, array $data);

    public function delete($id);
}

If this were a real interface there would be PHPDoc blocks to indicate the behavior of the methods and parameter types, but for the sake of the example I omit them. Now we can implement this interface in our database table class and define the behavior for each of the methods in terms of how our chosen rdbms will understand them, e.g., create() is an INSERT statement, read() is a SELECT statement, so on and so forth.

We can then use this class in our unit tests and it will actually test that the database vendor correctly implemented the INSERT, SELECT, UPDATE, and DELETE statements and that we are calling them appropriately. While I do think the latter should be tested when we look at the database abstraction implementation, the former is not necessary and will only slow down tests that use the data source code but don't directly depend on it being a database, for example. In such a case a simple array-based storage mechanism will work.

Array-based Stub for Unit Testing

Thus, we implement the ICrudDataSource interface in a stub that is used for our unit tests that need to interact with the data storage but necessarily need to interact with the specific data storage used in production.

class UserDataStorageStub implements ICrudDataSource
{
    protected $_store;

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

    public function create(array $data)
    {
        if (!$this->exists($data['id'])) {
            $this->_store[$data['id']] = $data;
            return true;
        }

        return false;
    }

    public function read($id)
    {
        if ($this->exists($id)) {
            return $this->_store[$id];
        }

        return false;
    }

    public function update($id, array $data)
    {
        if (!$this->exists($id)) {
            return false;
        }

        $this->_store[$id] = $data;
    }

    public function delete($id)
    {
        unset($this->_store[$id]);
    }

    private function exists($id)
    {
        return array_key_exists($id, $this->_store);
    }
}

With this array-based implementation the unit tests will be fast regardless of the availability of the actual data source or the load on that data source. This stub, or a stub that extends this one, can also be easily pre-populated with test data to allow for testing with fixed data (although this can lead to very brittle tests if done lackadaisically).

In my previous post I chose an example that did not illustrate my point. In this post I will address the issues with previous post, specifically those brought to light by Matthew Weier O'Phinney in his comment.

His first point is that changing the method signature on a constructor should and will break any client code, thus modifications will be necessary to the tests. I agree with this wholeheartedly and my choice of using a constructor was obviously flawed. Let's just chalk this one up to not having had my coffee as I typed that post…

His second point deals with using the tools available to you within the framework. Specifically he mentions the use of the setUp() method which executes prior to each test case and is normally used to establish required state, set up fixtures, etc. I already committed to the constructor example so I carried it through this segment of the code. It was, again, a bad decision.

So this post will serve as a replacement for the old post to better illustrate my point.

Maintainable Tests

Great unit testing is a learned skill. Unfortunately the motivation developers have for dabbling in writing unit tests for an application usually comes from someone else, e.g., his or her boss, a fellow team member, etc. This leads to writing tests just to have tests which, in my opinion at least, is no better than not having tests in the first place.

A non-maintainable code base is know to be a problem. The corollary, a non-maintainable test suite is a huge problem, is also true. If you cannot maintain your test suite, what is the point? Any time a unit test reaches beyond a single or violates the DRY principle a development team could find that the test suite is verging on a non-maintainable state.

Testing Units More Than Once

If a requirement or business rule is tested more than once in the test suite, as is the case in the following example, any changes become difficult to manage. In this example the business requirement that changed is that all cars start with five gallons of gas before they arrive at your showroom. Thus a brand new car, i.e., the default constructed car, will not have an empty gas tank and should be able to start—unless something else is wrong, but I am a programmer not a mechanic.

class CarTest extends PHPUnit_Framework_TestCase
{
    protected $_car;

    public function setUp()
    {
        $this->_car = new Car();
    }

    public function testGasolinePresentBeforeStarting()
    {
        $this->setExpectedException('GasTankEmptyException');
        $this->_car->start();
    }

    public function testCarStartsAfterFillup()
    {
        $fuelVessel = $this->getMock(
            'GasolineContainer',
            array('dispense')
        );
        //set expectation on fuelContainer to give 10
        //gallons of fuel when dispense is called

        try {
            $this->_car->start();
            $this->fail(
                'Empty gas tank but no exception caught'
            );
        } catch(GasTankEmptyException $e) {
            $this->_car->addGasoline($fuelVessel);
        }

        $this->_car->start();
        $this->assertTrue($this->_car->isRunning());
    }
}

This change is not necessarily a regression because code that used the Car object before should still work as intended the cars will just start from scratch with some gasoline. Since we changed this requirement both tests in the above code will fail. The first will fail because we assumed a brand new car object would have no gasoline in the tank. The same for the second test. The code repeats itself, and so does my explanation.

Avoiding the duplication in the second test by immediately filling up the car with gasoline solves the problem of having to dig through the unit test and makes the second test case a true unit test. As it stands above, it tests two units: 1) that a car with an empty tank throws a specific exception and 2) that after adding gasoline to the car it will start.

Using the Tools Correctly

I knew about setUp() and tearDown() but I was trying too hard to come up with a fancy solution to my problem. The problem, as it should have been explained previously, occurs when a test case has groups of tests that require different configurations of the UUT. For example, sticking with our Car class, we have several tests that require a stock instance of Car while a group of others needs a car with a special engine. We can accomplish this as follows:

class CarTest extends PHPUnit_Framework_TestCase
{
    protected $_car;

    public function setUp()
    {
        $this->_car = new Car();
    }

    public function testSomethingWithAStockCar()
    {
        //work
        $this->assert(…);
    }

    public function testSomethingElseWithStockCar()
    {
        //same as above
    }

    public function testCarWithDifferentEngine()
    {
        //mock/stub of engine: $engine
        $this->_car->setEngine($engine);
    }

    public function testCarWithDifferentEngineAgain()
    {
        //mock/stub of engine: $engine
        $this->_car->setEngine($engine);
    }
}

Assuming I abstract the creation of the mock engine into a helper method, I still have a lot of duplicated code and I still have to call the setEngine() method in each test. That's absurd. One solution is to create a new test case for the different configuration; I'll call it CarWithEngineBTest.

class CarWithEngineBTest extends PHPUnit_Framework_TestCase
{
    protected $_car;

    public function setUp()
    {
        $engine = $this->getMock('EngineB');
        //…configure mock object…
        $this->_car = new Car();
        $this->_car->setEngine($engine);
    }

    //test cases that need this configuration
}

And remove these specific tests from the previous test case. This probably isn't the only way to solve this issue, but it does seem better than my previous factory method "solution".

The example still isn't perfect, but I couldn't come up with a better one. You are more than welcomed to weigh in.

Great unit testing is a learned skill. Unfortunately the motivation developers have for dabbling in writing unit tests for an application usually comes from someone else, e.g., his or her boss, a fellow team member, etc. This leads to writing tests just to have tests which, in my opinion at least, is no better than not having tests in the first place.

A non-maintainable code base is know to be a problem. The corollary, a non-maintainable test suite is a huge problem, is also true. If you cannot maintain your test suite, what is the point?

Looking at an example, I frequently see test cases that have the UUT's constructor called at the beginning of each test. This works fine up until the requirements change and the constructor now requires an instance of IDataSource or an array instead of a string. Now each test must be touched, i.e., development time devoted to each test function, to implement this change.

class CarTest extends PHPUnit_Framework_TestCase
{
    public function testStartFailsIfGasTankEmpty()
    {
        $car = new Car();
        $this->setExpectedException('GasTankEmptyException');
        $car->start();
    }

    public function testSomethingElse()
    {
        $car = new Car();
        //assert something
    }

    //so on and so forth
}

Instead, if a developer uses a factory method within the test suite to return a default instance of the UUT, the change to the tests is only necessary in cases where the initialized state of the instance must change via the constructor, as follows.

class CarTest extends PHPUnit_Framework_TestCase
{
    public function testStartFailsIfGasTankEmpty()
    {
        $car = $this->Factory_Car();
        //…snip…
    }

    //…snip…

    private function Factory_Car()
    {
        return new Car();
    }
}

Okay, that works for a while. But what if in ninety-five percent of the tests you need to use the "default constructor"—in quotes because PHP classes can only have one constructor—but the other five percent need to pass in some configuration options. You have two choices:

1. create a new factory method for each group of, e.g., Factory_Car and Factory_SuperFastCar, or
2. allow the existing factory method to take arguments and pass them on to the constructor.

Which you choose depends on the unique situation of your test case. For this example I'll assume there are ten tests. Seven of the tests use a default Car object while the other three each need a unique Car instance, thus each passes a configuration argument to the constructor. To handle this situation the factory method will make use of the PHP functions func_get_args() and call_user_func_array().

public function Factory_Car()
{

    $car = new Car();
    if (func_num_args() > 0) {
        $args = func_get_args();
        call_user_func_array(array($car, '__construct'), $args);
    }

    return $car;
}

This factory method allows each test to retrieve a properly-configured instance—where configuration is done via the constructor—of the Car class with which to work without sacrificing maintainability. One caveat: the three test methods in the example will need to be modified if the constructor's signature changes, but, last time I checked, three is less than ten.

One area that I like to make use of exceptions is unexpected input, especially in terms of function/method arguments. A lot of times the standard practice seems to be to return FALSE for invalid input, but the boolean value false should be reserved for boolean indication. Likewise, NULL should have a special connotation, semantically speaking.

In this first example, a repository (or mapper) is attempting to find a user with an id—let's assume it is a database id—that should be an integer. (This code uses the Zend_Db_Table component to abstract queries, etc.)

class UserRepository implements IRepository
{
 public function fetchById($id)
 {
     $data = $this->getDbTable()
                 ->find($id)
                 ->current();

     if (null === $data) {
         return null;
     }

     return new User($data->toArray());
 }
}

Notice there is no validation performed on the $id parameter which is pushed directly into the database table query. Granted the Zend_Db component will handle this error with minimal pain, i.e., you should be fairly protected against a SQL injection attack, but you know that your database table uses an integer for the ID column thus your application should only respond positively to an  integer value for $id.

public function fetchById($id)
{
    if (!is_int($id)) {
        return false;
    }
    //…snip
}

My first attempt (above) at validation uses the native is_int() validation function to check if the value supplied for $id is an integer. If it is not the function returns false. There is plenty of precedent behind using the value FALSE as the error state, but it is blatantly not semantic. FALSE is obviously not the user object I asked for, but it does not indicate what went wrong.

Finally, I decide to use the Zend_Validate component—for this trivial example it may be overkill, but it does the job nonetheless—to validate my input parameter for the user's ID property. Also notice that I am now throwing an exception object, specifically an InvalidArgumentException.

public function fetchById($id)
{
    $validator = new Zend_Validate_Int();
    if (!$validator->isValid($id)) {
        throw new InvalidArgumentException(
            'User ID must be an integer.
        );
    }
    //…snip
}

The InvalidArgumentException exception is one of many defined in the SPL as an extension of a logic exception. The reason for using such an exception class would be to improve the readability and usefulness of client code. When I use the UserRepository object, my client code will look as follows. When an invalid argument, i.e., a non integer is given to the fetchById() method it is obvious which code path will execute.

try {
    $repository = new UserRepository();
    $user = $repository->fetchById("jcarouth");
} catch(InvalidArgumentException $e) {
    //we passed an invalid argument, i.e., a non-integer
} catch(Exception $e) {
    //some other
}