Top down and test driven

PHP unit testing tutorial - Top down design test first with mock objects

# mock Mock now, code later

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... <?php class <strong>Writer</strong> { function <strong>Writer()</strong> { } function write($message) { } } ?> The corresponding test changes are... <?php require_once('../classes/log.php'); require_once('../classes/clock.php'); require_once('../classes/writer.php'); Mock::generate('Clock');<strong> Mock::generate('Writer');</strong> class TestOfLogging extends UnitTestCase { function TestOfLogging() { $this->UnitTestCase('Log class test'); } function testWriting() { $clock = &new MockClock($this); $clock->setReturnValue('now', 'Timestamp'); $writer = &new <strong>MockWriter($this)</strong>; $writer->expectOnce('write', array('[Timestamp] Test line')); $log = &new Log($writer); $log->message('Test line', &$clock); $writer->tally(); } } ?> 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.

# bridge Approaching the bridge

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.

# design Mock down 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.

Mock now, code later. We derive the bridge pattern. Designing and testing hand in hand.
This tutorial follows Boundary classes. You will need the SimpleTest testing framework to try these examples. For more mock object discussion see the Extreme Tuesday Wiki or the C2 Wiki
software development, php programming tutorial, programming php test cases, software development tools, php tutorial, free php code, architecture, php examples, mock object examples, junit style testing, php testing frameworks, unit test, mock objects in PHP, php testing