In my last blog post, Let Code Quality Guide You, I said you don’t have to focus on all five CLEAN code qualities and that if you improve one, it’s typical that the others improve as well because they’re all interrelated.
And that’s true, but they’re interrelated at a higher level, which points to a higher quality or a meta-quality they all conform to. This meta-quality is testability.
Testability is not testing. The testability of code is determined by simply asking, ”How would I test this code?” We understand the testability of software without necessarily having to write tests. When software is testable, the five CLEAN code qualities are present. When I’m working with code that’s untestable, invariably I find the reason it’s untestable is that one or more of these code qualities are missing. There is a direct relationship between the five CLEAN code qualities and testability.
Cohesive classes are straightforward to test because they deal with one and only one responsibility. This means we don’t have multiple responsibilities in the same class, so we don’t have to test responsibilities in combination with each other and we can rely on our object model and programming language to protect us.
To me, testability is the one guiding light, the one eternal principle, the one thing I look to that tells me what’s good and virtuous in software. More than anything else, I want the software industry to know that testability of code is paramount and more than anything is what distinguishes good code from bad code.
And you can’t ask the testability question too soon. Even before I code, when I’m thinking about my design, I think about how testable my design is, or how testable the code would be in support of the design, and I find that this one question more than anything else has guided me in the process of discovering better ways of building software. And by the way, that’s what I do. That’s my job, to figure out better ways of building software that’s more cost-effective and efficient and that doesn’t come from a Taylorist approach. It comes from an approach that is decidedly different, one aspect of which is to pay attention to code qualities.
Several posts ago, I said that these code qualities are quantifiable, that we could look at code and measure whether they’re present or not, and this is entirely true. A fellow programmer could look at a piece of code I wrote and we could discuss its cohesiveness or assertiveness or lack of redundancy. This is extremely helpful for developers to do in order to improve their craft. Far too often we build software in isolation and that doesn’t help anyone. I’m as good as I am because of other people, because I stand on the shoulders of giants, as DeMorgan once said. I learn from my colleagues and I’ve had the great opportunity to pair and work with them.
The very best way to write testable software is to write a test first because when you build code by making a failing test pass, all of the code you built is focused around behaviors, the CLEAN code qualities are present, and of course all the code is testable.
But test driven development is much more than just a trick to get developers to write testable code. It’s a discipline that has many, many advantages that I no doubt will write about in the coming months. Stay tuned…
Previous Post: « Let Code Quality Guide You
Next Post: Testability Affects Code Quality »