Over a million developers have joined DZone.

Test Attributes #1: Validity

· DevOps Zone

The DevOps zone is brought to you in partnership with Sonatype Nexus. The Nexus suite helps scale your DevOps delivery with continuous component intelligence integrated into development tools, including Eclipse, IntelliJ, Jenkins, Bamboo, SonarQube and more. Schedule a demo today

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.

The DevOps zone is brought to you in partnership with Sonatype Nexus. Use the Nexus Suite to automate your software supply chain and ensure you're using the highest quality open source components at every step of the development lifecycle. Get Nexus today

Topics:

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

Opinions expressed by DZone contributors are their own.

The best of DZone straight to your inbox.

SEE AN EXAMPLE
Please provide a valid email address.

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.
Subscribe

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

{{ parent.tldr }}

{{ parent.urlSource.name }}