Skip to content

Testability as the design metric

March 26, 2006 by Artem

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?


Remember Fowler's definition of "detestable" ;)

March 27, 2006 by thrantal, 9 years 28 weeks ago
Comment id: 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 ;)

Timo, I agree with you.

March 27, 2006 by Artem, 9 years 28 weeks ago
Comment id: 2

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.

Post new comment

The content of this field is kept private and will not be shown publicly.
  • Allowed HTML tags: <a> <b> <i> <em> <strong> <cite> <code> <ul> <ol> <li> <dl> <dt> <dd> <img> <br> <blockquote>
  • Lines and paragraphs break automatically.
  • Web page addresses and e-mail addresses turn into links automatically.
  • You can enable syntax highlighting of source code with the following tags: <code>, <blockcode>. Beside the tag style "<foo>" it is also possible to use "[foo]".

More information about formatting options

By submitting this form, you accept the Mollom privacy policy.

Best of