• Home
  • Line#
  • Scopes#
  • Navigate#
  • Raw
  • Download
1<!--
2 * Licensed to the Apache Software Foundation (ASF) under one
3 * or more contributor license agreements. See the NOTICE file
4 * distributed with this work for additional information
5 * regarding copyright ownership. The ASF licenses this file
6 * to you under the Apache License, Version 2.0 (the  "License");
7 * you may not use this file except in compliance with the License.
8 * You may obtain a copy of the License at
9 *
10 *     http://www.apache.org/licenses/LICENSE-2.0
11 *
12 * Unless required by applicable law or agreed to in writing, software
13 * distributed under the License is distributed on an "AS IS" BASIS,
14 * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
15 * See the License for the specific language governing permissions and
16 * limitations under the License.
17-->
18<!-- $Id$ -->
19<html>
20  <title>XSL-TEST Reporter package.</title>
21  <body>
22    <p>This package is an independent framework for writing automated test scripts in Java.</p>
23    <dl>
24      <dt><b>Author: </b></dt><dd><a href="mailto:shane_curcuru@lotus.com">Shane_Curcuru@lotus.com</a></dd>
25      <dt><b>Program(s) Under Test: </b></dt>
26      <dd><a href="http://xml.apache.org/xalan-j" target="_top">Xalan-J 2.x XSLT Processor</a></dd>
27      <dd><a href="http://xml.apache.org/xalan" target="_top">Xalan-J 1.x XSLT Processor</a></dd>
28      <dd><a href="http://xml.apache.org/xalan-c" target="_top">Xalan-C 1.x XSLT Processor</a></dd>
29      <dt><b>Goals: </b></dt><dd>
30        <ul>
31          <li>Provide a solid, independent test framework.</li>
32          <li>Encourage good testing/verification practices.</li>
33          <li>Enable quicker generation of Xalan test cases.</li>
34          <li>Simplify maintenance of test cases.</li>
35          <li>Provide basic test results analysis frameworks.</li>
36        </ul>
37      </dd>
38    </dl>
39    <p>This package is primarily focused on the quality
40    engineer, and system or integration level tests that are to be
41    shared with a larger audience, rather than on a developer who
42    writes unit tests primarily for their own use.</p>
43    <ul>A few of the basic design patterns/principles used:
44    <li>Most objects can be initialized either through their
45    constructor or an initialize() method with a Properties
46    block of name=value pairs to setup their internal state
47    from.  Composite objects will typically pass their entire
48    Properties block to sub-objects or contained objects for
49    their own initializations.  One future drawback: need to
50    ensure the namespace doesn't have collisions between tests,
51    reporters, and loggers. Eventually I'd like to have a
52    'namespace' for just the tests themselves.</li>
53    <li>Test, TestImpl, FileBasedTest: these all provide structure
54    and utility methods useful for testing in general.</li>
55    <li>Testlet, Datalet: these small, focused mini-tests
56    that encourage creating data driven tests and allow you
57    to separate the specific testing algorithim used from
58    the set of data to execute it on.</li>
59    <li>User subclasses of the Test classes should simply focus on
60    manipulating the product under test and calling log*() or check*()
61    methods to report information.  They shouldn't worry about the
62    external environment or managing their reporter unless they have
63    a specific reason to.</li>
64    <li>Loggers simply provide a mechanisim to output data in a manner
65    so that the test doesn't have to manage the output at all.  They
66    ensure that all tests produce output in a common format, making it
67    easier to evaluate test results across many tests or products.
68    Loggers generally don't keep track of the test's result state,
69    relying on the user to analyze the result set later.</li>
70    <li>Reporters act as a composite of Loggers, as well as providing
71    various useful utilities.  Reporters also keep a running track of
72    the pass/fail state of a Test during execution, as well as reporting
73    it out using their Loggers.</li>
74    <li>CheckService is a generic service for checking 'equivalence'
75    of two objects and reporting the pass/fail/other result thereof.
76    A SimpleFileCheckService implementation is provided as an
77    example; we have plans to add various other kinds of checkers,
78    perhaps a DOMCheckService.</li>
79    <li>OutputNameManager is a cheap-o helper for tests that create
80    a large number of consecutive output files.</li>
81    <li>TestfileInfo is a simple data-holding class to store info
82    about a test data file.  It is used in FileBasedTest, which may
83    be a useful base class for your tests.  This should probably be
84    replaced with a Datalet which, along with Testlets, provides a
85    lighter-weight way to write tests.</li>
86    </ul>
87  </body>
88</html>
89
90
91