Skip to content
This repository

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP
Browse code

Merge remote-tracking branch 'KentBeck/master' into junit.improvements

Conflicts:
	src/main/java/org/junit/experimental/ParallelComputer.java
  • Loading branch information...
commit c781baaea6db389aa089a9116cf4e985d78db68e 2 parents fdbf41e + 2f879b9
Tibor Digana authored
33 build.xml
@@ -133,7 +133,7 @@
133 133 <property name="basename" value="doc/ReleaseNotes${version-base}" />
134 134 <exec executable="perl" failonerror="true">
135 135 <arg file="build/Markdown.pl"/>
136   - <arg file="${basename}.txt"/>
  136 + <arg file="${basename}.md"/>
137 137 <redirector output="${basename}.html" />
138 138 </exec>
139 139 </target>
@@ -174,7 +174,8 @@
174 174 <copy file="build.xml" tofile="${dist}/build.xml" />
175 175 </target>
176 176
177   - <macrodef name="run-tests">
  177 + <macrodef name="run-dist-tests">
  178 + <!-- Runs the tests against the built jar files -->
178 179 <element name="extra-args" implicit="yes" />
179 180 <sequential>
180 181 <java classname="org.junit.runner.JUnitCore" fork="yes" failonerror="true">
@@ -188,16 +189,34 @@
188 189 </sequential>
189 190 </macrodef>
190 191
  192 + <macrodef name="run-local-tests">
  193 + <!-- Runs the tests against the local class files -->
  194 + <sequential>
  195 + <java classname="org.junit.runner.JUnitCore" fork="yes" failonerror="true">
  196 + <arg value="org.junit.tests.AllTests"/>
  197 + <classpath>
  198 + <pathelement location="${bin}" />
  199 + <pathelement location="${testbin}" />
  200 + <pathelement location="${hamcrestlib}" />
  201 + </classpath>
  202 + </java>
  203 + </sequential>
  204 + </macrodef>
  205 +
  206 + <target name="test" depends="build">
  207 + <run-local-tests />
  208 + </target>
  209 +
191 210 <target name="dist" depends="populate-dist">
192   - <run-tests>
193   - <jvmarg value="-Dignore.this=ignored" />
194   - </run-tests>
  211 + <run-dist-tests>
  212 + <jvmarg value="-Dignore.this=ignored"/>
  213 + </run-dist-tests>
195 214 </target>
196 215
197 216 <target name="profile" depends="populate-dist">
198   - <run-tests>
  217 + <run-dist-tests>
199 218 <jvmarg value="-agentlib:hprof=cpu=samples"/>
200   - </run-tests>
  219 + </run-dist-tests>
201 220 </target>
202 221
203 222 <target name="zip" depends="dist">
40 build/maven/junit-dep-pom-template.xml
@@ -4,10 +4,50 @@
4 4 <modelVersion>4.0.0</modelVersion>
5 5 <groupId>junit</groupId>
6 6 <artifactId>junit-dep</artifactId>
  7 + <packaging>pom</packaging>
7 8 <version>@version@</version>
8 9 <distributionManagement>
9 10 <relocation>
10 11 <artifactId>junit</artifactId>
  12 + <version>@version@</version>
  13 + <message>The artifact junit:junit does not contain Hamcrest anymore but declares a dependency to Hamcrest. Thus, junit:junit-dep has become obsolete.</message>
11 14 </relocation>
12 15 </distributionManagement>
  16 + <name>JUnit</name>
  17 + <url>http://junit.org</url>
  18 + <description>
  19 + JUnit is a regression testing framework written by Erich Gamma and Kent Beck.
  20 + It is used by the developer who implements unit tests in Java.
  21 + </description>
  22 + <organization>
  23 + <name>JUnit</name>
  24 + <url>http://www.junit.org</url>
  25 + </organization>
  26 + <mailingLists>
  27 + <mailingList>
  28 + <name>JUnit Mailing List</name>
  29 + <post>junit@yahoogroups.com</post>
  30 + <archive>
  31 + http://tech.groups.yahoo.com/group/junit/
  32 + </archive>
  33 + </mailingList>
  34 + </mailingLists>
  35 + <licenses>
  36 + <license>
  37 + <name>Common Public License Version 1.0</name>
  38 + <url>http://www.opensource.org/licenses/cpl1.0.txt</url>
  39 + </license>
  40 + </licenses>
  41 + <scm>
  42 + <connection>scm:git:git://github.com/KentBeck/junit.git</connection>
  43 + <developerConnection>scm:git:git@github.com:KentBeck/junit.git</developerConnection>
  44 + <url>http://github.com/KentBeck/junit/tree/master</url>
  45 + </scm>
  46 + <developers>
  47 + <developer>
  48 + <id>dsaff</id>
  49 + <name>David Saff</name>
  50 + <email>david@saff.net</email>
  51 + </developer>
  52 + </developers>
13 53 </project>
84 doc/ReleaseNotes4.10.md
Source Rendered
... ... @@ -0,0 +1,84 @@
  1 +## Summary of Changes in version 4.10 ##
  2 +
  3 +Thanks to a full cast of contributors of bug fixes and new features.
  4 +
  5 +A full summary of commits between 4.9 and 4.10 is on [github](https://github.com/KentBeck/junit/compare/r4.9...4.10)
  6 +
  7 +### junit-dep has correct contents ###
  8 +
  9 +junit-dep-4.9.jar incorrectly contained hamcrest classes, which could lead to version conflicts in projects that depend on hamcrest directly. This is fixed in 4.10 [@dsaff, closing gh-309]
  10 +
  11 +### RuleChain ###
  12 +
  13 +The RuleChain rule allows ordering of TestRules:
  14 +
  15 + public static class UseRuleChain {
  16 + @Rule
  17 + public TestRule chain= RuleChain
  18 + .outerRule(new LoggingRule("outer rule")
  19 + .around(new LoggingRule("middle rule")
  20 + .around(new LoggingRule("inner rule");
  21 +
  22 + @Test
  23 + public void example() {
  24 + assertTrue(true);
  25 + }
  26 + }
  27 +
  28 +writes the log
  29 +
  30 + starting outer rule
  31 + starting middle rule
  32 + starting inner rule
  33 + finished inner rule
  34 + finished middle rule
  35 + finished outer rule
  36 +
  37 +### TemporaryFolder ###
  38 +
  39 +- `TemporaryFolder#newFolder(String... folderNames)` creates recursively deep temporary folders
  40 + [@rodolfoliviero, closing gh-283]
  41 +- `TemporaryFolder#newFile()` creates a randomly named new file, and `#newFolder()` creates a randomly named new folder
  42 + [@Daniel Rothmaler, closing gh-299]
  43 +
  44 +### Theories ###
  45 +
  46 +The `Theories` runner does not anticipate theory parameters that have generic
  47 +types, as reported by github#64. Fixing this won't happen until `Theories` is
  48 +moved to junit-contrib. In anticipation of this, 4.9.1 adds some of the
  49 +necessary machinery to the runner classes, and deprecates a method that only
  50 +the `Theories` runner uses, `FrameworkMethod`#producesType().
  51 +The Common Public License that JUnit is released under is now included
  52 +in the source repository.
  53 +
  54 +Thanks to `@pholser` for identifying a potential resolution for github#64
  55 +and initiating work on it.
  56 +
  57 +### Bug fixes ###
  58 +
  59 +- Built-in Rules implementations
  60 + - TemporaryFolder should not create files in the current working directory if applying the rule fails
  61 + [@orfjackal, fixing gh-278]
  62 + - TestWatcher and TestWatchman should not call failed for AssumptionViolatedExceptions
  63 + [@stefanbirkner, fixing gh-296]
  64 +- Javadoc bugs
  65 + - Assert documentation [@stefanbirkner, fixing gh-134]
  66 + - ClassRule [@stefanbirkner, fixing gh-254]
  67 + - Parameterized [@stefanbirkner, fixing gh-89]
  68 + - Parameterized, again [@orfjackal, fixing gh-285]
  69 +- Miscellaneous
  70 + - Useless code in RunAfters [@stefanbirkner, fixing gh-289]
  71 + - Parameterized test classes should be able to have `@Category` annotations
  72 + [@dsaff, fixing gh-291]
  73 + - Error count should be initialized in junit.tests.framework.TestListenerTest [@stefanbirkner, fixing gh-225]
  74 + - AssertionFailedError constructor shouldn't call super with null message [@stefanbirkner, fixing gh-318]
  75 + - Clearer error message for non-static inner test classes [@stefanbirkner, fixing gh-42]
  76 +
  77 +### Minor changes ###
  78 +
  79 +- Description, Result and Failure are Serializable [@ephox-rob, closing gh-101]
  80 +- FailOnTimeout is reusable, allowing for retrying Rules [@stefanbirkner, closing gh-265]
  81 +- New `ErrorCollector.checkThat` overload, that allows you to specify a reason [@drothmaler, closing gh-300]
  82 +
  83 +
  84 +
85 doc/ReleaseNotes4.10.txt
... ... @@ -1,84 +1 @@
1   -## Summary of Changes in version 4.10 ##
2   -
3   -Thanks to a full cast of contributors of bug fixes and new features.
4   -
5   -A full summary of commits between 4.9 and 4.10 is on [github](https://github.com/KentBeck/junit/compare/r4.9...4.10)
6   -
7   -### junit-dep has correct contents ###
8   -
9   -junit-dep-4.9.jar incorrectly contained hamcrest classes, which could lead to version conflicts in projects that depend on hamcrest directly. This is fixed in 4.10 [@dsaff, closing gh-309]
10   -
11   -### RuleChain ###
12   -
13   -The RuleChain rule allows ordering of TestRules:
14   -
15   - public static class UseRuleChain {
16   - @Rule
17   - public TestRule chain= RuleChain
18   - .outerRule(new LoggingRule("outer rule")
19   - .around(new LoggingRule("middle rule")
20   - .around(new LoggingRule("inner rule");
21   -
22   - @Test
23   - public void example() {
24   - assertTrue(true);
25   - }
26   - }
27   -
28   -writes the log
29   -
30   - starting outer rule
31   - starting middle rule
32   - starting inner rule
33   - finished inner rule
34   - finished middle rule
35   - finished outer rule
36   -
37   -### TemporaryFolder ###
38   -
39   -- `TemporaryFolder#newFolder(String... folderNames)` creates recursively deep temporary folders
40   - [@rodolfoliviero, closing gh-283]
41   -- `TemporaryFolder#newFile()` creates a randomly named new file, and `#newFolder()` creates a randomly named new folder
42   - [@Daniel Rothmaler, closing gh-299]
43   -
44   -### Theories ###
45   -
46   -The `Theories` runner does not anticipate theory parameters that have generic
47   -types, as reported by github#64. Fixing this won't happen until `Theories` is
48   -moved to junit-contrib. In anticipation of this, 4.9.1 adds some of the
49   -necessary machinery to the runner classes, and deprecates a method that only
50   -the `Theories` runner uses, `FrameworkMethod`#producesType().
51   -The Common Public License that JUnit is released under is now included
52   -in the source repository.
53   -
54   -Thanks to `@pholser` for identifying a potential resolution for github#64
55   -and initiating work on it.
56   -
57   -### Bug fixes ###
58   -
59   -- Built-in Rules implementations
60   - - TemporaryFolder should not create files in the current working directory if applying the rule fails
61   - [@orfjackal, fixing gh-278]
62   - - TestWatcher and TestWatchman should not call failed for AssumptionViolatedExceptions
63   - [@stefanbirkner, fixing gh-296]
64   -- Javadoc bugs
65   - - Assert documentation [@stefanbirkner, fixing gh-134]
66   - - ClassRule [@stefanbirkner, fixing gh-254]
67   - - Parameterized [@stefanbirkner, fixing gh-89]
68   - - Parameterized, again [@orfjackal, fixing gh-285]
69   -- Miscellaneous
70   - - Useless code in RunAfters [@stefanbirkner, fixing gh-289]
71   - - Parameterized test classes should be able to have `@Category` annotations
72   - [@dsaff, fixing gh-291]
73   - - Error count should be initialized in junit.tests.framework.TestListenerTest [@stefanbirkner, fixing gh-225]
74   - - AssertionFailedError constructor shouldn't call super with null message [@stefanbirkner, fixing gh-318]
75   - - Clearer error message for non-static inner test classes [@stefanbirkner, fixing gh-42]
76   -
77   -### Minor changes ###
78   -
79   -- Description, Result and Failure are Serializable [@ephox-rob, closing gh-101]
80   -- FailOnTimeout is reusable, allowing for retrying Rules [@stefanbirkner, closing gh-265]
81   -- New `ErrorCollector.checkThat` overload, that allows you to specify a reason [@drothmaler, closing gh-300]
82   -
83   -
84   -
  1 +Please see ReleaseNotes4.10.md
121 doc/ReleaseNotes4.11.html
... ... @@ -1 +1,120 @@
1   -<h2>Summary of Changes in version 4.11 [unreleased!]</h2>
  1 +<h2>Summary of changes in version 4.11 [unreleased!]</h2>
  2 +
  3 +<h3>Matchers: Upgrade to Hamcrest 1.3</h3>
  4 +
  5 +<p>JUnit now uses the latest version of Hamcrest. Thus, you can use all the available matchers and benefit from an improved <code>assertThat</code> which will now print the mismatch description from the matcher when an assertion fails.</p>
  6 +
  7 +<h4>Example</h4>
  8 +
  9 +<pre><code>assertThat(Long.valueOf(1), instanceOf(Integer.class));
  10 +</code></pre>
  11 +
  12 +<p>Old error message:</p>
  13 +
  14 +<pre><code>Expected: an instance of java.lang.Integer
  15 + got: &lt;1L&gt;
  16 +</code></pre>
  17 +
  18 +<p>New error message:</p>
  19 +
  20 +<pre><code>Expected: an instance of java.lang.Integer
  21 + but: &lt;1L&gt; is a java.lang.Long
  22 +</code></pre>
  23 +
  24 +<p>Hamcrest's new <code>FeatureMatcher</code> makes writing custom matchers that make use of custom mismatch descriptions quite easy:</p>
  25 +
  26 +<pre><code>@Test
  27 +public void featureMatcher() throws Exception {
  28 + assertThat("Hello World!", length(is(0)));
  29 +}
  30 +
  31 +private Matcher&lt;String&gt; length(Matcher&lt;? super Integer&gt; matcher) {
  32 + return new FeatureMatcher&lt;String, Integer&gt;(matcher, "a String of length that", "length") {
  33 + @Override
  34 + protected Integer featureValueOf(String actual) {
  35 + return actual.length();
  36 + }
  37 + };
  38 +}
  39 +</code></pre>
  40 +
  41 +<p>Running this test will return the following failure message:</p>
  42 +
  43 +<pre><code>Expected: a String of length that is &lt;0&gt;
  44 + but: length was &lt;12&gt;
  45 +</code></pre>
  46 +
  47 +<p>Most of the matchers in <code>JUnitMatchers</code> have been deprecated. Please use <code>org.hamcrest.CoreMatchers</code> directly.</p>
  48 +
  49 +<h3>Parameterized Tests</h3>
  50 +
  51 +<p>In order to easily identify the individual test cases in a Parameterized test, you may provide a name using the <code>@Parameters</code> annotation. This name is allowed to contain placeholders that are replaced at runtime:</p>
  52 +
  53 +<ul>
  54 +<li><code>{index}</code>: the current parameter index</li>
  55 +<li><code>{0}</code>, <code>{1}</code>, …: the first, second, and so on, parameter value</li>
  56 +</ul>
  57 +
  58 +<h4>Example</h4>
  59 +
  60 +<pre><code>@RunWith(Parameterized.class)
  61 +public class FibonacciTest {
  62 +
  63 + @Parameters(name = "{index}: fib({0})={1}")
  64 + public static Iterable&lt;Object[]&gt; data() {
  65 + return Arrays.asList(new Object[][] { { 0, 0 }, { 1, 1 }, { 2, 1 },
  66 + { 3, 2 }, { 4, 3 }, { 5, 5 }, { 6, 8 } });
  67 + }
  68 +
  69 + private int input;
  70 + private int expected;
  71 +
  72 + public FibonacciTest(int input, int expected) {
  73 + this.input = input;
  74 + this.expected = expected;
  75 + }
  76 +
  77 + @Test
  78 + public void test() {
  79 + assertEquals(expected, Fibonacci.compute(input));
  80 + }
  81 +}
  82 +</code></pre>
  83 +
  84 +<p>In the example given above, the <code>Parameterized</code> runner creates names like <code>[1: fib(3)=2]</code>. If you don't specify a name, the current parameter index will be used by default.</p>
  85 +
  86 +<h3>Test execution order</h3>
  87 +
  88 +<p>By design, JUnit does not specify the execution order of test method invocations. Until now, the methods were simply invoked in the order returned by the reflection API. However, using the JVM order is unwise since the Java platform does not specify any particular order, and in fact JDK 7 returns a more or less random order. Of course, well-written test code would not assume any order, but some does, and a predictable failure is better than a random failure on certain platforms.</p>
  89 +
  90 +<p>From now on, JUnit will by default use a deterministic, but not predictable, order (<code>MethodSorters.DEFAULT</code>). To change the test execution order simply annotate your test class using <code>@FixMethodOrder</code> and specify one of the available <code>MethodSorters</code>:</p>
  91 +
  92 +<ul>
  93 +<li><p><code>@FixMethodOrder(MethodSorters.JVM)</code>: Leaves the test methods in the order returned by the JVM. This order may vary from run to run.</p></li>
  94 +<li><p><code>@FixMethodOrder(MethodSorters.NAME_ASCENDING)</code>: Sorts the test methods by method name, in lexicographic order.</p></li>
  95 +</ul>
  96 +
  97 +<h3>Maven artifacts</h3>
  98 +
  99 +<p>Up until now there were two Maven artifacts for JUnit: <code>junit:junit-dep</code> and <code>junit:junit</code>. From a Maven point-of-view only the former made sense because it did not contain the Hamcrest classes but declared a dependency to the Hamcrest Maven artifact. The latter included the Hamcrest classes which was very un-Maven-like.</p>
  100 +
  101 +<p>From this release on, you should use <code>junit:junit</code> which will be what <code>junit:junit-dep</code> used to. If you still reference <code>junit:junit-dep</code>, Maven will automatically relocate you to the new <code>junit:junit</code> and issue a warning for you to fix.</p>
  102 +
  103 +<h3>Rules</h3>
  104 +
  105 +<p>A number of improvements have been made to Rules:</p>
  106 +
  107 +<ul>
  108 +<li>Both <code>@Rule</code> and <code>@ClassRule</code> can now be used on methods that return a <code>TestRule</code>.</li>
  109 +<li><code>ExpectedException</code> now always prints the stacktrace of the actual exception in case of failure.</li>
  110 +<li>A parent folder can be specified for <code>TemporaryFolder</code>. In addition, the <code>newFile</code>/<code>newFolder</code> methods will now fail when the file or folder could not be created.</li>
  111 +<li><code>TestWatcher</code> has a new template method called <code>skipped</code> that is invoked when a test is skipped due to a failed assumption.</li>
  112 +</ul>
  113 +
  114 +<h3>Improvements to Assert and Assume</h3>
  115 +
  116 +<ul>
  117 +<li><code>assertNotEquals</code> has been added to <code>Assert</code>.</li>
  118 +<li><code>assertEquals</code> has been overloaded in order to check whether two floats are equal given a certain float delta.</li>
  119 +<li>Most methods in <code>Assume</code> now allow to pass a custom message.</li>
  120 +</ul>
109 doc/ReleaseNotes4.11.md
Source Rendered
... ... @@ -0,0 +1,109 @@
  1 +## Summary of changes in version 4.11 [unreleased!]
  2 +
  3 +### Matchers: Upgrade to Hamcrest 1.3
  4 +
  5 +JUnit now uses the latest version of Hamcrest. Thus, you can use all the available matchers and benefit from an improved `assertThat` which will now print the mismatch description from the matcher when an assertion fails.
  6 +
  7 +#### Example
  8 +
  9 + assertThat(Long.valueOf(1), instanceOf(Integer.class));
  10 +
  11 +Old error message:
  12 +
  13 + Expected: an instance of java.lang.Integer
  14 + got: <1L>
  15 +
  16 +New error message:
  17 +
  18 + Expected: an instance of java.lang.Integer
  19 + but: <1L> is a java.lang.Long
  20 +
  21 +Hamcrest's new `FeatureMatcher` makes writing custom matchers that make use of custom mismatch descriptions quite easy:
  22 +
  23 + @Test
  24 + public void featureMatcher() throws Exception {
  25 + assertThat("Hello World!", length(is(0)));
  26 + }
  27 +
  28 + private Matcher<String> length(Matcher<? super Integer> matcher) {
  29 + return new FeatureMatcher<String, Integer>(matcher, "a String of length that", "length") {
  30 + @Override
  31 + protected Integer featureValueOf(String actual) {
  32 + return actual.length();
  33 + }
  34 + };
  35 + }
  36 +
  37 +Running this test will return the following failure message:
  38 +
  39 + Expected: a String of length that is <0>
  40 + but: length was <12>
  41 +
  42 +
  43 +Most of the matchers in `JUnitMatchers` have been deprecated. Please use `org.hamcrest.CoreMatchers` directly.
  44 +
  45 +### Parameterized Tests
  46 +
  47 +In order to easily identify the individual test cases in a Parameterized test, you may provide a name using the `@Parameters` annotation. This name is allowed to contain placeholders that are replaced at runtime:
  48 +
  49 +* `{index}`: the current parameter index
  50 +* `{0}`, `{1}`, …: the first, second, and so on, parameter value
  51 +
  52 +#### Example
  53 +
  54 + @RunWith(Parameterized.class)
  55 + public class FibonacciTest {
  56 +
  57 + @Parameters(name = "{index}: fib({0})={1}")
  58 + public static Iterable<Object[]> data() {
  59 + return Arrays.asList(new Object[][] { { 0, 0 }, { 1, 1 }, { 2, 1 },
  60 + { 3, 2 }, { 4, 3 }, { 5, 5 }, { 6, 8 } });
  61 + }
  62 +
  63 + private int input;
  64 + private int expected;
  65 +
  66 + public FibonacciTest(int input, int expected) {
  67 + this.input = input;
  68 + this.expected = expected;
  69 + }
  70 +
  71 + @Test
  72 + public void test() {
  73 + assertEquals(expected, Fibonacci.compute(input));
  74 + }
  75 + }
  76 +
  77 +In the example given above, the `Parameterized` runner creates names like `[1: fib(3)=2]`. If you don't specify a name, the current parameter index will be used by default.
  78 +
  79 +### Test execution order
  80 +
  81 +By design, JUnit does not specify the execution order of test method invocations. Until now, the methods were simply invoked in the order returned by the reflection API. However, using the JVM order is unwise since the Java platform does not specify any particular order, and in fact JDK 7 returns a more or less random order. Of course, well-written test code would not assume any order, but some does, and a predictable failure is better than a random failure on certain platforms.
  82 +
  83 +From now on, JUnit will by default use a deterministic, but not predictable, order (`MethodSorters.DEFAULT`). To change the test execution order simply annotate your test class using `@FixMethodOrder` and specify one of the available `MethodSorters`:
  84 +
  85 +* `@FixMethodOrder(MethodSorters.JVM)`: Leaves the test methods in the order returned by the JVM. This order may vary from run to run.
  86 +
  87 +* `@FixMethodOrder(MethodSorters.NAME_ASCENDING)`: Sorts the test methods by method name, in lexicographic order.
  88 +
  89 +### Maven artifacts
  90 +
  91 +Up until now there were two Maven artifacts for JUnit: `junit:junit-dep` and `junit:junit`. From a Maven point-of-view only the former made sense because it did not contain the Hamcrest classes but declared a dependency to the Hamcrest Maven artifact. The latter included the Hamcrest classes which was very un-Maven-like.
  92 +
  93 +From this release on, you should use `junit:junit` which will be what `junit:junit-dep` used to. If you still reference `junit:junit-dep`, Maven will automatically relocate you to the new `junit:junit` and issue a warning for you to fix.
  94 +
  95 +### Rules
  96 +
  97 +A number of improvements have been made to Rules:
  98 +
  99 +* Both `@Rule` and `@ClassRule` can now be used on methods that return a `TestRule`.
  100 +* `ExpectedException` now always prints the stacktrace of the actual exception in case of failure.
  101 +* A parent folder can be specified for `TemporaryFolder`. In addition, the `newFile`/`newFolder` methods will now fail when the file or folder could not be created.
  102 +* `TestWatcher` has a new template method called `skipped` that is invoked when a test is skipped due to a failed assumption.
  103 +
  104 +### Improvements to Assert and Assume
  105 +
  106 +* `assertNotEquals` has been added to `Assert`.
  107 +* `assertEquals` has been overloaded in order to check whether two floats are equal given a certain float delta.
  108 +* Most methods in `Assume` now allow to pass a custom message.
  109 +
2  doc/ReleaseNotes4.11.txt
... ... @@ -1 +1 @@
1   -## Summary of Changes in version 4.11 [unreleased!] ##
  1 +Please see ReleaseNotes4.11.md
295 doc/ReleaseNotes4.4.md
Source Rendered
... ... @@ -0,0 +1,295 @@
  1 +## Summary of Changes in version 4.5 ##
  2 +
  3 +### Categories ###
  4 +Each test method and test class can be annotated as belonging to a _category_:
  5 +
  6 + public static class SomeUITests {
  7 + @Category(UserAvailable.class)
  8 + @Test
  9 + public void askUserToPressAKey() { }
  10 +
  11 + @Test
  12 + public void simulatePressingKey() { }
  13 + }
  14 +
  15 + @Category(InternetConnected.class)
  16 + public static class InternetTests {
  17 + @Test
  18 + public void pingServer() { }
  19 + }
  20 +
  21 +To run all of the tests in a particular category, you must currently explicitly create a custom request:
  22 +
  23 + new JUnitCore().run(Request.aClass(SomeUITests.class).inCategories(UserAvailable.class));
  24 +
  25 +This feature will very likely be improved before the final release of JUnit 4.5
  26 +
  27 +### Theories ###
  28 +
  29 +- `@Before` and `@After` methods are run before and after each set of attempted parameters
  30 + on a Theory, and each set of parameters is run on a new instance of the test class.
  31 +
  32 +- Exposed API's `ParameterSignature.getType()` and `ParameterSignature.getAnnotations()`
  33 +
  34 +- An array of data points can be introduced by a field or method marked with the new annotation `@DataPoints`
  35 +
  36 +- The Theories custom runner has been refactored to make it easier to extend
  37 +
  38 +### JUnit 4 Runner API ###
  39 +
  40 +- There has been a drastic rewrite of the API for custom Runners in 4.5. This
  41 + needs to be written up separately before release.
  42 +
  43 +- Tests with failed assumptions are now marked as Ignored, rather than silently passing.
  44 + This may change behavior in some client tests, and also will require some new support
  45 + on the part of IDE's.
  46 +
  47 +## Summary of Changes in version 4.4 ##
  48 +
  49 +JUnit is designed to efficiently capture developers' intentions about
  50 +their code, and quickly check their code matches those intentions.
  51 +Over the last year, we've been talking about what things developers
  52 +would like to say about their code that have been difficult in the
  53 +past, and how we can make them easier.
  54 +
  55 +[Download][]
  56 +
  57 +[Download]: http://sourceforge.net/project/showfiles.php?group_id=15278
  58 +
  59 +### assertThat ###
  60 +
  61 +Two years ago, Joe Walnes built a [new assertion mechanism][walnes] on top of what was
  62 +then [JMock 1][]. The method name was `assertThat`, and the syntax looked like this:
  63 +
  64 +[walnes]: http://joe.truemesh.com/blog/000511.html
  65 +[JMock 1]: http://www.jmock.org/download.html
  66 +
  67 + assertThat(x, is(3));
  68 + assertThat(x, is(not(4)));
  69 + assertThat(responseString, either(containsString("color")).or(containsString("colour")));
  70 + assertThat(myList, hasItem("3"));
  71 +
  72 +More generally:
  73 +
  74 + assertThat([value], [matcher statement]);
  75 +
  76 +Advantages of this assertion syntax include:
  77 +
  78 +- More readable and typeable: this syntax allows you to think in terms of subject, verb, object
  79 + (assert "x is 3") rather than `assertEquals`, which uses verb, object, subject (assert "equals 3 x")
  80 +
  81 +- Combinations: any matcher statement `s` can be negated (`not(s)`), combined (`either(s).or(t)`),
  82 + mapped to a collection (`each(s)`), or used in custom combinations (`afterFiveSeconds(s)`)
  83 +
  84 +- Readable failure messages. Compare
  85 +
  86 + assertTrue(responseString.contains("color") || responseString.contains("colour"));
  87 + // ==> failure message:
  88 + // java.lang.AssertionError:
  89 +
  90 + assertThat(responseString, anyOf(containsString("color"), containsString("colour")));
  91 + // ==> failure message:
  92 + // java.lang.AssertionError:
  93 + // Expected: (a string containing "color" or a string containing "colour")
  94 + // got: "Please choose a font"
  95 +
  96 +- Custom Matchers. By implementing the `Matcher` interface yourself, you can get all of the
  97 + above benefits for your own custom assertions.
  98 +
  99 +- For a more thorough description of these points, see [Joe Walnes's
  100 + original post][walnes].
  101 +
  102 +We have decided to include this API directly in JUnit.
  103 +It's an extensible and readable syntax, and it enables
  104 +new features, like [assumptions][] and [theories][].
  105 +
  106 +[assumptions]: #assumptions
  107 +[theories]: #theories
  108 +
  109 +Some notes:
  110 +
  111 +- The old assert methods are never, ever, going away. Developers may
  112 + continue using the old `assertEquals`, `assertTrue`, and so on.
  113 +- The second parameter of an `assertThat` statement is a `Matcher`.
  114 + We include the Matchers we want as static imports, like this:
  115 +
  116 + import static org.hamcrest.CoreMatchers.is;
  117 +
  118 + or:
  119 +
  120 + import static org.hamcrest.CoreMatchers.*;
  121 +
  122 +- Manually importing `Matcher` methods can be frustrating. [Eclipse 3.3][] includes the ability to
  123 + define
  124 + "Favorite" classes to import static methods from, which makes it easier
  125 + (Search for "Favorites" in the Preferences dialog).
  126 + We expect that support for static imports will improve in all Java IDEs in the future.
  127 +
  128 +[Eclipse 3.3]: http://www.eclipse.org/downloads/
  129 +
  130 +- To allow compatibility with a wide variety of possible matchers,
  131 + we have decided to include the classes from hamcrest-core,
  132 + from the [Hamcrest][] project. This is the first time that
  133 + third-party classes have been included in JUnit.
  134 +
  135 +[Hamcrest]: http://code.google.com/p/hamcrest/
  136 +
  137 +- JUnit currently ships with a few matchers, defined in
  138 + `org.hamcrest.CoreMatchers` and `org.junit.matchers.JUnitMatchers`.
  139 + To use many, many more, consider downloading the [full hamcrest package][].
  140 +
  141 +[full hamcrest package]: http://hamcrest.googlecode.com/files/hamcrest-all-1.1.jar
  142 +
  143 +- JUnit contains special support for comparing string and array
  144 + values, giving specific information on how they differ. This is not
  145 + yet available using the `assertThat` syntax, but we hope to bring
  146 + the two assert methods into closer alignment in future releases.
  147 +
  148 +<a name="assumptions" />
  149 +### Assumptions ###
  150 +
  151 +Ideally, the developer writing a test has control of all of the forces that might cause a test to fail.
  152 +If this isn't immediately possible, making dependencies explicit can often improve a design.
  153 +For example, if a test fails when run in a different locale than the developer intended,
  154 +it can be fixed by explicitly passing a locale to the domain code.
  155 +
  156 +However, sometimes this is not desirable or possible.
  157 +It's good to be able to run a test against the code as it is currently written,
  158 +implicit assumptions and all, or to write a test that exposes a known bug.
  159 +For these situations, JUnit now includes the ability to express "assumptions":
  160 +
  161 + import static org.junit.Assume.*
  162 +
  163 + @Test public void filenameIncludesUsername() {
  164 + assumeThat(File.separatorChar, is('/'));
  165 + assertThat(new User("optimus").configFileName(), is("configfiles/optimus.cfg"));
  166 + }
  167 +
  168 + @Test public void correctBehaviorWhenFilenameIsNull() {
  169 + assumeTrue(bugFixed("13356")); // bugFixed is not included in JUnit
  170 + assertThat(parse(null), is(new NullDocument()));
  171 + }
  172 +
  173 +With this release, a failed assumption will lead to the test being marked as passing,
  174 +regardless of what the code below the assumption may assert.
  175 +In the future, this may change, and a failed assumption may lead to the test being ignored:
  176 +however, third-party runners do not currently allow this option.
  177 +
  178 +We have included `assumeTrue` for convenience, but thanks to the
  179 +inclusion of Hamcrest, we do not need to create `assumeEquals`,
  180 +`assumeSame`, and other analogues to the `assert*` methods. All of
  181 +those functionalities are subsumed in `assumeThat`, with the appropriate
  182 +matcher.
  183 +
  184 +A failing assumption in a `@Before` or `@BeforeClass` method will have the same effect
  185 +as a failing assumption in each `@Test` method of the class.
  186 +
  187 +<a name="theories" />
  188 +### Theories ###
  189 +
  190 +More flexible and expressive assertions, combined with the ability to
  191 +state assumptions clearly, lead to a new kind of statement of intent,
  192 +which we call a "Theory". A test captures the intended behavior in
  193 +one particular scenario. A theory captures some aspect of the
  194 +intended behavior in possibly
  195 +infinite numbers of potential scenarios. For example:
  196 +
  197 + @RunWith(Theories.class)
  198 + public class UserTest {
  199 + @DataPoint public static String GOOD_USERNAME = "optimus";
  200 + @DataPoint public static String USERNAME_WITH_SLASH = "optimus/prime";
  201 +
  202 + @Theory public void filenameIncludesUsername(String username) {
  203 + assumeThat(username, not(containsString("/")));
  204 + assertThat(new User(username).configFileName(), containsString(username));
  205 + }
  206 + }
  207 +
  208 +This makes it clear that the user's filename should be included in the
  209 +config file name, only if it doesn't contain a slash. Another test
  210 +or theory might define what happens when a username does contain a slash.
  211 +
  212 +`UserTest` will attempt to run `filenameIncludesUsername` on
  213 +every compatible `DataPoint` defined in the class. If any of the
  214 +assumptions fail, the data point is silently ignored. If all of the
  215 +assumptions pass, but an assertion fails, the test fails.
  216 +
  217 +The support for Theories has been absorbed from the [Popper][]
  218 +project, and [more complete documentation][popper-docs] can be found
  219 +there.
  220 +
  221 +[Popper]: http://popper.tigris.org
  222 +[popper-docs]: http://popper.tigris.org/tutorial.html
  223 +
  224 +Defining general statements in this way can jog the developer's memory
  225 +about other potential data points and tests, also allows [automated
  226 +tools][junit-factory] to [search][my-blog] for new, unexpected data
  227 +points that expose bugs.
  228 +
  229 +[junit-factory]: http://www.junitfactory.org
  230 +[my-blog]: http://shareandenjoy.saff.net/2007/04/popper-and-junitfactory.html
  231 +
  232 +### Other changes ###
  233 +
  234 +This release contains other bug fixes and new features. Among them:
  235 +
  236 +- Annotated descriptions
  237 +
  238 + Runner UIs, Filters, and Sorters operate on Descriptions of test
  239 + methods and test classes. These Descriptions now include the
  240 + annotations on the original Java source element, allowing for richer
  241 + display of test results, and easier development of annotation-based
  242 + filters.
  243 +
  244 +- Bug fix (1715326): assertEquals now compares all Numbers using their
  245 + native implementation of `equals`. This assertion, which passed in
  246 + 4.3, will now fail:
  247 +
  248 + assertEquals(new Integer(1), new Long(1));
  249 +
  250 + Non-integer Numbers (Floats, Doubles, BigDecimals, etc),
  251 + which were compared incorrectly in 4.3, are now fixed.
  252 +
  253 +- `assertEquals(long, long)` and `assertEquals(double, double)` have
  254 + been re-introduced to the `Assert` class, to take advantage of
  255 + Java's native widening conversions. Therefore, this still passes:
  256 +
  257 + assertEquals(1, 1L);
  258 +
  259 +- The default runner for JUnit 4 test classes has been refactored.
  260 + The old version was named `TestClassRunner`, and the new is named
  261 + `JUnit4ClassRunner`. Likewise, `OldTestClassRunner` is now
  262 + `JUnit3ClassRunner`. The new design allows variations in running
  263 + individual test classes to be expressed with fewer custom classes.
  264 + For a good example, see the source to
  265 + `org.junit.experimental.theories.Theories`.
  266 +
  267 +- The rules for determining which runner is applied by default to a
  268 + test class have been simplified:
  269 +
  270 + 1. If the class has a `@RunWith` annotation, the annotated runner
  271 + class is used.
  272 +
  273 + 2. If the class can be run with the JUnit 3 test runner (it
  274 + subclasses `TestCase`, or contains a `public static Test suite()`
  275 + method), JUnit38ClassRunner is used.
  276 +
  277 + 3. Otherwise, JUnit4ClassRunner is used.
  278 +
  279 + This default guess can always be overridden by an explicit
  280 + `@RunWith(JUnit4ClassRunner.class)` or
  281 + `@RunWith(JUnit38ClassRunner.class)` annotation.
  282 +
  283 + The old class names `TestClassRunner` and `OldTestClassRunner`
  284 + remain as deprecated.
  285 +
  286 +- Bug fix (1739095): Filters and Sorters work correctly on test
  287 + classes that contain a `suite` method like:
  288 +
  289 + public static junit.framework.Test suite() {
  290 + return new JUnit4TestAdapter(MyTest.class);
  291 + }
  292 +
  293 +- Bug fix (1745048): @After methods are now correctly called
  294 + after a test method times out.
  295 +
296 doc/ReleaseNotes4.4.txt
... ... @@ -1,295 +1 @@
1   -## Summary of Changes in version 4.5 ##
2   -
3   -### Categories ###
4   -Each test method and test class can be annotated as belonging to a _category_:
5   -
6   - public static class SomeUITests {
7   - @Category(UserAvailable.class)
8   - @Test
9   - public void askUserToPressAKey() { }
10   -
11   - @Test
12   - public void simulatePressingKey() { }
13   - }
14   -
15   - @Category(InternetConnected.class)
16   - public static class InternetTests {
17   - @Test
18   - public void pingServer() { }
19   - }
20   -
21   -To run all of the tests in a particular category, you must currently explicitly create a custom request:
22   -
23   - new JUnitCore().run(Request.aClass(SomeUITests.class).inCategories(UserAvailable.class));
24   -
25   -This feature will very likely be improved before the final release of JUnit 4.5
26   -
27   -### Theories ###
28   -
29   -- `@Before` and `@After` methods are run before and after each set of attempted parameters
30   - on a Theory, and each set of parameters is run on a new instance of the test class.
31   -
32   -- Exposed API's `ParameterSignature.getType()` and `ParameterSignature.getAnnotations()`
33   -
34   -- An array of data points can be introduced by a field or method marked with the new annotation `@DataPoints`
35   -
36   -- The Theories custom runner has been refactored to make it easier to extend
37   -
38   -### JUnit 4 Runner API ###
39   -
40   -- There has been a drastic rewrite of the API for custom Runners in 4.5. This
41   - needs to be written up separately before release.
42   -
43   -- Tests with failed assumptions are now marked as Ignored, rather than silently passing.
44   - This may change behavior in some client tests, and also will require some new support
45   - on the part of IDE's.
46   -
47   -## Summary of Changes in version 4.4 ##
48   -
49   -JUnit is designed to efficiently capture developers' intentions about
50   -their code, and quickly check their code matches those intentions.
51   -Over the last year, we've been talking about what things developers
52   -would like to say about their code that have been difficult in the
53   -past, and how we can make them easier.
54   -
55   -[Download][]
56   -
57   -[Download]: http://sourceforge.net/project/showfiles.php?group_id=15278
58   -
59   -### assertThat ###
60   -
61   -Two years ago, Joe Walnes built a [new assertion mechanism][walnes] on top of what was
62   -then [JMock 1][]. The method name was `assertThat`, and the syntax looked like this:
63   -
64   -[walnes]: http://joe.truemesh.com/blog/000511.html
65   -[JMock 1]: http://www.jmock.org/download.html
66   -
67   - assertThat(x, is(3));
68   - assertThat(x, is(not(4)));
69   - assertThat(responseString, either(containsString("color")).or(containsString("colour")));
70   - assertThat(myList, hasItem("3"));
71   -
72   -More generally:
73   -
74   - assertThat([value], [matcher statement]);
75   -
76   -Advantages of this assertion syntax include:
77   -
78   -- More readable and typeable: this syntax allows you to think in terms of subject, verb, object
79   - (assert "x is 3") rather than `assertEquals`, which uses verb, object, subject (assert "equals 3 x")
80   -
81   -- Combinations: any matcher statement `s` can be negated (`not(s)`), combined (`either(s).or(t)`),
82   - mapped to a collection (`each(s)`), or used in custom combinations (`afterFiveSeconds(s)`)
83   -
84   -- Readable failure messages. Compare
85   -
86   - assertTrue(responseString.contains("color") || responseString.contains("colour"));
87   - // ==> failure message:
88   - // java.lang.AssertionError:
89   -
90   - assertThat(responseString, anyOf(containsString("color"), containsString("colour")));
91   - // ==> failure message:
92   - // java.lang.AssertionError:
93   - // Expected: (a string containing "color" or a string containing "colour")
94   - // got: "Please choose a font"
95   -
96   -- Custom Matchers. By implementing the `Matcher` interface yourself, you can get all of the
97   - above benefits for your own custom assertions.
98   -
99   -- For a more thorough description of these points, see [Joe Walnes's
100   - original post][walnes].
101   -
102   -We have decided to include this API directly in JUnit.
103   -It's an extensible and readable syntax, and it enables
104   -new features, like [assumptions][] and [theories][].
105   -
106   -[assumptions]: #assumptions
107   -[theories]: #theories
108   -
109   -Some notes:
110   -
111   -- The old assert methods are never, ever, going away. Developers may
112   - continue using the old `assertEquals`, `assertTrue`, and so on.
113   -- The second parameter of an `assertThat` statement is a `Matcher`.
114   - We include the Matchers we want as static imports, like this:
115   -
116   - import static org.hamcrest.CoreMatchers.is;
117   -
118   - or:
119   -
120   - import static org.hamcrest.CoreMatchers.*;
121   -
122   -- Manually importing `Matcher` methods can be frustrating. [Eclipse 3.3][] includes the ability to
123   - define
124   - "Favorite" classes to import static methods from, which makes it easier
125   - (Search for "Favorites" in the Preferences dialog).
126   - We expect that support for static imports will improve in all Java IDEs in the future.
127   -
128   -[Eclipse 3.3]: http://www.eclipse.org/downloads/
129   -
130   -- To allow compatibility with a wide variety of possible matchers,
131   - we have decided to include the classes from hamcrest-core,
132   - from the [Hamcrest][] project. This is the first time that
133   - third-party classes have been included in JUnit.
134   -
135   -[Hamcrest]: http://code.google.com/p/hamcrest/
136   -
137   -- JUnit currently ships with a few matchers, defined in
138   - `org.hamcrest.CoreMatchers` and `org.junit.matchers.JUnitMatchers`.
139   - To use many, many more, consider downloading the [full hamcrest package][].
140   -
141   -[full hamcrest package]: http://hamcrest.googlecode.com/files/hamcrest-all-1.1.jar
142   -
143   -- JUnit contains special support for comparing string and array
144   - values, giving specific information on how they differ. This is not
145   - yet available using the `assertThat` syntax, but we hope to bring
146   - the two assert methods into closer alignment in future releases.
147   -
148   -<a name="assumptions" />
149   -### Assumptions ###
150   -
151   -Ideally, the developer writing a test has control of all of the forces that might cause a test to fail.
152   -If this isn't immediately possible, making dependencies explicit can often improve a design.
153   -For example, if a test fails when run in a different locale than the developer intended,
154   -it can be fixed by explicitly passing a locale to the domain code.
155   -
156   -However, sometimes this is not desirable or possible.
157   -It's good to be able to run a test against the code as it is currently written,
158   -implicit assumptions and all, or to write a test that exposes a known bug.
159   -For these situations, JUnit now includes the ability to express "assumptions":
160   -
161   - import static org.junit.Assume.*
162   -
163   - @Test public void filenameIncludesUsername() {
164   - assumeThat(File.separatorChar, is('/'));
165   - assertThat(new User("optimus").configFileName(), is("configfiles/optimus.cfg"));
166   - }
167   -
168   - @Test public void correctBehaviorWhenFilenameIsNull() {
169   - assumeTrue(bugFixed("13356")); // bugFixed is not included in JUnit
170   - assertThat(parse(null), is(new NullDocument()));
171   - }
172   -
173   -With this release, a failed assumption will lead to the test being marked as passing,
174   -regardless of what the code below the assumption may assert.
175   -In the future, this may change, and a failed assumption may lead to the test being ignored:
176   -however, third-party runners do not currently allow this option.
177   -
178   -We have included `assumeTrue` for convenience, but thanks to the
179   -inclusion of Hamcrest, we do not need to create `assumeEquals`,
180   -`assumeSame`, and other analogues to the `assert*` methods. All of
181   -those functionalities are subsumed in `assumeThat`, with the appropriate
182   -matcher.
183   -
184   -A failing assumption in a `@Before` or `@BeforeClass` method will have the same effect
185   -as a failing assumption in each `@Test` method of the class.
186   -
187   -<a name="theories" />
188   -### Theories ###
189   -
190   -More flexible and expressive assertions, combined with the ability to
191   -state assumptions clearly, lead to a new kind of statement of intent,
192   -which we call a "Theory". A test captures the intended behavior in
193   -one particular scenario. A theory captures some aspect of the
194   -intended behavior in possibly
195   -infinite numbers of potential scenarios. For example:
196   -
197   - @RunWith(Theories.class)
198   - public class UserTest {
199   - @DataPoint public static String GOOD_USERNAME = "optimus";
200   - @DataPoint public static String USERNAME_WITH_SLASH = "optimus/prime";
201   -
202   - @Theory public void filenameIncludesUsername(String username) {
203   - assumeThat(username, not(containsString("/")));
204   - assertThat(new User(username).configFileName(), containsString(username));
205   - }
206   - }
207   -
208   -This makes it clear that the user's filename should be included in the
209   -config file name, only if it doesn't contain a slash. Another test
210   -or theory might define what happens when a username does contain a slash.
211   -
212   -`UserTest` will attempt to run `filenameIncludesUsername` on
213   -every compatible `DataPoint` defined in the class. If any of the
214   -assumptions fail, the data point is silently ignored. If all of the
215   -assumptions pass, but an assertion fails, the test fails.
216   -
217   -The support for Theories has been absorbed from the [Popper][]
218   -project, and [more complete documentation][popper-docs] can be found
219   -there.
220   -
221   -[Popper]: http://popper.tigris.org
222   -[popper-docs]: http://popper.tigris.org/tutorial.html
223   -
224   -Defining general statements in this way can jog the developer's memory
225   -about other potential data points and tests, also allows [automated
226   -tools][junit-factory] to [search][my-blog] for new, unexpected data
227   -points that expose bugs.
228   -
229   -[junit-factory]: http://www.junitfactory.org
230   -[my-blog]: http://shareandenjoy.saff.net/2007/04/popper-and-junitfactory.html
231   -
232   -### Other changes ###
233   -
234   -This release contains other bug fixes and new features. Among them:
235   -
236   -- Annotated descriptions
237   -
238   - Runner UIs, Filters, and Sorters operate on Descriptions of test
239   - methods and test classes. These Descriptions now include the
240   - annotations on the original Java source element, allowing for richer
241   - display of test results, and easier development of annotation-based
242   - filters.
243   -
244   -- Bug fix (1715326): assertEquals now compares all Numbers using their
245   - native implementation of `equals`. This assertion, which passed in
246   - 4.3, will now fail:
247   -
248   - assertEquals(new Integer(1), new Long(1));
249   -
250   - Non-integer Numbers (Floats, Doubles, BigDecimals, etc),
251   - which were compared incorrectly in 4.3, are now fixed.
252   -
253   -- `assertEquals(long, long)` and `assertEquals(double, double)` have
254   - been re-introduced to the `Assert` class, to take advantage of
255   - Java's native widening conversions. Therefore, this still passes:
256   -
257   - assertEquals(1, 1L);
258   -
259   -- The default runner for JUnit 4 test classes has been refactored.
260   - The old version was named `TestClassRunner`, and the new is named
261   - `JUnit4ClassRunner`. Likewise, `OldTestClassRunner` is now
262   - `JUnit3ClassRunner`. The new design allows variations in running
263   - individual test classes to be expressed with fewer custom classes.
264   - For a good example, see the source to
265   - `org.junit.experimental.theories.Theories`.
266   -
267   -- The rules for determining which runner is applied by default to a
268   - test class have been simplified:
269   -
270   - 1. If the class has a `@RunWith` annotation, the annotated runner
271   - class is used.
272   -
273   - 2. If the class can be run with the JUnit 3 test runner (it
274   - subclasses `TestCase`, or contains a `public static Test suite()`
275   - method), JUnit38ClassRunner is used.
276   -
277   - 3. Otherwise, JUnit4ClassRunner is used.
278   -
279   - This default guess can always be overridden by an explicit
280   - `@RunWith(JUnit4ClassRunner.class)` or
281   - `@RunWith(JUnit38ClassRunner.class)` annotation.
282   -
283   - The old class names `TestClassRunner` and `OldTestClassRunner`
284   - remain as deprecated.
285   -
286   -- Bug fix (1739095): Filters and Sorters work correctly on test
287   - classes that contain a `suite` method like:
288   -
289   - public static junit.framework.Test suite() {
290   - return new JUnit4TestAdapter(MyTest.class);
291   - }
292   -
293   -- Bug fix (1745048): @After methods are now correctly called
294   - after a test method times out.
295   -
  1 +Please see ReleaseNotes4.4.md
96 doc/ReleaseNotes4.5.md
Source Rendered
... ... @@ -0,0 +1,96 @@
  1 +## Summary of Changes in version 4.5 ##
  2 +
  3 +### Installation ###
  4 +
  5 +- We are releasing `junit-4.5.jar`, which contains all the classes
  6 + necessary to run JUnit, and `junit-dep-4.5.jar`, which leaves out
  7 + hamcrest classes, for developers who already use hamcrest outside of
  8 + JUnit.
  9 +
  10 +### Basic JUnit operation ###
  11 +
  12 +- JUnitCore now more often exits with the correct exit code (0 for
  13 + success, 1 for failure)
  14 +
  15 +- Badly formed test classes (exceptions in constructors, classes
  16 + without tests, multiple constructors, Suite without @SuiteClasses)
  17 + produce more helpful error messages
  18 +
  19 +- Test classes whose only test methods are inherited from superclasses
  20 + now run.
  21 +
  22 +- Optimization to annotation processing can cut JUnit overhead by more than half
  23 + on large test classes, especially when using Theories. [Bug 1796847]
  24 +
  25 +- A failing assumption in a constructor ignores the class
  26 +
  27 +- Correct results when comparing the string "null" with potentially
  28 + null values. [Bug 1857283]
  29 +
  30 +- Annotating a class with `@RunWith(JUnit4.class)` will always invoke the
  31 + default JUnit 4 runner in the current version of JUnit. This default changed
  32 + from `JUnit4ClassRunner` in 4.4 to `BlockJUnit4ClassRunner` in 4.5 (see below),
  33 + and may change again.
  34 +
  35 +### Extension ###
  36 +
  37 +- `BlockJUnit4Runner` is a new implementation of the standard JUnit 4
  38 + test class functionality. In contrast to `JUnit4ClassRunner` (the old
  39 + implementation):
  40 +
  41 + - `BlockJUnit4Runner` has a much simpler implementation based on
  42 + Statements, allowing new operations to be inserted into the
  43 + appropriate point in the execution flow.
  44 +
  45 + - `BlockJUnit4Runner` is published, and extension and reuse are
  46 + encouraged, whereas `JUnit4ClassRunner` was in an internal package,
  47 + and is now deprecated.
  48 +
  49 +- `ParentRunner` is a base class for runners that iterate over
  50 + a list of "children", each an object representing a test or suite to run.
  51 + `ParentRunner` provides filtering, sorting, `@BeforeClass`, `@AfterClass`,
  52 + and method validation to subclasses.
  53 +
  54 +- `TestClass` wraps a class to be run, providing efficient, repeated access
  55 + to all methods with a given annotation.
  56 +
  57 +- The new `RunnerBuilder` API allows extending the behavior of
  58 + Suite-like custom runners.
  59 +
  60 +- `AssumptionViolatedException.toString()` is more informative
  61 +
  62 +### Extra Runners ###
  63 +
  64 +- `Parameterized.eachOne()` has been removed
  65 +
  66 +- New runner `Enclosed` runs all static inner classes of an outer class.
  67 +