`'"
### [Pull request #1406 (part 2)](https://github.com/junit-team/junit4/pull/1406): TemporaryFolder.newFolder(String...) supports path separator
You can now pass paths with path separators to `TemporaryFolder.newFolder(String...)`. E.g.
tempFolder.newFolder("temp1", "temp2", "temp3/temp4")
It creates a folder `temp1/temp2/temp3/temp4`.
### [Pull request #1406 (part 3)](https://github.com/junit-team/junit4/pull/1406): TemporaryFolder.newFolder(String...) fails for empty array
When you call
tempFolder.newFolder(new String[])
then it throws an `IllegalArgumentException` instead of returning an already existing folder.
### [Pull request #1335](https://github.com/junit-team/junit4/pull/1335): Fix ExternalResource: the test failure could be lost
When both the test failed and closing the resource failed, only the exception coming from the `after()` method was propagated, as per semantics of the try-finally (see also http://docs.oracle.com/javase/specs/jls/se8/html/jls-14.html#jls-14.20.2).
The new behavior is compatible with @After method semantics, as implemented in [RunAfters](https://github.com/junit-team/junit4/blob/HEAD/src/main/java/org/junit/internal/runners/statements/RunAfters.java).
### [Pull request #1435](https://github.com/junit-team/junit4/pull/1435): @BeforeParam/@AfterParam method annotations for Parameterized tests.
This allows having preparation and/or cleanup in tests for specific parameter values.
### [Pull request #1460](https://github.com/junit-team/junit4/pull/1460): Handle assumption violations in the @Parameters method for Parameterized tests.
This allows skipping the whole test class when its assumptions are not met.
### [Pull request #1445](https://github.com/junit-team/junit4/pull/1445) and [Pull request #1335](https://github.com/junit-team/junit4/pull/1501): Declarative ordering of rules.
The order in which rules are executed is specified by the annotation attribute: `@Rule(order = N)`, deprecating `RuleChain`. This may be used for avoiding some common pitfalls with `TestWatcher, `ErrorCollector` and `ExpectedException` for example. The Javadoc of `TestWatcher` was retrofitted accordingly.
### [Pull request #1517](https://github.com/junit-team/junit4/pull/1517): Timeout rule destroys its ThreadGroups at the end
The `ThreadGroup` created for handling the timeout of tests is now destroyed, so the main thread group no longer keeps a reference to all timeout groups created during the tests. This caused the `threadGroup` to remain in memory, and all of its context along with it.
### [Pull request #1633](https://github.com/junit-team/junit4/pull/1633): Deprecate ExpectedException.none()
The method Assert.assertThrows provides a nicer way for verifying exceptions. In addition the use of ExpectedException is error-prone when used with other rules like TestWatcher because the order of rules is important in that case.
### [Pull request #1413](https://github.com/junit-team/junit4/pull/1413): Ignore bridge methods when scanning for annotated methods
In a setup with a class hierarchy for test classes the order of rules (from methods), before methods, after methods and others depends on the class that contains these methods. Compilers can add bridge methods to child classes and therefore the order of the aforementioned methods can change in older JUnit releases. This is now fixed because bridge methods are ignored when scanning for annotated methods.
### [Pull request #1612](https://github.com/junit-team/junit4/pull/1612): Make @ValidateWith only applicable to annotation types
`@Target(ANNOTATION_TYPE)` has been added to `@ValidateWith` since it's only designed to be applied to another annotation.
# Run Listener
### [Pull request #1118:](https://github.com/junit-team/junit4/pull/1118) Add suite start/finish events to listener
The `RunListener` class now has `fireTestSuiteStarted` and `fireTestSuiteFinished` methods that notify when test suites are about to be started/finished.
# Exception Testing
### [Pull request #1359:](https://github.com/junit-team/junit4/pull/1359) Fixes how `MultipleFailureException` stack traces are printed
Previously, calling `MultipleFailureException.printStackTrace()` only printed the stack trace for the `MultipleFailureException` itself. After this change, the stack trace for each exception caught in the `MultipleFailureException` is printed.
### [Pull request #1376:](https://github.com/junit-team/junit4/pull/1376) Initializing MultipleFailureException with an empty list will now fail the test
Previously, initializing `MultipleFailureException` with an empty list of contained Exceptions and throwing it in a test case wouldn't actually fail the test. Now an `IllegalArgumentException` will be raised in this situation and thus also fail the test.
### [Pull request #1371:](https://github.com/junit-team/junit4/pull/1371) Update MultipleFailureException.assertEmpty() to wrap assumption failure
`MultipleFailureException` will now wrap `MultipleFailureException` with `TestCouldNotBeSkippedException`. Previously, if you passed `MultipleFailureException` one `MultipleFailureException`--and no other exceptions--
then the test would be skipped, otherwise it would fail. With the new behavior, it will always fail.
### [Issue #1290:](https://github.com/junit-team/junit4/issues/1290) `@Test(expected = AssumptionViolatedException.class)` passes for AssumptionViolatedException
Tests annotated with `@test(expected = AssumptionViolatedException.class)`
which throw AssumptionViolatedException had been marked as skipped. Now the are marked as successful tests.
# JUnit 3 Changes
### [Pull request #1227:](https://github.com/junit-team/junit/pull/1227) Behave better if the `SecurityManager` denies access to `junit.properties`
Previously, running tests with a `SecurityManager` would cause the test runner itself to throw an `AccessControlException` if the security policy didn't want it reading from `~/junit.properties`. This will now be treated the same as if the file does not exist.
# Misc
### [Pull request #1571:](https://github.com/junit-team/junit4/pull/1571) Set "junit" as "Automatic-Module-Name"
For existing releases of JUnit the `Automatic-Module-Name` was derived from the name of the jar. In most cases it is already the name "junit". JUnit 4.13 explicitly sets the module name to "junit" so that it is independent from the jar's name.
### [Pull request #1028:](https://github.com/junit-team/junit4/pull/1028) Trim stack trace
JUnit's command-line runner (`JUnitCore`) prints smaller stack traces. It skips all stack trace elements that come before the test method so that it starts at the test method. E.g. the output for the example from [Getting started](https://github.com/junit-team/junit4/wiki/Getting-started) page is now
.E
Time: 0,006
There was 1 failure:
1) evaluatesExpression(CalculatorTest)
java.lang.AssertionError: expected:<6> but was:<-6>
at org.junit.Assert.fail(Assert.java:89)
at org.junit.Assert.failNotEquals(Assert.java:835)
at org.junit.Assert.assertEquals(Assert.java:647)
at org.junit.Assert.assertEquals(Assert.java:633)
at CalculatorTest.evaluatesExpression(CalculatorTest.java:9)
FAILURES!!!
Tests run: 1, Failures: 1
### [Pull request #1403:](https://github.com/junit-team/junit4/pull/1403) Restore CategoryFilter constructor
The constructor `CategoryFilter(Class> includedCategory, Class> excludedCategory)` has been removed in JUnit 4.12. It is now available again.
### [Pull request #1530:](https://github.com/junit-team/junit4/pull/1530) Add Result#getAssumptionFailureCount
Add method `getAssumptionFailureCount()` to `Result` which returns the number of assumption failures.
### [Pull request #1292:](https://github.com/junit-team/junit4/pull/1292) Fix ResultMatchers#hasFailureContaining
`ResultMatchers.hasFailureContaining()` should return `false` when the given `PrintableResult` has no failures.
### [Pull request #1380:](https://github.com/junit-team/junit4/pull/1380) Fix Assume#assumeNotNull
`Assume.assumeNotNull` should throw AssumptionViolatedException when called with a `null` array.
### [Pull request #1557:](https://github.com/junit-team/junit4/pull/1380) MaxCore always closes stream of history file
MaxCore didn't close the output stream of the history file when write failed. Now it does.
### Signing
The 4.13 release is signed with a new key (id 5EC61B51):
https://github.com/junit-team/junit4/blob/8c0df64ff17fead54c304a8b189da839084925c2/KEYS
junit4-r4.13.2/doc/ReleaseNotes4.4.html 0000664 0000000 0000000 00000027665 14011777271 0017501 0 ustar 00root root 0000000 0000000 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
Miscellaneous
@Before
and @After
methods are run before and after each set of attempted parameters
on a Theory
Refactoring removed duplication that used to exist in classes MethodRoadie and ClassRoadie
Exposed API ParameterSignature.getType()
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
assertThat
Two years ago, Joe Walnes built a new assertion mechanism on top of what was
then JMock 1. The method name was assertThat
, and the syntax looked like this:
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.
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.
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.
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.
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.
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.
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.
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 can be found
there.
Defining general statements in this way can jog the developer's memory
about other potential data points and tests, also allows automated
tools to search for new, unexpected data
points that expose bugs.
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:
If the class has a @RunWith
annotation, the annotated runner
class is used.
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.
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.
junit4-r4.13.2/doc/ReleaseNotes4.4.md 0000664 0000000 0000000 00000026623 14011777271 0017126 0 ustar 00root root 0000000 0000000 ## Summary of Changes in version 4.5 ##
### Categories ###
Each test method and test class can be annotated as belonging to a _category_:
```java
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:
```java
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://joewalnes.com/2005/05/13/flexible-junit-assertions-with-assertthat/
[JMock 1]: http://www.jmock.org/download.html
```java
assertThat(x, is(3));
assertThat(x, is(not(4)));
assertThat(responseString, either(containsString("color")).or(containsString("colour")));
assertThat(myList, hasItem("3"));
```
More generally:
```java
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
```java
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:
```java
import static org.hamcrest.CoreMatchers.is;
```
or:
```java
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.
### 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":
```java
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.
### 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:
```java
@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:
```java
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:
```java
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:
```java
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.
junit4-r4.13.2/doc/ReleaseNotes4.4.txt 0000664 0000000 0000000 00000000036 14011777271 0017333 0 ustar 00root root 0000000 0000000 Please see ReleaseNotes4.4.md
junit4-r4.13.2/doc/ReleaseNotes4.5.html 0000664 0000000 0000000 00000036023 14011777271 0017466 0 ustar 00root root 0000000 0000000 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
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.
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.
assertThat
Two years ago, Joe Walnes built a new assertion mechanism on top of what was
then JMock 1. The method name was assertThat
, and the syntax looked like this:
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") rathern 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.:
We have decided to include this API directly in JUnit.
It's an extensible and readable syntax, and because it enables
new features, like assumptions and 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.
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.
To allow developers to maintain full control of the classpath contents, the JUnit distribution also provides an unbundled junit-dep jar,
ie without hamcrest-core classes included. This is intended for situations when using other libraries that also depend on hamcrest-core, to
avoid classloading conflicts or issues. Developers using junit-dep should ensure a compatible version of hamcrest-core jar (ie 1.1+) is present in the classpath.
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.
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.
assumeThat
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 beta release, a failed assumption will lead to the test being marked as passing,
regardless of what the code below the assumption may assert.
In the future, this may change, and a failed assumption may lead to the test being ignored:
however, third-party runners do not currently allow this option.
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.
Theories
More flexible and expressive assertions, combined with the ability to
state assumptions clearly, lead to a new kind of statement of intent,
which we call a "Theory". A test captures the intended behavior in
one particular scenario. A theory allows a developer to be
as precise as desired about the behavior of the code in possibly
infinite numbers of possible scenarios. For example:
@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 can be found
there.
Defining general statements in this way can jog the developer's memory
about other potential data points and tests, also allows automated
tools to search for new, unexpected data
points that expose bugs.
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:
If the class has a @RunWith
annotation, the annotated runner
class is used.
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.
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.
junit4-r4.13.2/doc/ReleaseNotes4.5.md 0000664 0000000 0000000 00000006601 14011777271 0017121 0 ustar 00root root 0000000 0000000 ## 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
junit4-r4.13.2/doc/ReleaseNotes4.5.txt 0000664 0000000 0000000 00000000036 14011777271 0017334 0 ustar 00root root 0000000 0000000 Please see ReleaseNotes4.5.md
junit4-r4.13.2/doc/ReleaseNotes4.6.html 0000664 0000000 0000000 00000006607 14011777271 0017474 0 ustar 00root root 0000000 0000000 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)
junit4-r4.13.2/doc/ReleaseNotes4.6.md 0000664 0000000 0000000 00000005732 14011777271 0017126 0 ustar 00root root 0000000 0000000 ## 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:
```java
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 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:
```java
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:
```java
@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)
junit4-r4.13.2/doc/ReleaseNotes4.6.txt 0000664 0000000 0000000 00000000036 14011777271 0017335 0 ustar 00root root 0000000 0000000 Please see ReleaseNotes4.6.md
junit4-r4.13.2/doc/ReleaseNotes4.7.html 0000664 0000000 0000000 00000013321 14011777271 0017464 0 ustar 00root root 0000000 0000000 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
junit4-r4.13.2/doc/ReleaseNotes4.7.md 0000664 0000000 0000000 00000012305 14011777271 0017121 0 ustar 00root root 0000000 0000000 ## 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):
```java
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:
```java
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):
```java
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
```java
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:
```java
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:
```java
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:
```java
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:
```java
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
junit4-r4.13.2/doc/ReleaseNotes4.7.txt 0000664 0000000 0000000 00000000036 14011777271 0017336 0 ustar 00root root 0000000 0000000 Please see ReleaseNotes4.7.md
junit4-r4.13.2/doc/ReleaseNotes4.8.1.html 0000664 0000000 0000000 00000000320 14011777271 0017617 0 ustar 00root root 0000000 0000000 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.
junit4-r4.13.2/doc/ReleaseNotes4.8.1.md 0000664 0000000 0000000 00000000262 14011777271 0017260 0 ustar 00root root 0000000 0000000 ## 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. junit4-r4.13.2/doc/ReleaseNotes4.8.1.txt 0000664 0000000 0000000 00000000040 14011777271 0017471 0 ustar 00root root 0000000 0000000 Please see ReleaseNotes4.8.1.md
junit4-r4.13.2/doc/ReleaseNotes4.8.2.html 0000664 0000000 0000000 00000000333 14011777271 0017624 0 ustar 00root root 0000000 0000000 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
junit4-r4.13.2/doc/ReleaseNotes4.8.2.md 0000664 0000000 0000000 00000000300 14011777271 0017252 0 ustar 00root root 0000000 0000000 ## 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
junit4-r4.13.2/doc/ReleaseNotes4.8.2.txt 0000664 0000000 0000000 00000000040 14011777271 0017472 0 ustar 00root root 0000000 0000000 Please see ReleaseNotes4.8.2.md
junit4-r4.13.2/doc/ReleaseNotes4.8.html 0000664 0000000 0000000 00000003011 14011777271 0017460 0 ustar 00root root 0000000 0000000 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
junit4-r4.13.2/doc/ReleaseNotes4.8.md 0000664 0000000 0000000 00000002563 14011777271 0017127 0 ustar 00root root 0000000 0000000 ## 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:
```java
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
junit4-r4.13.2/doc/ReleaseNotes4.8.txt 0000664 0000000 0000000 00000000036 14011777271 0017337 0 ustar 00root root 0000000 0000000 Please see ReleaseNotes4.8.md
junit4-r4.13.2/doc/ReleaseNotes4.9.1.md 0000664 0000000 0000000 00000001203 14011777271 0017255 0 ustar 00root root 0000000 0000000 ## 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.
junit4-r4.13.2/doc/ReleaseNotes4.9.1.txt 0000664 0000000 0000000 00000000040 14011777271 0017472 0 ustar 00root root 0000000 0000000 Please see ReleaseNotes4.9.1.md
junit4-r4.13.2/doc/ReleaseNotes4.9.html 0000664 0000000 0000000 00000006617 14011777271 0017500 0 ustar 00root root 0000000 0000000 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
junit4-r4.13.2/doc/ReleaseNotes4.9.md 0000664 0000000 0000000 00000005716 14011777271 0017133 0 ustar 00root root 0000000 0000000 ## 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:
```java
@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
junit4-r4.13.2/doc/ReleaseNotes4.9.txt 0000664 0000000 0000000 00000000036 14011777271 0017340 0 ustar 00root root 0000000 0000000 Please see ReleaseNotes4.9.md
junit4-r4.13.2/doc/building-junit.txt 0000664 0000000 0000000 00000011175 14011777271 0017446 0 ustar 00root root 0000000 0000000 Steps to build junit:
- Must be manual
- Write release notes
- Not too tedious:
- Push to github (junit-team)
- Run the ./mvnw clean install
- If not done, update $M2_HOME/settings.xml
- If not done, copy GnuPG keys in to ${gpg.homedir}. See settings.xml.
- Perform Maven deployment of a snapshot or release version in Jenkins
Remember that the version specified in the pom.xml indicates the version
to be deployed, with -SNAPSHOT indicating that this is an unofficial
pre-release version towards the goal of the version without the -SNAPSHOT
- (to deploy gpg signed snapshot version)
$ ./mvnw -Pjunit-release clean deploy
- (to cut a release of the current targetted version)
$ ./mvnw -B release:prepare release:perform
This will result in the current pom.xml version having -SNAPSHOT removed
and the release cut from that version. The version will then be incremented
and -SNAPSHOT added back in anticipation of the next release version.
- (to cut a release of while changing the version from the current target)
$ ./mvnw -B -DreleaseVersion=5.0 release:prepare release:perform
This will ignore the current version in the pom.xml, set it to 5.0 and
the release cut from that 5.0 version. Then 5.0 will be incremented (to 5.1)
and -SNAPSHOT added back in anticipation of the next release version.
- (to deploy specified release version and next target release in non-interactive mode -B)
An example with the next development version and deploying release version:
$ ./mvnw -B -DreleaseVersion=4.12 -DdevelopmentVersion=4.13-SNAPSHOT release:prepare release:perform
- If you are not an official release manager, and you want to cut a release of
JUnit for use within your organization, use the following command
$ ./mvnw -DpushChanges=false -DlocalCheckout '-Darguments=-Dgpg.skip=true -DaltDeploymentRepository=my-company-repo-id::default::my-company-repo-url' -B -DreleaseVersion=4.12-mycompany-1 release:prepare release:perform
where
- my-company-repo-id is the of your company's entry in your
settings.xml with the credentials to deploy to your company's Maven repository
- my-company-repo-url is the deployment URL of your company's Maven repository
- 4.12-mycompany-1 is the version you are deploying, be sure to namespace
the version so that you don't conflict with others, hence why the text "mycompany"
is included in the example version number.
- Promote the maven artifacts and close staging repository if released successfully
- Tedious:
- Update SourceForge if major release
- Update javadocs on github site (and "latest" link)
- Update javadocs on junit.org
- Put release notes on github.
- Announce on blog, user list, dev list, announce list, junit.org, twitter
- Profit!
===================================================================================
== Internal template of Maven settings used by JUnit build machine. ==
== settings.xml ==
===================================================================================
junit-snapshot-repo
junit-releases-repo
junit-release
...
false
true
/private/.../.gnupg
/private/.../.gnupg/pubring.gpg
/private/.../.gnupg/secring.gpg
===================================================================================
junit4-r4.13.2/doc/cookstour/ 0000775 0000000 0000000 00000000000 14011777271 0016004 5 ustar 00root root 0000000 0000000 junit4-r4.13.2/doc/cookstour/Image1.gif 0000664 0000000 0000000 00000003434 14011777271 0017602 0 ustar 00root root 0000000 0000000 GIF89a \ , \ @ H*\ȰÇ#JHŋ3jȱǏ CI$H&S
Dː,"f5sĉSAϝ12QDnL
qAP&5*UUju`e#YN*0So8]q.+]t-CWzM,qŐFxLAWbya ~
q4ӨS^ͺװc˞MM֍7BkҜٓ8qDžLaGOdSޞݺS5Nӫ_~b|r
|Vjf]wzcUa(g?
GOU!}^^r!_r`h{0(h8<@)DtEdkK&bsH:TC9gB'
b%:]fkeP>1\|5RfgzdT%gjh`1&AFk)
hD>*^@*^U_i^vږ\W*5]vUd'[zJ봓V/[fa;fjg-נfJEj+k ,lK7f*qGVx1gb1pQnHOM_OLi.K
5yh&lYcs8%9L2+=͝QeU\]}X͗VUi_
s~MN:ob6pznoM]}o}hZ51{*ޅ*k-Qއ+8k(ު@2+( bVbGu.W妋Ny7KTۏ79tY_A?k
6^cϵ}F]}wDqiFS (Ëɞߴ$vctnNjS#A.9ˁ+!BH `H8̡w@H@ ; junit4-r4.13.2/doc/cookstour/Image2.gif 0000664 0000000 0000000 00000004672 14011777271 0017610 0 ustar 00root root 0000000 0000000 GIF89a , @ H*\ȰÇ#JHŋ3jȱǏ CIɓ("HRʖ0c$2!.q@<YsD3*tiǦNJuŪ$X+WZzvزbӚ],۵oEKU~Ew^~+
-x$VE]LS]2ZC+<0ң=sVͨQNm3?ݶݧɾNȓ+_μr!Wy:4#[w7/L铑j,tz%/ +\ϾPս_~t&F(VhfaZxQ9AvK'h%"D Ha(c)<@I7hؒJƤbh9I֓S6ԁ(%pK&vژY@VF&cj~&9cVus̙F衈&Z\oadCH,"i)~#Umi}o*D>F\f]Zވ k;
6F+VkfۨjR-J
E{฿.DOP첺}/HT:|0H
;~rrV %Cp<Mʵq0,&NԲYyXk^_w&3lzEtc"ugf'jz֜֙5yu}N".ZY*jfzqHK3m#VWM\]W}kv٩G+) "3'wrJ9YjktoXyܼK%;nidMOzeFfGjjz=ۭz/o H^YLsdر3rTґEE b$TTAn'I{
(]*W 78/qP0a9H0
hۏzB谈1Dt5%O_;ĉL$W_KEuq[U(Fy0xZ~63ťcH!phx#8qyd)@B*"G R!E,4){ yI5oq$ F~1FO 4R,JSڔ2+$7BJ$hˤ5S
DT]3= $
&9)(R5aӦٚiaK;i4ɞF05><\<~~3f?MCyѳER&JУ写Kin43C͓l)6ڣFIԢ:=RԦ:uq̀JXͪVգqJdϺJֲլ}hs#g\U~֣!xB=B
Wv/wym4Rv]r[ ;㱊LYS_T_hYqgi DszNa@'RZS[ah*.ͭnY҂NsmXl0V-55mtre%lc:XFw!o%r>7}-q8?=ۃ\pRԹU`5WM_y˳M0t+7{ GLZ ; junit4-r4.13.2/doc/cookstour/Image3.gif 0000664 0000000 0000000 00000005602 14011777271 0017603 0 ustar 00root root 0000000 0000000 GIF89aE , E @ H*\ȰÇ#JHŋ3jȱǏ CIɓ(S\ɲ˗$P&͛8sO>jshСT:ϓOuJ2*UVj1+ת1f*!ٲ%ώe(ХmV)ݤE]H߿LaHy
4Φ#+~8reƓ%CmE8ҡS=xQO3_^ٲK9${Ɖ#_{}^tֳޮ;wY|vSܷ@߃-|W_|7`~&_} oE%Z݆qa ~(b RșeI&-X+p4bZ\ը<@)DiH&L6$EE)TVyؓXx_ٌY6Zlz1%\f:ך8y=!IVwAjbgRcs~_P"OxN^(\hhXgF^eQifl娞vzggKզ*X8D$"u$hl[[IכWT`˟˟[Y:T6lu͆X0tFJkvv/h5hf;20,4l8<@-DmtY.ѷݼ4,5Vڗɚs B>=dg3iv@rmdh*5\o]Jr~<ƹkiHR]{]l(!1>\%v:!^5.wH{ٳLqT(N|qm]5萣Ѓ }8qNݱB=#!Ro]7ܽ=߷?~>Uב݇arN?|
v-V ֡#Ru: )p^zPJ(.
^Ve0( וsUkC ]JdNE/B"ik(Ɗf_6]]2W|#FMIȂa!?HRhCmp !RG;fRN$(&RL*WV,gIZ̥.w^0ILLz%2IedZ.A%Fs1?mufCmnO^4NQ8Murg"1]R
G&}l&B
̅2T1#YE=ٷd A!лnf~3)&:R%H.Yh(ݧ8y29zXH zS I:ݒy״'9ES1)渶eu[6ǖIA5RMVIt+] %7:ΫrPVJ!.];=ۊԗZer-\7}骓 IeW]5V4SUMcmij}vIdcRTf
kZ^5m{}e:rUA\ ik(dn@
=no(;F^.r0M$` cAAJpYꅯ|_l$kGYEV 28pCvdﵯVF0`FnHnc1 -z7/N=2Dˁf0|w
t?+FEDIt.[֗$8r0(U@:@s|Lg!Á̮Byx3L8)f+_b07p|7?U(drtil5+
BmNzѩF t-zՊ.
J
EaAF1w`{,`e?涺gYq53c}o~; Ƿ-Aڷ\.p?[F%N!fKpI<&gO9vT^0GesbMdMݴŭ-?ri.C.E-Ao:-uwҲĺuޥzQNhOpZ@ ; junit4-r4.13.2/doc/cookstour/Image4.gif 0000664 0000000 0000000 00000007156 14011777271 0017612 0 ustar 00root root 0000000 0000000 GIF89a , @ H*\ȰÇ#JHŋ3jȱǏ CIɓ(E"Hɒʖ0c|M6s9Ц@uSh˛2*tӠOJMtӪV&ŪU&`O~gO Ylƅ[-\aWl߿&}[Pr.EƎgF!v3Vʠ1zq4o\˚nWv}3IӨO-q7oʇNȓ\uX$H }uձS>=s~]uc'>|o\pkK|zy@ؠ8{=!o-gb(b,_4&c8&X4GT!"z&=9VZ9Eݕ
@.FYeEHQ7am"ݑ
THbb
Ng{g|I栂B)|*YC馜v駠*ꨤ(t5P?jawĥ{i5W뮼+찢;+1VDCױ;,ZDmsV;Qq-Dоljne.acy.KFf1kB% gEpiY&/(-S\qCY7ށeRL,CY˔{il؟>见Ik. 2j(](&э(A~zi0Gs[g.uc-vY\JͶU6r
E*|7~Zƃ5b!'Rx^;q7+3H3Z84
Q+hLt+b>
{}n{*ҬY+ƀ4V0][w3G/Wog/U?,_k,b8*?[6ER
ӟ mVr$ כfc*٥)*b.2@PXS~?!6dzx+(aZVbģ8i!wFiQ+L!A1
NUXƫq߳ƙbfVFb
H5Bыȳ ^2c%PTS\&dgZT串l"bNf/u[%&]Mu,ӆ
UKM?Kʖb*4!yhi{iuNSB<'t'HOgLO
A:։D;OlM>f:Ohs ysW_A/Iґg2C%Rt=0MZL[:ӗ4ũMsӝ4GdT*T?R]Yȥ
9Nm]T8;VժW#VzT3FM*19Ӭg,GUj f[KJWɕEϫISH5>O39m,7ω.gǚXr:rJk-28r +YlwVŭXoKzթ5$><_jAw7Uz,ͪvz
xKMz^ZVE}qY)߰
e@IR14DtC&14p`S\
r!77ʴnf*8ʥN5j:5]Z֢Ng̲xε98zIftb'^6[wej'rT{ޯ6]mf|dl
`Y?wcK6 r;-%JDK5x3X wvy2GWP9@Gι=+ZyKdՓџuHC,/ȋ,MƄ|.9yהTؓwT]x_(nw2E\iYʛ]B(Ϲ˪RΘ9z?Uҷ\yEwy|Dy#;De_'>b368Mh%v]|3LUcY?謉YűWP{=y?O58E%nmhLx\"3)MM8Drr