There’re No Feelings In Testing!

Testing gets lots of happy cases. Sometime negative cases.
When I hear those terms, my spider-sense starts to tingle. Well, not really, it’s more like Bruce Banner, starts changing into the Hulk.

Here’s an example. The method changes the balance, after validation of expiration. Simple.

As you can plainly see, there are two possible paths in the code. Now, think about it – which is the happy path? And which is the unhappy, miserable one?

Look at the validation part at the top. Validation usually deals with some error conditions, so that can’t be the happy case.

Or can it?

Maybe, the validation part is the one that keeps the hackers at bay? Wouldn’t you be happy, when that hacker-cracker comes by, and fails the validation?

By the way, the “if” part is also called a guard clause, because it guards the rest of the method body from something. That may be a good thing. Happy maybe?

Less Feeling, More Testing

We usually think about functions, or APIs, doing an important, meaty thong. Then, they sometimes carry some not-so-important parts.

Then, we go on and name parts of the function after “feelings”. That felt weird even writing that.

Where does the happy/unhappy distinction come from? Sometimes, we give those names, based on what other people told us about the users’ behavior – how they are likely to use the system. Or, what they do in a failure condition. We then do the mapping in hour head and code.

Communication is important. If we all use the same terms, it’s a good start.

But there’s a problem with those names. The problem is, we then go on and test the different parts, based on our happy-positive/unhappy-negative criteria. The “Happy” path gets more testing attention. A “negative case” – we conflate it with “less likely to happen”. Then we give it less testing attention.

And who wants to test an unhappy condition, anyway? Sounds sad.

Think about it. As a user – wouldn’t you want both behaviors to work correctly? It doesn’t matter which path we’re running, we have expectations about how the system should behave. And we don’t want to be surprised. We expect all cases to behave, and therefore to be tested, the same way. The good way.

It’s not about those “feelings”, snowflake. It’s about expectations and behavior. In the end, these are just code paths. And all of them need to work.

To give all code paths the attention they need, check out my Unit Testing workshop. All languages are considered equal too.