Alexey Popov's Blog

Community: JDK Archives

What is new in JT harness 4

As I wrote once,  development of this product is primarily driven by using it as a test harness for Technology Compatibility Kits. The next big step in the history of the product was its adoption  in the new area of Java ME quality test suites, specifically JDTS, the Java Device Test Suite. JDTS2.0 went out December 2006, see its DataSheet for more information. Among lots of other minor and major changes, this was first JDTS version based on JavaTest ^TM Harness, version 4.0.

The initial launch of the JT harness, the Open Source version of JavaTest Harness,  was based on the current stable version of the product, 3.2.2.  The version 4.0 was primarily driven and targeted to this release of JDTS 2.0, due to tight time line it was developed internally for some time and become available in open source only now since version 4.1.1

Major new JavaTest harness 4 Features

• Tutorial is now available with the binary.
  
• Backward compatibility with JavaTest harness 3.2.2
  
• Customization features.
  
  The requirement was to make JavaTest 4 a testing platform, that can be supplied with product-specific functionality and have customizable functions and appearance.
  
• Custom splash screen can be used to provide stronger identification of the JavaTest-based testing product.
• Custom tool bars, menus, pop-up menus, preferences can be used to associate functionality extensions with GUI
• Customizable GUI rendering of a test's result - e.g. show a graph of some data for a test. This is targeted for test categories, that may result in more then just pass/fail criteria, like performance tests. 
• Plug-in report mechanism. It can be used to fit the JavaTest-based test suite into the larger testing/certification system
  
  
• Configuration process improvements
  
  Configuration process is known as one of the most complex steps in usage of the large test suites, that are targeting multiple environments. JavaTest 4 made significant steps to improve usability in this area. New usage models, specific to quality vs compatibility testing area, were also addressed.
  
• Improved configuration templates mechanism to allow different levels of configuration tuning.
  
• Added new configuration interview question types
  
• Per-test configuration, accessible through test tree context menu. This allows development of the test suites, where user is required to configure only those parameters, that are minimally necessary for execution of specific test or group of tests and not pass through complete configuration process for the whole test suite.
  
  
• Management of test suite updates
  
  Ability to dynamically apply updates using existing installation of the configured testing product allows significant decrease in cost of applying updates to users, allowing more frequent updates and hence better product quality
  
  
• Reporting
  
  
• Merging report directories, generation of consolidated report to improve support to multi-user environment.
• XML formatted reports to simplify post-processing of test results using custom tools and integration into large testing/reporting infrastructure.
  
  
• Other
  
  Number of minor improvements, like: UI enhancements, logging

One of the First Java Applications

Few words for a background.

The Java ^TM Compatibility Kit (JCK) is a test suite, used to verify if the Java standard is correctly implemented. The first JCK came out together with the first JDK from SUN, now this effort evolved into the industry-wide Java Community Process.

The JavaTest ^TM harness is a test monitor, used in first versions of JCK, then across multiple Java Technology Compatibility Kits (TCK), now evolved into a general purpose open source test harness.

How it started

With permission of Jonathan Gibbons, who was around when Java was born, here is his story of the JavaTest childhood:

JavaTest started round about JDK 1.0.2, JCK 1.0.2a was applet-based and did not use JavaTest;  JavaTest was introduced in JCK 1.0.2b.

It definitely was not the first application written in Java, but it is true that testing was important to Java from the beginning. JavaTest is sufficiently old that we had to develop many GUI widgets ourselves, and one of the early JavaTest developers (Tim Prinzing) went on to become a significant member in the Swing team. It is probably reasonable to say that Tim pioneered light-weight components.

Curious how it looked like back then at early JDK times ? Check here.

You can see that testing is one of keys that brought Java platform to where it is now. Java's way of compatibility testing, that is having high quality TCK required to pass to get Java logo,  is how Write Once Run Anywhere is achieved,  it is the cost of application portability and platform standardization.

On the road

Inspired by the conversation at David Herron's Blog, I was looking for analogy to illustrate the value of compatibility testing in the Java ecosystem, here it is - Java is a road, compatibility testing is its pavement. Applications are vehicles and the hard cover on the road makes it possible to drive fast. 

For Java ME platform, its fragmentation is a freedom to choose number of wheels, engine, use a bicycle or a truck. Another part, the 'dark side', is where the road cover has holes, caused by bugs in specification and implementations, test coverage problems. Services are built around the road to take care of vehicles and holes, like JDTS and Java Verified, while the road has its pavement (TCKs), differentiating it from deserts, forests and swamps.

This work is licensed under a Creative Commons License.