Designing software for testability

You know it makes sense

In contrast, the following version of this system uses a separate "business processor" class. This is referenced by the bean but encapsulates all the logic of the application. I can now test the business logic independently of the EJB world merely by compiling the processor class and calling it from a test harness.

This processor is simplified further via the use of a factory class. Of course, the bean version still needs testing, but the larger bulk of the tests will be on the business logic and not on the deployment and invocation mechanisms.

Figure 2: Design taking into account testability of business logic

As an illustration of how simply the business logic can now be tested, see the test harness class below.


public class TestHarness1 {
        public static void main(String[] args) {
                CalculatorProcessor processor = 


Note that EJB 3.0 has to some extent made the testing of EJBs simpler, but EJBs are used here merely as an example and should not be taken as the only application of the concept.

Test first design

Test first design means that if you can design the test then you can design the model. The corollary of this is that if you can't design the tests then you shouldn't design the model.

This is the design equivalent of the Extreme Programming (XP) idea of "test first coding" and follows directly on from the previous section. That is, in order to really carry out "design for testability" you need to know what you want to test and where. Thus, you should consider the tests you want to perform before you start to design your software. In fact, you should be able to write (or in this case design) the tests for a module or subsystem before you design that module. The argument is that if you can't design the tests for the module then you don't know enough about the module to design it yet.

Even if you do not subscribe to the agile philosophy, I believe designers should take into account how the system they are designing will be tested during the modelling phase (and not just during coding). This is because it is the designer who has the overall context within which they are designing; it is the designer who knows how a particular module or subsystem will function within the greater whole. It is all too common to find that junior programmers understand their small section of the system but have no reference point within which to position this. Thus, the designer should take into account how the software should be tested.


The idea of taking testing into account during design may seem obvious to you, but when I first encountered this concept it almost stopped me in my tracks for its simplicity, benefit, utility, and how obvious it was.

However, I had not seen anything written about this before and realised that I had been failing to take testability into account at design time. That is not to say that code was not tested, but this was not an issue considered during design.

But, by considering how the code to be produced from the modelling phase could be tested, you can make it much easier for the person who codes the model to test it and thus make it easier to identify potential problems. Since encountering this concept it is one of the things that I have most widely adopted. ®

Sponsored: Network DDoS protection