protected long getShortDelay() {
    return 100;
  }
Base class for JSR166 Junit TCK tests. Defines some constants, utility methods and classes, as
well as a simple framework for helping to make sure that assertions failing in generated threads
cause the associated test that generated them to itself fail (which JUnit doe not otherwise
arrange). The rules for creating such tests are:

<ol>

<li>All assertions in code running in generated threads must use the forms threadFail,
threadAssertTrue, threadAssertEquals, or threadAssertNull, (not <tt>fail</tt>,
<tt>assertTrue</tt>, etc.) It is OK (but not particularly recommended) for other code to use
these forms too. Only the most typically used JUnit assertion methods are defined this way, but
enough to live with.</li>

<li>If you override {@link #setUp} or {@link #tearDown}, make sure to invoke <tt>super.setUp</tt>
and <tt>super.tearDown</tt> within them. These methods are used to clear and check for thread
assertion failures.</li>

<li>All delays and timeouts must use one of the constants <tt>
SHORT_DELAY_MS</tt>, <tt> SMALL_DELAY_MS</tt>, <tt> MEDIUM_DELAY_MS</tt>,
<tt> LONG_DELAY_MS</tt>. The idea here is that a SHORT is always discriminable from zero time,
and always allows enough time for the small amounts of computation (creating a thread, calling a
few methods, etc) needed to reach a timeout point. Similarly, a SMALL is always discriminable as
larger than SHORT and smaller than MEDIUM. And so on. These constants are set to conservative
values, but even so, if there is ever any doubt, they can all be increased in one spot to rerun
tests on slower platforms</li>

<li>All threads generated must be joined inside each test case method (or <tt>fail</tt> to do so)
before returning from the method. The <tt> joinPool</tt> method can be used to do this when using
Executors.</li>

</ol>

<p>
<b>Other notes</b>
<ul>

<li>Usually, there is one testcase method per JSR166 method covering "normal" operation, and then
as many exception-testing methods as there are exceptions the method can throw. Sometimes there
are multiple tests per JSR166 method when the different "normal" behaviors differ significantly.
And sometimes testcases cover multiple methods when they cannot be tested in isolation.</li>

<li>The documentation style for testcases is to provide as javadoc a simple sentence or two
describing the property that the testcase method purports to test. The javadocs do not say
anything about how the property is tested. To find out, read the code.</li>

<li>These tests are "conformance tests", and do not attempt to test throughput, latency,
scalability or other performance factors (see the separate "jtreg" tests for a set intended to
check these for the most central aspects of functionality.) So, most tests use the smallest
sensible numbers of threads, collection sizes, etc needed to check basic conformance.</li>

<li>The test classes currently do not declare inclusion in any particular package to simplify
things for people integrating them in TCK test suites.</li>

<li>As a convenience, the <tt>main</tt> of this class (JSR166TestCase) runs all JSR166 unit
tests.</li>

</ul>


@version Based on JSR166 TCK version 1.8
geode-junit/src/main/java/org/apache/geode/util/JSR166TestCase.java