Featured White Papers

• Measuring Risk to Improve Java Software Quality
• Do You Really Get Classloaders?
• Pragmatic Continuous Delivery with Jenkins, Nexus, and LiveRebel
• Your Next Java Web App: Less XML, No Long Restarts, Fewer Hassles
• Coding with JRebel, Java Forever Changed
• 2012 Developer Productivity Report: Java Tools, Tech, Devs, and Data

Sponsored Links

• Graph databases are 1000x faster than relational.

  Learn More!

• Career opportunities at Harman- Careers That'll Rock Your Socks Off.

  Learn More!

• Developer-friendly Java PDF libraries by Qoppa Software

  Live Demos

• Stop blaming your app! Diagnose Java performance issues.

  Free tool >

• UrbanCode: Go From Continuous Integration to
  Continuous Delivery

  Learn More!

Sponsored Links

Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs

"Runnability" testing of Java programs

A unique aspect of Java technology is that programs can run anywhere without recompilation. Here's how to test your programs so that you can find any runnability problems before your customers do

By Roger Hayes and Manoochehr Ghiassi, JavaWorld.com, 08/01/98

Page 6 of 7

The testing process

Testing, which requires supplying input to the program being tested and then examining the results, may be performed at all levels of program development -- from unit tests for individual classes or methods (structural testing) to system or usability tests at the outermost layer of the program (functional testing). Runnability testing is likely to occur at the outer levels of the program, because it is by nature a test of the integrated product -- and because runnability problems often don't show up in an isolated piece of the program.

Although, fundamentally, runnability testing is functionality testing, and can be done entirely from outside the program, it's also useful to delve into the interior of a program during the test. For example, it may be efficient to take control of an interior component module of a program in order to exercise it more directly than can be done by exercising the integrated product. It may also be useful to insert a probe into the interior of a program, to help diagnose problems that may be masked in the integrated product.

When it comes to testing, a big advantage of Java technology is that it is quite easy to write and maintain this kind of into-the-box code. Because Java programs are linked on demand, at runtime, the test probe can be inserted without recompiling or relinking the rest of the program.

Earlier, we discussed some of the reasons a Java program may fall short of the write-once, run-anywhere goal. Below, we explore some ideas about how to efficiently screen for these shortcomings. Your tests for Java program runnability should have the following properties.

Robustness testing

A program is said to be robust if it successfully completes its job even when it encounters unanticipated circumstances, as a result of some input data or execution environment anomalies. Note that runnability testing is essentially robustness testing. We make the fundamental assumption that functionality testing has been successfully completed and we know what the program is supposed to do. Further, we know how to measure what it has done. The challenge of runnability testing is to ascertain that the tested program fulfills its function on other JRE implementations -- in other words, that the program is robust against platform variations.

Note that this is slightly different from testing that your program does the same thing on every platform. It is entirely possible that the program specification implies that your program, in order to be correct, should behave differently on a different platform. A simple example is:

    class WhatOS {
        public static void main(String[] args) {
            String osName =System.getProperty("os.name");
            System.out.println(osName);
        }
    }

The above program is runnable in any Java environment, but clearly it produces different results on different platforms. A more subtle example is window displays and layouts, the details of which are likely to be platform dependent even though the intention and functionality is the same.