Testability is the degree of ease with which a piece of code can be tested. Anything that makes a piece of code harder to test reduces Testability. This gives the bugs an opportunity to hide for longer and conceal themselves better. Hence, it is always advisable to design and code with Testability in mind.
I always used to wonder that why should somebody like me who is more responsible for coding and designing part of the software development process be concerned about Testability? Why should I take the pain to coding for testability? What does it bring to the table for somebody like me?
Well! The answer is, “better design”.
In order to make a code more testable, the classes must have the ability to be tested in isolation. This means more mockable classes. It is easier to mock classes which are interface driven (Yes, we are talking about Design by contract here). Also, in order to make classes easily mockable, they must be as loosely coupled as possible. The dependencies must be abstracted out. Hence, good design practices like Dependency Inversion Principle becomes an obvious candidate for consideration.
To achieve high testability, i.e. degree of ease with which a piece of code can be tested, the classes must be smaller, focused and cohesive in nature. That is, they should focus on one or few related piece of functionality. Such classes are easier to maintain and tend to have neater Separation of Concerns. Such classes are closer to Single Responsibility Principle at their hearts.
The more testable the code is, the more coverage it tends to have. This is because of a simple reason that writing more and more tests for such code is easier. This allows the developers more cushion to refactor those pieces of code which has become obsolete and ugly over a period of time.
Hence, coding for Testability is all about writing more maintainable, flexible and robust code. Code which has a solid foundation and code which can withstand the only constant of software development life – change.