67 |
|
* |
68 |
|
* <ol> |
69 |
|
* |
70 |
< |
* <li> All assertions in code running in generated threads must use |
70 |
> |
* <li>All assertions in code running in generated threads must use |
71 |
|
* the forms {@link #threadFail}, {@link #threadAssertTrue}, {@link |
72 |
|
* #threadAssertEquals}, or {@link #threadAssertNull}, (not |
73 |
|
* {@code fail}, {@code assertTrue}, etc.) It is OK (but not |
74 |
|
* particularly recommended) for other code to use these forms too. |
75 |
|
* Only the most typically used JUnit assertion methods are defined |
76 |
< |
* this way, but enough to live with.</li> |
76 |
> |
* this way, but enough to live with. |
77 |
|
* |
78 |
< |
* <li> If you override {@link #setUp} or {@link #tearDown}, make sure |
78 |
> |
* <li>If you override {@link #setUp} or {@link #tearDown}, make sure |
79 |
|
* to invoke {@code super.setUp} and {@code super.tearDown} within |
80 |
|
* them. These methods are used to clear and check for thread |
81 |
< |
* assertion failures.</li> |
81 |
> |
* assertion failures. |
82 |
|
* |
83 |
|
* <li>All delays and timeouts must use one of the constants {@code |
84 |
|
* SHORT_DELAY_MS}, {@code SMALL_DELAY_MS}, {@code MEDIUM_DELAY_MS}, |
89 |
|
* is always discriminable as larger than SHORT and smaller than |
90 |
|
* MEDIUM. And so on. These constants are set to conservative values, |
91 |
|
* but even so, if there is ever any doubt, they can all be increased |
92 |
< |
* in one spot to rerun tests on slower platforms.</li> |
92 |
> |
* in one spot to rerun tests on slower platforms. |
93 |
|
* |
94 |
< |
* <li> All threads generated must be joined inside each test case |
94 |
> |
* <li>All threads generated must be joined inside each test case |
95 |
|
* method (or {@code fail} to do so) before returning from the |
96 |
|
* method. The {@code joinPool} method can be used to do this when |
97 |
< |
* using Executors.</li> |
97 |
> |
* using Executors. |
98 |
|
* |
99 |
|
* </ol> |
100 |
|
* |
101 |
|
* <p><b>Other notes</b> |
102 |
|
* <ul> |
103 |
|
* |
104 |
< |
* <li> Usually, there is one testcase method per JSR166 method |
104 |
> |
* <li>Usually, there is one testcase method per JSR166 method |
105 |
|
* covering "normal" operation, and then as many exception-testing |
106 |
|
* methods as there are exceptions the method can throw. Sometimes |
107 |
|
* there are multiple tests per JSR166 method when the different |
108 |
|
* "normal" behaviors differ significantly. And sometimes testcases |
109 |
|
* cover multiple methods when they cannot be tested in |
110 |
< |
* isolation.</li> |
110 |
> |
* isolation. |
111 |
|
* |
112 |
< |
* <li> The documentation style for testcases is to provide as javadoc |
112 |
> |
* <li>The documentation style for testcases is to provide as javadoc |
113 |
|
* a simple sentence or two describing the property that the testcase |
114 |
|
* method purports to test. The javadocs do not say anything about how |
115 |
< |
* the property is tested. To find out, read the code.</li> |
115 |
> |
* the property is tested. To find out, read the code. |
116 |
|
* |
117 |
< |
* <li> These tests are "conformance tests", and do not attempt to |
117 |
> |
* <li>These tests are "conformance tests", and do not attempt to |
118 |
|
* test throughput, latency, scalability or other performance factors |
119 |
|
* (see the separate "jtreg" tests for a set intended to check these |
120 |
|
* for the most central aspects of functionality.) So, most tests use |
121 |
|
* the smallest sensible numbers of threads, collection sizes, etc |
122 |
< |
* needed to check basic conformance.</li> |
122 |
> |
* needed to check basic conformance. |
123 |
|
* |
124 |
|
* <li>The test classes currently do not declare inclusion in |
125 |
|
* any particular package to simplify things for people integrating |
126 |
< |
* them in TCK test suites.</li> |
126 |
> |
* them in TCK test suites. |
127 |
|
* |
128 |
< |
* <li> As a convenience, the {@code main} of this class (JSR166TestCase) |
129 |
< |
* runs all JSR166 unit tests.</li> |
128 |
> |
* <li>As a convenience, the {@code main} of this class (JSR166TestCase) |
129 |
> |
* runs all JSR166 unit tests. |
130 |
|
* |
131 |
|
* </ul> |
132 |
|
*/ |
379 |
|
"LongAdderTest", |
380 |
|
"SplittableRandomTest", |
381 |
|
"StampedLockTest", |
382 |
+ |
"SubmissionPublisherTest", |
383 |
|
"ThreadLocalRandom8Test", |
384 |
|
}; |
385 |
|
addNamedTestClasses(suite, java8TestClassNames); |
388 |
|
// Java9+ test classes |
389 |
|
if (atLeastJava9()) { |
390 |
|
String[] java9TestClassNames = { |
391 |
< |
// Currently empty |
391 |
> |
// Currently empty, but expecting varhandle tests |
392 |
|
}; |
393 |
|
addNamedTestClasses(suite, java9TestClassNames); |
394 |
|
} |
744 |
|
} |
745 |
|
|
746 |
|
/** Like Runnable, but with the freedom to throw anything */ |
747 |
< |
interface Thunk { public void run() throws Throwable; } |
747 |
> |
interface Action { public void run() throws Throwable; } |
748 |
|
|
749 |
|
/** |
750 |
< |
* Runs all the given tasks in parallel, failing if any fail. |
750 |
> |
* Runs all the given actions in parallel, failing if any fail. |
751 |
|
* Useful for running multiple variants of tests that are |
752 |
|
* necessarily individually slow because they must block. |
753 |
|
*/ |
754 |
< |
void testInParallel(Thunk ... thunks) { |
754 |
> |
void testInParallel(Action ... actions) { |
755 |
|
ExecutorService pool = Executors.newCachedThreadPool(); |
756 |
|
try { |
757 |
< |
ArrayList<Future<?>> futures = new ArrayList<>(thunks.length); |
758 |
< |
for (final Thunk thunk : thunks) |
757 |
> |
ArrayList<Future<?>> futures = new ArrayList<>(actions.length); |
758 |
> |
for (final Action action : actions) |
759 |
|
futures.add(pool.submit(new CheckedRunnable() { |
760 |
< |
public void realRun() throws Throwable { thunk.run();}})); |
760 |
> |
public void realRun() throws Throwable { action.run();}})); |
761 |
|
for (Future<?> future : futures) |
762 |
|
try { |
763 |
|
assertNull(future.get(LONG_DELAY_MS, MILLISECONDS)); |