Feeds

Designing software for testability

You know it makes sense

Secure remote control for conventional and virtual desktops

The subject of testing seems to be in the air at the moment - Matt Stephens recently discussed it in his "Agile" column entitled "Don't unit test GUIs". This month in the Java column we are also going to look at testing, but this time from the viewpoint of design.

Software design, in some ways, is a particularly strange art. The design itself is not a physical thing, it is not the artefact that will eventually be run nor is it any more concrete (in the sense of the real world) than the actual software that will be executed. Yet it is key to the successful production of effective software. It is also the step that will determine the overall structure, nature, and approach of the resulting software. Herein, of course, lies one of the ironies of the software development world – you can't test a design (at least not directly).

However, this does not mean that testing isn't relevant for design activities. Indeed, I would argue that testing is as important a consideration during design as it is during coding. It is certainly no less important than any other requirement that needs to be considered during any design steps.

In this column I am going to present two aspects to the consideration of testing that need to be considered during any design process. These are "design for testability" and "test first design".

Design for testability

Given any set of requirements, different designers may come out with markedly different designs. These designs will then form the blueprint of the way in which the software will be built, deployed, and executed. It is not necessarily true that one design is better per se than another, but it may certainly be true that one design is easier to implement, maintain, deploy and test than another. It is this last point that I want to consider here. That is: "How easy is a design to test once implemented in a language such as Java?"

It is certainly possible to design software in such a way as to make testing easier. The easier software is to test, the more likely it is to be tested. Certainly, in my experience, if software is hard to configure, set up and to actually test then less testing gets done. If software is easier to test more testing is likely to be performed and a greater number of flaws may be discovered.

As an example, consider the Java application presented below. As can be seen from this diagram we have a simple stateful session bean (using EJB 2.0) that provides a calculator-like function. However, to test the "business logic" of this bean we will need to either compile the classes, create appropriate XML files, jar these up with the classes, and deploy to an EJB container such as JBOSS or possibly OpenEJB (which can provide a lightweight test environment). We will then need to create a client class that uses an initial context and an EJB Home object to access the remote bean object. Only then can we test the business logic.


Figure 1: Standard stateless EJB design

However, we may all put off testing the business logic because we do not have a tool such as JBOSS or OpenEJB installed – and certainly the mantra of "test often and little" might well be forgotten.

The essential guide to IT transformation

Next page: Test first design

More from The Register

next story
The Return of BSOD: Does ANYONE trust Microsoft patches?
Sysadmins, you're either fighting fires or seen as incompetents now
Munich considers dumping Linux for ... GULP ... Windows!
Give a penguinista a hug, the Outlook's not good for open source's poster child
Intel's Raspberry Pi rival Galileo can now run Windows
Behold the Internet of Things. Wintel Things
Linux Foundation says many Linux admins and engineers are certifiable
Floats exam program to help IT employers lock up talent
Microsoft cries UNINSTALL in the wake of Blue Screens of Death™
Cache crash causes contained choloric calamity
Eat up Martha! Microsoft slings handwriting recog into OneNote on Android
Freehand input on non-Windows kit for the first time
prev story

Whitepapers

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 10 endpoint backup mistakes
Avoid the ten endpoint backup mistakes to ensure that your critical corporate data is protected and end user productivity is improved.
Top 8 considerations to enable and simplify mobility
In this whitepaper learn how to successfully add mobile capabilities simply and cost effectively.
Rethinking backup and recovery in the modern data center
Combining intelligence, operational analytics, and automation to enable efficient, data-driven IT organizations using the HP ABR approach.
Reg Reader Research: SaaS based Email and Office Productivity Tools
Read this Reg reader report which provides advice and guidance for SMBs towards the use of SaaS based email and Office productivity tools.