Java Application Testing Tools
Many organizations are surprised to find that it is more expensive to do testing using tools. In order to gain benefits from testing tools, careful thought must be given for which tests you want to use tools and to the tool being chosen.
One of the most widely-used tools is Abbot, a framework for testing Java GUIs. Using simple XML-based scripts, we can launch a GUI, play back arbitrary user actions on it, and examine its state. It also includes a script editor (Costello) that records user actions. The framework may be invoked directly from Java code (JUnit) or accessed without programming through the use of scripts. It is suitable for use both by developers for unit tests and QA for functional testing, especially with JFC swing. This tool has an excellent development team, which constantly updates the software.
DejaGnu is a framework for testing applications such as Tcl, C, C++, Java, and network applications, and cross testing embedded systems. Its purpose is to provide a single frontend for all tests. Think of it as a custom library of Tcl procedures crafted to support writing a test harness. A "test harness" is the testing infrastructure that is created to support a specific program or tool. Each program can have multiple test suites, all supported by a single test harness. DejaGnu is written in Expect, which in turn uses Tcl, Tool Command Language. There has not been a new release in quite a while, although the snapshots are quite stable.
The JavaTest™ harness is a general purpose Open Source Java API for creating Java test software, a fully-featured, flexible, and configurable test harness very well suited for most types of unit testing, especially Technology Compatibility Kit (TCK) test suites. The JavaTest harness is an excellent tool for configuring, sequencing, and running test suites that consist of large numbers of discrete, independent tests. It is especially good at testing APIs and compilers. Originally developed as a test harness to run the JCK test suite, it has since evolved into a general-purpose test platform well suited for use with all TCK test suites.
JFunc is an extension to the JUnit testing framework to make it easier for use with functional tests. Functional testing (also called integration testing) significantly differs from unit testing in a number of respects. Part of this project is dedicated towards putting together code to address these differences; the other part of this project is putting together methodologies for functional testing.
Marathon is a general-purpose tool for both running and authoring acceptance tests geared at the Java Platform Version 1.3 or later. Included with marathon is a rich suite of components to help you interact with your application at the User interface Level (GUI). To aid with the regression testing of existing applications, Marathon comes bundled with a recorder to capture events as you use and interact with your application. These events are then converted into a valid Marathon test, which can subsequently be played back.
Pounder is a utility for testing Java GUIs. It allows developers to dynamically load components, record scripts, and then use those scripts in JUnit. It supports custom components, drag-and-drop, and the examination of test runs in source.
QAT was developed to ease the issues encountered by having to perform Quality Assurance tests across a variety of hardware and software combinations. The way to achieve this is to abstract the process of running the test on a machine. So, from a tester's point of view, there is one test suite, which the tester executes, and then gets the results for further analysis. The specifics of the machine on which the test will be run is completely hidden, and is necessary for running the test.
The QAT tool can be divided into two main sections, the Agent, responsible for actually running each test or group of tests, and the Harness, which is responsible for test selection, management, results, and agent co-ordination. It can be accessed via a browser interface if remote access to the harness is required.
First, each test case is written in a platform-independent way in a simple scripting language, very similar to C shell, although it could be implemented as any language you want. All references to platform-specific items are delayed by referring to one or more configuration files. A configuration is then built for each test based on the architecture and operating system of the target machine. So, instead of directly executing a command within the test, we refer to variables, which will only be defined at the time of running the test.
Once the test case is ready, the test is transferred to whatever machine we want to run it on (agent). This is achieved by developing a relatively stupid agent that can respond to a limited set of requests from the harness via TCP sockets. Some examples are GETFILE, SENDFILE, DELFILE, EXECUTE, etc. The test script running on the harness may then use this command set to build a desired environment on the agent. We are able to transfer files, unzip files, delete files, set environment variables, and any of the other good things we need to run a test. Once the test is run, a result is decided on and sent back to the harness for processing.
Since the agent is written in Java, it runs on any architecture supporting a JVM, including restricted ones running pJava, kJava, and various other slimmed-down versions.
... to read more articles, visit http://sqa.fyicenter.com/art/