Glossary

active agent

A type of test agent that initiates a connection to the JavaTest harness. Active test agents you run tests in parallel using many agents at once and to specify the test machines at the time you run the tests. Use the agent monitor to view the list of registered active agents and synchronize active agents with the JavaTest harness before running tests. See also test agent, passive agent, and JavaTest harness agent.

agent monitor

The JavaTest harness window that is used to synchronize active agents and to monitor agent activity. The Agent Monitor window displays the agent pool and the agents currently in use.

agents

See test agent, active agent, passive agent, and JavaTest harness agent.

API member

Fields, methods, and constructors for all public classes that are defined in the specification.

API member tests

Tests (sometimes referred to as class and method tests) that are designed to verify the semantics of API members.

appeals process

A process for challenging the fairness, validity, accuracy, or relevance of one or more TCK tests. Tests that are successfully challenged are either corrected or added to the TCK's exclude list.

Application Programming Interface (API)

An API defines calling conventions by which an application program accesses the operating system and other services.

assertion

A statement contained in a structured Java technology API specification to specify some necessary aspect of the API. Assertions are statements of required behavior, either positive or negative, that are made within the Java technology specification.

assertion testing

Compatibility testing based on testing assertions in a specification.

automated tests

(AKA automatic tests.)Test that run without any intervention by a user. Automatic tests can be queued up and run by the test harness and their results recorded without anyone being present.

behavior-based testing

A set of test development methodologies that are based on the description, behavior, or requirements of the system under test, not the structure of that system. This is commonly known as "black-box" testing.

boundary value analysis

A test case development technique which entails developing additional test cases based on the boundaries defined by previously categorized equivalence classes.

class

The prototype for an object in an object-oriented language. A class might also be considered a set of objects that share a common structure and behavior. The structure of a class is determined by the class variables which represent the state of an object of that class and the behavior is given by a set of methods associated with the class. See also classes.

classes

Classes are related in a class hierarchy. One class might be a specialization (a subclass) of another (one of its superclasses), might be composed of other classes, or use other classes in a client-server relationship. See also class.

compatibility rules

Define the criteria a Java technology implementation must meet in order to be certified as compatible with the technology specification. See also compatibility testing.

compatibility testing

The process of testing an implementation to make sure it is compatible with the corresponding Java technology specification. A suite of tests contained in a Technology Compatibility Kit (TCK) is typically used to test that the implementation meets and passes all of the compatibility rules of that

configuration

Information about your computing environment required to execute a Technology Compatibility Kit (TCK) test suite. The JavaTest harness uses a configuration interview to collect and store configuration information.

Configuration Editor

The dialog box used by JavaTest harness to present the configuration interview.

configuration interview

A series of questions displayed by the JavaTest harness version 3.x to gather information from the user about the computing environment in which the TCK is being run. The JavaTest harness creates a test environment from this information that it uses to execute tests.

configuration value

Information about your computing environment required to execute a TCK test or tests. The JavaTest harness uses a configuration interview to collect configuration values.

distributed tests

Tests consisting of multiple components that are running on both the device and the JavaTest harness host. Dividing test components between the device and JavaTest harness is often used for tests of communication APIs, tests that are heavily dependent on external resources, tests designed to run on devices with constrained resources such as a small display, and data transfer tests.

environment

See test environment.

equivalence class partitioning

A test case development technique that entails breaking a large number of test cases into smaller subsets with each subset representing an equivalent category of test cases.

exclude list

A list of TCK tests that a technology implementation is not required to pass to certify compatibility. The JavaTest harness uses exclude list files (*.jtx) to exclude from a test run those tests that do not have to be passed. The exclude list provides a level playing field for all implementors by ensuring that when a test is determined to be invalid, no implementation is required to pass it. Exclude lists are maintained by the Maintenance Lead (ML) and are made available to all technology licensees. The ML might add tests to the exclude list for the test suite as needed at any time. An updated exclude list replaces any previous exclude lists for that test suite.

Executive Committee (EC)

Composed of Members who guide the evolution of the Java technologies, representing a cross-section of both major stakeholders and other Members of the Java Community.

Expert

A Member representative (or an individual who has signed the IEPA) who has expert knowledge and is an active practitioner in the technology covered by the JSR.

Expert Group

The group of Experts who develop or make significant revisions to a Specification.

Individual Expert Participation Agreement (IEPA)

An agreement between Sun Microsystems and an individual that allows that individual to serve on an Expert Group at the invitation of the Specification Lead. There is no fee associated with the IEPA and it is valid until the Expert Group disbands. The IEPA allows individual technical experts who do not represent companies or organizations to participate on Expert Groups.

interactive tests

Tests that require some intervention by the user. For example, the user might have to provide some data, perform some operation, or judge if the implementation passed or failed the test.

Java Archive (JAR) file

A platform-independent file format that combines many files into one.

Java Community Process (JCP)

An open organization of international Java community software developers and licensees whose charter is to develop and revise Java specification (Specification)s, and their associated reference implementation (RI), and Technology Compatibility Kit (TCK).

Java^TM platform. Standard Edition (Java SE^TM)

A set of specifications that defines the desktop runtime environment required for the deployment of Java technology applications. Java SE platform implementations are available for a variety of platforms, but most notably the Sun Solaristrademark Operating System and Microsoft Windows.

Java Platform Libraries

The class libraries that are defined for each particular version of a Java technology in its Java specification (Specification).

Java specification (Specification)

A written specification for some aspect of the Java technology.

Java Specification Request (JSR)

The actual description of a proposed or final Java specification (Specification) for the Java platform under the Java Community Process (JCP).

Java technology

A Java technology is defined as a Java specification (Specification) and its reference implementation (RI). Examples of Java technologies are the Java SE platform, the Connected Limited Device Configuration (CLDC), and the Mobile Information Device Profile (MIDP).

JavaTest harness

A test harness that has been developed by Sun to manage test execution and result reporting for a Technology Compatibility Kit (TCK). The harness configures, sequences, and runs test suites. The JavaTest harness provides flexible and customizable test execution. It includes everything a test architect needs to design and implement tests for implementations of a Java specification (Specification).

JavaTest harness agent

A test agent supplied with the JavaTest harness to run TCK tests on a Java technology implementation where it is not possible or desirable to run the main JavaTest harness. See also test agent, active agent, and passive agent.

JCP

See Java Community Process (JCP).

JCP Specification Page (Spec Page)

Each Specification approved for development or revision will have a dedicated public web page established on the JCP Web Site to contain a history of the passage of the Specification through the JCP, including a record of the decisions, actions, and votes taken by the EC with respect to the draft Specification.

JCP Web Site

The web site where anyone with an Internet connection can stay informed about JCP activities, download draft and final Specifications, and follow the progress of Specifications through the JCP.

Maintenance Lead (ML)

The person or organization responsible for maintaining an existing Java specification (Specification) and related reference implementation (RI) and Technology Compatibility Kit (TCK). The ML manages the TCK appeals process, exclude list, and any revisions needed to the specification, TCK, or RI.

passive agent

A JavaTest harness component that runs the server portion of distributed tests. It is a type of test agent that must wait for a request from the JavaTest harness before it can run tests. The JavaTest harness initiates connections to passive agents as required. It opens a server socket on the specified port for communications with the JavaTest harness. See also test agent, active agent, and JavaTest harness agent.

prior status

A JavaTest harness selection criteria to restrict the set of tests in a test run based on the last test result information stored in the test result files (.jtr).

Profile specification

A specification that references one of the platform edition specifications and zero or more other Java specifications (that are not already a part of a platform edition specification). APIs from the referenced platform edition must be included according to the referencing rules set out in that platform edition specification. Other referenced specifications must be referenced in their entirety.

Program Management Office (PMO)

The administrative structure that implements the Java Community Process (JCP) service.

protected API

APIs that require that an applet have permission to access them. An attempt to use a protected API without the necessary permissions causes a security exception error.

protection domain

A set of permissions that control that protected APIs an applet can use.

reference implementation (RI)

The prototype or proof-of-concept implementation of a Java specification (Specification). All new or revised specifications must include an RI. A specification RI must pass all of the TCK tests for that specification.

security domain

A set of permissions that define what an application is allowed to do in relationship to restricted APIs and secure communications.

security policy

The set of permissions that a technology implementation or Application Programming Interface (API) requires an application to have for the application to access the implementation or API.

signature file

A text representation of the set of public and protected features provided by an API that is part of a finished TCK. It is used as a signature reference during the TCK signature test for comparison to the technology implementation under test.

signature test

A test that checks that all the necessary API members are present and that there are no extra members which illegally extend the API. It compares the API being tested with a reference API and confirms if the API being tested and the reference API are mutually binary compatible.

specification

See Java specification (Specification).

structure-based testing

A set of test development methodologies that are based on the internal structure or logic of the system under test, not the description, behavior, or requirements of that system. This is commonly known as "white-box" or "glass-box" testing. Compatibility testing does not make use of structure-based test techniques.

system configuration

Refers to the combination of operating system platform, Java programming language, and JavaTest harness tools and settings.

TCK coverage file

A file used by the Java CTT Spec Trac tool to track the test coverage of a test suite during test development. It binds test cases to their related assertions in the specification. The bindings make it possible to generate statistical reports on test coverage.

Technology Compatibility Kit (TCK)

The suite of tests, tools, and documentation that allows an implementor of a Java specification (Specification) to determine if the implementation is compliant with the specification.

technology implementation

Any binary representation of the form and function defined by a Java specification (Specification).

test

The source code and any accompanying information that exercise a particular feature, or part of a feature, of a technology implementation to make sure that the feature complies with the Java specification (Specification)'s compatibility rules. A single test can contain multiple test cases. Accompanying information can include test documentation, auxiliary data files, or other resources used by the source code. Tests correspond to assertions of the specification.

test agent

An application that receives tests from the test harness, runs them on the implementation being tested, and reports the results back to the test harness. Test agents are normally only used when the TCK and implementation being tested are running on different platforms. See also active agent, passive agent, and JavaTest harness agent.

test cases

A small test that is run as part of a set of similar tests. Test cases are implemented using the JavaTest harness MultiTest library class. A test case exercises a specification assertion, or a particular feature, or part of a feature, of an assertion.

test command

A class that knows how to execute test classes in different environments. Test commands are used by the test script to execute tests.

test command template

A generalized specification of a test command in a test environment. The test command is specified in the test environment using variables so that it can execute any test in the test suite regardless of its arguments.

test command template

A generalized specification of a test command in a test environment. The test command is specified in the test environment using variables so that it can execute any test in the test suite regardless of its arguments.

test description

Machine-readable information that describes a test to the test harness so that it can correctly process and run the related test. The actual form and type of test description depends on the attributes of the test suite. A test description exists for every test in the test suite and is read by the test finder. When using the JavaTest harness, the test description is a set of test suite-specific name-value pairs in either HTML tables or Javadoc tool-style tags.

test environment

A collection of configuration values derived from environment entries in the configuration file that provide information used by test suite specific plugin code about how to execute and run each test on a particular platform. When a test in a test suite is run, the JavaTest harness gives the testscript a test environment containing environment entries from configuration data collected by the c onfiguration editor. See configuration.

test execution model

The steps involved in executing the tests in a test suite. The test execution model is implemented by the test script.

test finder

When using the JavaTest harness, a nominated class or set of classes that read, verify, and process the files that contain test description in a test suite. All test descriptions that are located are handed off to the JavaTest harness for further processing.

test harness

The applications and tools used for test execution and test suite management. The JavaTest harness is an example of a test harness.

test script

A Java technology software class whose job is to interpret the test description values, run the tests, and report the results to the JavaTest harness. The test script must understand how to interpret the test description information returned to it by the test finder.

test specification

A human-readable description in logical terms of what a test does and the expected results. Test descriptions are written for test users who need to know in specific detail what a test does. The common practice is to write the test specification in HTML format and store it in the test suite's test directory tree.

test suite

A collection of tests used with the test harness to verify compliance of the licensee's implementation to a Java specification (Specification). Every Technology Compatibility Kit (TCK) contains one or more test suites.

test URL

The test URL is tied closely to the test finder and the underlying construction of any particular testsuite. JavaTest will internally convert the path to a test from a platform-specific format into a common internal format - a test URL.

There are two differences between the platform-specific version and the internal format:

• the path is made relative to the root of the test suite

• the path separator is translated to a forward slash

A test URL consists of three components:

• the folder names relative to the test suite root

• the file name which holds the test description for the test

• the optional identifier within the file

  For example: api/javatest/TestSuite.html#getName

  where javatest — folder, TestSuite.html — file, and getName — id.

JavaTest does case insensitive matching when dealing with test URLs. It will preserve case when possible to increase readability for the user. White space is never allowed in the test URL.

The folder names you select must use only these characters:

• English alphabet A-Z (mixed case permitted)

• digits 0-9

• underscore character '_'

• dash character '-'

• period character '.' (deprecated)

• open and close parentheses (deprecated)

Do not use any of the deprecated characters, they are for backwards compatibility and may be unsupported in future.

The filename may contain the same set of characters as the folder names. Note that when the result file (JTR) is created, the text after the last period will be lost. The test identifier can only contain the following characters:

• English alphabet A-Z (mixed case permitted)

• digits 0-9

• underscore character '_'

The URL identifies a location relative to the top of the test suite. A test URL should identify a ``real'' location in the filesystem and in the file identified (if applicable). If a HTMLTestFinder were to be used, and a test named api/java_lang/Character/index.html#foo was found, the path to the index.html file should be valid and there should be an anchor named ``foo'' in that file.

work directory

A directory associated with a specific test suite and used by the JavaTest harness to store files containing information about the test suite and its tests.