CHAPTER 20 ■ OBJECTS, PATTERNS, PRACTICETesting
Although testing is part of the framework that one applies to a project from the outside, it is intimately
integrated into the code itself. Because total decoupling is not possible, or even desirable, test
frameworks are a powerful way of monitoring the ramifications of change. Altering the return type of a
method could influence client code elsewhere, causing bugs to emerge weeks or months after the
change is made. A test framework gives you half a chance of catching errors of this kind (the better the
tests, the better the odds here).
Testing is also a tool for improving object-oriented design. Testing first (or at least concurrently)
helps you to focus on a class’s interface and think carefully about the responsibility and behavior of
every method. I introduced the PHPUnit2 package, which is used for testing, in Chapter 18.
Documentation
Your code is not as clear as you think it is. A stranger visiting a codebase for the first time can be faced
with a daunting task. Even you, as author of the code, will eventually forget how it all hangs together. In
Chapter 16, I covered phpDocumentor, which allows you to document as you go, and automatically
generates hyperlinked output.
The output from phpDocumentor is particularly useful in an object-oriented context, as it allows
the user to click around from class to class. As classes are often contained in their own files, reading the
source directly can involve following complex trails from source file to source file.
Version Control
Collaboration is hard. Let’s face it: people are awkward. Programmers are even worse. Once you’ve
sorted out the roles and tasks on your team, the last thing you want to deal with is clashes in the source
code itself. As you saw in Chapter 17, Subversion (and similar tools such as CVS and Git) enable you to
merge the work of multiple programmers into a single repository. Where clashes are unavoidable,
Subversion flags the fact and points you to the source to fix the problem.
Even if you are a solo programmer, version control is a necessity. Subversion supports branching, so
that you can maintain a software release and develop the next version at the same time, merging bug
fixes from the stable release to the development branch.
Subversion also provides a record of every commit ever made on your project. This means that you
can roll back by date or tag to any moment. This will save your project someday—believe me.
Automated Build
Version control without automated build is of limited use. A project of any complexity takes work to
deploy. Various files need to be moved to different places on a system, configuration files need to be
transformed to have the right values for the current platform and database, database tables need to be
set up or transformed. I covered two tools designed for installation. The first, PEAR (see Chapter 15), is
ideal for standalone packages and small applications. The second build tool I covered was Phing (see
Chapter 19), which is a tool with enough power and flexibility to automate the installation of the largest
and most labyrinthine project.
Automated build transforms deployment from a chore to a matter of a line or two at the command
line. With little effort, you can invoke your test framework and your documentation output from your
build tool. If the needs of your developers do not sway you, bear in mind the pathetically grateful cries of
your users as they discover that they need no longer spend an entire afternoon copying files and
changing configuration fields every time you release a new version of your project.