[Pull request #1054:](junit-team/junit#1054) Improved error message for assertArrayEquals when multi-dimensional arrays have different lengths
Previously, JUnit's assertion error message would indicate only that some array lengths x and y were unequal, without indicating whether this pertained to the outer array or some nested array. Now, in case of a length mismatch between two nested arrays, JUnit will tell at which indices they reside.
The Assert class now includes methods that can assert that a given function call (specified, for instance, as a lambda expression or method reference) results in a particular type of exception being thrown. In addition it returns the exception that was thrown, so that further assertions can be made (e.g. to verify that the message and cause are correct).
Previously, when comparing two arrays which differ in length, assertArrayEquals() would only report that they differ in length. Now, it does the usual array comparison even when arrays differ in length, producing a failure message which combines the difference in length and the first difference in content. Where the content is another array, it is described by its type and length.
[Pull request #1315:](junit-team/junit4#1315) assertArrayEquals shouldn't throw an NPE when test suites are compiled/run across versions of junit
A redundant field, fCause, was removed on v4.12, and was seemingly harmless because Throwable#initCause() could directly initialize cause in the constructor. Unfortunately, this backwards incompatible change got aggravated when a test class, compiled with the latest (4.12+), ran with an older version that depended on fCause when building the assertion message1.
This change adds back fCause, and overrides getCause() to handle forward compatibility2.
To ensure serializability of further changes in ArrayAssertionFailure (until excising these fields by a major rev), a unit test now runs against v4.11, v4.12 failures, asserting around #toString/getCause().
[1] [Issue #1178](junit-team/junit4#1178) details a particular case where gradle v2.2 is packaged with junit v4.11 and is used on running a test, generating test reports, despite specifying a particular version of junit (users would specify v4.12, or v4.+) in the test compile dependencies).
[2] Case if the test class is compiled with <= v4.11, where only fCause is initialized and not Throwable#cause, it can now fallback to the field, fCause, when building the message.
The method assertThat is used for writing assertions with Hamcrest. Hamcrest is an independent assertion library and contains an own assertThat method in the class org.hamcrest.MatcherAssert. It is available both in the old Hamcrest 1.3 release and in the current Hamcrest 2.1. Therefore the JUnit team recommends to use Hamcrest's own assertThat directly.
Test Runners
[Pull request #1037:](junit-team/junit#1037) BlockJUnit4ClassRunner#createTest now accepts FrameworkMethod
Subclasses of BlockJUnit4ClassRunner can now produce a custom test object based on the FrameworkMethod test being executed by implementing the new createTest(FrameworkMethod) method. The default implementation calls the existing createTest() method.
[Pull request #1082](junit-team/junit#1082): Ensure exceptions from BlockJUnit4ClassRunner.methodBlock() don't result in unrooted tests
The introduction of the runLeaf() method in BlockJUnit4ClassRunner in JUnit 4.9 introduced a regression with regard to exception handling. Specifically, in JUnit 4.9 through 4.12 the invocation of methodBlock() is no longer executed within a try-catch block as was the case in previous versions of JUnit. Custom modifications to methodBlock() or the methods it invokes may in fact throw exceptions, and such exceptions cause the current test execution to abort immediately. As a result, the failing test method is unrooted in test reports, and subsequent test methods are never invoked. Furthermore, any RunListener registered with JUnit is not notified.
As of JUnit 4.13, the invocation of methodBlock() is once again wrapped within a try-catch block. If an exception is not thrown, the resulting Statement is passed to runLeaf(). If an exception is thrown, it is wrapped in a Fail statement which is passed to runLeaf().
[Pull request #1286](junit-team/junit#1286): Provide better feedback to the user in case of invalid test classes
Only one exception per invalid test class is now thrown, rather than one per validation error.
The message of the exception includes all of the validation errors.
Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.
Dependabot commands and options
You can trigger Dependabot actions by commenting on this PR:
- `@dependabot rebase` will rebase this PR
- `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it
- `@dependabot merge` will merge this PR after your CI passes on it
- `@dependabot squash and merge` will squash and merge this PR after your CI passes on it
- `@dependabot cancel merge` will cancel a previously requested merge and block automerging
- `@dependabot reopen` will reopen this PR if it is closed
- `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
- `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
- `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
- `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
olamy
commented
4 years ago
Bumps junit from 3.8.1 to 4.13.
Release notes
Sourced from junit's releases.
Changelog
Sourced from junit's changelog.
Commits
Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting
@dependabot rebase.Dependabot commands and options
You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot merge` will merge this PR after your CI passes on it - `@dependabot squash and merge` will squash and merge this PR after your CI passes on it - `@dependabot cancel merge` will cancel a previously requested merge and block automerging - `@dependabot reopen` will reopen this PR if it is closed - `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually - `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)