Test Attribute #1 – Validity

In my last post, I created a list of test attributes. If one of them isn’t ok, you need to do some fixin’.
This is the first of a series of posts that is going to discuss the different faces of tests.
Let’s start with validity. Admittedly, it’s not the first of attribute I thought about. What are the chances we’re going to write a wrong test?

How can this happen?

We usually write tests based on our understanding of the code, the requirements we need to implement, and we fill the gap by assumptions.
We can be wrong on either. Or all.
A more interesting question is: How do we know we’ve written an incorrect test?
We find out we have the wrong tests in one or more ways:

• The Review: Someone looks at our test and code, and tells us we’re either testing the wrong thing, or that it isn’t the way to prove our code works.
• The Surprise: Our test surprisingly fails, where it should have passed. It can happen the other way too.
• The Smell: We have a feeling we’re on the wrong path. The test passes, but something feels wrong.
• The Facepalm: A penny drops, and we get  the “what the hell are you doing?” followed by “glad no one noticed” feelings.

Once we know what is wrong we can easily fix it. But wouldn’t it be easier if we avoided this altogether?
The easiest way is to involve someone. Pair programming helps avoid bugs and writing the wrong test. Obviously, in the Review a partner helps, but they can also avoid the Surprise, Smell and the Facepalm. And you don’t want them there when you have a Facepalm moment, right?
One of the foundation of agile development is feedback. We all make mistakes. In agile development we acknowledge that, so we put brakes in place, such as pair programming, to identify problems early.
Next up: Readability.

For training and coaching on testing and agile, contact me.