Feeds

Designing software for testability

You know it makes sense

Maximizing your infrastructure through virtualization

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

Reducing security risks from open source software

More from The Register

next story
HIDDEN packet sniffer spy tech in MILLIONS of iPhones, iPads – expert
Don't panic though – Apple's backdoor is not wide open to all, guru tells us
Do YOU work at Microsoft? Um. Are you SURE about that?
Nokia and marketing types first to get the bullet, says report
Microsoft takes on Chromebook with low-cost Windows laptops
Redmond's chief salesman: We're taking 'hard' decisions
Cheer up, Nokia fans. It can start making mobes again in 18 months
The real winner of the Nokia sale is *drumroll* ... Nokia
EU dons gloves, pokes Google's deals with Android mobe makers
El Reg cops a squint at investigatory letters
Chrome browser has been DRAINING PC batteries for YEARS
Google is only now fixing ancient, energy-sapping bug
Big Blue Apple: IBM to sell iPads, iPhones to enterprises
iOS/2 gear loaded with apps for big biz ... uh oh BlackBerry
prev story

Whitepapers

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.
Consolidation: The Foundation for IT Business Transformation
In this whitepaper learn how effective consolidation of IT and business resources can enable multiple, meaningful business benefits.
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.
Build a business case: developing custom apps
Learn how to maximize the value of custom applications by accelerating and simplifying their development.
Consolidation: the foundation for IT and business transformation
In this whitepaper learn how effective consolidation of IT and business resources can enable multiple, meaningful business benefits.