diff options
| author | Yohann Roussel <yroussel@google.com> | 2014-03-19 16:25:37 +0100 |
|---|---|---|
| committer | Yohann Roussel <yroussel@google.com> | 2014-03-20 15:13:33 +0100 |
| commit | 4eceb95409e844fdc33c9c706e1dc307bfd40303 (patch) | |
| tree | ee9f4f3fc79f757c79081c336bce4f1782c6ccd8 /junit4/README.html | |
| parent | 3d2402901b1a6462e2cf47a6fd09711f327961c3 (diff) | |
| download | toolchain_jack-4eceb95409e844fdc33c9c706e1dc307bfd40303.zip toolchain_jack-4eceb95409e844fdc33c9c706e1dc307bfd40303.tar.gz toolchain_jack-4eceb95409e844fdc33c9c706e1dc307bfd40303.tar.bz2 | |
Initial Jack import.
Change-Id: I953cf0a520195a7187d791b2885848ad0d5a9b43
Diffstat (limited to 'junit4/README.html')
| -rw-r--r-- | junit4/README.html | 672 |
1 files changed, 672 insertions, 0 deletions
diff --git a/junit4/README.html b/junit4/README.html new file mode 100644 index 0000000..42f29a6 --- /dev/null +++ b/junit4/README.html @@ -0,0 +1,672 @@ +<!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> |