This package is an independent framework for writing automated test scripts in Java.

Author:

Shane_Curcuru@lotus.com

Program(s) Under Test:

Xalan-J 2.x XSLT Processor

Xalan-J 1.x XSLT Processor

Xalan-C 1.x XSLT Processor

Goals:

• Provide a solid, independent test framework.
• Encourage good testing/verification practices.
• Enable quicker generation of Xalan test cases.
• Simplify maintenance of test cases.
• Provide basic test results analysis frameworks.

This package is primarily focused on the quality engineer, and system or integration level tests that are to be shared with a larger audience, rather than on a developer who writes unit tests primarily for their own use.

A few of the basic design patterns/principles used:
• Most objects can be initialized either through their constructor or an initialize() method with a Properties block of name=value pairs to setup their internal state from. Composite objects will typically pass their entire Properties block to sub-objects or contained objects for their own initializations. One future drawback: need to ensure the namespace doesn't have collisions between tests, reporters, and loggers. Eventually I'd like to have a 'namespace' for just the tests themselves.
• Test, TestImpl, FileBasedTest: these all provide structure and utility methods useful for testing in general.
• Testlet, Datalet: these small, focused mini-tests that encourage creating data driven tests and allow you to separate the specific testing algorithim used from the set of data to execute it on.
• User subclasses of the Test classes should simply focus on manipulating the product under test and calling log*() or check*() methods to report information. They shouldn't worry about the external environment or managing their reporter unless they have a specific reason to.
• Loggers simply provide a mechanisim to output data in a manner so that the test doesn't have to manage the output at all. They ensure that all tests produce output in a common format, making it easier to evaluate test results across many tests or products. Loggers generally don't keep track of the test's result state, relying on the user to analyze the result set later.
• Reporters act as a composite of Loggers, as well as providing various useful utilities. Reporters also keep a running track of the pass/fail state of a Test during execution, as well as reporting it out using their Loggers.
• CheckService is a generic service for checking 'equivalence' of two objects and reporting the pass/fail/other result thereof. A SimpleFileCheckService implementation is provided as an example; we have plans to add various other kinds of checkers, perhaps a DOMCheckService.
• OutputNameManager is a cheap-o helper for tests that create a large number of consecutive output files.
• TestfileInfo is a simple data-holding class to store info about a test data file. It is used in FileBasedTest, which may be a useful base class for your tests. This should probably be replaced with a Datalet which, along with Testlets, provides a lighter-weight way to write tests.