Real Life TDD – Test Case Analysis, Part IV

PM: You know, you could have something built by now. You do call this series “integration testing with Spring TDD” or something.

Me: Yeah, and I would probably build something you did not want. Just a few more cases. Remember, we were talking about actual calculations and special cases?

PM: Ok. Let’s take a step backwards. What happens when we do this?

“5”,”+”,”-“,”3″,”=”

Me: Hmmm. User error. She pressed “+”, then decided “-“. So clearly she changed her mind. “-” cancels “+”, and we’ll see “2”.

PM: If I had a penny for every time a developer said “Clearly”…

Me: Gotcha. So am I right or not?

PM: Let’s go with your intuition. That means that the following sequence behaves the same:

“5”,”+”,”C”,”-“,”3″,”=” => “2”

Because the user canceled the operation and entered a new one. We need to support that too.

Me: It could be. But if we only look at the beginning of the sequence:
“5”,”+”,”C”

Do we see “5”? Or “0”? Do we want to cancel the operation? Or the last number we entered (this time we didn’t start to write it yet). We may have a conflict with a former example.

PM: You’re starting to annoy me.
Me: The feeling is mutual.

PM: Ok. For consistency, “C” should cancel numbers. That means:

“5”,”+”,”C” => “0”
“5”,”+”,”C”,”-“,”3″,”=” => “-3”

Me: Are you sure?
PM: For now.

Good enough. But we’re not done yet. Simple calculator my foot.

The Calculator Runneth Over

Let’s talk calculation overflow. We’ve already discussed the display limits when entering data, and the answer was we can’t – we’ll stop entering new digits. But we can overflow also as a result of a calculation. What happens then?

PM: There’s nothing better than an “E” for error. Show me an “E”.

“9”,”9″,”9″,”9″,”9″,”9″,”9″,”9″,”9″,”9″,”+”,”1″,”=” => “E”

ME: We didn’t have an “E” before. It opens the door to other questions, like how do you get out of “E” mode.

PM: Any key starts a new thing.

“9”,”9″,”9″,”9″,”9″,”9″,”9″,”9″,”9″,”9″,”+”,”1″,”=”,”2″ => “2”
“9”,”9″,”9″,”9″,”9″,”9″,”9″,”9″,”9″,”9″,”+”,”1″,”=”,”C” => “0”

Me: Hmm. And what about an operation key?

PM: Hmm. Then don’t change the display until a digit or a “C” is pressed. Operations stay in “E” mode, and we don’t start a new calculation until a digit is pressed.

“9”,”9″,”9″,”9″,”9″,”9″,”9″,”9″,”9″,”9″,”+”,”1″,”=”,”+” => “E”

Right, overflow is done. How about our favorite error, division by zero?

PM: Lucky we’ve already got an “E” mode. Use the same behavior.

“8”,”/”,”0″,”=” => “E”

This is the end

Me: Almost there, a couple more clarifications please, for the cases right after we’ve completed a calculation. What happens when we reset after a calculation?

PM: Show “0”, clearly.

“1”,”+”,”2″,”=”,”C” => “0”

Me: Clearly. How about if we press a digit key?

PM: That’s a start of a new calculation. First we show the new digit:
“1”,”+”,”2″,”=”,”4″ => “4”

PM: Then, it’s a new calculation:
“1”,”+”,”2″,”=”,”4″,”*”,”3″,”=” => “12”

Me: What if the next key is an operation? Is that the continuation of the calculation?

PM: Let me think. Yes it is.

“1”,”+”,”2″,”*”,”4″,”=” => “9”

Me: So we’re keeping the order of operations (multiplications before addition)?

PM: Of course. This is like 1+(2*4).

Me: I feel a disturbance in the force. What does this result in?
“1”,”+”,”2″,”*”,”=”

PM: Well, that’s a 3. I think…
“1”,”+”,”2″,”*”,”=” => “3”

It makes sense. But then, if we look at this one again:
“1”,”+”,”2″,”*”,”4″,”=” => “9”

It’s a conflict – not of an implementation, but of expectations.

PM: Ok, let’s keep it simple for now. We won’t keep track of the order of operations. We do it as input comes in.

“1”,”+”,”2″,”*”,”4″,”=” => “12”

PM: Don’t worry. We’ll get the additional budget for that feature yet. But for now, I think we’ve covered all the functionality. I think. I want to  believe. Did we?

Me: Yup. For now. Funny, it didn’t look like we needed so many examples to figure out a simple calculator.

It Is Nigh

If you’ve made it so far, you’re probably thinking – should I really know all these things prior to writing a single bit of code? Should I analyze all the possible cases before I even fire up Eclipse?

My answer is: You don’t. If you promise to come up with all these cases as you go.

The thing is, there are probably cases I’ve missed here. You’re going to miss some as well. And assuming you do, those cases will either not be coded or tested. That means that the system gets released that way, and in many cases, that’s a risk, sometimes a big one.

We usually don’t wait for the analysis to be over, and sometimes we don’t even wait for it to start. We’re eager to “create” although we still don’t know what we need to develop. That means we’re programming based on a lot of assumptions, some of them are wrong. Based on these assumptions, we’ll write some code that may contain bugs. And that is not so easy to maintain once written.

So, in a nutshell, yes, you do have to think those through.

Right. Enough planning. Time to set up a Spring project.