Unit Testing and Testability

Overview

A revolution has occurred
in software development over the last few years. From being the poor cousin of
development, despised by those with more interesting and important things to do,
testing— at least, unit testing—has been welcomed into the
heart of the development process. At last, rather than seen as a tedious
requirement of certain processes (for example, to achieve ISO 9001 compliance),
it has been integrated into a highly productive way of working.

I think this is a very important, and very beneficial, change. In
this chapter I’ll try to explain why I attach so much importance to testability,
and why testability considerations should influence how you go about designing
and implementing applications.

Late in 2002 I spent several weeks developing a testing strategy
for a large J2EE project for a major financial institution. I was working
alongside a testing guru, and my remit was to combine my J2EE expertise with his
experience formulating testing strategies for large projects to formulate a
testing strategy covering the entire project lifecycle. I was asked to recommend
changes in development practice where necessary to ensure that the strategy was
applied. I was also to ensure the developers came onboard, and mentor them in
the coding and testing techniques.

I learned a lot.

• I discovered that my code was much easier to test than
  that of most of the developers on the project. My programming style, described
  in Expert One-on-One J2EE, lends itself to effective
  unit testing. The Spring Framework makes this style easy to practice.

• I became increasingly convinced of the value of test driven (or test first) development.

• I became increasingly convinced that EJB is an enemy of
  testability.

• I reached a better understanding of the goals of unit
  testing.

• I became more convinced of the value of mock objects in
  unit testing.

• I reviewed a number of testing tools.

On the negative side, I was reminded how difficult it is to
interest “old school” developers in unit testing or test first development, and
how difficult it is to introduce agile practices into a large, bureaucratic
organization.