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”.
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.
One thought on “Red, Green, Refactor”
Just go for the Zamboni https://www.youtube.com/watch?v=Lb1rQF2nvWE