Real Life TDD – Test Case Analysis, Part I

It is customary to think that in TDD we run ahead and just write tests. Not today, Spring will have to wait.

Let’s break down the requirement into test cases, so we can understand them better. Buckle your seat belts, it’s going to be a bumpy ride.

We’ll translate the requirements into “when-then” situations. Here’s the first one:

• When the calculator starts it displays “0”.

That’s easy. No pressing of keys shows zero. We’ll write examples so many times, so let’s use shorthand for the input to the output.

Nothing => “0”

Let’s continue.

• The calculator has a keypad with digits (0-9), operations (+,-,*,/), a C clear button and an ‘=‘ button to execute the calculation.

We all know calculators (hopefully) and how they work. We instinctively understand that the specified keys are clickable, while all other keys are not. However we can’t translate this requirement into an example. That’s ok, we can for the next one.

• Any other key pressed doesn’t affect the display

So for example:

“E” => No change

Wait a minute. There’s no “E” on the keypad. What kind of requirement is this?
A confusing one. Check out how it makes sense when we read the requirements the first time, but when we read it again it’s not helpful.

Maybe because “key” is something we press on the computer’s keyboard, not necessarily the keys on the screen.

Or maybe, we’ve already translated it in our mind into “service” language. API services can accept other keys, but don’t necessarily do anything with them. Hmm… Let’s ask the product manager.

PM: Let’s make it easy – we can accept only the keys available in the GUI. No need to translate it into code, error handling or anything. We can throw that example away.

Next.

• Pressing any digit key, the display adds that digit to the existing display. The exception is ‘0’ which is presented only if a number different from ‘0’ wasn’t already pressed.

Ok. That’s easy enough. Let’s start with the obvious.

“1” => “1”
“2” => “2”

Wait. Do we need all nine examples? After all, these examples translate later into tests, so do we need to write nine tests?

We probably don’t. Examples may look different from each other, but the code would probably be the same for all of them. We don’t know it yet (that’s TDD for you), but knowing the domain and our coding skills, it’s ok for now to have one example of the digits.

Also, ours is a very simple calculator, not a nuclear facility management calculator. If there’s a bug in our calculator (for example: “8” => “k”), our calculator may now work, but it also won’t cause a Chernobyl-style meltdown. If there are high risks, I may want to add the test cases up-front to make sure they work.

Ok, that’s one digit. Let’s do two:

“3”,”4″ => “34”

Here’s another thing: All things being equal, I could choose the following:
“1”,”1″ => “11”

Again, while we didn’t program anything yet, we feel that these examples are equivalent in terms of how the code will behave. But by using more digits in my examples, I’m reducing the risks that the code will work for only keypads with, let’s say, one key. Also, consider that examples are a form of documentation: they explain the capabilities of our calculator even better than the code itself. With more diversity we understand it better.

We might want to add a 3 digit example as well:

“4”,”6″,”8″ => “468”

When should we stop? Again a question to the PM: How big is the display?

PM: (Thinking) Our budget is enough for 10 digits.

Ok, we want an example for the edge case:

“1”,”2″,”3″,”4″,”5″,”6″,”7″,”8″,”9″,”0″ => “1234567890”

I know what your thinking. What happens on the next key?

PM: (Thinking again) the display doesn’t change.

So the example would be:
“1”,”2″,”3″,”4″,”5″,”6″,”7″,”8″,”9″,”0″,”1″ => “1234567890”

Ok, maybe the display doesn’t change, but how about the values? is the last case really “1234567890”, or is it “12345678901” in disguise?

PM: Nope, what you see is what you get.

How do we put that into an example? For the time being we haven’t delved into actual calculation, but let’s do that now for this case:

“1”,”2″,”3″,”4″,”5″,”6″,”7″,”8″,”9″,”0″,”1″,”+”,”1″,”=” => “1234567891”

Now we can expect the calculator understand the values correctly.

Did you really think you’ll see Spring, or even some code by now? You need patience young padawan. We’re just starting out, next time: Test Case Analysis – The Sequel.