-
Notifications
You must be signed in to change notification settings - Fork 33
/
introduction.xml
191 lines (158 loc) · 8.02 KB
/
introduction.xml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
"http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [
<!ENTITY % BOOK_ENTITIES SYSTEM "tck.ent">
%BOOK_ENTITIES;
]>
<chapter id="introduction">
<title>Introduction</title>
<para>This chapter explains the purpose of a TCK and identifies the
foundation elements of the Bean Validation TCK.</para>
<section id="primer">
<title>TCK Primer</title>
<para>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.</para>
<para>The tests in the TCK are derived from assertions in the written
specification document. The assertions are itemized in an XML document
(<filename>tck-audit.xml</filename>), 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).</para>
<para>A TCK is entirely implementation agnostic. It should validate
assertions by consulting the specification's public API.</para>
</section>
<section>
<title>Compatibility Testing</title>
<para>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.</para>
<para>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.</para>
<para>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.</para>
<section>
<title>Why Compatibility Is Important</title>
<para>Java platform compatibility is important to different groups
involved with Java technologies for different reasons:</para>
<itemizedlist>
<listitem>
<para>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.</para>
</listitem>
<listitem>
<para>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.</para>
</listitem>
<listitem>
<para>Compatibility testing enables application users to obtain
applications from disparate sources and deploy them with
confidence.</para>
</listitem>
<listitem>
<para>Conformance testing benefits Java platform implementors by
ensuring the same extent of reliability for all Java platform
ports.</para>
</listitem>
</itemizedlist>
<para>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.</para>
</section>
</section>
<section>
<title>About the Bean Validation TCK</title>
<para>The Bean Validation TCK is designed as a portable, configurable and
automated test suite for verifying the compatibility of an implementation
of &jsrVersion;. 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).</para>
<para>Each test class in the suite acts as a deployable unit. The
deployable units, or artifacts, are defined in a declarative way using
annotations.</para>
<para>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.<note>
<para>The reason the Bean Validation TCK must pass running in a EE
container is that Bean Validation is part of Java EE 7 itself.</para>
</note></para>
<section>
<title>TCK Components</title>
<para>The Bean Validation TCK includes the following components:</para>
<itemizedlist>
<listitem>
<para><emphasis role="bold">The test suite</emphasis>, which is a
collection of TestNG tests, the TestNG test suite descriptor and
supplemental resources that configure Bean Validation and other
software components.</para>
</listitem>
<listitem>
<para><emphasis role="bold">The TCK audit</emphasis>
(<filename>tck-audit.xml</filename>) 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.</para>
<para>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.</para>
</listitem>
<listitem>
<para><emphasis role="bold">TCK documentation</emphasis> accompanied
by release notes identifying updates between versions.</para>
</listitem>
<listitem>
<para><emphasis role="bold">TCK Container Adapter</emphasis>
provided as a convenience for developers in order to run and debug
tests outside of the EE container.</para>
</listitem>
<listitem>
<para><emphasis role="bold">Setup examples</emphasis> demonstrating
Maven and Ant setups to run the TCK test suite</para>
</listitem>
</itemizedlist>
</section>
<section id="passing-the-tck">
<title>Passing the Bean Validation TCK</title>
<para>In order to pass the Bean Validation TCK (which is one requirement
for becoming a certified Bean Validation provider), you need to:</para>
<itemizedlist>
<listitem>
<para>Pass the Bean Validation signature tests (see <xref
linkend="sigtest"/>) asserting the correctness of the Bean
Validation API used.</para>
</listitem>
<listitem>
<para>Run and pass the test suite (see <xref
linkend="configuration"/>). The test must be run within an EE 7
container and pass with an unmodified TestNG suite file.</para>
</listitem>
</itemizedlist>
<note>
<para>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.</para>
</note>
</section>
</section>
</chapter>