The testability metrics

January 23, 2007 by Artem

Most of the agile software development methods explicitly or implicitly recommend the use of test-driven-development and generally development of the testable code. The reasons for the high testability demands are no secret. By the very definition of "agility", the agile project has to be ready and even embrace requirement and corresponding architecture changes. Every hardware engineer knows that it is easy to redesign the wired board only if all the components used are reliable and conform to the own specification. It holds true for the software world - it is easy to redesign the system only if its components are well tested.

There is little doubt that the code testability is a good thing, but how can you measure it? Is it possible to have a look at too classes and tell which one is more testable, than another? How to decide that the component is testable enough and doesn't need the further refactoring?

Score-based metric
Jay Flower proposed a score-based metric for testability. His metric is based on a set of attributes that make a class easily instantiable (public constructor with no arguments, does the constructor depend on other types) and easily sensible (how easy it is to check that the value has really been assigned, how many actors participated in the action). While these attributes are definitely important, I feel that the metric is a bit too indirect and focused on too low level details. At so detailed level there is always a possibly of omitting some of important details.

Integral metric
My measure of testability would be an integral value - the number of seconds or number of lines of code required to instantiate the class (actually same applies to the modules and subsystems) in the test harness and to run/sense the functionality of interest. I believe this metric correlates well with the Jay's proposal, but being an integral metric it allows for more broad view on the problem. For example, the class with ten construction arguments will be ranked as well-testable if there is already a test factory for this class.

What do you think about such an integral metric? Can a set of mocks, stubs and fakes be considered a way to raise the component testability?

Permalink