Skip to content
Browse files

Change extension to .md for all release note files

Because we do not want to break any URLs pointing to the .txt files,
we keep them around but they contain nothing more but a short hint
to look at the .md ones.
  • Loading branch information...
1 parent 7bd6fa1 commit ed01efa75f5975779efc686dfa5fae52096482b2 @marcphilipp marcphilipp committed Oct 21, 2012
View
84 doc/ReleaseNotes4.10.md
@@ -0,0 +1,84 @@
+## Summary of Changes in version 4.10 ##
+
+Thanks to a full cast of contributors of bug fixes and new features.
+
+A full summary of commits between 4.9 and 4.10 is on [github](https://github.com/KentBeck/junit/compare/r4.9...4.10)
+
+### junit-dep has correct contents ###
+
+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]
+
+### RuleChain ###
+
+The RuleChain rule allows ordering of TestRules:
+
+ public static class UseRuleChain {
+ @Rule
+ public TestRule chain= RuleChain
+ .outerRule(new LoggingRule("outer rule")
+ .around(new LoggingRule("middle rule")
+ .around(new LoggingRule("inner rule");
+
+ @Test
+ public void example() {
+ assertTrue(true);
+ }
+ }
+
+writes the log
+
+ starting outer rule
+ starting middle rule
+ starting inner rule
+ finished inner rule
+ finished middle rule
+ finished outer rule
+
+### TemporaryFolder ###
+
+- `TemporaryFolder#newFolder(String... folderNames)` creates recursively deep temporary folders
+ [@rodolfoliviero, closing gh-283]
+- `TemporaryFolder#newFile()` creates a randomly named new file, and `#newFolder()` creates a randomly named new folder
+ [@Daniel Rothmaler, closing gh-299]
+
+### Theories ###
+
+The `Theories` runner does not anticipate theory parameters that have generic
+types, as reported by github#64. Fixing this won't happen until `Theories` is
+moved to junit-contrib. In anticipation of this, 4.9.1 adds some of the
+necessary machinery to the runner classes, and deprecates a method that only
+the `Theories` runner uses, `FrameworkMethod`#producesType().
+The Common Public License that JUnit is released under is now included
+in the source repository.
+
+Thanks to `@pholser` for identifying a potential resolution for github#64
+and initiating work on it.
+
+### Bug fixes ###
+
+- Built-in Rules implementations
+ - TemporaryFolder should not create files in the current working directory if applying the rule fails
+ [@orfjackal, fixing gh-278]
+ - TestWatcher and TestWatchman should not call failed for AssumptionViolatedExceptions
+ [@stefanbirkner, fixing gh-296]
+- Javadoc bugs
+ - Assert documentation [@stefanbirkner, fixing gh-134]
+ - ClassRule [@stefanbirkner, fixing gh-254]
+ - Parameterized [@stefanbirkner, fixing gh-89]
+ - Parameterized, again [@orfjackal, fixing gh-285]
+- Miscellaneous
+ - Useless code in RunAfters [@stefanbirkner, fixing gh-289]
+ - Parameterized test classes should be able to have `@Category` annotations
+ [@dsaff, fixing gh-291]
+ - Error count should be initialized in junit.tests.framework.TestListenerTest [@stefanbirkner, fixing gh-225]
+ - AssertionFailedError constructor shouldn't call super with null message [@stefanbirkner, fixing gh-318]
+ - Clearer error message for non-static inner test classes [@stefanbirkner, fixing gh-42]
+
+### Minor changes ###
+
+- Description, Result and Failure are Serializable [@ephox-rob, closing gh-101]
+- FailOnTimeout is reusable, allowing for retrying Rules [@stefanbirkner, closing gh-265]
+- New `ErrorCollector.checkThat` overload, that allows you to specify a reason [@drothmaler, closing gh-300]
+
+
+
View
85 doc/ReleaseNotes4.10.txt
@@ -1,84 +1 @@
-## Summary of Changes in version 4.10 ##
-
-Thanks to a full cast of contributors of bug fixes and new features.
-
-A full summary of commits between 4.9 and 4.10 is on [github](https://github.com/KentBeck/junit/compare/r4.9...4.10)
-
-### junit-dep has correct contents ###
-
-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]
-
-### RuleChain ###
-
-The RuleChain rule allows ordering of TestRules:
-
- public static class UseRuleChain {
- @Rule
- public TestRule chain= RuleChain
- .outerRule(new LoggingRule("outer rule")
- .around(new LoggingRule("middle rule")
- .around(new LoggingRule("inner rule");
-
- @Test
- public void example() {
- assertTrue(true);
- }
- }
-
-writes the log
-
- starting outer rule
- starting middle rule
- starting inner rule
- finished inner rule
- finished middle rule
- finished outer rule
-
-### TemporaryFolder ###
-
-- `TemporaryFolder#newFolder(String... folderNames)` creates recursively deep temporary folders
- [@rodolfoliviero, closing gh-283]
-- `TemporaryFolder#newFile()` creates a randomly named new file, and `#newFolder()` creates a randomly named new folder
- [@Daniel Rothmaler, closing gh-299]
-
-### Theories ###
-
-The `Theories` runner does not anticipate theory parameters that have generic
-types, as reported by github#64. Fixing this won't happen until `Theories` is
-moved to junit-contrib. In anticipation of this, 4.9.1 adds some of the
-necessary machinery to the runner classes, and deprecates a method that only
-the `Theories` runner uses, `FrameworkMethod`#producesType().
-The Common Public License that JUnit is released under is now included
-in the source repository.
-
-Thanks to `@pholser` for identifying a potential resolution for github#64
-and initiating work on it.
-
-### Bug fixes ###
-
-- Built-in Rules implementations
- - TemporaryFolder should not create files in the current working directory if applying the rule fails
- [@orfjackal, fixing gh-278]
- - TestWatcher and TestWatchman should not call failed for AssumptionViolatedExceptions
- [@stefanbirkner, fixing gh-296]
-- Javadoc bugs
- - Assert documentation [@stefanbirkner, fixing gh-134]
- - ClassRule [@stefanbirkner, fixing gh-254]
- - Parameterized [@stefanbirkner, fixing gh-89]
- - Parameterized, again [@orfjackal, fixing gh-285]
-- Miscellaneous
- - Useless code in RunAfters [@stefanbirkner, fixing gh-289]
- - Parameterized test classes should be able to have `@Category` annotations
- [@dsaff, fixing gh-291]
- - Error count should be initialized in junit.tests.framework.TestListenerTest [@stefanbirkner, fixing gh-225]
- - AssertionFailedError constructor shouldn't call super with null message [@stefanbirkner, fixing gh-318]
- - Clearer error message for non-static inner test classes [@stefanbirkner, fixing gh-42]
-
-### Minor changes ###
-
-- Description, Result and Failure are Serializable [@ephox-rob, closing gh-101]
-- FailOnTimeout is reusable, allowing for retrying Rules [@stefanbirkner, closing gh-265]
-- New `ErrorCollector.checkThat` overload, that allows you to specify a reason [@drothmaler, closing gh-300]
-
-
-
+Please see ReleaseNotes4.10.md
View
1 doc/ReleaseNotes4.11.txt
@@ -0,0 +1 @@
+Please see ReleaseNotes4.11.md
View
295 doc/ReleaseNotes4.4.md
@@ -0,0 +1,295 @@
+## Summary of Changes in version 4.5 ##
+
+### Categories ###
+Each test method and test class can be annotated as belonging to a _category_:
+
+ public static class SomeUITests {
+ @Category(UserAvailable.class)
+ @Test
+ public void askUserToPressAKey() { }
+
+ @Test
+ public void simulatePressingKey() { }
+ }
+
+ @Category(InternetConnected.class)
+ public static class InternetTests {
+ @Test
+ public void pingServer() { }
+ }
+
+To run all of the tests in a particular category, you must currently explicitly create a custom request:
+
+ new JUnitCore().run(Request.aClass(SomeUITests.class).inCategories(UserAvailable.class));
+
+This feature will very likely be improved before the final release of JUnit 4.5
+
+### Theories ###
+
+- `@Before` and `@After` 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.
+
+- Exposed API's `ParameterSignature.getType()` and `ParameterSignature.getAnnotations()`
+
+- An array of data points can be introduced by a field or method marked with the new annotation `@DataPoints`
+
+- The Theories custom runner has been refactored to make it easier to extend
+
+### JUnit 4 Runner API ###
+
+- There has been a drastic rewrite of the API for custom Runners in 4.5. This
+ needs to be written up separately before release.
+
+- Tests with failed assumptions are now marked as Ignored, rather than silently passing.
+ This may change behavior in some client tests, and also will require some new support
+ on the part of IDE's.
+
+## Summary of Changes in version 4.4 ##
+
+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.
+
+[Download][]
+
+[Download]: http://sourceforge.net/project/showfiles.php?group_id=15278
+
+### assertThat ###
+
+Two years ago, Joe Walnes built a [new assertion mechanism][walnes] on top of what was
+then [JMock 1][]. The method name was `assertThat`, and the syntax looked like this:
+
+[walnes]: http://joe.truemesh.com/blog/000511.html
+[JMock 1]: http://www.jmock.org/download.html
+
+ assertThat(x, is(3));
+ assertThat(x, is(not(4)));
+ assertThat(responseString, either(containsString("color")).or(containsString("colour")));
+ assertThat(myList, hasItem("3"));
+
+More generally:
+
+ assertThat([value], [matcher statement]);
+
+Advantages of this assertion syntax include:
+
+- More readable and typeable: this syntax allows you to think in terms of subject, verb, object
+ (assert "x is 3") rather than `assertEquals`, which uses verb, object, subject (assert "equals 3 x")
+
+- Combinations: any matcher statement `s` can be negated (`not(s)`), combined (`either(s).or(t)`),
+ mapped to a collection (`each(s)`), or used in custom combinations (`afterFiveSeconds(s)`)
+
+- Readable failure messages. Compare
+
+ 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"
+
+- Custom Matchers. By implementing the `Matcher` interface yourself, you can get all of the
+ above benefits for your own custom assertions.
+
+- For a more thorough description of these points, see [Joe Walnes's
+ original post][walnes].
+
+We have decided to include this API directly in JUnit.
+It's an extensible and readable syntax, and it enables
+new features, like [assumptions][] and [theories][].
+
+[assumptions]: #assumptions
+[theories]: #theories
+
+Some notes:
+
+- The old assert methods are never, ever, going away. Developers may
+ continue using the old `assertEquals`, `assertTrue`, and so on.
+- The second parameter of an `assertThat` statement is a `Matcher`.
+ We include the Matchers we want as static imports, like this:
+
+ import static org.hamcrest.CoreMatchers.is;
+
+ or:
+
+ import static org.hamcrest.CoreMatchers.*;
+
+- Manually importing `Matcher` 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.
+
+[Eclipse 3.3]: http://www.eclipse.org/downloads/
+
+- To allow compatibility with a wide variety of possible matchers,
+ we have decided to include the classes from hamcrest-core,
+ from the [Hamcrest][] project. This is the first time that
+ third-party classes have been included in JUnit.
+
+[Hamcrest]: http://code.google.com/p/hamcrest/
+
+- JUnit currently ships with a few matchers, defined in
+ `org.hamcrest.CoreMatchers` and `org.junit.matchers.JUnitMatchers`.
+ To use many, many more, consider downloading the [full hamcrest package][].
+
+[full hamcrest package]: http://hamcrest.googlecode.com/files/hamcrest-all-1.1.jar
+
+- JUnit contains special support for comparing string and array
+ values, giving specific information on how they differ. This is not
+ yet available using the `assertThat` syntax, but we hope to bring
+ the two assert methods into closer alignment in future releases.
+
+<a name="assumptions" />
+### 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.
+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.
+
+However, sometimes this is not desirable or possible.
+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":
+
+ 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()));
+ }
+
+With this 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.
+
+We have included `assumeTrue` for convenience, but thanks to the
+inclusion of Hamcrest, we do not need to create `assumeEquals`,
+`assumeSame`, and other analogues to the `assert*` methods. All of
+those functionalities are subsumed in `assumeThat`, with the appropriate
+matcher.
+
+A failing assumption in a `@Before` or `@BeforeClass` method will have the same effect
+as a failing assumption in each `@Test` method of the class.
+
+<a name="theories" />
+### 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 captures some aspect of the
+intended behavior in possibly
+infinite numbers of potential scenarios. For example:
+
+ @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));
+ }
+ }
+
+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.
+
+`UserTest` will attempt to run `filenameIncludesUsername` on
+every compatible `DataPoint` 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.
+
+The support for Theories has been absorbed from the [Popper][]
+project, and [more complete documentation][popper-docs] can be found
+there.
+
+[Popper]: http://popper.tigris.org
+[popper-docs]: http://popper.tigris.org/tutorial.html
+
+Defining general statements in this way can jog the developer's memory
+about other potential data points and tests, also allows [automated
+tools][junit-factory] to [search][my-blog] for new, unexpected data
+points that expose bugs.
+
+[junit-factory]: http://www.junitfactory.org
+[my-blog]: http://shareandenjoy.saff.net/2007/04/popper-and-junitfactory.html
+
+### Other changes ###
+
+This release contains other bug fixes and new features. Among them:
+
+- Annotated descriptions
+
+ 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.
+
+- Bug fix (1715326): assertEquals now compares all Numbers using their
+ native implementation of `equals`. This assertion, which passed in
+ 4.3, will now fail:
+
+ assertEquals(new Integer(1), new Long(1));
+
+ Non-integer Numbers (Floats, Doubles, BigDecimals, etc),
+ which were compared incorrectly in 4.3, are now fixed.
+
+- `assertEquals(long, long)` and `assertEquals(double, double)` have
+ been re-introduced to the `Assert` class, to take advantage of
+ Java's native widening conversions. Therefore, this still passes:
+
+ assertEquals(1, 1L);
+
+- The default runner for JUnit 4 test classes has been refactored.
+ The old version was named `TestClassRunner`, and the new is named
+ `JUnit4ClassRunner`. Likewise, `OldTestClassRunner` is now
+ `JUnit3ClassRunner`. 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
+ `org.junit.experimental.theories.Theories`.
+
+- The rules for determining which runner is applied by default to a
+ test class have been simplified:
+
+ 1. If the class has a `@RunWith` annotation, the annotated runner
+ class is used.
+
+ 2. If the class can be run with the JUnit 3 test runner (it
+ subclasses `TestCase`, or contains a `public static Test suite()`
+ method), JUnit38ClassRunner is used.
+
+ 3. Otherwise, JUnit4ClassRunner is used.
+
+ This default guess can always be overridden by an explicit
+ `@RunWith(JUnit4ClassRunner.class)` or
+ `@RunWith(JUnit38ClassRunner.class)` annotation.
+
+ The old class names `TestClassRunner` and `OldTestClassRunner`
+ remain as deprecated.
+
+- Bug fix (1739095): Filters and Sorters work correctly on test
+ classes that contain a `suite` method like:
+
+ public static junit.framework.Test suite() {
+ return new JUnit4TestAdapter(MyTest.class);
+ }
+
+- Bug fix (1745048): @After methods are now correctly called
+ after a test method times out.
+
View
296 doc/ReleaseNotes4.4.txt
@@ -1,295 +1 @@
-## Summary of Changes in version 4.5 ##
-
-### Categories ###
-Each test method and test class can be annotated as belonging to a _category_:
-
- public static class SomeUITests {
- @Category(UserAvailable.class)
- @Test
- public void askUserToPressAKey() { }
-
- @Test
- public void simulatePressingKey() { }
- }
-
- @Category(InternetConnected.class)
- public static class InternetTests {
- @Test
- public void pingServer() { }
- }
-
-To run all of the tests in a particular category, you must currently explicitly create a custom request:
-
- new JUnitCore().run(Request.aClass(SomeUITests.class).inCategories(UserAvailable.class));
-
-This feature will very likely be improved before the final release of JUnit 4.5
-
-### Theories ###
-
-- `@Before` and `@After` 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.
-
-- Exposed API's `ParameterSignature.getType()` and `ParameterSignature.getAnnotations()`
-
-- An array of data points can be introduced by a field or method marked with the new annotation `@DataPoints`
-
-- The Theories custom runner has been refactored to make it easier to extend
-
-### JUnit 4 Runner API ###
-
-- There has been a drastic rewrite of the API for custom Runners in 4.5. This
- needs to be written up separately before release.
-
-- Tests with failed assumptions are now marked as Ignored, rather than silently passing.
- This may change behavior in some client tests, and also will require some new support
- on the part of IDE's.
-
-## Summary of Changes in version 4.4 ##
-
-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.
-
-[Download][]
-
-[Download]: http://sourceforge.net/project/showfiles.php?group_id=15278
-
-### assertThat ###
-
-Two years ago, Joe Walnes built a [new assertion mechanism][walnes] on top of what was
-then [JMock 1][]. The method name was `assertThat`, and the syntax looked like this:
-
-[walnes]: http://joe.truemesh.com/blog/000511.html
-[JMock 1]: http://www.jmock.org/download.html
-
- assertThat(x, is(3));
- assertThat(x, is(not(4)));
- assertThat(responseString, either(containsString("color")).or(containsString("colour")));
- assertThat(myList, hasItem("3"));
-
-More generally:
-
- assertThat([value], [matcher statement]);
-
-Advantages of this assertion syntax include:
-
-- More readable and typeable: this syntax allows you to think in terms of subject, verb, object
- (assert "x is 3") rather than `assertEquals`, which uses verb, object, subject (assert "equals 3 x")
-
-- Combinations: any matcher statement `s` can be negated (`not(s)`), combined (`either(s).or(t)`),
- mapped to a collection (`each(s)`), or used in custom combinations (`afterFiveSeconds(s)`)
-
-- Readable failure messages. Compare
-
- 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"
-
-- Custom Matchers. By implementing the `Matcher` interface yourself, you can get all of the
- above benefits for your own custom assertions.
-
-- For a more thorough description of these points, see [Joe Walnes's
- original post][walnes].
-
-We have decided to include this API directly in JUnit.
-It's an extensible and readable syntax, and it enables
-new features, like [assumptions][] and [theories][].
-
-[assumptions]: #assumptions
-[theories]: #theories
-
-Some notes:
-
-- The old assert methods are never, ever, going away. Developers may
- continue using the old `assertEquals`, `assertTrue`, and so on.
-- The second parameter of an `assertThat` statement is a `Matcher`.
- We include the Matchers we want as static imports, like this:
-
- import static org.hamcrest.CoreMatchers.is;
-
- or:
-
- import static org.hamcrest.CoreMatchers.*;
-
-- Manually importing `Matcher` 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.
-
-[Eclipse 3.3]: http://www.eclipse.org/downloads/
-
-- To allow compatibility with a wide variety of possible matchers,
- we have decided to include the classes from hamcrest-core,
- from the [Hamcrest][] project. This is the first time that
- third-party classes have been included in JUnit.
-
-[Hamcrest]: http://code.google.com/p/hamcrest/
-
-- JUnit currently ships with a few matchers, defined in
- `org.hamcrest.CoreMatchers` and `org.junit.matchers.JUnitMatchers`.
- To use many, many more, consider downloading the [full hamcrest package][].
-
-[full hamcrest package]: http://hamcrest.googlecode.com/files/hamcrest-all-1.1.jar
-
-- JUnit contains special support for comparing string and array
- values, giving specific information on how they differ. This is not
- yet available using the `assertThat` syntax, but we hope to bring
- the two assert methods into closer alignment in future releases.
-
-<a name="assumptions" />
-### 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.
-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.
-
-However, sometimes this is not desirable or possible.
-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":
-
- 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()));
- }
-
-With this 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.
-
-We have included `assumeTrue` for convenience, but thanks to the
-inclusion of Hamcrest, we do not need to create `assumeEquals`,
-`assumeSame`, and other analogues to the `assert*` methods. All of
-those functionalities are subsumed in `assumeThat`, with the appropriate
-matcher.
-
-A failing assumption in a `@Before` or `@BeforeClass` method will have the same effect
-as a failing assumption in each `@Test` method of the class.
-
-<a name="theories" />
-### 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 captures some aspect of the
-intended behavior in possibly
-infinite numbers of potential scenarios. For example:
-
- @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));
- }
- }
-
-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.
-
-`UserTest` will attempt to run `filenameIncludesUsername` on
-every compatible `DataPoint` 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.
-
-The support for Theories has been absorbed from the [Popper][]
-project, and [more complete documentation][popper-docs] can be found
-there.
-
-[Popper]: http://popper.tigris.org
-[popper-docs]: http://popper.tigris.org/tutorial.html
-
-Defining general statements in this way can jog the developer's memory
-about other potential data points and tests, also allows [automated
-tools][junit-factory] to [search][my-blog] for new, unexpected data
-points that expose bugs.
-
-[junit-factory]: http://www.junitfactory.org
-[my-blog]: http://shareandenjoy.saff.net/2007/04/popper-and-junitfactory.html
-
-### Other changes ###
-
-This release contains other bug fixes and new features. Among them:
-
-- Annotated descriptions
-
- 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.
-
-- Bug fix (1715326): assertEquals now compares all Numbers using their
- native implementation of `equals`. This assertion, which passed in
- 4.3, will now fail:
-
- assertEquals(new Integer(1), new Long(1));
-
- Non-integer Numbers (Floats, Doubles, BigDecimals, etc),
- which were compared incorrectly in 4.3, are now fixed.
-
-- `assertEquals(long, long)` and `assertEquals(double, double)` have
- been re-introduced to the `Assert` class, to take advantage of
- Java's native widening conversions. Therefore, this still passes:
-
- assertEquals(1, 1L);
-
-- The default runner for JUnit 4 test classes has been refactored.
- The old version was named `TestClassRunner`, and the new is named
- `JUnit4ClassRunner`. Likewise, `OldTestClassRunner` is now
- `JUnit3ClassRunner`. 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
- `org.junit.experimental.theories.Theories`.
-
-- The rules for determining which runner is applied by default to a
- test class have been simplified:
-
- 1. If the class has a `@RunWith` annotation, the annotated runner
- class is used.
-
- 2. If the class can be run with the JUnit 3 test runner (it
- subclasses `TestCase`, or contains a `public static Test suite()`
- method), JUnit38ClassRunner is used.
-
- 3. Otherwise, JUnit4ClassRunner is used.
-
- This default guess can always be overridden by an explicit
- `@RunWith(JUnit4ClassRunner.class)` or
- `@RunWith(JUnit38ClassRunner.class)` annotation.
-
- The old class names `TestClassRunner` and `OldTestClassRunner`
- remain as deprecated.
-
-- Bug fix (1739095): Filters and Sorters work correctly on test
- classes that contain a `suite` method like:
-
- public static junit.framework.Test suite() {
- return new JUnit4TestAdapter(MyTest.class);
- }
-
-- Bug fix (1745048): @After methods are now correctly called
- after a test method times out.
-
+Please see ReleaseNotes4.4.md
View
96 doc/ReleaseNotes4.5.md
@@ -0,0 +1,96 @@
+## Summary of Changes in version 4.5 ##
+
+### Installation ###
+
+- We are releasing `junit-4.5.jar`, which contains all the classes
+ necessary to run JUnit, and `junit-dep-4.5.jar`, which leaves out
+ hamcrest classes, for developers who already use hamcrest outside of
+ JUnit.
+
+### Basic JUnit operation ###
+
+- JUnitCore now more often exits with the correct exit code (0 for
+ success, 1 for failure)
+
+- Badly formed test classes (exceptions in constructors, classes
+ without tests, multiple constructors, Suite without @SuiteClasses)
+ produce more helpful error messages
+
+- Test classes whose only test methods are inherited from superclasses
+ now run.
+
+- Optimization to annotation processing can cut JUnit overhead by more than half
+ on large test classes, especially when using Theories. [Bug 1796847]
+
+- A failing assumption in a constructor ignores the class
+
+- Correct results when comparing the string "null" with potentially
+ null values. [Bug 1857283]
+
+- Annotating a class with `@RunWith(JUnit4.class)` will always invoke the
+ default JUnit 4 runner in the current version of JUnit. This default changed
+ from `JUnit4ClassRunner` in 4.4 to `BlockJUnit4ClassRunner` in 4.5 (see below),
+ and may change again.
+
+### Extension ###
+
+- `BlockJUnit4Runner` is a new implementation of the standard JUnit 4
+ test class functionality. In contrast to `JUnit4ClassRunner` (the old
+ implementation):
+
+ - `BlockJUnit4Runner` has a much simpler implementation based on
+ Statements, allowing new operations to be inserted into the
+ appropriate point in the execution flow.
+
+ - `BlockJUnit4Runner` is published, and extension and reuse are
+ encouraged, whereas `JUnit4ClassRunner` was in an internal package,
+ and is now deprecated.
+
+- `ParentRunner` is a base class for runners that iterate over
+ a list of "children", each an object representing a test or suite to run.
+ `ParentRunner` provides filtering, sorting, `@BeforeClass`, `@AfterClass`,
+ and method validation to subclasses.
+
+- `TestClass` wraps a class to be run, providing efficient, repeated access
+ to all methods with a given annotation.
+
+- The new `RunnerBuilder` API allows extending the behavior of
+ Suite-like custom runners.
+
+- `AssumptionViolatedException.toString()` is more informative
+
+### Extra Runners ###
+
+- `Parameterized.eachOne()` has been removed
+
+- New runner `Enclosed` runs all static inner classes of an outer class.
+
+### Theories ###
+
+- `@Before` and `@After` 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.
+
+- Exposed API's `ParameterSignature.getType()` and `ParameterSignature.getAnnotations()`
+
+- An array of data points can be introduced by a field or method
+ marked with the new annotation `@DataPoints`
+
+- The Theories custom runner has been refactored to make it faster and
+ easier to extend
+
+### Development ###
+
+- Source has been split into directories `src/main/java` and
+ `src/test/java`, making it easier to exclude tests from builds, and
+ making JUnit more maven-friendly
+
+- Test classes in `org.junit.tests` have been organized into
+ subpackages, hopefully making finding tests easier.
+
+- `ResultMatchers` has more informative descriptions.
+
+- `TestSystem` allows testing return codes and other system-level interactions.
+
+### Incompatible changes ###
+
+- Removed Request.classes(String, Class<?>...) factory method
View
97 doc/ReleaseNotes4.5.txt
@@ -1,96 +1 @@
-## Summary of Changes in version 4.5 ##
-
-### Installation ###
-
-- We are releasing `junit-4.5.jar`, which contains all the classes
- necessary to run JUnit, and `junit-dep-4.5.jar`, which leaves out
- hamcrest classes, for developers who already use hamcrest outside of
- JUnit.
-
-### Basic JUnit operation ###
-
-- JUnitCore now more often exits with the correct exit code (0 for
- success, 1 for failure)
-
-- Badly formed test classes (exceptions in constructors, classes
- without tests, multiple constructors, Suite without @SuiteClasses)
- produce more helpful error messages
-
-- Test classes whose only test methods are inherited from superclasses
- now run.
-
-- Optimization to annotation processing can cut JUnit overhead by more than half
- on large test classes, especially when using Theories. [Bug 1796847]
-
-- A failing assumption in a constructor ignores the class
-
-- Correct results when comparing the string "null" with potentially
- null values. [Bug 1857283]
-
-- Annotating a class with `@RunWith(JUnit4.class)` will always invoke the
- default JUnit 4 runner in the current version of JUnit. This default changed
- from `JUnit4ClassRunner` in 4.4 to `BlockJUnit4ClassRunner` in 4.5 (see below),
- and may change again.
-
-### Extension ###
-
-- `BlockJUnit4Runner` is a new implementation of the standard JUnit 4
- test class functionality. In contrast to `JUnit4ClassRunner` (the old
- implementation):
-
- - `BlockJUnit4Runner` has a much simpler implementation based on
- Statements, allowing new operations to be inserted into the
- appropriate point in the execution flow.
-
- - `BlockJUnit4Runner` is published, and extension and reuse are
- encouraged, whereas `JUnit4ClassRunner` was in an internal package,
- and is now deprecated.
-
-- `ParentRunner` is a base class for runners that iterate over
- a list of "children", each an object representing a test or suite to run.
- `ParentRunner` provides filtering, sorting, `@BeforeClass`, `@AfterClass`,
- and method validation to subclasses.
-
-- `TestClass` wraps a class to be run, providing efficient, repeated access
- to all methods with a given annotation.
-
-- The new `RunnerBuilder` API allows extending the behavior of
- Suite-like custom runners.
-
-- `AssumptionViolatedException.toString()` is more informative
-
-### Extra Runners ###
-
-- `Parameterized.eachOne()` has been removed
-
-- New runner `Enclosed` runs all static inner classes of an outer class.
-
-### Theories ###
-
-- `@Before` and `@After` 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.
-
-- Exposed API's `ParameterSignature.getType()` and `ParameterSignature.getAnnotations()`
-
-- An array of data points can be introduced by a field or method
- marked with the new annotation `@DataPoints`
-
-- The Theories custom runner has been refactored to make it faster and
- easier to extend
-
-### Development ###
-
-- Source has been split into directories `src/main/java` and
- `src/test/java`, making it easier to exclude tests from builds, and
- making JUnit more maven-friendly
-
-- Test classes in `org.junit.tests` have been organized into
- subpackages, hopefully making finding tests easier.
-
-- `ResultMatchers` has more informative descriptions.
-
-- `TestSystem` allows testing return codes and other system-level interactions.
-
-### Incompatible changes ###
-
-- Removed Request.classes(String, Class<?>...) factory method
+Please see ReleaseNotes4.5.md
View
100 doc/ReleaseNotes4.6.md
@@ -0,0 +1,100 @@
+## Summary of Changes in version 4.6 ##
+
+### Max ###
+
+JUnit now includes a new experimental Core, `MaxCore`. `MaxCore`
+remembers the results of previous test runs in order to run new
+tests out of order. `MaxCore` 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
+`MaxCore` included in JUnit, but there is a UI included in the JUnit
+Max Eclipse plug-in at:
+
+ http://www.junitmax.com/junitmax/subscribe.html
+
+Example:
+
+ 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());
+ }
+
+### Test scheduling strategies ###
+
+`JUnitCore` now includes an experimental method that allows you to
+specify a model of the `Computer` that runs your tests. Currently,
+the only built-in Computers are the default, serial runner, and two
+runners provided in the `ParallelRunner` class:
+`ParallelRunner.classes()`, which runs classes in parallel, and
+`ParallelRunner.methods()`, which runs classes and methods in parallel.
+
+This feature is currently less stable than MaxCore, and may be
+merged with MaxCore in some way in the future.
+
+Example:
+
+ 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));
+ }
+
+### Comparing double arrays ###
+
+Arrays of doubles can be compared, using a delta allowance for equality:
+
+ @Test
+ public void doubleArraysAreEqual() {
+ assertArrayEquals(new double[] {1.0, 2.0}, new double[] {1.0, 2.0}, 0.01);
+ }
+
+### `Filter.matchDescription` API ###
+
+Since 4.0, it has been possible to run a single method using the `Request.method`
+API. In 4.6, the filter that implements this is exposed as `Filter.matchDescription`.
+
+### Documentation ###
+
+- A couple classes and packages that once had empty javadoc have been
+ doc'ed.
+
+- Added how to run JUnit from the command line to the cookbook.
+
+- junit-4.x.zip now contains build.xml
+
+### Bug fixes ###
+- Fixed overly permissive @DataPoint processing (2191102)
+- Fixed bug in test counting after an ignored method (2106324)
View
101 doc/ReleaseNotes4.6.txt
@@ -1,100 +1 @@
-## Summary of Changes in version 4.6 ##
-
-### Max ###
-
-JUnit now includes a new experimental Core, `MaxCore`. `MaxCore`
-remembers the results of previous test runs in order to run new
-tests out of order. `MaxCore` 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
-`MaxCore` included in JUnit, but there is a UI included in the JUnit
-Max Eclipse plug-in at:
-
- http://www.junitmax.com/junitmax/subscribe.html
-
-Example:
-
- 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());
- }
-
-### Test scheduling strategies ###
-
-`JUnitCore` now includes an experimental method that allows you to
-specify a model of the `Computer` that runs your tests. Currently,
-the only built-in Computers are the default, serial runner, and two
-runners provided in the `ParallelRunner` class:
-`ParallelRunner.classes()`, which runs classes in parallel, and
-`ParallelRunner.methods()`, which runs classes and methods in parallel.
-
-This feature is currently less stable than MaxCore, and may be
-merged with MaxCore in some way in the future.
-
-Example:
-
- 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));
- }
-
-### Comparing double arrays ###
-
-Arrays of doubles can be compared, using a delta allowance for equality:
-
- @Test
- public void doubleArraysAreEqual() {
- assertArrayEquals(new double[] {1.0, 2.0}, new double[] {1.0, 2.0}, 0.01);
- }
-
-### `Filter.matchDescription` API ###
-
-Since 4.0, it has been possible to run a single method using the `Request.method`
-API. In 4.6, the filter that implements this is exposed as `Filter.matchDescription`.
-
-### Documentation ###
-
-- A couple classes and packages that once had empty javadoc have been
- doc'ed.
-
-- Added how to run JUnit from the command line to the cookbook.
-
-- junit-4.x.zip now contains build.xml
-
-### Bug fixes ###
-- Fixed overly permissive @DataPoint processing (2191102)
-- Fixed bug in test counting after an ignored method (2106324)
+Please see ReleaseNotes4.6.md
View
194 doc/ReleaseNotes4.7.md
@@ -0,0 +1,194 @@
+## Summary of Changes in version 4.7 ##
+
+### Rules ###
+
+- Rules allow very flexible addition or redefinition of the behavior
+ of each test method in a test class. Testers can reuse or extend one of the
+ provided Rules below, or write their own.
+
+ For more on this feature, see http://www.threeriversinstitute.org/blog/?p=155
+
+- The TemporaryFolder Rule allows creation of files and folders
+ that are guaranteed to be deleted when the test method finishes
+ (whether it passes or fails):
+
+ public static class HasTempFolder {
+ @Rule
+ public TemporaryFolder folder= new TemporaryFolder();
+
+ @Test
+ public void testUsingTempFolder() throws IOException {
+ File createdFile= folder.newFile("myfile.txt");
+ File createdFolder= folder.newFolder("subfolder");
+ // ...
+ }
+ }
+
+- ExternalResource is a base class for Rules (like TemporaryFolder)
+ that set up an external resource before a test (a file, socket, server,
+ database connection, etc.), and guarantee to tear it down afterward:
+
+ public static class UsesExternalResource {
+ Server myServer = new Server();
+
+ @Rule public ExternalResource resource = new ExternalResource() {
+ @Override
+ protected void before() throws Throwable {
+ myServer.connect();
+ };
+
+ @Override
+ protected void after() {
+ myServer.disconnect();
+ };
+ };
+
+ @Test public void testFoo() {
+ new Client().run(myServer);
+ }
+ }
+
+- The ErrorCollector Rule allows execution of a test to continue
+ after the first problem is found (for example, to collect _all_ the
+ incorrect rows in a table, and report them all at once):
+
+ public static class UsesErrorCollectorTwice {
+ @Rule
+ public ErrorCollector collector= new ErrorCollector();
+
+ @Test public void example() {
+ collector.addError(new Throwable("first thing went wrong"));
+ collector.addError(new Throwable("second thing went wrong"));
+ }
+ }
+
+- Verifier is a base class for Rules like ErrorCollector, which
+ can turn otherwise passing test methods into failing tests if a verification
+ check is failed
+
+ public static class ErrorLogVerifier() {
+ private ErrorLog errorLog = new ErrorLog();
+
+ @Rule
+ public MethodRule verifier = new Verifier() {
+ @Override public void verify() {
+ assertTrue(errorLog.isEmpty());
+ }
+ }
+
+ @Test public void testThatMightWriteErrorLog() {
+ // ...
+ }
+ }
+
+- TestWatchman is a base class for Rules that take note
+ of the testing action, without modifying it.
+ For example, this class will keep a log of each passing and failing
+ test:
+
+ public static class WatchmanTest {
+ private static String watchedLog;
+
+ @Rule
+ public MethodRule watchman= new TestWatchman() {
+ @Override
+ public void failed(Throwable e, FrameworkMethod method) {
+ watchedLog+= method.getName() + " "
+ + e.getClass().getSimpleName() + "\n";
+ }
+
+ @Override
+ public void succeeded(FrameworkMethod method) {
+ watchedLog+= method.getName() + " " + "success!\n";
+ }
+ };
+
+ @Test
+ public void fails() {
+ fail();
+ }
+
+ @Test
+ public void succeeds() {
+ }
+ }
+
+- The TestName Rule makes the current test name available inside test methods:
+
+ public class NameRuleTest {
+ @Rule public TestName name = new TestName();
+
+ @Test public void testA() {
+ assertEquals("testA", name.getMethodName());
+ }
+
+ @Test public void testB() {
+ assertEquals("testB", name.getMethodName());
+ }
+ }
+
+- The Timeout Rule applies the same timeout to all test methods in a class:
+
+ public static class HasGlobalTimeout {
+ public static String log;
+
+ @Rule public MethodRule globalTimeout = new Timeout(20);
+
+ @Test public void testInfiniteLoop1() {
+ log+= "ran1";
+ for(;;) {}
+ }
+
+ @Test public void testInfiniteLoop2() {
+ log+= "ran2";
+ for(;;) {}
+ }
+ }
+
+- The ExpectedException Rule allows in-test specification
+ of expected exception types and messages:
+
+ public static class HasExpectedException {
+ @Rule
+ public ExpectedException thrown= ExpectedException.none();
+
+ @Test
+ public void throwsNothing() {
+
+ }
+
+ @Test
+ public void throwsNullPointerException() {
+ thrown.expect(NullPointerException.class);
+ throw new NullPointerException();
+ }
+
+ @Test
+ public void throwsNullPointerExceptionWithMessage() {
+ thrown.expect(NullPointerException.class);
+ thrown.expectMessage("happened?");
+ thrown.expectMessage(startsWith("What"));
+ throw new NullPointerException("What happened?");
+ }
+ }
+
+### Timeouts ###
+- Tests that time out now show the stack trace of the test thread.
+
+### Matchers ###
+- Due to typing incompatibilities, JUnit is still including the 1.1 release
+ of hamcrest. This is not a change from 4.6, but is a change from
+ pre-beta releases of 4.7. Due to this incompatibility, tests using
+ Hamcrest 1.2 must still use the MatcherAssert.assertThat method from
+ Hamcrest, not Assert.assertThat from JUnit.
+
+### Docs ###
+- Javadocs now link to online JDK javadocs (bug 2090230)
+- Parameterized runner javadocs improved (bug 2186792)
+- Fixed Javadoc code sample for AfterClass (2126279)
+- Fixed Javadoc for assertArraysEqual(float[], float[])
+
+### Bug fixes ###
+- Fixed: BaseTestRunner.getTest() requires class to extend TestCase (1812200)
+- Fixed: Suite does not allow for inheritance in annotations (2783118)
+- Fixed: ParallelComputer skipped tests that took longer than 2 seconds
View
195 doc/ReleaseNotes4.7.txt
@@ -1,194 +1 @@
-## Summary of Changes in version 4.7 ##
-
-### Rules ###
-
-- Rules allow very flexible addition or redefinition of the behavior
- of each test method in a test class. Testers can reuse or extend one of the
- provided Rules below, or write their own.
-
- For more on this feature, see http://www.threeriversinstitute.org/blog/?p=155
-
-- The TemporaryFolder Rule allows creation of files and folders
- that are guaranteed to be deleted when the test method finishes
- (whether it passes or fails):
-
- public static class HasTempFolder {
- @Rule
- public TemporaryFolder folder= new TemporaryFolder();
-
- @Test
- public void testUsingTempFolder() throws IOException {
- File createdFile= folder.newFile("myfile.txt");
- File createdFolder= folder.newFolder("subfolder");
- // ...
- }
- }
-
-- ExternalResource is a base class for Rules (like TemporaryFolder)
- that set up an external resource before a test (a file, socket, server,
- database connection, etc.), and guarantee to tear it down afterward:
-
- public static class UsesExternalResource {
- Server myServer = new Server();
-
- @Rule public ExternalResource resource = new ExternalResource() {
- @Override
- protected void before() throws Throwable {
- myServer.connect();
- };
-
- @Override
- protected void after() {
- myServer.disconnect();
- };
- };
-
- @Test public void testFoo() {
- new Client().run(myServer);
- }
- }
-
-- The ErrorCollector Rule allows execution of a test to continue
- after the first problem is found (for example, to collect _all_ the
- incorrect rows in a table, and report them all at once):
-
- public static class UsesErrorCollectorTwice {
- @Rule
- public ErrorCollector collector= new ErrorCollector();
-
- @Test public void example() {
- collector.addError(new Throwable("first thing went wrong"));
- collector.addError(new Throwable("second thing went wrong"));
- }
- }
-
-- Verifier is a base class for Rules like ErrorCollector, which
- can turn otherwise passing test methods into failing tests if a verification
- check is failed
-
- public static class ErrorLogVerifier() {
- private ErrorLog errorLog = new ErrorLog();
-
- @Rule
- public MethodRule verifier = new Verifier() {
- @Override public void verify() {
- assertTrue(errorLog.isEmpty());
- }
- }
-
- @Test public void testThatMightWriteErrorLog() {
- // ...
- }
- }
-
-- TestWatchman is a base class for Rules that take note
- of the testing action, without modifying it.
- For example, this class will keep a log of each passing and failing
- test:
-
- public static class WatchmanTest {
- private static String watchedLog;
-
- @Rule
- public MethodRule watchman= new TestWatchman() {
- @Override
- public void failed(Throwable e, FrameworkMethod method) {
- watchedLog+= method.getName() + " "
- + e.getClass().getSimpleName() + "\n";
- }
-
- @Override
- public void succeeded(FrameworkMethod method) {
- watchedLog+= method.getName() + " " + "success!\n";
- }
- };
-
- @Test
- public void fails() {
- fail();
- }
-
- @Test
- public void succeeds() {
- }
- }
-
-- The TestName Rule makes the current test name available inside test methods:
-
- public class NameRuleTest {
- @Rule public TestName name = new TestName();
-
- @Test public void testA() {
- assertEquals("testA", name.getMethodName());
- }
-
- @Test public void testB() {
- assertEquals("testB", name.getMethodName());
- }
- }
-
-- The Timeout Rule applies the same timeout to all test methods in a class:
-
- public static class HasGlobalTimeout {
- public static String log;
-
- @Rule public MethodRule globalTimeout = new Timeout(20);
-
- @Test public void testInfiniteLoop1() {
- log+= "ran1";
- for(;;) {}
- }
-
- @Test public void testInfiniteLoop2() {
- log+= "ran2";
- for(;;) {}
- }
- }
-
-- The ExpectedException Rule allows in-test specification
- of expected exception types and messages:
-
- public static class HasExpectedException {
- @Rule
- public ExpectedException thrown= ExpectedException.none();
-
- @Test
- public void throwsNothing() {
-
- }
-
- @Test
- public void throwsNullPointerException() {
- thrown.expect(NullPointerException.class);
- throw new NullPointerException();
- }
-
- @Test
- public void throwsNullPointerExceptionWithMessage() {
- thrown.expect(NullPointerException.class);
- thrown.expectMessage("happened?");
- thrown.expectMessage(startsWith("What"));
- throw new NullPointerException("What happened?");
- }
- }
-
-### Timeouts ###
-- Tests that time out now show the stack trace of the test thread.
-
-### Matchers ###
-- Due to typing incompatibilities, JUnit is still including the 1.1 release
- of hamcrest. This is not a change from 4.6, but is a change from
- pre-beta releases of 4.7. Due to this incompatibility, tests using
- Hamcrest 1.2 must still use the MatcherAssert.assertThat method from
- Hamcrest, not Assert.assertThat from JUnit.
-
-### Docs ###
-- Javadocs now link to online JDK javadocs (bug 2090230)
-- Parameterized runner javadocs improved (bug 2186792)
-- Fixed Javadoc code sample for AfterClass (2126279)
-- Fixed Javadoc for assertArraysEqual(float[], float[])
-
-### Bug fixes ###
-- Fixed: BaseTestRunner.getTest() requires class to extend TestCase (1812200)
-- Fixed: Suite does not allow for inheritance in annotations (2783118)
-- Fixed: ParallelComputer skipped tests that took longer than 2 seconds
+Please see ReleaseNotes4.7.md
View
7 doc/ReleaseNotes4.8.1.md
@@ -0,0 +1,7 @@
+## Summary of Changes in version 4.8.1 ##
+
+This was a quick bugfix release for an important bug
+
+### Bug fixes ###
+
+- github#61: Category annotations on classes were not honored.
View
8 doc/ReleaseNotes4.8.1.txt
@@ -1,7 +1 @@
-## Summary of Changes in version 4.8.1 ##
-
-This was a quick bugfix release for an important bug
-
-### Bug fixes ###
-
-- github#61: Category annotations on classes were not honored.
+Please see ReleaseNotes4.8.1.md
View
8 doc/ReleaseNotes4.8.2.md
@@ -0,0 +1,8 @@
+## Summary of Changes in version 4.8.2 ##
+
+This was a quick bugfix release
+
+### Bug fixes ###
+
+- github#96: TestSuite(MyTestCase.class) should dynamically detect if MyTestCase
+ is a TestCase
View
9 doc/ReleaseNotes4.8.2.txt
@@ -1,8 +1 @@
-## Summary of Changes in version 4.8.2 ##
-
-This was a quick bugfix release
-
-### Bug fixes ###
-
-- github#96: TestSuite(MyTestCase.class) should dynamically detect if MyTestCase
- is a TestCase
+Please see ReleaseNotes4.8.2.md
View
56 doc/ReleaseNotes4.8.md
@@ -0,0 +1,56 @@
+## Summary of Changes in version 4.8 ##
+
+### Categories ###
+
+From a given set of test classes, the `Categories` runner
+runs only the classes and methods
+that are annotated with either the category given with the `@IncludeCategory`
+annotation, or a subtype of that category. Either classes or interfaces can be
+used as categories. Subtyping works, so if you say `@IncludeCategory(SuperClass.class)`,
+a test marked `@Category({SubClass.class})` will be run.
+
+You can also exclude categories by using the `@ExcludeCategory` annotation
+
+Example:
+
+ public interface FastTests { /* category marker */ }
+ public interface SlowTests { /* category marker */ }
+
+ public class A {
+ @Test
+ public void a() {
+ fail();
+ }
+
+ @Category(SlowTests.class)
+ @Test
+ public void b() {
+ }
+ }
+
+ @Category({SlowTests.class, FastTests.class})
+ public class B {
+ @Test
+ public void c() {
+
+ }
+ }
+
+ @RunWith(Categories.class)
+ @IncludeCategory(SlowTests.class)
+ @SuiteClasses( { A.class, B.class }) // Note that Categories is a kind of Suite
+ public class SlowTestSuite {
+ // Will run A.b and B.c, but not A.a
+ }
+
+ @RunWith(Categories.class)
+ @IncludeCategory(SlowTests.class)
+ @ExcludeCategory(FastTests.class)
+ @SuiteClasses( { A.class, B.class }) // Note that Categories is a kind of Suite
+ public class SlowTestSuite {
+ // Will run A.b, but not A.a or B.c
+ }
+
+### Bug fixes ###
+
+- github#16: thread safety of Result counting
View
57 doc/ReleaseNotes4.8.txt
@@ -1,56 +1 @@
-## Summary of Changes in version 4.8 ##
-
-### Categories ###
-
-From a given set of test classes, the `Categories` runner
-runs only the classes and methods
-that are annotated with either the category given with the `@IncludeCategory`
-annotation, or a subtype of that category. Either classes or interfaces can be
-used as categories. Subtyping works, so if you say `@IncludeCategory(SuperClass.class)`,
-a test marked `@Category({SubClass.class})` will be run.
-
-You can also exclude categories by using the `@ExcludeCategory` annotation
-
-Example:
-
- public interface FastTests { /* category marker */ }
- public interface SlowTests { /* category marker */ }
-
- public class A {
- @Test
- public void a() {
- fail();
- }
-
- @Category(SlowTests.class)
- @Test
- public void b() {
- }
- }
-
- @Category({SlowTests.class, FastTests.class})
- public class B {
- @Test
- public void c() {
-
- }
- }
-
- @RunWith(Categories.class)
- @IncludeCategory(SlowTests.class)
- @SuiteClasses( { A.class, B.class }) // Note that Categories is a kind of Suite
- public class SlowTestSuite {
- // Will run A.b and B.c, but not A.a
- }
-
- @RunWith(Categories.class)
- @IncludeCategory(SlowTests.class)
- @ExcludeCategory(FastTests.class)
- @SuiteClasses( { A.class, B.class }) // Note that Categories is a kind of Suite
- public class SlowTestSuite {
- // Will run A.b, but not A.a or B.c
- }
-
-### Bug fixes ###
-
-- github#16: thread safety of Result counting
+Please see ReleaseNotes4.8.md
View
14 doc/ReleaseNotes4.9.1.md
@@ -0,0 +1,14 @@
+## Summary of Changes in version 4.9.1 [unreleased!] ##
+
+### Theories ###
+
+The `Theories` runner does not anticipate theory parameters that have generic
+types, as reported by github#64. Fixing this won't happen until `Theories` is
+moved to junit-contrib. In anticipation of this, 4.9.1 adds some of the
+necessary machinery to the runner classes, and deprecates a method that only
+the `Theories` runner uses, `FrameworkMethod`#producesType().
+The Common Public License that JUnit is released under is now included
+in the source repository.
+
+Thanks to `@pholser` for identifying a potential resolution for github#64
+and initiating work on it.
View
15 doc/ReleaseNotes4.9.1.txt
@@ -1,14 +1 @@
-## Summary of Changes in version 4.9.1 [unreleased!] ##
-
-### Theories ###
-
-The `Theories` runner does not anticipate theory parameters that have generic
-types, as reported by github#64. Fixing this won't happen until `Theories` is
-moved to junit-contrib. In anticipation of this, 4.9.1 adds some of the
-necessary machinery to the runner classes, and deprecates a method that only
-the `Theories` runner uses, `FrameworkMethod`#producesType().
-The Common Public License that JUnit is released under is now included
-in the source repository.
-
-Thanks to `@pholser` for identifying a potential resolution for github#64
-and initiating work on it.
+Please see ReleaseNotes4.9.1.md
View
89 doc/ReleaseNotes4.9.md
@@ -0,0 +1,89 @@
+## Summary of Changes in version 4.9, final ##
+
+Release theme: Test-class and suite level Rules.
+
+### ClassRule ###
+
+The `ClassRule` annotation extends the idea of method-level Rules,
+adding static fields that can affect the operation of a whole class. Any
+subclass of `ParentRunner`, including the standard `BlockJUnit4ClassRunner`
+and `Suite` classes, will support `ClassRule`s.
+
+For example, here is a test suite that connects to a server once before
+all the test classes run, and disconnects after they are finished:
+
+ @RunWith(Suite.class)
+ @SuiteClasses({A.class, B.class, C.class})
+ public class UsesExternalResource {
+ public static Server myServer= new Server();
+
+ @ClassRule
+ public static ExternalResource resource= new ExternalResource() {
+ @Override
+ protected void before() throws Throwable {
+ myServer.connect();
+ };
+
+ @Override
+ protected void after() {
+ myServer.disconnect();
+ };
+ };
+ }
+
+### TestRule ###
+
+In JUnit 4.9, fields that can be annotated with either `@Rule` or `@ClassRule`
+should be of type `TestRule`. The old `MethodRule` type, which only made sense
+for method-level rules, will still work, but is deprecated.
+
+Most built-in Rules have been moved to the new type already, in a way that
+should be transparent to most users. `TestWatchman` has been deprecated,
+and replaced by `TestWatcher`, which has the same functionality, but implements
+the new type.
+
+### Maven support ###
+
+Maven bundles have, in the past, been uploaded by kind volunteers. Starting
+with this release, the JUnit team is attempting to perform this task ourselves.
+
+### LICENSE checked in ###
+
+The Common Public License that JUnit is released under is now included
+in the source repository.
+
+### Bug fixes ###
+
+- github#98: assumeTrue() does not work with expected exceptions
+- github#74: Categories + Parameterized
+
+ In JUnit 4.8.2, the Categories runner would fail to run correctly
+ if any contained test class had a custom Runner with a structure
+ significantly different from the built-in Runner. With this fix,
+ such classes can be assigned one or more categories at the class level,
+ and will be run correctly. Trying to assign categories to methods within
+ such a class will flag an error.
+
+- github#38: ParentRunner filters more than once
+
+ Thanks to `@reinholdfuereder`
+
+- github#248: protected BlockJUnit4ClassRunner#rules method removed from 4.8.2
+- github#187: Accidental dependency on Java 6
+
+Thanks to `@kcooney` for:
+
+- github#163: Bad comparison failure message when using assertEquals(String, String)
+- github#227: ParentRunner now assumes that getChildren() returns a modifiable list
+
+### Minor changes ###
+
+- Backed out unused folder "experimental-use-of-antunit", replaced by
+ bash-based script at build_tests.sh
+- Various Javadoc fixes
+
+Thanks to `@kcooney` for:
+
+- Made MultipleFailureException public, to assist extension writers.
+- github#240: Add "test" target to build.xml, for faster ant-driven testing.
+- github#247: Give InitializationError a useful message
View
90 doc/ReleaseNotes4.9.txt
@@ -1,89 +1 @@
-## Summary of Changes in version 4.9, final ##
-
-Release theme: Test-class and suite level Rules.
-
-### ClassRule ###
-
-The `ClassRule` annotation extends the idea of method-level Rules,
-adding static fields that can affect the operation of a whole class. Any
-subclass of `ParentRunner`, including the standard `BlockJUnit4ClassRunner`
-and `Suite` classes, will support `ClassRule`s.
-
-For example, here is a test suite that connects to a server once before
-all the test classes run, and disconnects after they are finished:
-
- @RunWith(Suite.class)
- @SuiteClasses({A.class, B.class, C.class})
- public class UsesExternalResource {
- public static Server myServer= new Server();
-
- @ClassRule
- public static ExternalResource resource= new ExternalResource() {
- @Override
- protected void before() throws Throwable {
- myServer.connect();
- };
-
- @Override
- protected void after() {
- myServer.disconnect();
- };
- };
- }
-
-### TestRule ###
-
-In JUnit 4.9, fields that can be annotated with either `@Rule` or `@ClassRule`
-should be of type `TestRule`. The old `MethodRule` type, which only made sense
-for method-level rules, will still work, but is deprecated.
-
-Most built-in Rules have been moved to the new type already, in a way that
-should be transparent to most users. `TestWatchman` has been deprecated,
-and replaced by `TestWatcher`, which has the same functionality, but implements
-the new type.
-
-### Maven support ###
-
-Maven bundles have, in the past, been uploaded by kind volunteers. Starting
-with this release, the JUnit team is attempting to perform this task ourselves.
-
-### LICENSE checked in ###
-
-The Common Public License that JUnit is released under is now included
-in the source repository.
-
-### Bug fixes ###
-
-- github#98: assumeTrue() does not work with expected exceptions
-- github#74: Categories + Parameterized
-
- In JUnit 4.8.2, the Categories runner would fail to run correctly
- if any contained test class had a custom Runner with a structure
- significantly different from the built-in Runner. With this fix,
- such classes can be assigned one or more categories at the class level,
- and will be run correctly. Trying to assign categories to methods within
- such a class will flag an error.
-
-- github#38: ParentRunner filters more than once
-
- Thanks to `@reinholdfuereder`
-
-- github#248: protected BlockJUnit4ClassRunner#rules method removed from 4.8.2
-- github#187: Accidental dependency on Java 6
-
-Thanks to `@kcooney` for:
-
-- github#163: Bad comparison failure message when using assertEquals(String, String)
-- github#227: ParentRunner now assumes that getChildren() returns a modifiable list
-
-### Minor changes ###
-
-- Backed out unused folder "experimental-use-of-antunit", replaced by
- bash-based script at build_tests.sh
-- Various Javadoc fixes
-
-Thanks to `@kcooney` for:
-
-- Made MultipleFailureException public, to assist extension writers.
-- github#240: Add "test" target to build.xml, for faster ant-driven testing.
-- github#247: Give InitializationError a useful message
+Please see ReleaseNotes4.9.md

0 comments on commit ed01efa

Please sign in to comment.
Something went wrong with that request. Please try again.