TDD and that First Awkward Moment

This is the third in a series of posts about Test-Driven Development (TDD). These are what I posted before:

• Why is TDD so Hard?
• TDD and the Backwards Brain

These posts were partly inspired by a question I answered at coderanch.com about how to develop a simple calculator program with TDD.  It turned out to be quite a long discussion and you can head over to the Ranch and read through all 200+ responses there, if you have that kind of time to kill. Or you can stick around here as I review and summarize some of the things I mentioned in that thread.

Ok, I created a new test... now what?

So you've decided to do TDD and you're all excited and eager to see and experience just what everyone has been talking about. You've created a new JUnit test class, which typically looks something like this:

public class MyNewTest {

    @Test
    public void test() {
        fail("Not yet implemented");
    }
}

Now comes that first of many awkward moments people new to TDD are most likely to have. It's just like being on a first date and not knowing exactly how to break the ice, so you sit there uncomfortably, hoping and praying for a flash of inspiration for a witty remark. 

You say to yourself or your programming partner(s), "Now what?"

Why do we hesitate? What are we afraid of?

Think about that for a minute.

Here's my best armchair psychologist's analysis: We get stuck because we're afraid of being wrong. We're afraid that we'll mess up, that we'll look stupid, or that we'll feel stupid. 

My wife would probably say it's a typical "guy thing," knowing that we're hopelessly lost but not wanting to ask directions for fear of being called "a dumb schmuck" or looking like one.

Ok, I'll admit that I think the invention of portable GPS navigation systems and mobile apps has probably saved more marriages than AAA TripTiks, Dr. Phil, and Couples Counseling combined ever will. 

I see the same thing with beginners in the dojo. They'll start the technique, then stop midstride and ask for validation. Then they'll want to start all over. We always tell them to just keep going and do what they think they saw sensei demonstrate just a few minutes ago.

The Challenge

As pointed out in my previous post, knowing is not understanding. You may be nodding your head in agreement to all of the above but to really understand, you need to get on that backwards bicycle and feel it for yourself! You need to step on the mat and practice!

Let's try to create a simple calculator through TDD. Now, if you've never written a program using TDD (or maybe even if you think you have), then I'm sorry to tell you this but "You can't do it! You may think you can, but you can't!" 

Destin's words, not mine. But yeah, he's probably right.

At this point, hopefully you're saying "Ok, homes, challenge accepted!" as you're firing up your favorite IDE and deftly clicking around various menus with your mouse, or better yet, quickly typing in the keyboard shortcuts, to create a new project.

What, are you still just reading? Go ahead and fire up your IDE, dude!

Enter the TDD dojo

I expect that by now, you have your brand spanking new project laid out in front of you. Hopefully, you've navigated to the /src/test/java folder or wherever you plan to keep your unit test classes. If you're a real go-git-'er-done type, then you probably have already created a new JUnit test called CalculatorTest.  I am, of course, assuming that you're programming in Java and using JUnit. If you're not, feel free to go ahead and make the necessary mental adjustments.

Now what?

What's that? You need requirements? Ok, here they are:

Write a simple calculator program that can handle the four basic arithmetic operations of addition, subtraction, multiplication, and division. The calculator should adhere to the order of precedence rules associated with the mnemonic "Please Excuse My Dear Aunt Sally," except this calculator need not support exponents for now. Your calculator should honor the order of precedence dictated by parentheses.

The calculator should be able to handle decimal calculations and a result that is a rational number supported by your platform, presumably a typical laptop or desktop computer. Any underflow or overflow should be reported as an error. (Note: if you're trying to do this on a mobile device or a mainframe, I salute you, but maybe ease up a little and find a PC or Mac for this, you weirdo)

For example, given the expression 1 + 2 * 3, the calculator should return 7 as the result rather than 9.  However, given the expression (1 + 2) * 3, the calculator should return 9 as the result.

Also, the calculator should be able to display intermediate results as they become available throughout the process of evaluating an expression. 

For example, while evaluating the expression 3 * 4 + 5, the calculator should be able to display the intermediate result of 12 when the "+" operator is reached.  And while evaluating the expression (1 + 2) * 5, the intermediate result of 3 (the sum of 1 and 2) should be available for display when the closed parenthesis is reached.

That's all I have for now.

I'm going to end this post here and give you a chance to go and prove Destin and me wrong. (And no, you grammar police wanna-be, the correct form is "Destin and me," not "Destin and I."  Look it up for yourself if you doubt it.)

In the next article, I will go over what typically happens with TDD neophytes and cargo culters when they try to do this.

Hajime!

Next: TDD: First Time Crash and Burn