I lied.

I haven't created a writer test at all, only the FileWriter interface that I showed earlier. In fact I'll go one step further away from a finished article and assume only an abstract writer in classes/writer.php... Writer { function Writer() { } function write($message) { } } ?> ]]> The corresponding test changes are... Mock::generate('Writer'); class TestOfLogging extends UnitTestCase { function testWriting() { $clock = new MockClock(); $clock->returns('now', 'Timestamp'); $writer = new MockWriter(); $writer->expectOnce('write', array('[Timestamp] Test line')); $log = new Log($writer); $log->message('Test line', $clock); } } ?> ]]> In order to use the logging class we would need to code a file writer or other sort of writer, but at the moment we are only testing and so we do not yet need it. So, in other words, using mocks we can defer the creation of lower level objects until we feel like it. Not only can we design top down, but we can test top down too.

Imagine for the moment that we had started the logging class from another direction. Pretend that we had coded just enough of the Log to realise we needed a Writer somehow. How would we have included it?

Well, inheriting from the writer would not have allowed us to mock it from the testing point of view. From the design point of view we would have been restricted to just one writer without multiple inheritence.

Creating the writer internally, rather than passing it in the constructor, by choosing a class name is possible, but we would have less control of the mock object set up. From the design point of view it would have been nearly impossible to pass parameters to the writer in all the different formats ever needed. You would have to have the writer restricted to say a hash or complicated string describing the target details. Needlessly complicated at best.

Using a factory method to create the writer internally would be possible, but would mean subclassing it for testing so that the factory method could be replaced with one returning a mock. More work from the test point of view, although still possible. From the design point of view it would mean a new logger subclass for every type of writer that we want to use. This is called a parallel class hiearchy and obviously involves duplication. Yuk.

At the other extreme, passing or creating the writer on every message would have been repetitive and reduced the Log class code to a single method, a sure sign that the whole class has become redundant.

This tension between ease of testing and avoiding repetition has allowed us to find a flexible and clean design. Remember our brief yearning for multiple inheritence? We have replaced it with polymorphism (lots of writers) and separated the logging hierachy from the writing hierarchy. We connect the two through this simpler Log by aggregation. This trick is actually a design pattern called a "Bridge".

So we have been pushed by test code (we haven't written much else yet) into a design pattern. Think about this for a second. Tests improve code quality, certainly in my case, but this is something far more profound and far more powerful.

Testing has improved the design.

Creating a mock object is as easy as creating the interface in text form. If you have UML or other tools that create these interfaces for you, then you have an even more flexible route to quickly generate test objects. Even if you do not, you can switch from white board drawing, to writing a test case, to writing a mock, to generating an interface which takes us back to the whiteboard drawing again, fairly easily. Like refactoring, design, code and test become unified.

Because mock objects work top down they can be bought into the design more quickly than normal refactoring, which requires at least partially working code before it kicks in. This means that the testing code interacts with the design faster and this means that the design quality goes up sooner.

A unit tester is a coding tool. A unit tester with mock objects is a design tool.