Hibernate.orgCommunity Documentation
This chapter explains the purpose of a TCK and identifies the foundation elements of the Bean Validation 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
(tck-audit.xml), 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
(meaning the provided test suite must be run unmodified).
A TCK is entirely implementation agnostic. It should validate assertions by consulting the specification's public API.
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.
Java platform compatibility is important to different groups involved with Java technologies for different reasons:
Compatibility testing is the means by which the JCP ensures that the Java platform does not become fragmented as it is ported to different operating systems and hardware.
Compatibility testing benefits developers working in the Java programming language, enabling them to write applications once and deploy them across heterogeneous computing environments without porting.
Compatibility testing enables application users to obtain applications from disparate sources and deploy them with confidence.
Conformance testing benefits Java platform implementors by ensuring the same extent of reliability for all Java platform ports.
The Bean Validation specification goes to great lengths to ensure that programs written for Java EE are compatible and the TCK is rigorous about enforcing the rules the specification lays down.
The Bean Validation TCK is designed as a portable, configurable and automated test suite for verifying the compatibility of an implementation of JSR 349. 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 (Arquillian).
Each test class in the suite acts as a deployable unit. The deployable units, or artifacts, are defined in a declarative way using annotations.
The declarative approach allows many of the tests to be executed in a standalone implementation of Bean Validation, accounting for a boost 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.
The reason the Bean Validation TCK must pass running in a EE container is that Bean Validation is part of Java EE 7 itself.
The Bean Validation TCK includes the following components:
The test suite, which is a collection of TestNG tests, the TestNG test suite descriptor and supplemental resources that configure Bean Validation and other software components.
The TCK audit
(tck-audit.xml) used to list out the assertions
identified in the Bean Validation specification. It matches the
assertions to test cases in the test suite by unique identifier and
produces a coverage report.
The audit document is provided along with the TCK. Each assertion is defined with a reference to a chapter, section and paragraph from the specification document, making it easy for the implementor to locate the language in the specification document that supports the feature being tested.
TCK documentation accompanied by release notes identifying updates between versions.
TCK Container Adapter provided as a convenience for developers in order to run and debug tests outside of the EE container.
Setup examples demonstrating Maven and Ant setups to run the TCK test suite
In order to pass the Bean Validation TCK (which is one requirement for becoming a certified Bean Validation provider), you need to:
Pass the Bean Validation signature tests (see Chapter 6, Running the Signature Test) asserting the correctness of the Bean Validation API used.
Run and pass the test suite (see Chapter 5, Running the TCK test suite). The test must be run within an EE 7 container and pass with an unmodified TestNG suite file.
The designated reference runtime for compatibility testing of the Bean Validation specification is the Sun Java Platform, Enterprise Edition (Java EE) 7 reference implementation (RI), aka Glassfish 4.
Copyright © 2009 - 2014 Red Hat, Inc.