Testability vs. Testing
The first time I heard the expression "unit testing" at a .NET conference was--if memory serves well--back in 2004. Since then, it took probably a couple of more years for the theme of "unit testing" to gain due visibility in the .NET space. I can't mention a date when I heard the word "testability" instead. And still in articles, blogs, and conference talks the prevailing term is "testing". Not that no conferences in the world had the word testability pronounced lately, but it never happened to me to attend a talk or something where I could hear it--maybe I just go to the wrong sessions and miss a lot of great events :)
Seriously, I feel that the word "testing" is used much more frequently than the word "testability". And I do believe that for developers and, especially, architects testability is a far more important aspect. In first place, testability is one of the required attributes of any software system according to the ISO standard for software architecture. Second, testability has a deeper impact than testing on the quality of the code you write. What's testability?
In our book "Architecting Applications for the Enterprise" Andrea and I write it as follows:
A broadly accepted definition for testability in the context of software architecture describes it as the ease of performing testing. And testing is the process of checking software to ensure that it behaves as expected, contains no errors, and satisfies its requirements.
In a nutshell, testing returns you a working application; testability returns you a better designed code. Honestly, can you spot any difference between a unit-tested piece of code that works and a piece code that just works (maybe tested by simply poking around)?
With the excuse of letting you do that cool thing called unit-testing more quickly and effectively, testability silently drives you towards a much better design of the code with plenty of SoC, dependency injection, low coupling, high class cohesion, and minimal responsibilities for classes.
Ultimately,design for testability means applying a software contract (code-contract in .NET 4.0) to classes and methods and keep classes cohesive, loosely coupled, and with dependencies clearly listed. Once classes are testable, unit-testing them is really a little detail.