Coding Is Like Cooking

I’m very pleased to announce I’ve just published my first Pluralsight course – “Coding Dojo: Test Driven Development“! It’s based on the material in my book, converted to a video-friendly format along with audio commentary. If you purchase a subscription to the Pluralsight course library, you’ll get access to this video course, and hundreds of other courses aimed at software developers.

Since the video is also another iteration of my ideas and material, after I wrote the book, I’ve developed some themes, particularly around deliberate and incidental practice. I also had to focus more, and pick out the really important parts to talk about in the video. If you enjoy the video course, you might find the book contains useful extra material – especially the code kata catalogue.

I really think there is a big need in our industry for professional software developers to learn Test Driven Development and associated skills, and I can’t see it happening via the traditional method of instructor-led two day training courses. TDD is a practical coding skill that you actually have to do in order to get competent at it. It’s a lot more difficult in your average codebase than it needs to be, so a lot of people get discouraged and quickly go back to the way they wrote code before.

The Coding Dojo is a way to start a long term change in yourself and others in your team, and my hope is that the book and the video will provide you with the inspiration and means to get started.

This week I published my first book! I’ve been writing “The Coding Dojo Handbook” since last September, and publishing it as a work-in-progress on Leanpub.com. This week I decided it was time to declare it completed, since I think it hangs together as a whole book, and is useful in the role I imagined for it. In other words, I think this book has everything it needs to be a good starting point for someone setting up a new coding dojo, or for someone experienced in running one already, looking for ideas for new katas and collaborative games. I hope you’ll consider getting a copy if you’re in either of those situations!

Now the book is finished, I have to decide whether to look for a “real” publisher, or whether to just continue to sell it on leanpub. My current feeling is that my target audience, (programmers), are quite comfortable buying an ebook, and having a paper copy isn’t really a priority. The advantage of a publisher might be more sales channels, bookshops etc, and more copies sold overall. I’d also get a considerably lower proportion of the sale price. I’ve noticed that several authors I respect – people like Brian Marick and Roy Osherove – are publishing their newer titles exclusively on leanpub.com. So my current plan is to stick with leanpub and see how things develop.

I had originally planned a few more chapters, about London School TDD, and Approval Testing. When I started writing these chapters, I found I had far more to say than I had anticipated, and it didn’t seem to me that the material really fitted into this book. So what I’ve done is started a new book project, called “Mocks, Fakes and Stubs”

Right now it’s fairly small, more a pamphlet than a book, and I’m not charging a lot of money for it. If, as I hope, there is interest, I plan to add more material over the next few months. The focus is on showing TDD techniques using some of the code katas from “The Coding Dojo Handbook“. I’m hoping the new book will have the feeling of pair programming with an experienced coder, explaining the theory of a technique at the same time as demonstrating it.

I’ve got a couple of workshops coming up, at XP2013, when I’ll be doing research for my new book. Basically I’ll be using code katas to explore TDD techniques like Outside-In, Approval Testing, and Given-When-Then style BDD tests.

So my first book is finished, and I have a new book project to occupy my time!

I’m pleased to announce a new home for my blog: henceforth I will be blogging on the url “coding-is-like-cooking.info“. Please update your RSS feeds to point at the new site!

At some point I plan to delete my blogger account, since all the articles have been transferred to the new url. (If you find links between articles that don’t work on the new site, please let me know, there are some aspects the automatic import doesn’t handle very well.)

I’ve been using Blogger for years, and I can recommend it as being easy to use and quick to get started with. What’s prompted the change is that I really wanted to take full control of my content and the way it’s presented. Since I started this blog 6 years ago, it has turned from a hobby project into an important channel for me to present my newest ideas and get feedback from my peers in the community.

Over the last 6 months or so, the traffic on my blog has exploded. I used to average about 1000 page views per month, but since mid 2012 I’ve been consistently getting 3000-4000 page views per month. That huge peak in September 2012 corresponds to my article “SOLID principles and TDD”, which received lots of comments and tweets. The most recent peak corresponds to my follow-up series of posts about London School TDD.

Monthly Page views for “Coding is Like Cooking”

I think the reason for the increased popularity of my articles is that I’ve been spending more time writing, generally. I’ve been doing more research, more background reading, and working on my writing style. Some of my recent blog posts have also ended up becoming chapters in my book.

I hope all my readers will continue to follow my writings in their new home, on coding-is-like-cooking.info. I have more great articles planned!

This is the third post in a series about London School TDD. The first one is here, introducing the topic. The second post discusses “Outside-In Development with Double-Loop TDD”. In this post I’d like to talk about the second difference I see between Classic and London School TDD, which is to do with your style of Object Oriented Design.

“Different design styles have different techniques that are most applicable for test-driving code written in those styles, and there are different tools that help you with those techniques…

That’s what we  … designed JMock to do …
“Tell, Don’t Ask” object-oriented design.”

— Nat Pryce, in an email to a discussion forum.

That quote explains the objective Nat et al had when designing JMock, and I think it shows  that London School TDD is actually a school of design as much as a testing technique. Let’s take a closer look at this way of designing objects.

Tell, Don’t Ask

“Tell, Don’t Ask” Object Oriented Design is about having Cohesive objects that hide their internal workings. If your objects obey the Law of Demeter, that’s a good start, it means they hide their inner workings and don’t talk to objects far away on the object graph. It reduces Coupling in your system, which should make for better maintainability.

In their book “Growing Object Oriented Software, Guided by Tests”, Freeman & Pryce actually define “Tell, Don’t Ask” as the same as following the Law of Demeter (p17). Then they go on with several chapters about their design style, expanding far beyond simply “following the Law of Demeter”. It’s well worth a read, here’s a sample:

“… we focus our design effort on how the objects collaborate … obviously, we want to achieve a well-designed class structure, but we think the communication patterns between objects are more important.”

— Freeman & Pryce, GOOS, p58

Message passing vs Types with Data

So it’s basically about how you view your objects. Do you see them primarily in terms of sending and receiving messages to other objects in order to get stuff done? Or are you more focussed on the data your objects look after and the class of objects they are part of?

In the diagram below you can see an object is defined in terms of which messages it sends and receives:     

This diagram shows the same object, but with a focus on data rather than messages:

If you have a “message” focus, you’ll be concerned with defining protocols and interfaces. You’ll worry about which collaborators will be needed to process a particular message. If you have a “data” focus, you’ll be interested in checking your object goes through particular state transitions. You’ll check it makes correct calculations based on its data, and hides whether the result is cached or calculated.

In my first post I talked about the three ways to verify object behaviour. In Classic TDD, the most popular way to write your assert is to check the state of the object you’re testing, or a collaborator, using a public API. This naturally leads you to design objects that are more type-oriented, with the emphasis on class relationships.

In London School TDD, the favoured way to write your assert is to use a mock and check a particular interaction happened, or in other words, a particular message was passed. This is because you favour a design where objects don’t reveal much at all about their data – your system is all about the interactions.

Dependencies and Collaborators

In a message-oriented design, it’s natural to want to specify which collaborators a particular object needs in order to get something done, and what messages it will send them. It’s part of the public specification of an object, and natural to pin down in a test case using mocks. If you instead check your object via a method that lets you query its state, it could expose details that might stop you refactoring the internals later. This leads you to prefer to check your messages, rather than state and data.

If you have a more type-oriented design, you may want to hide the fact you’re storing data accross several objects, or delegating certain calculations to other objects. Those dependencies aren’t part of the public specification, what matters is the end result. If you start exposing these interactions in your test via mocks, you’ll end up with brittle tests that hinder a subsequent redistribution of responsibilities between an object and its dependents. This leads you to prefer to check state and data, rather than interactions.

Comparing the two styles

In these articles I’ve tried to draw each style of TDD to an extreme in order to emphasize the differences. Of course, in practice, a competent developer will use the style most appropriate to the situation she finds herself in. She may use both styles while developing different pieces of the same system. In my next post, I’d like to illustrate this with a small example.

In my last post, I started talking about London School TDD, and the two features of it that I think distinguish it from Classic TDD. The first was Outside-In development with Double Loop TDD, which I’d like to talk more about in this post. The second was “Tell, Don’t Ask” Object Oriented Design. I’ll take that topic up in my next post.

Double Loop TDD

When you’re doing double loop TDD, you go around the inner loop on the timescale of minutes, and the outer loop on the timescale of hours to days. The outer loop tests are written from the perspective of the user of the system. They generally cover thick slices of functionality, deployed in a realistic environment, or something close to it. In my book I’ve called this kind of test a “Guiding Test”, but Freeman & Pryce call them “Acceptance Tests”. These tests should fail if something the customer cares about stops working – in other words they provide good regression protection. They also help document what the system does. (See also my article “Principles for Agile Automated Test Design“).

I don’t think Double Loop TDD is unique to the London School of TDD, I think Classic TDDers do it too. The idea is right there in Kent Beck’s first book about eXtreme Programming. What I think is different in London School, is designing Outside-In, and the use of mocks to enable this.

Designing Outside-In

If you’re doing double loop TDD, you’ll begin with a Guiding Test that expresses something about how a user wants to interact with your system. That test helps you identify the top level function or class that is the entry point to the desired functionality, that will be called first. Often it’s a widget in a GUI, a link on a webpage, or a command line flag.

With London School TDD, you’ll often start your inner loop TDD by designing the class or method that gets called by that widget in the GUI, that link on the webpage, or that command line flag. You should quickly discover that this new piece of code can’t implement the whole function by itself, but will need collaborating classes to get stuff done.

The user looks at the system, and wants some functionality. This implies a new class is needed at the boundary of the system. This class in turn needs collaborating classes that don’t yet exist.

The collaborating classes don’t exist yet, or at least don’t provide all the functionality you need. Instead of going away and developing these collaborating classes straight away, you can just replace them with mocks in your test. It’s very cheap to change mocks and experiment until you get the the interface and the protocol just the way you want it. While you’re designing a test case, you’re also designing the production code.

You replace collaborating objects with mocks so you can design the interface and protocol between them.

When you’re happy with your design, and your test passes, you can move down the stack and start working on developing the implementation of one of the collaborating classes. Of course, if this class in turn has other collaborators, you can replace them with mocks and design these interactions too. This approach continues all the way through the system, moving through architectural layers and levels of abstraction.

You’ve designed the class at the boundary of the system, and now you design one of the collaborating classes, replacing its collaborators with mocks.

This way of working lets you break a problem down into manageable pieces, and get each part specified and tested before you move onto the next part. You start with a focus on what the user needs, and build the system from the “outside-in”, following the user interaction through all the parts of the system until the guiding test passes. The Guiding Test will not usually replace parts of the system with mocks, so when it passes you should be confident you’ve remembered to actually implement all the needed collaborating classes.

Outside-In with Classic TDD

A Classic TDD approach may work outside-in too, but using an approach largely without mocks. There are various strategies to cope with the fact that collaborators don’t exist yet. One is to start with the degenerate case, where nothing much actually happens from the user’s point of view. It’s some kind of edge case where the output is much simpler than in the normal or happy-path case. It lets you build up the structure of the classes and methods needed for a simple version of the functionality, but with basically empty implementations, or simple faked return values. Once the whole structure is there, you flesh it out, perhaps working inside-out.

Another way to do this in Classic TDD is to start writing the tests from the outside-in, but when you discover you need a collaborating class to be implemented before the test will pass, comment out that test and move down to work on the collaborator instead. Eventually you find something you can implement with collaborators that already exist, then work your way up again.

A Classic TDD approach will often just not work outside-in at all. You start with one of the classes nearer the heart of the system. You’ll pick something that can be fully implemented and tested using collaborating classes that already exist.  Often it’s a class in the central domain model of the application. When that is done, you continue to develop the system from the heart towards the outside, adding new classes that build on one another. Because you’re using classes that already exist, there is little need for using mocks. Eventually you find you’ve built all the functionality needed to get the Guiding Test to pass.

Pros and Cons

I think there’s a definite advantage to working outside-in, it keeps your focus on what the user really needs, and helps you to build something useful, without too much gold-plating. I think it takes skill and discipline to work this way with either Classic or London School. It’s not easy to see how to break down a piece of functionality into incremental pieces that you can develop and design step-by-step. If you work from the heart outwards, there is a danger you’ll build more than you need for what the user wants, or that you’ll get to the outside, discover it doesn’t “fit”, and have to refactor your work.

Assuming you are working outside-in, though, one difference seems to me to be in whether you write faked implementations in the actual production code, or in mocks. If you start with fakes in the production code, you’ll gradually replace them with real functionality. If you put all the faked functionality into mocks, they’ll live with the test code, and remain there when the real functionality is implemented. This could be useful for documentation, and will make your tests continue to execute really fast.

Having said that, there some debate about the maintainability of tests that use a lot of mocks. When the design changes, it can be prohibitive to update all the mocks as well as the production code. Once the real implementations are done, maybe the inner-loop tests should just be deleted? The Guiding Test could provide all the regression protection you need, and maybe the tests that helped you with your original design aren’t useful to keep? I don’t think it’s clear-cut actually. From talking to London School proponents, they don’t seem to delete all the tests that use mocks. They do delete some though.

I’m still trying to understand these issues and work out in what contexts London School TDD brings the most advantage. I hope I’ve outlined what I see as the differences in way of working with outside-in development. In my next post I look at how London School TDD promotes “Tell, Don’t Ask” Object Oriented Design.