673 lines
26 KiB
HTML
673 lines
26 KiB
HTML
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
|
|
<html>
|
|
<head>
|
|
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
|
|
<meta name="GENERATOR" content="Microsoft FrontPage 4.0">
|
|
<meta name="Author" content="Erich Gamma, Kent Beck, and David Saff">
|
|
<title>JUnit 4.6</title>
|
|
</head>
|
|
<body>
|
|
|
|
<h1>
|
|
<b><font color="#00CC00">J</font><font color="#FF0000">U</font><font color="#000000">nit
|
|
4.6</b></h1>
|
|
<br>Brought to you by <a href="http://www.threeriversinstitute.org">Kent Beck</a>, Erich
|
|
Gamma, and <a href="http://david.saff.net">David Saff</a>.
|
|
<br>FAQ edited by <a href="http://www.clarkware.com">Mike Clark</a>. Web mastering by Erik
|
|
Meade.
|
|
<br>(see also <a href="http://www.junit.org">JUnit.org</a>)
|
|
|
|
<hr WIDTH="100%">
|
|
<br>6 April 2009
|
|
<p>JUnit is a simple framework to write repeatable tests. It is an instance
|
|
of the xUnit architecture for unit testing frameworks.
|
|
<ul>
|
|
<li>
|
|
<a href="#Summary of">Summary of Changes</a></li>
|
|
|
|
<li>
|
|
<a href="#Contents">Contents</a></li>
|
|
|
|
<li>
|
|
<a href="#Installation">Installation</a></li>
|
|
|
|
<li>
|
|
<a href="#Getting">Getting Started</a></li>
|
|
|
|
<li>
|
|
<a href="#Documentation">Documentation</a></li>
|
|
<li>
|
|
<a href="#Known Defects">Known Defects</a></li>
|
|
</ul>
|
|
|
|
<a NAME="Summary of">
|
|
<h2>Summary of Changes in version 4.6</h2>
|
|
|
|
<h3>Max</h3>
|
|
|
|
<p>JUnit now includes a new experimental Core, <code>MaxCore</code>. <code>MaxCore</code>
|
|
remembers the results of previous test runs in order to run new
|
|
tests out of order. <code>MaxCore</code> prefers new tests to old tests, fast
|
|
tests to slow tests, and recently failing tests to tests that last
|
|
failed long ago. There's currently not a standard UI for running
|
|
<code>MaxCore</code> included in JUnit, but there is a UI included in the JUnit
|
|
Max Eclipse plug-in at:</p>
|
|
|
|
<p>http://www.junitmax.com/junitmax/subscribe.html</p>
|
|
|
|
<p>Example:</p>
|
|
|
|
<pre><code>public static class TwoUnEqualTests {
|
|
@Test
|
|
public void slow() throws InterruptedException {
|
|
Thread.sleep(100);
|
|
fail();
|
|
}
|
|
|
|
@Test
|
|
public void fast() {
|
|
fail();
|
|
}
|
|
}
|
|
|
|
@Test
|
|
public void rememberOldRuns() {
|
|
File maxFile = new File("history.max");
|
|
MaxCore firstMax = MaxCore.storedLocally(maxFile);
|
|
firstMax.run(TwoUnEqualTests.class);
|
|
|
|
MaxCore useHistory= MaxCore.storedLocally(maxFile);
|
|
List<Failure> failures= useHistory.run(TwoUnEqualTests.class)
|
|
.getFailures();
|
|
assertEquals("fast", failures.get(0).getDescription().getMethodName());
|
|
assertEquals("slow", failures.get(1).getDescription().getMethodName());
|
|
}
|
|
</code></pre>
|
|
|
|
<h3>Test scheduling strategies</h3>
|
|
|
|
<p><code>JUnitCore</code> now includes an experimental method that allows you to
|
|
specify a model of the <code>Computer</code> that runs your tests. Currently,
|
|
the only built-in Computers are the default, serial runner, and two
|
|
runners provided in the <code>ParallelRunner</code> class:
|
|
<code>ParallelRunner.classes()</code>, which runs classes in parallel, and
|
|
<code>ParallelRunner.methods()</code>, which runs classes and methods in parallel.</p>
|
|
|
|
<p>This feature is currently less stable than MaxCore, and may be
|
|
merged with MaxCore in some way in the future.</p>
|
|
|
|
<p>Example:</p>
|
|
|
|
<pre><code>public static class Example {
|
|
@Test public void one() throws InterruptedException {
|
|
Thread.sleep(1000);
|
|
}
|
|
@Test public void two() throws InterruptedException {
|
|
Thread.sleep(1000);
|
|
}
|
|
}
|
|
|
|
@Test public void testsRunInParallel() {
|
|
long start= System.currentTimeMillis();
|
|
Result result= JUnitCore.runClasses(ParallelComputer.methods(),
|
|
Example.class);
|
|
assertTrue(result.wasSuccessful());
|
|
long end= System.currentTimeMillis();
|
|
assertThat(end - start, betweenInclusive(1000, 1500));
|
|
}
|
|
</code></pre>
|
|
|
|
<h3>Comparing double arrays</h3>
|
|
|
|
<p>Arrays of doubles can be compared, using a delta allowance for equality:</p>
|
|
|
|
<pre><code>@Test
|
|
public void doubleArraysAreEqual() {
|
|
assertArrayEquals(new double[] {1.0, 2.0}, new double[] {1.0, 2.0}, 0.01);
|
|
}
|
|
</code></pre>
|
|
|
|
<h3><code>Filter.matchDescription</code> API</h3>
|
|
|
|
<p>Since 4.0, it has been possible to run a single method using the <code>Request.method</code>
|
|
API. In 4.6, the filter that implements this is exposed as <code>Filter.matchDescription</code>.</p>
|
|
|
|
<h3>Documentation</h3>
|
|
|
|
<ul>
|
|
<li><p>A couple classes and packages that once had empty javadoc have been
|
|
doc'ed.</p></li>
|
|
<li><p>Added how to run JUnit from the command line to the cookbook.</p></li>
|
|
<li><p>junit-4.x.zip now contains build.xml</p></li>
|
|
</ul>
|
|
|
|
<h3>Bug fixes</h3>
|
|
|
|
<ul>
|
|
<li>Fixed overly permissive @DataPoint processing (2191102)</li>
|
|
<li>Fixed bug in test counting after an ignored method (2106324)</li>
|
|
</ul>
|
|
|
|
<h2>Summary of Changes in version 4.5</h2>
|
|
|
|
<h3>Installation</h3>
|
|
|
|
<ul>
|
|
<li>We are releasing <code>junit-4.6.jar</code>, which contains all the classes
|
|
necessary to run JUnit, and <code>junit-dep-4.6.jar</code>, which leaves out
|
|
hamcrest classes, for developers who already use hamcrest outside of
|
|
JUnit.</li>
|
|
</ul>
|
|
|
|
<h3>Basic JUnit operation</h3>
|
|
|
|
<ul>
|
|
<li><p>JUnitCore now more often exits with the correct exit code (0 for
|
|
success, 1 for failure)</p></li>
|
|
<li><p>Badly formed test classes (exceptions in constructors, classes
|
|
without tests, multiple constructors, Suite without @SuiteClasses)
|
|
produce more helpful error messages</p></li>
|
|
<li><p>Test classes whose only test methods are inherited from superclasses
|
|
now run.</p></li>
|
|
<li><p>Optimization to annotation processing can cut JUnit overhead by more than half
|
|
on large test classes, especially when using Theories. [Bug 1796847]</p></li>
|
|
<li><p>A failing assumption in a constructor ignores the class</p></li>
|
|
<li><p>Correct results when comparing the string "null" with potentially
|
|
null values. [Bug 1857283]</p></li>
|
|
<li><p>Annotating a class with <code>@RunWith(JUnit4.class)</code> will always invoke the
|
|
default JUnit 4 runner in the current version of JUnit. This default changed
|
|
from <code>JUnit4ClassRunner</code> in 4.4 to <code>BlockJUnit4ClassRunner</code> in 4.5 (see below),
|
|
and may change again.</p></li>
|
|
</ul>
|
|
|
|
<h3>Extension</h3>
|
|
|
|
<ul>
|
|
<li><p><code>BlockJUnit4Runner</code> is a new implementation of the standard JUnit 4
|
|
test class functionality. In contrast to <code>JUnit4ClassRunner</code> (the old
|
|
implementation):</p>
|
|
|
|
<ul>
|
|
<li><p><code>BlockJUnit4Runner</code> has a much simpler implementation based on
|
|
Statements, allowing new operations to be inserted into the
|
|
appropriate point in the execution flow.</p></li>
|
|
<li><p><code>BlockJUnit4Runner</code> is published, and extension and reuse are
|
|
encouraged, whereas <code>JUnit4ClassRunner</code> was in an internal package,
|
|
and is now deprecated.</p></li>
|
|
</ul></li>
|
|
<li><p><code>ParentRunner</code> is a base class for runners that iterate over
|
|
a list of "children", each an object representing a test or suite to run.
|
|
<code>ParentRunner</code> provides filtering, sorting, <code>@BeforeClass</code>, <code>@AfterClass</code>,
|
|
and method validation to subclasses.</p></li>
|
|
<li><p><code>TestClass</code> wraps a class to be run, providing efficient, repeated access
|
|
to all methods with a given annotation.</p></li>
|
|
<li><p>The new <code>RunnerBuilder</code> API allows extending the behavior of
|
|
Suite-like custom runners.</p></li>
|
|
<li><p><code>AssumptionViolatedException.toString()</code> is more informative</p></li>
|
|
</ul>
|
|
|
|
<h3>Extra Runners</h3>
|
|
|
|
<ul>
|
|
<li><p><code>Parameterized.eachOne()</code> has been removed</p></li>
|
|
<li><p>New runner <code>Enclosed</code> runs all static inner classes of an outer class.</p></li>
|
|
</ul>
|
|
|
|
<h3>Theories</h3>
|
|
|
|
<ul>
|
|
<li><p><code>@Before</code> and <code>@After</code> methods are run before and after each set of attempted parameters
|
|
on a Theory, and each set of parameters is run on a new instance of the test class.</p></li>
|
|
<li><p>Exposed API's <code>ParameterSignature.getType()</code> and <code>ParameterSignature.getAnnotations()</code></p></li>
|
|
<li><p>An array of data points can be introduced by a field or method
|
|
marked with the new annotation <code>@DataPoints</code></p></li>
|
|
<li><p>The Theories custom runner has been refactored to make it faster and
|
|
easier to extend</p></li>
|
|
</ul>
|
|
|
|
<h3>Development</h3>
|
|
|
|
<ul>
|
|
<li><p>Source has been split into directories <code>src/main/java</code> and
|
|
<code>src/test/java</code>, making it easier to exclude tests from builds, and
|
|
making JUnit more maven-friendly</p></li>
|
|
<li><p>Test classes in <code>org.junit.tests</code> have been organized into
|
|
subpackages, hopefully making finding tests easier.</p></li>
|
|
<li><p><code>ResultMatchers</code> has more informative descriptions.</p></li>
|
|
<li><p><code>TestSystem</code> allows testing return codes and other system-level interactions.</p></li>
|
|
</ul>
|
|
|
|
<h2>Summary of Changes in version 4.4</h2>
|
|
|
|
<p>JUnit is designed to efficiently capture developers' intentions about
|
|
their code, and quickly check their code matches those intentions.
|
|
Over the last year, we've been talking about what things developers
|
|
would like to say about their code that have been difficult in the
|
|
past, and how we can make them easier.</p>
|
|
|
|
<h3>assertThat</h3>
|
|
|
|
<p>Two years ago, Joe Walnes built a <a href="http://joe.truemesh.com/blog/000511.html">new assertion mechanism</a> on top of what was
|
|
then <a href="http://www.jmock.org/download.html">JMock 1</a>. The method name was <code>assertThat</code>, and the syntax looked like this:</p>
|
|
|
|
<pre><code>assertThat(x, is(3));
|
|
assertThat(x, is(not(4)));
|
|
assertThat(responseString, either(containsString("color")).or(containsString("colour")));
|
|
assertThat(myList, hasItem("3"));
|
|
</code></pre>
|
|
|
|
<p>More generally:</p>
|
|
|
|
<pre><code>assertThat([value], [matcher statement]);
|
|
</code></pre>
|
|
|
|
<p>Advantages of this assertion syntax include:</p>
|
|
|
|
<ul>
|
|
<li><p>More readable and typeable: this syntax allows you to think in terms of subject, verb, object
|
|
(assert "x is 3") rathern than <code>assertEquals</code>, which uses verb, object, subject (assert "equals 3 x")</p></li>
|
|
<li><p>Combinations: any matcher statement <code>s</code> can be negated (<code>not(s)</code>), combined (<code>either(s).or(t)</code>),
|
|
mapped to a collection (<code>each(s)</code>), or used in custom combinations (<code>afterFiveSeconds(s)</code>)</p></li>
|
|
<li><p>Readable failure messages. Compare</p>
|
|
|
|
<pre><code>assertTrue(responseString.contains("color") || responseString.contains("colour"));
|
|
// ==> failure message:
|
|
// java.lang.AssertionError:
|
|
|
|
|
|
assertThat(responseString, anyOf(containsString("color"), containsString("colour")));
|
|
// ==> failure message:
|
|
// java.lang.AssertionError:
|
|
// Expected: (a string containing "color" or a string containing "colour")
|
|
// got: "Please choose a font"
|
|
</code></pre></li>
|
|
<li><p>Custom Matchers. By implementing the <code>Matcher</code> interface yourself, you can get all of the
|
|
above benefits for your own custom assertions.</p></li>
|
|
<li><p>For a more thorough description of these points, see <a href="http://joe.truemesh.com/blog/000511.html">Joe Walnes's
|
|
original post</a>.:</p></li>
|
|
</ul>
|
|
|
|
<p>We have decided to include this API directly in JUnit.
|
|
It's an extensible and readable syntax, and because it enables
|
|
new features, like <a href="#assumptions">assumptions</a> and <a href="#theories">theories</a>.</p>
|
|
|
|
<p>Some notes:</p>
|
|
|
|
<ul>
|
|
<li>The old assert methods are never, ever, going away. <br />
|
|
Developers may continue using the old <code>assertEquals</code>, <code>assertTrue</code>, and
|
|
so on.</li>
|
|
<li><p>The second parameter of an <code>assertThat</code> statement is a <code>Matcher</code>.
|
|
We include the Matchers we want as static imports, like this:</p>
|
|
|
|
<pre><code>import static org.hamcrest.CoreMatchers.is;
|
|
</code></pre>
|
|
|
|
<p>or:</p>
|
|
|
|
<pre><code>import static org.hamcrest.CoreMatchers.*;
|
|
</code></pre></li>
|
|
<li><p>Manually importing <code>Matcher</code> methods can be frustrating. [Eclipse
|
|
3.3][] includes the ability to
|
|
define
|
|
"Favorite" classes to import static methods from, which makes it easier
|
|
(Search for "Favorites" in the Preferences dialog).
|
|
We expect that support for static imports will improve in all Java IDEs in the future.</p></li>
|
|
<li><p>To allow compatibility with a wide variety of possible matchers,
|
|
we have decided to include the classes from hamcrest-core,
|
|
from the <a href="http://code.google.com/p/hamcrest/">Hamcrest</a> project. This is the first time that
|
|
third-party classes have been included in JUnit. </p></li>
|
|
<li><p>To allow developers to maintain full control of the classpath contents, the JUnit distribution also provides an unbundled junit-dep jar,
|
|
ie without hamcrest-core classes included. This is intended for situations when using other libraries that also depend on hamcrest-core, to
|
|
avoid classloading conflicts or issues. Developers using junit-dep should ensure a compatible version of hamcrest-core jar (ie 1.1+) is present in the classpath.</p></li>
|
|
<li><p>JUnit currently ships with a few matchers, defined in
|
|
<code>org.hamcrest.CoreMatchers</code> and <code>org.junit.matchers.JUnitMatchers</code>. <br />
|
|
To use many, many more, consider downloading the <a href="http://hamcrest.googlecode.com/files/hamcrest-all-1.1.jar">full hamcrest package</a>.</p></li>
|
|
<li><p>JUnit contains special support for comparing string and array
|
|
values, giving specific information on how they differ. This is not
|
|
yet available using the <code>assertThat</code> syntax, but we hope to bring
|
|
the two assert methods into closer alignment in future releases.</p></li>
|
|
</ul>
|
|
|
|
<h3>assumeThat</h3>
|
|
|
|
<p><a name="assumptions" />
|
|
Ideally, the developer writing a test has control of all of the forces that might cause a test to fail.
|
|
If this isn't immediately possible, making dependencies explicit can often improve a design. <br />
|
|
For example, if a test fails when run in a different locale than the developer intended,
|
|
it can be fixed by explicitly passing a locale to the domain code.</p>
|
|
|
|
<p>However, sometimes this is not desirable or possible. <br />
|
|
It's good to be able to run a test against the code as it is currently written,
|
|
implicit assumptions and all, or to write a test that exposes a known bug.
|
|
For these situations, JUnit now includes the ability to express "assumptions":</p>
|
|
|
|
<pre><code>import static org.junit.Assume.*
|
|
|
|
@Test public void filenameIncludesUsername() {
|
|
assumeThat(File.separatorChar, is('/'));
|
|
assertThat(new User("optimus").configFileName(), is("configfiles/optimus.cfg"));
|
|
}
|
|
|
|
@Test public void correctBehaviorWhenFilenameIsNull() {
|
|
assumeTrue(bugFixed("13356")); // bugFixed is not included in JUnit
|
|
assertThat(parse(null), is(new NullDocument()));
|
|
}
|
|
</code></pre>
|
|
|
|
<p>With this beta release, a failed assumption will lead to the test being marked as passing,
|
|
regardless of what the code below the assumption may assert.
|
|
In the future, this may change, and a failed assumption may lead to the test being ignored:
|
|
however, third-party runners do not currently allow this option.</p>
|
|
|
|
<p>We have included <code>assumeTrue</code> for convenience, but thanks to the
|
|
inclusion of Hamcrest, we do not need to create <code>assumeEquals</code>,
|
|
<code>assumeSame</code>, and other analogues to the <code>assert*</code> methods. All of
|
|
those functionalities are subsumed in assumeThat, with the appropriate
|
|
matcher.</p>
|
|
|
|
<p>A failing assumption in a <code>@Before</code> or <code>@BeforeClass</code> method will have the same effect
|
|
as a failing assumption in each <code>@Test</code> method of the class.</p>
|
|
|
|
<h3>Theories</h3>
|
|
|
|
<p><a name="theories" />
|
|
More flexible and expressive assertions, combined with the ability to
|
|
state assumptions clearly, lead to a new kind of statement of intent,
|
|
which we call a "Theory". A test captures the intended behavior in
|
|
one particular scenario. A theory allows a developer to be
|
|
as precise as desired about the behavior of the code in possibly
|
|
infinite numbers of possible scenarios. For example:</p>
|
|
|
|
<pre><code>@RunWith(Theories.class)
|
|
public class UserTest {
|
|
@DataPoint public static String GOOD_USERNAME = "optimus";
|
|
@DataPoint public static String USERNAME_WITH_SLASH = "optimus/prime";
|
|
|
|
@Theory public void filenameIncludesUsername(String username) {
|
|
assumeThat(username, not(containsString("/")));
|
|
assertThat(new User(username).configFileName(), containsString(username));
|
|
}
|
|
}
|
|
</code></pre>
|
|
|
|
<p>This makes it clear that the user's filename should be included in the
|
|
config file name, only if it doesn't contain a slash. Another test
|
|
or theory might define what happens when a username does contain a slash.</p>
|
|
|
|
<p><code>UserTest</code> will attempt to run <code>filenameIncludesUsername</code> on
|
|
every compatible <code>DataPoint</code> defined in the class. If any of the
|
|
assumptions fail, the data point is silently ignored. If all of the
|
|
assumptions pass, but an assertion fails, the test fails.</p>
|
|
|
|
<p>The support for Theories has been absorbed from the <a href="http://popper.tigris.org">Popper</a>
|
|
project, and <a href="http://popper.tigris.org/tutorial.html">more complete documentation</a> can be found
|
|
there.</p>
|
|
|
|
<p>Defining general statements in this way can jog the developer's memory
|
|
about other potential data points and tests, also allows <a href="http://www.junitfactory.org">automated
|
|
tools</a> to <a href="http://shareandenjoy.saff.net/2007/04/popper-and-junitfactory.html">search</a> for new, unexpected data
|
|
points that expose bugs.</p>
|
|
|
|
<h3>Other changes</h3>
|
|
|
|
<p>This release contains other bug fixes and new features. Among them:</p>
|
|
|
|
<ul>
|
|
<li><p>Annotated descriptions</p>
|
|
|
|
<p>Runner UIs, Filters, and Sorters operate on Descriptions of test
|
|
methods and test classes. These Descriptions now include the
|
|
annotations on the original Java source element, allowing for richer
|
|
display of test results, and easier development of annotation-based
|
|
filters.</p></li>
|
|
<li><p>Bug fix (1715326): assertEquals now compares all Numbers using their
|
|
native implementation of <code>equals</code>. This assertion, which passed in
|
|
4.3, will now fail:</p>
|
|
|
|
<p>assertEquals(new Integer(1), new Long(1));</p>
|
|
|
|
<p>Non-integer Numbers (Floats, Doubles, BigDecimals, etc),
|
|
which were compared incorrectly in 4.3, are now fixed.</p></li>
|
|
<li><p><code>assertEquals(long, long)</code> and <code>assertEquals(double, double)</code> have
|
|
been re-introduced to the <code>Assert</code> class, to take advantage of
|
|
Java's native widening conversions. Therefore, this still passes:</p>
|
|
|
|
<p>assertEquals(1, 1L);</p></li>
|
|
<li><p>The default runner for JUnit 4 test classes has been refactored.
|
|
The old version was named <code>TestClassRunner</code>, and the new is named
|
|
<code>JUnit4ClassRunner</code>. Likewise, <code>OldTestClassRunner</code> is now
|
|
<code>JUnit3ClassRunner</code>. The new design allows variations in running
|
|
individual test classes to be expressed with fewer custom classes.
|
|
For a good example, see the source to
|
|
<code>org.junit.experimental.theories.Theories</code>.</p></li>
|
|
<li><p>The rules for determining which runner is applied by default to a
|
|
test class have been simplified:</p>
|
|
|
|
<ol>
|
|
<li><p>If the class has a <code>@RunWith</code> annotation, the annotated runner
|
|
class is used.</p></li>
|
|
<li><p>If the class can be run with the JUnit 3 test runner (it
|
|
subclasses <code>TestCase</code>, or contains a <code>public static Test suite()</code>
|
|
method), JUnit38ClassRunner is used.</p></li>
|
|
<li><p>Otherwise, JUnit4ClassRunner is used.</p></li>
|
|
</ol>
|
|
|
|
<p>This default guess can always be overridden by an explicit
|
|
<code>@RunWith(JUnit4ClassRunner.class)</code> or
|
|
<code>@RunWith(JUnit38ClassRunner.class)</code> annotation.</p>
|
|
|
|
<p>The old class names <code>TestClassRunner</code> and <code>OldTestClassRunner</code>
|
|
remain as deprecated.</p></li>
|
|
<li><p>Bug fix (1739095): Filters and Sorters work correctly on test
|
|
classes that contain a <code>suite</code> method like:</p>
|
|
|
|
<p>public static junit.framework.Test suite() {
|
|
return new JUnit4TestAdapter(MyTest.class);
|
|
}</p></li>
|
|
<li><p>Bug fix (1745048): @After methods are now correctly called
|
|
after a test method times out.</p></li>
|
|
</ul>
|
|
|
|
<h2>
|
|
<a NAME="Summary of"></a>Summary of Changes in version 4.3.1</h2>
|
|
<p>
|
|
<ul>
|
|
<li>Bug fix: 4.3 introduced a
|
|
<a href="https://sourceforge.net/tracker/?func=detail&atid=115278&aid=1684562&group_id=15278">bug</a>
|
|
that caused a NullPointerException
|
|
when comparing a null reference to a non-null reference in <tt>assertEquals</tt>.
|
|
This has been fixed.
|
|
<li>Bug fix: The binary jar for 4.3 <a href="https://sourceforge.net/tracker/?func=detail&atid=115278&aid=1686931&group_id=15278">accidentally</a> included the tests and sample code,
|
|
which are now removed for a smaller download, but, as always, available from the
|
|
full zip.
|
|
</ul>
|
|
</p>
|
|
|
|
<h2>
|
|
<a NAME="Summary of"></a>Summary of Changes with version 4.3</h2>
|
|
<p>
|
|
<ul>
|
|
<li>Changes in array equality. Using <tt>assertEquals</tt> to compare array contents is now deprecated.
|
|
In the future, <tt>assertEquals</tt> will revert to its pre-4.0 meaning of comparing objects based on
|
|
Java's <tt>Object.equals</tt> semantics. To compare array contents, use the new, more reliable
|
|
<tt>Assert.assertArrayEquals</tt> methods.
|
|
<li>The <tt>@Ignore</tt> annotation can now be applied to classes, to ignore the entire class, instead of
|
|
individual methods.
|
|
<li>Originally, developers who wanted to use a static <tt>suite()</tt> method from JUnit 3.x with a JUnit 4.x
|
|
runner had to annotate the class with <tt>@RunWith(AllTests.class)</tt>. In the common case, this requirement
|
|
has been removed. However, when such a class is wrapped with a JUnit4TestAdapter (which we believe is rare), the
|
|
results may not be as expected.
|
|
<li>Improved error messages for array comparison("arrays first differed at element [1][0]")
|
|
<li>Bug fix: Inaccessible base class is caught at test construction time.
|
|
<li>Bug fix: Circular suites are caught at test construction time.
|
|
<li>Bug fix: Test constructors that throw exceptions are reported correctly.
|
|
<li><b>For committers and extenders</b>
|
|
<ul>
|
|
<li>Sources now are in a separate "src" directory (this means a big break in the CVS history)
|
|
<li>Improved documentation in <tt>Request</tt>, <tt>RunWith</tt>
|
|
</ul>
|
|
</ul>
|
|
</p>
|
|
|
|
<h2>
|
|
<a NAME="Summary of"></a>Summary of Changes with version 4.2</h2>
|
|
<p>
|
|
<ul>
|
|
<li>Bug fix: Inaccessible base class is caught at test construction time.
|
|
<li>Bug fix: Circular suites are caught at test construction time.
|
|
<li>Improved error messages for array comparison("arrays first differed at element [1][0]")
|
|
<li>Test constructors that throw exceptions are reported correctly.
|
|
</ul>
|
|
</p>
|
|
|
|
|
|
<h2>
|
|
<a NAME="Summary of"></a>Summary of Changes with version 4.1</h2>
|
|
<p>
|
|
<ul>
|
|
<li>Bug fix: listeners now get a correct test running time, rather than always being told 0 secs.
|
|
<li>The @RunWith annotation is now inherited by subclasses:
|
|
all subclasses of an abstract test class will be run by the same runner.
|
|
<li>The build script fails if the JUnit unit tests fail
|
|
<li>The faq has been updated
|
|
<li>Javadoc has been improved, with more internal links, and package descriptions added (Thanks, Matthias Schmidt!)
|
|
<li>An acknowledgements.txt file has been created to credit outside contributions
|
|
<li>The <tt>Enclosed</tt> runner, which runs all of the static inner classes of a given class, has been added
|
|
to <tt>org.junit.runners</tt>.
|
|
</ul>
|
|
</p>
|
|
|
|
<h2>Summary of Changes with version 4.0</h2>
|
|
<p>
|
|
The architecture of JUnit 4.0 is a substantial departure from that of earlier releases.
|
|
Instead of
|
|
tagging test classes by subclassing junit.framework.TestCase and tagging test methods by
|
|
starting their name with "test", you now tag test methods with the @Test annotation.
|
|
</p>
|
|
|
|
|
|
<h2>
|
|
<a NAME="Contents"></a>Contents of the Release</h2>
|
|
|
|
<table CELLSPACING=0 CELLPADDING=0 >
|
|
<tr>
|
|
<td><tt>README.html </tt></td>
|
|
|
|
<td>this file</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td><tt>junit-4.6.jar</tt></td>
|
|
|
|
<td>a jar file with the JUnit framework, bundled with the hamcrest-core-1.1 dependency.</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td><tt>junit-dep-4.6.jar</tt></td>
|
|
|
|
<td>a jar file with the JUnit framework, unbundled from any external dependencies.
|
|
Choosing to use this jar developers will need to also provide in the classpath a compatible version of external dependencies (ie hamcrest-core-1.1+)</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td><tt>junit-4.6-src.jar</tt></td>
|
|
|
|
<td>a jar file with the source code of the JUnit framework</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td><tt>org/junit</tt></td>
|
|
|
|
<td>the source code of the basic JUnit annotations and classes</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td><tt> samples</tt></td>
|
|
|
|
<td>sample test cases</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td><tt> tests</tt></td>
|
|
|
|
<td>test cases for JUnit itself</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td><tt>javadoc</tt></td>
|
|
|
|
<td>javadoc generated documentation</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td><tt>doc</tt></td>
|
|
|
|
<td>documentation and articles</td>
|
|
</tr>
|
|
</table>
|
|
|
|
<h2>
|
|
<a NAME="Installation"></a>Installation</h2>
|
|
Below are the installation steps for installing JUnit:
|
|
<ol>
|
|
<li>
|
|
unzip the junit4.6.zip file</li>
|
|
|
|
<li>
|
|
add<i> </i><b>junit-4.6.jar</b> to the CLASSPATH. For example:
|
|
<tt> set classpath=%classpath%;INSTALL_DIR\junit-4.6.jar;INSTALL_DIR</tt></li>
|
|
|
|
<li>
|
|
test the installation by running <tt>java org.junit.runner.JUnitCore org.junit.tests.AllTests</tt></li>
|
|
|
|
<br><b><font color="#FF0000">Notice</font></b>: that the tests are not
|
|
contained in the junit-4.6.jar but in the installation directory directly.
|
|
Therefore make sure that the installation directory is on the class path
|
|
</ol>
|
|
<b><font color="#FF0000">Important</font></b>: don't install junit-4.6.jar
|
|
into the extension directory of your JDK installation. If you do so the
|
|
test class on the files system will not be found.
|
|
<h2>
|
|
<a NAME="Getting"></a>Getting Started</h2>
|
|
To get started with unit testing and JUnit read the article:
|
|
<a href="doc/cookbook/cookbook.htm">JUnit Cookbook</a>.
|
|
<br>This article describes basic test writing using JUnit 4.
|
|
<p>You find additional samples in the org.junit.samples package:
|
|
<ul>
|
|
<li>
|
|
SimpleTest.java - some simple test cases</li>
|
|
|
|
<li>
|
|
VectorTest.java - test cases for java.util.Vector</li>
|
|
</ul>
|
|
|
|
<h2>
|
|
<a NAME="Documentation"></a>Documentation</h2>
|
|
|
|
<blockquote><a href="doc/cookbook/cookbook.htm">JUnit Cookbook</a>
|
|
<br> A cookbook for implementing tests with JUnit.
|
|
<br><a href="javadoc/index.html">Javadoc</a>
|
|
<br> API documentation generated with javadoc.
|
|
<br><a href="doc/faq/faq.htm">Frequently asked questions</a>
|
|
<br> Some frequently asked questions about using JUnit.
|
|
<br><a href="cpl-v10.html">License</a>
|
|
<br> The terms of the common public license used for JUnit.<br>
|
|
</blockquote>
|
|
The following documents still describe JUnit 3.8.
|
|
<blockquote>
|
|
<br><a href="doc/testinfected/testing.htm">Test Infected - Programmers
|
|
Love Writing Tests</a>
|
|
<br> An article demonstrating the development process
|
|
with JUnit.
|
|
<br><a href="doc/cookstour/cookstour.htm">JUnit - A cooks tour</a>
|
|
</blockquote>
|
|
|
|
<hr WIDTH="100%">
|
|
<!--webbot bot="HTMLMarkup" startspan --><a href="http://sourceforge.net"><IMG
|
|
src="http://sourceforge.net/sflogo.php?group_id=15278"
|
|
width="88" height="31" border="0" alt="SourceForge Logo"></a><!--webbot
|
|
bot="HTMLMarkup" endspan -->
|
|
</body>
|
|
</html>
|