The Artima Developer Community
Sponsored Link

The Road to Code
A Test of Knowledge
by Kevlin Henney
February 27, 2012
What can you learn from testing? When you look beyond the red and the green, the fail and the pass, you can learn a lot more about the nature of the code and the nature of the problem domain. And there is a lot to learn — software development is called knowledge work for a reason.


Software development is often described as knowledge work. This label is invariably used as a shorthand for "work that doesn't involve getting your hands dirty", "jobs your parents never had and you struggle to explain to them" or, without any apparent irony over the use of keyboards, "the digital economy". But step back from these simple substitutions and an obvious yet deeper truth becomes visible: knowledge work is about knowledge. It's about knowing stuff and, most often, also about how you deal with stuff you don't know.

By far and away the most popular response to ignorance is to ignore it. Sound good? Feel free to stop reading! You must have stumbled across this article by mistake.

OK, you're still here. In that case I'll assume curiosity on your part. Which is a good thing: curiosity is key to how we address a lack of knowledge. Questions are the agents of curiosity. Even without answers, questions can help us to increase and refine our knowledge, to learn.

Software testing is a form of learning. A set of tests can be considered a set of questions. The most obvious question a test poses is "Does the code pass?" to which there are two simple answers: yes or no. A test allows us to move from belief to knowledge — for example, to move from merely believing something works to knowing that, in a particular context, it does. Even limiting the scope of testing to just this question and these two answers reveals a rich little set of possible outcomes:

The reasons for failure (or success) run even deeper: a test might fail because the test is at fault, not the code; a test might pass because both the test and the code are at fault and in sympathy; and so on.

And that's just what we can learn from a simple red or green! Of course can is not will — having the opportunity is not the same as taking it — but the first part of any feedback-based process is generating the feedback; what you do with it becomes the next challenge.

But more learning opportunities are available from testing: in the formulation rather than the execution of tests.

What does it mean if a test is hard to write? In particular, a unit test. Difficulty in writing unit tests is a principal demotivator among programmers trying to get into unit testing, causing many to get out of it. "We tried unit testing, but it took too much effort" is a common lament. The more experienced practitioner will typically rejoin with "if your code is difficult to test, it means your code is messy", a comeback that is not necessarily unreasonable but also not necessarily correct. At best it is a provocative oversimplification intended to make you reflect. At worst it may prevent you from learning about your assumptions and the nature of your work.

The difficulty in being able to write a test can be boiled down to the two broad themes of complexity and ignorance, each manifested in a couple of different ways:

Of course, each of these aspects is not entirely independent from the others: a challenging domain may often require novel techniques for testing; uncertainty over the functionality may reflect a complex or, by being ill-defined, seemingly complex domain; and so on. Nonetheless, by recognising these four aspects we can learn more about our assumptions, our knowledge, our ignorance and the nature of our work than either writing off tests as too hard to be worthwhile or assuming that messy code is necessarily the root cause.

Testing? It's an education.

Talk Back!

Have an opinion? Readers have already posted 6 comments about this weblog entry. Why not add yours?

RSS Feed

If you'd like to be notified whenever Kevlin Henney adds a new entry to his weblog, subscribe to his RSS feed.

About the Blogger

Kevlin is an independent consultant and trainer based in the UK. His development interests are in patterns, programming, practice and process. He has been a columnist for various magazines and web sites, including Better Software, The Register, Application Development Advisor, Java Report and the C/C++ Users Journal. Kevlin is co-author of A Pattern Language for Distributed Computing and On Patterns and Pattern Languages, two volumes in the Pattern-Oriented Software Architecture series. He is also editor of the 97 Things Every Programmer Should Know site and book.

This weblog entry is Copyright © 2012 Kevlin Henney. All rights reserved.

Sponsored Links


Copyright © 1996-2019 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use