Test objects, not methods

As you may or may not know, I am part of the team pushing the boundaries of Agile & XP at Industrial Logic with Josh Kerievsky. As such, I'll be posting some of my rantings in our new Industrial Blogic album (the blog portion of our truly kick-ass "Greatist Hits" eLearning platform).

My debut there is a classic, but so grossly unknown topic. Summarize it as so: if you want to test your private methods, take out a ruler and slap yourself over the wrist. As a personal mentor of mine, J.B. Rainsberger, used to tell me: "if you really need to test that private method, then it should go somewhere else dude."

Check out the rest of the story here, and while you're in add our Industrial Blogic to your RSS reader, we'll be keeping it hot there.

TDD: The Rhythm

Good TDD, well real TDD, provides the team with a heartbeat.

Everyone has a heartbeat, you know what it's like: continuous and clear, smoothly flowing, subtle yet ever so present and soothing. Its unlikely that you're explicitly listening to it, but you are without doubt subconciously aware of the supreme comfort and reassurance that heartbeat provides you each and every minute of your day. It keeps you alive!

Same is true with software development. And while Iterations, Stand-ups, and CIT no doubt provide an essential macro-heartbeat, those things aren't what give us that minute to minute assurance analogous to our human heartbeat. That's where TDD comes in - true TDD provides us that comforting development heartbeat to actually get us productively and happily through the day.

It provides the transition from story card to failing storytest (acceptance test). Then from failing storytest to the first failing microtest (unit test). Then minutes later to the first passing microtest. Then minutes later to the next failing microtest, then the next passing microtest, and our first refactoring. Then minutes later to our next quick cycle of "red/green/refactor". Then within an hour our first check-in. Then a few more "red/green/refactor" cycles and another checkin. And before you know it, after one of those cycles, boom, a passing storytest! A high-five and a final checkin, then home by 6 to see the kids.

Do you hear it? Thum-THUMP, Thum-THUMP, Thum-THUMP...RedBar-GREENBAR, RedBar-GREENBAR, RedBar-GREENBAR...
A development heartbeat.

It's this rhythm that guides you, that keeps you on track. Its what gives you the constant feedback to know, at every step of the way, that you're growing the right design, that you're satisfying the customer's needs, and that you haven't broken any windows. It's what allows you to move freely and move fast. It's this rhythm that makes you feel good. It's this rhythm that makes you feel alive and happy.

Ask anyone whose felt it. Once you've actually truly experienced this rhythm - this heartbeat - I assure you, just as with your human heartbeat, you'll find it unbearable to ever live without.

TDD: The Synergy

TDD. What does this stand for?

Test Driven Development.

Said another way: Development, driven by tests.

Notice, the acronym doesn't stand for test driven design. Not test driven analysis. Not test driven coding. Nope, not even test driven testing. It is, again, test driven development.

TDD is not a "task". It's not a thing we do in addition to doing design, or in addition to writing production code, or in addition to "writing" stories. Rather, TDD it is the way we design, the way we write code, the way we define a story. It is the way we do development.

When done well, TDD exists at root of nearly everything we do in our agile team - it is the team's minute-to-minute comforting heartbeat.

TDD means that "writing a story" equates to specifying in an automated acceptance/story test (most often using FitNesse, Selenium, WaTiR, or something similar) "what it will look like" for a story to be working once we've implemented it. How the new application feature monickered on the story card must behave for it to be DONE.

TDD means that "designing" equates to specifying in an automated unit/micro test (most often using a member of the xUnit family of tools) "what it will look like" for any particular object to work once we've implemented it. In other words, what the expected behavior of that object is.

TDD means that "coding" equates to letting that unit test tell us when we've written working production code. Possibly more importantly, it means that "coding" equates to letting those passing unit tests ensure that our object continues to work (satisfy it's expected behavior) while we mercilessly refactor that object to keep it super clean and expressive.

And, in case you didn't notice in the above assertions, it means that our development is driven by tests. This means that the test is written first. The existing [failing] test is what drives us to conjure up production code. The test is the only reason for us to write a line of code. It's the only way we know what code to write - the test is our specification. Yes, we can write production code first then try to write a unit test to verify it's implementation, but, in addition to the mechanics of that likely being extremely difficult and counter-productive, that's simply not TDD.

Make no mistake about it. True TDD, at the acceptance (Story/Service) test level, is an act of analysis. And true TDD, at the micro (unit/object) test level, is an act of design. In a single statement: True TDD is much less an act of verification (as the "test" part of the name might accidentally and incorrectly imply) as it is an act of specification.

In summary, TDD provides the fundamental synergy between and foundation for all of our development "tasks" that enables us to truly build the right software and to build the software right. It ensures quality² - which, in the end, is the only true way for us to go fast and go fun.

** Upon further review, authors are changing the catchy phrase "ensures quality²" to the more appropriate phrase of "ensures high quality and low shittiness"

Nutshells: Why TDD?

So, ya need that techie-friendly quick-pick-list to explain to someone why your project simply cannot live another second without TDD? I know I did, so I created one. And I'd like to share it with you faithful readers.

Confidence & Productivity … Today

• Immediate feedback, ie. "cookies": Green bars that give me full confidence in what I’m coding, or in other words, meeting requirements with decreased bugs


• A more efficient design:
• Clear “expectations” (tests) drive my mind quickly and smoothly to solutions (algorithms)
• Good public interfaces – my tests make me “eat my own dog food”
• Simplicity – I’ve coded only what was needed to pass the tests

• A more effective design: in order to write software that is effectively tested in this manner, I’m naturally encouraged to ultimately write more cohesive and less coupled code

• Test “protection”: “my tests” give me freedom to refactor mercilessly to create a more expressive, readable code-base while I’m coding

• And then even more Test “protection”: “all the tests” allow the build to silently ensure that today’s collective changes across the group haven’t broken any windows

Confidence & Productivity … Tomorrow

• Fact: addressing yesterday's bugs exponentially decreases today's productivity...unless:
• yesterday 's TDD decreases (if not nearly altogether removes) yesterday's bugs


• Fact: most bugs occur upon changing an existing code-base...unless:
• Today’s [automated] tests become your safety net tomorrow
• Growing test suite allows build to be the perpetual “silent police”


• Fact: easy to understand my design; hard to understand your design...unless:
• Today’s [expectation-based] tests become your documentation tomorrow
• My expressive code is easy for you to understand tomorrow


• Fact: “code rot” (poorly factored code) slows development over time...but:
• My tests force me to keep my design well-factored – forever!


• Fact: “paper documentation” gets outdated (and lies!) over time...in contrast to:
• Automated Storytests: up-to-date, runnable “what it does” documentation (analysis)
• Automated Microtests: up-to-date, runnable “how it does it” documentation (design)

Of course, I'm not perfect, and feedback is king. So, please, pretty please with sugar on top, let me know how you think this list can be improved!