Complex enterprise applications are generally hard to maintain, and risky and difficult to change. As a new developer on a team, a large legacy code base is often difficult to understand, especially when the code has evolved over a long period and new functionality has been grafted onto an existing application. The situation is exacerbated by the usual time and delivery pressures of commercial enterprise systems development. With a modest amount of effort, however, it is possible to design and develop applications that are well architected and easy to change, and moreover that remain so as they grow and evolve.
What Is a Testable System?
There are certain characteristics that are common to all clean, well-architected applications. Features such as modular design, good separation of concerns, loose coupling, and high cohesion - behavior in one and only one place within an application - are all well-established best practices. Writing applications with testability in mind tends to lead to systems that display these characteristics. For instance, focusing on the ease of black- and white-box testing of individual modules is a sure-fire way to generate cleanly separated functional units. Saying that a module is easy to unit test is the same as saying we know exactly what the module should do, under what circumstances, and that we know (and can prove) its boundary behavior. Saying that a module is easy to integration test implies that it is easy to deploy and configure.
To keep ourselves honest and consistent, we write tests as we go to define and prove that components work in a particular way, and we automatically run all those tests often. As discussed in my previous article ("Test-Driven Development Is Not About Testing" [JDJ, Vol. 8, issue 11]), each test case becomes a model client of the module it is testing. This can be true at any level of granularity, whether the module is an individual class, a deployed component such as an EJB or servlet, a service, or an entire subsystem. The size of the unit may vary, but the purpose of the test case remains consistent.
This new column looks at what makes an application testable, and provides practical help and real-world advice for writing applications in a clean and test-driven fashion. Its focus will be on simplicity of design, from the viewpoint of a developer wanting to work with clean code, not as a professional tester. The target audience is enterprise application developers who are either embarking on a new application or maintaining an existing enterprise application. I'll offer pragmatic advice and techniques for choosing - and sticking to - clean and extensible architectures, and help you contrast different approaches effectively from a testability perspective.
What Is an Enterprise Application?
If you ask 10 developers what constitutes an enterprise application, you'll most likely get 10 different responses, but in general an enterprise application will display some, if not all, of the following characteristics:
