Red, Green, Refactor

Once upon a time I was the “Solaris Guy” in a Java project. My boss asked me if I wanted to do some Java. Sure: Java was one of “our” languages, and I liked it.

I was also done my part. The cluster was designed, and we had things like backup and failover in place, and I knew my boss, Rod MacMillan, was a pretty subtle Java guy, who had learned from the authors.

This was going to be Java as taught to Sun Canada, not from the gang of seven.

Mind you, I expected getting asked about Objects.

Nope: I got asked if I wrote man pages first.

“Well, yes I did, but eveybody does.”

“How about writing tests first?”

“No, I hadn’t tried that. Is that new?”

Well, yes it was, but Rod said he’d happily teach me that.

So presently he offered me a use case to deliver. And asked me for the tests

… so here’s the use case, come back to me with your tests.”

“My test plan?”

“Nope, the actual tests”

So off I go, and come back the next day with tests…. and we talked about them. And then I fixed them (:-))

Rod wanted wanted me to write down the spec, in the form of tests, just like I was used to doing in the shape of man pages. Black box, no internal. Basic happy and sad paths

After a bit, I got then idea, and we both agreed that

1. these tests would tell us if I’d done it right

2. none of them would pass today

Presently I came back with code… and he didn’t want to review it. He just wanted to know if the tests passed.

Surprise, You’re Done!

I asked “What now?”

He said “Nothing. You’re done”

If the tests described what we needed, and the tests passed, then we must have what we needed. QED.

Boy, did I ever feel good! When I write tests last, it’s a pain.

– have I done testable code?

– am I confident the test aren’t biased toward passing?

– what is enough? When do I stop?

Previously, testing was “thinking up plausible malicious lies, to make the program do the wrong thing”. Today, it was making the program do what we’d decided it should do.

That day, I was done. Finished. And finished in the good way.

At this point, Rod had made a convert.

What Did we Just Do ?

Then Rod told me what I’d just done: it’s called the “red green method”.

– First you write tests to prove the program doesn’t do what you want, that’s “red”.

– Then you write code to make the tests pass, that’s “green”

– Then clean up the little stuff that now needs work. That’s “refactor”.

Variants

There are variants to this: our example was at the granularity of one method.

You can concentrate on reviewing requirements:

– If the requirements are fuzzy (we used to did that a lot with man pages)

– If the code is inherently hard to test (ie, middleware)

You can easily do a lot of refactoring, because the tests will keep you from adding new bugs

You can do bigger or smaller

– TDD is a lot like that, for multiple methods

You can address “doing the right thing”

– am I writing the right tests?

– that can be clearer than the code, sometimes

The tests will tell you if “you’re doing the thing right”

I Love Red Green Refactor

It saves me time and effort.