Testability is a quality attribute, just like usability, security, or maintainability. In the domain of developer testing, it’s composed of controllability, observability, and smallness. In practice, it means that whenever we complain about something(*) being “untestable,” we either:

  • Can’t set it to a known state
  • Can’t see what’s happening under the hood
  • Perceive it as too big and don’t know where to start digging

When classes, modules, components, and even entire systems, are designed with testability in mind, it’s easy to employ various kinds of test doubles(**)  to isolate them. Isolating actually means getting
control of indirect input and output, which are arguably the number #1 enemy of testability.

Testability: a schematic

Book Reference
Read more about testability in Developer Testing: Building Quality into Software:

  • Chapter 4: Testability from a Developer’s Perspective
  • Chapter 6: Drivers of Testability

*) In the future, this will be changed to “program element” with an apropriate definition.
**) A test double page is coming