eclipse test & performance tools platform project
Project Descriptions

This project proposal is in the Proposal Phase and is posted here to solicit additional project participation and ways the project can be leveraged from the Eclipse membership-at-large. You are invited to comment on and/or join the project. Please send all feedback to the eclipse.test-and-performance newsgroup or the test-and-performance-proposal mailing list.

Project Descriptions

The Eclipse Test & Performance Tools Platform Top Level Project is currently comprised of four Projects that are in effect a repartitioning of the previous Eclipse Tools Hyades Subproject. Other projects may be added over time.


Hyades Platform Project
Hyades Test Tools Project
Hyades Tracing and Profiling Project
Hyades Monitoring Project

Hyades Platform Project

The Top Level Project consists of a large amount of common infrastructure in the areas of user interface, EMF based data models, data collection and communications control, as well as remote execution environments. All of these subsystems are included in the Hyades Platform.

The Platform provides these common subsystems as well as all the extension points for leveraging or extending them in solution specific tooling or runtime. This includes Eclipse workbench plug-ins as well as runtime plug-ins on a target and optionally remote system.

Following is a very brief description of the subsystems. For more details on these subsystems, please refer to the project website.

User Interface
User interfaces are provided to manage and access resources used by the Test and Performance Top Level Project. The interfaces also provide the basic user metaphors desired for interacting with remote systems and the resources involved in order to have consistent end user experiences. A basic navigator and many extension points are provided as well as user preferences and facilities to preserve session user state. Along with the basic navigation and extension points, several controls, viewers and editors are also provided in order to give access to all the resources and make common behavior easier.

EMF models
Data models are intended to be a key integration point in the project and are provided in 5 basic areas.

  1. Trace for the collection of local or distributed execution stacks as well as heap information.
  2. Definition models for the creation and management of test cases as well as behavioral models for tests, and/or related activities.
  3. Test execution histories for the collection of test executions over time.
  4. Generic statistical model for the capturing of arbitrary numerical data over time.
  5. Log model that can hold associated Common Base Events or any logged message that can be transformed into a Common Base Event.

All these models can be cross-linked and made persistent using XMI or in some cases a relational database back is optionally used.

Data Collection
An infrastructure is provided to collect data for the various models. This includes the XML fragment specifications that need to be created as well as the model loaders that will load those fragments into the specific model. Where meaningful, service function is provided to assist in creating the instances of these fragments. For example, a correlation service is provided to assist in creating data that can be correlated across machine boundaries. A set of classes to create Common Base Event instances is also provided.

Although the actual communication layer can be replaced via plug-in, a default TCP/IP based infrastructure is provided that has an optional security plug-in. Wrapped around the actual communication layer is a generic interface to facilitate the movement of commands and data between the workbench and one or more agents. The agents reside in the system being monitored and shared memory pipes are provided to the common communications infrastructure.

There is also a full management system for agents. This includes registration so they can be shared across process and transaction boundaries on a given machine. The data communication and control interfaces are being exposed with C, Java, and Web services bindings.

Execution Environment
A method for controlling an execution environment for a system under test is often needed. From the basics of attaching, starting, and stopping a remote process as well as providing a predefined link to the communication layer is provided in this subsystem of the platform.

A generic runtime that can be driven by a process description is also provided. The initial intent is to use this environment as a generic test behavior implementation that can be used to drive any public interface, especially a web service binding.


Hyades Test Tools Project

The Hyades Test Tools Project provides specializations of the Platform for testing (e.g. test editors, trace/test conversion support), and exemplary extensible tools for specific testing environments. Initially this includes three test environments: JUnit, manual, and URL testing.

These specializations provide optimized editing and reporting experiences for these use cases. In the cases where a unique runtime or an implementation of a testability interface is required, it is also developed in the project. For example, the manual test execution environment provides a remotely managed user interface specifically for collecting manual test progress. This manual user interface is unique from the common execution environment for JUnit and URL testing.

Hyades Tracing and Profiling Project

The Hyades Tracing and Profiling Tools Project extends the Platform with specific data collection for Java and distributed applications that populate the common trace model, additional language and protocol support is anticipated. There are also viewers and analysis services that draw data from the common trace model.

Capabilities are provided to collect and analyze heap and stack information as well as generic toolkits for instrumenting running applications.

Hyades Monitoring Project

The Hyades Monitoring Tools Project extends the platform for collecting, analyzing, aggregating, and visualizing data that can be captured in the log and statistical models.

The typical examples are the collection of system or application resources such as cpu or memory utilization and support for the viewing, aggregation, and analysis of that data. Logs can also be transformed into a common format and model allowing for symptom and pattern analysis. The correlation of the data in these models is of particular interest when it is associated with other model instances of statistical or log data as well as traces and tests.