Testability as the design metric

I don’t care how good you think your design is. If I can’t walk in and write a test for an arbitrary method of yours in five minutes its not as good as you think it is, and whether you know it or not, you’re paying a price for it. (Michael Feathers)

If you practice a lot of unit testing, test-driven-development of whatever method that includes a lot of testing, you have to spend a lot of time on it. And most of time you have to do the testing-related work before the problem happens and before anyone is affected. Certainly it is good to capture the bug early, before it hurts anybody, but the need to do the “extra” work in advice introduces the temptation to “just tweak this small feature and test it if the problem arises later”.

One of the usual consequences of this kind of approach is a set of hardly testable classes. Just because they use a lot of direct dependencies, instantiate concrete classes instead of using generic interfaces, etc. Programmers can use the best patterns available, document the implementation very well and still the heavily dependent code would be difficult to maintain and update. One of the reasons is that unless the class is separable (to be put into the test-tube), it is complex to examine what exactly consequence the new changes have. Another reason is that since the Stone Age people learn best from the examples. It is much easier to understand the class logics if you can scrutinize it alone, without having to instantiate the rest of the system and put the test data into the DB.

What is your experience? Did you have situations, when well-designed and well-documented code is difficult to maintain, because it is not modular enough?

2 thoughts on “Testability as the design metric”

  1. I find your idea of “well-designed… code… [which] is not modular enough” self-contradictory 🙂

    Seriously though, I have gone as far as saying that testability and good design would be synonymous. This is obviously inaccurate in a provocative way.

    Nevertheless orthogonality and loose coupling as some characteristics of good code go well further back than the recent programmer testing hype. And tight coupling I have experienced as the prime obstacle of programmer testing.

    The lack of source code comments, for example, is not so grave. If it is easy to get a particular functionality running in fast programmer tests, you can use this to get empirical data of what the code does. This sometimes gets your understanding closer to the reality than documentation can, especially copy-pasted documentation 😉

    1. Timo, I agree with you. However, I believe, that the “lack of testability” is not that visible metric and therefore not that obvious. The same way as a house might look perfectly until you discover that sewer system is missing.

      Unfortunately, testability as well as all the other design nuts’n’bolts does not have the concrete visible link to the balance line. Rather often one has to do the research to prove [to his boss] that the testable design is profitable.

Leave a Reply

Your email address will not be published. Required fields are marked *