SeamFramework.orgCommunity Documentation

Chapter 1. Introduction (CDI TCK)

1.1. TCK Primer
1.2. Compatibility Testing
1.2.1. Why Compatibility Is Important
1.3. About the CDI TCK
1.3.1. CDI TCK Specifications and Requirements
1.3.2. CDI TCK Components

This chapter explains the purpose of a TCK and identifies the foundation elements of the CDI TCK.

A TCK, or Technology Compatibility Kit, is one of the three required pieces for any JSR (the other two being the specification document and the reference implementation). The TCK is a set of tools and tests to verify that an implementation of the technology conforms to the specification. The tests are the primary component, but the tools serve an equally critical role of providing a framework and/or set of SPIs for executing the tests.

The tests in the TCK are derived from assertions in the written specification document. The assertions are itemized in an XML document, where they each get assigned a unique identifier, and materialize as a suite of automated tests that collectively validate whether an implementation complies with the aforementioned assertions, and in turn the specification. For a particular implementation to be certified, all of the required tests must pass (i.e., the provided test suite must be run unmodified).

A TCK is entirely implementation agnostic. Ideally, it should validate assertions by consulting the specficiation's public API. However, when the information returned by the public API is not low-level enough to validate the assertion, the implementation must be consulted directly. In this case, the TCK provides an independent API as part of a porting package that enables this transparency. The porting package must be implemented for each CDI implementation. Section 1.3.4 introduces the porting package and section 4.1 covers the requirements for implementing it.

The goal of any specification is to eliminate portability problems so long as the program which uses the implementation also conforms to the rules laid out in the specification.

Executing the TCK is a form of compatibility testing. It's important to understand that compatibility testing is distinctly different from product testing. The TCK is not concerned with robustness, performance or ease of use, and therefore cannot vouch for how well an implementation meets these criteria. What a TCK can do is to ensure the exactness of an implementation as it relates to the specification.

Compatibility testing of any feature relies on both a complete specification and a complete reference implementation. The reference implementation demonstrates how each test can be passed and provides additional context to the implementor during development for the corresponding assertion.

The CDI TCK is designed as a portable, configurable and automated test suite for verifying the compatibility of an implementation of the JSR-299: Contexts and Dependency Injection for Java EE specification. The test suite is built atop TestNG and provides a series of extensions that allow runtime packaging and deployment of JEE artifacts for in-container testing (JBoss Test Harness).

Each test class in the suite acts as a deployable unit. The deployable units, or artifacts, are defined declaratively using annotations. The artifact produced can be either a WAR or an EAR.

The declarative approach allows many of the tests to be executed in a standalone implementation of CDI, accounting for a boast in developer productivity. However, an implementation is only valid if all tests pass using the in-container execution mode. The standalone mode is merely a developer convenience.

This section lists the applicable requirements and specifications for the CDI TCK.

The CDI TCK includes the following components:

The CDI TCK has been tested run on following platforms:

CDI supports Java EE 5, Java EE 6, Java EE 6 Web Profile and the Embeddable EJB 3.1. The TCK will execute on any of these runtimes, but is only part of the CTS for Java EE 6 and Java EE 6 Web Profile.