Feeds

Designing software for testability

You know it makes sense

Securing Web Applications Made Simple and Scalable

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.

package com.reg.dev.dft.basic;


public class TestHarness1 {
        public static void main(String[] args) {
                CalculatorProcessor processor = 
                 CalculatorProcessorFactory.getCalculatorProcessor();
                processor.setValue1(10);
                processor.setOperator("+");
                processor.setValue2(15);
                System.out.println(processor.calculate());
        }

}

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.

Summary

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. ®

Bridging the IT gap between rising business demands and ageing tools

More from The Register

next story
NO MORE ALL CAPS and other pleasures of Visual Studio 14
Unpicking a packed preview that breaks down ASP.NET
Secure microkernel that uses maths to be 'bug free' goes open source
Hacker-repelling, drone-protecting code will soon be yours to tweak as you see fit
KDE releases ice-cream coloured Plasma 5 just in time for summer
Melty but refreshing - popular rival to Mint's Cinnamon's still a work in progress
Cheer up, Nokia fans. It can start making mobes again in 18 months
The real winner of the Nokia sale is *drumroll* ... Nokia
Put down that Oracle database patch: It could cost $23,000 per CPU
On-by-default INMEMORY tech a boon for developers ... as long as they can afford it
Another day, another Firefox: Version 31 is upon us ALREADY
Web devs, Mozilla really wants you to like this one
Google shows off new Chrome OS look
Athena springs full-grown from Chromium project's head
prev story

Whitepapers

Designing a Defense for Mobile Applications
Learn about the various considerations for defending mobile applications - from the application architecture itself to the myriad testing technologies.
Implementing global e-invoicing with guaranteed legal certainty
Explaining the role local tax compliance plays in successful supply chain management and e-business and how leading global brands are addressing this.
Top 8 considerations to enable and simplify mobility
In this whitepaper learn how to successfully add mobile capabilities simply and cost effectively.
Seven Steps to Software Security
Seven practical steps you can begin to take today to secure your applications and prevent the damages a successful cyber-attack can cause.
Boost IT visibility and business value
How building a great service catalog relieves pressure points and demonstrates the value of IT service management.