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?

Permalink