It is, however, a skill and it must be learned just as any other must be learned.

Having tools helps. Many modern scripting languages such as Python and Ruby have testing tools built into the language or in standard libraries. With other languages, such as c or c++, some effort must be made to set up an appropriate tool chain. This tool chain usually require using either pre-written libraries, or writing the necessary test infrastructure internally.

At least as important as having useful tools is creating the right habits for test driving coding. These test-first habits live in your workflow.

Structuring workflow

Learning how to do anything once is not that hard. Mastering the practice of a discipline requires building effective habits. For example, many people have exercise equipment at home, and know how to use it. But they go to the gym instead, where they find context, motivation and inspiration. The habit is at the gym, not at home.

While motivation and inspiration can be elusive, creating an appropriate context is mechanical. It’s as easy (and difficult) as creating an appropriate set of habits. Here are a few habits I’ve found useful for practicing test driven development:

1. In your editor of choice, always open spec or test files in a known buffer which you can get to with a keystroke or two. I’m currently using vim, so I always know that the file containing tests is in buffer 1: ESC:b1 gets me there in a flash.
2. Use a repl like irb or pry to check syntax. This is more helpful than it first appears. It takes the place of all those puts and prints. If you’re working with a compiled language, write stupid simple standalone programs to check behavior. This can as efficient as cat-ing a program into gcc from the command line.
3. Always commit a test first, or never less than a test in parallel with new code. Never commit untested code. This is not the same as never pushing untested code.
4. Scope objects and internal API in the test or spec file and build your functionality in the test file first.
5. More? You tell me, comments are open!

Following these rules helps me create a workflow structure conducive to TDD.

One of the examples discusses a vending machine providing a food sample first, before payment. The vending machine is used as an illustration for Hoare’s theoretical notation.

But think of that vending machine for a moment.

A vending machine which randomly serves free stuff. For example, on average, 10% is served free.

It could work two ways:

1. Refund the money, “compliments of the house”, or
2. Just walk up and push a random button, free food pops out.

I have a hunch the sales volume would go up. Way, way up.

When a constructor is used for the main processing part of a class, such the code requires an instance of Foo to spend a lot of cycles computing Bar, that’s almost a sure indicator the design needs improvement. It may not need a lot of improvement, but it almost surely needs rethinking.

Constructors should only set state, really. If arguments
must be passed, those should be easy to instantiate themselves.

I’m not the only person who believes doing work in constructors is a flaw.

You can google “doing work in constructors” to find like thinking.

Really bad smell

Check this out:

Foo::Foo(Bar b) : b(b) {

 private_m = Baz::some_wackadoodle_preset_structure;
};

I recently had to find a way to test such a constructor, where the constructor depended on some static (global) value of another class, which was initialized elsewhere.

Very painful.

Consider the following function with two “top level” loops:

def function():
    for ():
        ....
        ....
        ....
    for ():
        ....
        ....
        ....

Refactor 1

The body of a loop is often a great candidate for a refactoring. Do this instead:

def helper1():
    for():
        ...
        ...
        ...

def helper2():
    for():
        ...
        ...
        ...

def function():
    helper1()
    helper2()

Instead of sweating one nasty integration test for the function with two loops, you now have two unit tests (test_helper1, test_helper2) and two integration tests (test_function1, test_function2).

Refactor 2

def function1():
    for ():
        ...
        ...
        ...

def function2():
    for ():
        ...
        ...
        ...

function1()
function2()

Depending on what function1 and function2 accomplish, they might be amenable to unit testing as well.

Query actions have a number of well-established naming conventions. Let’s examine the “is_whatever?” pattern.

Consider a car, a spider and word (Ruby syntax):

car.is_vehicle?       # true
spider.is_insect?     # false, spiders are arachnids
word.is_abbreviation? # 4. WTF!?

The convention is that any function or method prefixed with “is” queries for a boolean value. Returning anything other than true or false will induce cognitive dissonance in the reader.

The reader might well be you, next year.

Query functions return stuff. For example, new, create, get are all functions which ask for something in return.

Command functions change state. For example, set, adjust, compute.

Try very, very hard not to “mix and match”. Functions which both query and command are really hard to test, and worse, they are much harder to understand.

Think of it this way: testing a query function means testing only that the returned result is correct. Testing a command function means testing only the state of the object as a result of the command. If you have a function which commands and queries, you may find your function has weird interactions. Basically, your test code has to test the return, the state, and every possible interaction.

Plus, it’s just semantically confusing otherwise.

Update 2012/05/19: Command and query are analogous to “inspect” and “mutate” in the c++ world.

One reason is this: Vast amounts of software engineering literature provide examples using these languages.

Currently, I’m reading “Working Effectively with Legacy Code” by Michael C. Feathers.

All the code in the book is (of course) C, C++ or Java. But the principles documented in the book are language independent.

The last example in the book, on extraction refactoring, is something I’ve been doing for years, and didn’t know there was a name for it. That’s pretty cool.

But it can be learned.

1. Write the code you’re going to write anyway.
2. Test your just-written code thoroughly.
3. Keep your tests and throw away all your code.
4. Now rewrite your code.

It takes extra time, but only the first time.

Given you’re writing test code anyway, test-first will pay you back the second or third time you write the code.

If you’re not writing test code, move along, nothing to see here.

The main gotcha: he didn’t write any test code.

Most likely, the client was unable or unwilling to pay for the test code when the site was first created.

Most likely, the client will not be interested in paying for test code now.

The irony here is that had the developer originally written test code, he would have much more confidence updating the site.

The client pays regardless: either someone comes and cleans it up, or the client pays for a new web site. At this point, not writing test code increases developer time as the new developer reverse engineers the existing code. Might as well test.

Finishing might be really boring, but it’s in no way difficult.

Here’s how to finish those projects:

1. Do all the work.
2. Publish what you did, like write a blog post or something.
3. Promote it everywhere sensible.

I bet you have a project which wants only three or four hours to call done. Why not just do it?