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

How To Test Your Tests

DZone's Guide to

How To Test Your Tests

· DevOps Zone ·
Free Resource

Is the concept of adopting a continuous everything model a daunting task for your fast moving business? Read this whitepaper to break down and understand one of the key pillars of this model in Continuous Governance: The Guardrails for Continuous Everything.

 When we write tests, we focus on the scenario we want to test, and then write that test.

Pretty simple, right?

That’s how are are minds work. we can’t focus on many things at the same time. TDD acknowledges that and its incremental nature is built around it.

TDD or not, when we have a passing test, we should do an evaluation.

Start with this table:

Property

Description

Validity Does it test a valid scenario? Is this scenario always valid?
Readability Of course I understand the test now, but will someone else understand the test a year from now?
Speed How quickly does it run? Will it slow down an entire suite?
Accuracy When it fails, can I easily find the problem is in the code, or do I need to debug?
Differentiation How is this case different than its brothers? Can I understand just by looking at the tests?
Maintenance How much work will I need to do around this test when requirements change? How fragile is it?
Footprint Does the test clean after itself? Or does it leave files, registry handles, threads, or a memory blob that can affect other tests?
Robustness How easy it is to break this test? What kind of variation are we permitting, and is that variation allowed?
Deterministic Does this test have dependencies (the computer clock, CPU, files, data) that can alter its result based on when or where it runs?
Isolation Does the test rely on a state that was not specified explicitly in it? If not, will the implicit state always be true?

If something’s not up to your standards (I’m assuming you’re a high standard professional) fix it.

Now, I hear you asking: Do all this for every test?

Let’s put it this way: If the test fails the evaluation, there’s going to be work later to fix it. When would you rather do it – now, when the test is fresh in your head, or later, when you have to dive in again, into code that you haven’t seen in 6 months, instead of working on the new exciting feature you want to work on?

It’s testing economics 101. Do it now.

Are you looking for greater insight into your software development value stream? Check out this whitepaper: DevOps Performance: The Importance of Measuring Throughput and Stability to see how CloudBees DevOptics can give you the visibility to improve your continuous delivery process.

Topics:

Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

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

{{ parent.tldr }}

{{ parent.urlSource.name }}