Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Test Attributes #1: Validity

DZone's Guide to

Test Attributes #1: Validity

· DevOps Zone
Free Resource

Learn more about how CareerBuilder was able to resolve customer issues 5x faster by using Scalyr, the fastest log management tool on the market. 

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.

Find out more about how Scalyr built a proprietary database that does not use text indexing for their log management tool.

Topics:

Published at DZone with permission of Gil Zilberfeld, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}