Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

8274083: Update testing docs to mention tiered testing #5615

Closed
wants to merge 7 commits into from
Closed
Show file tree
Hide file tree
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
@@ -27,6 +27,7 @@ <h1 class="title">Testing the JDK</h1>
<li><a href="#configuration">Configuration</a></li>
</ul></li>
<li><a href="#test-selection">Test selection</a><ul>
<li><a href="#common-test-groups">Common Test Groups</a></li>
<li><a href="#jtreg">JTReg</a></li>
<li><a href="#gtest">Gtest</a></li>
<li><a href="#microbenchmarks">Microbenchmarks</a></li>
@@ -67,6 +68,15 @@ <h2 id="test-selection">Test selection</h2>
<p>All functionality is available using the <code>test</code> make target. In this use case, the test or tests to be executed is controlled using the <code>TEST</code> variable. To speed up subsequent test runs with no source code changes, <code>test-only</code> can be used instead, which do not depend on the source and test image build.</p>
<p>For some common top-level tests, direct make targets have been generated. This includes all JTReg test groups, the hotspot gtest, and custom tests (if present). This means that <code>make test-tier1</code> is equivalent to <code>make test TEST=&quot;tier1&quot;</code>, but the latter is more tab-completion friendly. For more complex test runs, the <code>test TEST=&quot;x&quot;</code> solution needs to be used.</p>
<p>The test specifications given in <code>TEST</code> is parsed into fully qualified test descriptors, which clearly and unambigously show which tests will be run. As an example, <code>:tier1</code> will expand to <code>jtreg:$(TOPDIR)/test/hotspot/jtreg:tier1 jtreg:$(TOPDIR)/test/jdk:tier1 jtreg:$(TOPDIR)/test/langtools:tier1 jtreg:$(TOPDIR)/test/nashorn:tier1 jtreg:$(TOPDIR)/test/jaxp:tier1</code>. You can always submit a list of fully qualified test descriptors in the <code>TEST</code> variable if you want to shortcut the parser.</p>
<h3 id="common-test-groups">Common Test Groups</h3>
<p>The source tree currently defines a few common test groups in the relevant <code>TEST.groups</code> files. The test groups are either covering a specific component, for example <code>hotspot_gc</code>, or represent one of the <em>tiered</em> test groups, for example <code>tier1</code>. It is a good idea to look into <code>TEST.groups</code> files to get a sense what tests to run for the changes in the particular JDK component.</p>
<p>A brief description of the common test groups:</p>
<ul>
<li><p><code>tier1</code>: This test group is the first line of defense against bugs. Multiple developers run these tests every day. Normally, at least this tier is ran before integration. Because of the widespread, the tests in <code>tier1</code> are carefully selected and optimized to run fast, and to run in the most stable manner. The test failures in <code>tier1</code> are usually followed up on quickly, either with fixes, or adding relevant tests to problem list. <a href="../.github/workflows/">GitHub Actions workflows</a>, if enabled, run <code>tier1</code> tests.</p></li>
<li><p><code>tier2</code>: This test group covers even more ground. These contain, among other things, tests that either run for too long to be at <code>tier1</code>, test unstable and/or experimental features, test less essential JDK components.</p></li>
<li><p><code>tier3</code>: This test group covers more stressful tests, the tests for corner cases not covered by previous tiers, plus the tests that require GUIs. As such, this suite should either be run with low concurrency (<code>TEST_JOBS=1</code>), or without headful tests (<code>JTREG_KEYWORDS=\!headful</code>), or both.</p></li>
shipilev marked this conversation as resolved.
Show resolved Hide resolved
<li><p><code>tier4</code>: This test group every other test not covered by previous tiers. It includes, for example, <code>vmTestbase</code> suites for Hotspot, which run for many hours even on large machines. It also runs GUI tests, so the same <code>TEST_JOBS</code> and <code>JTREG_KEYWORDS</code> caveats apply.</p></li>
</ul>
<h3 id="jtreg">JTReg</h3>
<p>JTReg tests can be selected either by picking a JTReg test group, or a selection of files or directories containing JTReg tests.</p>
<p>JTReg test groups can be specified either without a test root, e.g. <code>:tier1</code> (or <code>tier1</code>, the initial colon is optional), or with, e.g. <code>hotspot:tier1</code>, <code>test/jdk:jdk_util</code> or <code>$(TOPDIR)/test/hotspot/jtreg:hotspot_all</code>. The test root can be specified either as an absolute path, or a path relative to the JDK top directory, or the <code>test</code> directory. For simplicity, the hotspot JTReg test root, which really is <code>hotspot/jtreg</code> can be abbreviated as just <code>hotspot</code>.</p>
@@ -64,6 +64,37 @@ jtreg:$(TOPDIR)/test/nashorn:tier1 jtreg:$(TOPDIR)/test/jaxp:tier1`. You can
always submit a list of fully qualified test descriptors in the `TEST` variable
if you want to shortcut the parser.

### Common Test Groups

The source tree currently defines a few common test groups in the relevant `TEST.groups`
files. The test groups are either covering a specific component, for example `hotspot_gc`,
or represent one of the _tiered_ test groups, for example `tier1`. It is a good idea
to look into `TEST.groups` files to get a sense what tests to run for the changes in
the particular JDK component.

A brief description of the common test groups:

- `tier1`: This test group is the first line of defense against bugs. Multiple developers
run these tests every day. Normally, at least this tier is passed before integration.
Because of the widespread use, the tests in `tier1` are carefully selected and optimized
to run fast, and to run in the most stable manner. The test failures in `tier1` are
usually followed up on quickly, either with fixes, or adding relevant tests to problem
list. [GitHub Actions workflows](../.github/workflows/), if enabled, run `tier1` tests.

- `tier2`: This test group covers even more ground. These contain, among other things,
tests that either run for too long to be at `tier1`, tests for unstable and/or experimental
features, tests for less essential JDK components (for example, jaxp).

- `tier3`: This test group includes more stressful tests, the tests for corner cases
not covered by previous tiers, plus the tests that require GUIs. As such, this suite
should either be run with low concurrency (`TEST_JOBS=1`), or without headful tests
(`JTREG_KEYWORDS=\!headful`), or both.

- `tier4`: This test group includes every other test not covered by previous tiers. It includes,
shipilev marked this conversation as resolved.
Show resolved Hide resolved
for example, `vmTestbase` suites for Hotspot, which run for many hours even on large
machines. It also runs GUI tests, so the same `TEST_JOBS` and `JTREG_KEYWORDS` caveats
apply.

### JTReg

JTReg tests can be selected either by picking a JTReg test group, or a selection