Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Null Pointer exception assertArrayEquals with no message. #1178

Closed
EmteeW opened this issue Jul 7, 2015 · 18 comments
Closed

Null Pointer exception assertArrayEquals with no message. #1178

EmteeW opened this issue Jul 7, 2015 · 18 comments

Comments

@EmteeW
Copy link

EmteeW commented Jul 7, 2015

When assertArrayEquals (at least for Boolean[]) fails the assert, it throws a null pointer exception looking for a message. This is, of course, when using the prototype that has no message. You'll still get the line number for the failure, you'll still probably just debug focused test method, and be on your merry way, but just technically it's not quite the best/correct behavior.

Thanks!

Update: this is for 4.12

@marcphilipp
Copy link
Member

Can you please provide a test case to illustrate your problem?

@EmteeW
Copy link
Author

EmteeW commented Jul 8, 2015

@Test
public void testJunit() {
    assertArrayEquals(new Boolean[]{true}, new Boolean[]{false});
}

On Tue, Jul 7, 2015 at 12:27 PM, Marc Philipp notifications@github.com
wrote:

Can you please provide a test case to illustrate your problem?


Reply to this email directly or view it on GitHub
#1178 (comment).

@marcphilipp
Copy link
Member

package sandbox;

import static org.junit.Assert.assertArrayEquals;

import org.junit.Test;
import org.junit.runner.JUnitCore;
import org.junit.runner.Result;

public class Snippet {
    @Test
    public void testJunit() {
        assertArrayEquals(new Boolean[] { true }, new Boolean[] { false });
    }

    public static void main(String[] args) {
        Result result = JUnitCore.runClasses(Snippet.class);
        result.getFailures().get(0).getException().printStackTrace(System.out);
    }
}

Running this as a Java application prints

arrays first differed at element [0]; expected:<true> but was:<false>
    at org.junit.internal.ComparisonCriteria.arrayEquals(ComparisonCriteria.java:55)
    at org.junit.Assert.internalArrayEquals(Assert.java:532)
    at org.junit.Assert.assertArrayEquals(Assert.java:283)
    at org.junit.Assert.assertArrayEquals(Assert.java:298)
    at sandbox.Snippet.testJunit(Snippet.java:12)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:606)
    at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
    at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
    at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
    at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
    at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
    at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
    at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
    at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
    at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
    at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
    at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
    at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
    at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
    at org.junit.runners.Suite.runChild(Suite.java:128)
    at org.junit.runners.Suite.runChild(Suite.java:27)
    at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
    at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
    at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
    at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
    at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
    at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
    at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
    at org.junit.runner.JUnitCore.run(JUnitCore.java:115)
    at org.junit.runner.JUnitCore.run(JUnitCore.java:105)
    at org.junit.runner.JUnitCore.runClasses(JUnitCore.java:62)
    at org.junit.runner.JUnitCore.runClasses(JUnitCore.java:49)
    at sandbox.Snippet.main(Snippet.java:16)
Caused by: java.lang.AssertionError: expected:<true> but was:<false>
    at org.junit.Assert.fail(Assert.java:88)
    at org.junit.Assert.failNotEquals(Assert.java:834)
    at org.junit.Assert.assertEquals(Assert.java:118)
    at org.junit.Assert.assertEquals(Assert.java:144)
    at org.junit.internal.ExactComparisonCriteria.assertElementsEqual(ExactComparisonCriteria.java:8)
    at org.junit.internal.ComparisonCriteria.arrayEquals(ComparisonCriteria.java:53)
    ... 35 more

@marcphilipp
Copy link
Member

I cannot reproduce this issue. How do you run your tests? Do you have a stacktrace?

@EmteeW
Copy link
Author

EmteeW commented Jul 9, 2015

They're run from inside netbeans, and it is a gradle project. It doesn't
differ between testing the individual method, file, etc. I'll get a
stacktrace soon. Seems this issue may actually be much more subtle than I
first thought.

On Wed, Jul 8, 2015 at 2:18 PM, Marc Philipp notifications@github.com
wrote:

I cannot reproduce this issue. How do you run your tests? Do you have a
stacktrace?


Reply to this email directly or view it on GitHub
#1178 (comment).

@EmteeW
Copy link
Author

EmteeW commented Jul 9, 2015

Sorry, it looks like I didn't read this stack trace nearly close enough.
It's not the junit comparison looking for a message argument that is null,
it's this reporting framework (data collector) that's stuffing it up,
trying to get a string message for the comparison failure via toString().

Perhaps it's somewhat of a gradle bug, but if the toString is just getting
the message, I wonder how their framework was ever going to get the more
helpful string containing the "Arrays first differed at..."

If you can verify toString() does what you guys intended, then this can be
moved on to Gradle.

Could not determine failure message for exception of type
org.junit.internal.ArrayComparisonFailure:
java.lang.NullPointerException

java.lang.NullPointerException
at org.junit.internal.ArrayComparisonFailure.getMessage(ArrayComparisonFailure.java:52)
at org.junit.internal.ArrayComparisonFailure.toString(ArrayComparisonFailure.java:61)
at java.lang.String.valueOf(String.java:2982)
at java.io.PrintWriter.println(PrintWriter.java:754)
at java.lang.Throwable$WrappedPrintWriter.println(Throwable.java:764)
at java.lang.Throwable.printStackTrace(Throwable.java:655)
at java.lang.Throwable.printStackTrace(Throwable.java:721)
at org.gradle.api.internal.tasks.testing.junit.result.TestReportDataCollector.stackTrace(TestReportDataCollector.java:100)
at org.gradle.api.internal.tasks.testing.junit.result.TestReportDataCollector.afterTest(TestReportDataCollector.java:69)
at sun.reflect.GeneratedMethodAccessor75.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
at org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
at org.gradle.listener.BroadcastDispatch.dispatch(BroadcastDispatch.java:83)
at org.gradle.listener.BroadcastDispatch.dispatch(BroadcastDispatch.java:31)
at org.gradle.messaging.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:93)
at com.sun.proxy.$Proxy35.afterTest(Unknown Source)
at org.gradle.api.internal.tasks.testing.results.TestListenerAdapter.completed(TestListenerAdapter.java:48)
at org.gradle.api.internal.tasks.testing.results.StateTrackingTestResultProcessor.completed(StateTrackingTestResultProcessor.java:65)
at org.gradle.api.internal.tasks.testing.results.AttachParentTestResultProcessor.completed(AttachParentTestResultProcessor.java:52)
at sun.reflect.GeneratedMethodAccessor79.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
at org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
at org.gradle.messaging.dispatch.FailureHandlingDispatch.dispatch(FailureHandlingDispatch.java:29)
at org.gradle.messaging.dispatch.AsyncDispatch.dispatchMessages(AsyncDispatch.java:132)
at org.gradle.messaging.dispatch.AsyncDispatch.access$000(AsyncDispatch.java:33)
at org.gradle.messaging.dispatch.AsyncDispatch$1.run(AsyncDispatch.java:72)
at org.gradle.internal.concurrent.DefaultExecutorFactory$StoppableExecutorImpl$1.run(DefaultExecutorFactory.java:64)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)

On Thu, Jul 9, 2015 at 9:55 AM, Bob Saget aflred.g.fakename@gmail.com
wrote:

They're run from inside netbeans, and it is a gradle project. It doesn't
differ between testing the individual method, file, etc. I'll get a
stacktrace soon. Seems this issue may actually be much more subtle than I
first thought.

On Wed, Jul 8, 2015 at 2:18 PM, Marc Philipp notifications@github.com
wrote:

I cannot reproduce this issue. How do you run your tests? Do you have a
stacktrace?


Reply to this email directly or view it on GitHub
#1178 (comment).

@marcphilipp
Copy link
Member

Are you using 4.12 or a 4.12-beta?

@marcphilipp
Copy link
Member

We had problems with Gradle due to serialization issues in the first two 4.12-betas, see #976.

@marcphilipp
Copy link
Member

What version of Gradle are you using -- and what version of JUnit does it use?

It could be a regression introduced in #836.

@marcphilipp marcphilipp added the bug label Jul 9, 2015
@marcphilipp marcphilipp added this to the 4.13 milestone Jul 9, 2015
@EmteeW
Copy link
Author

EmteeW commented Jul 9, 2015

Sorry, work is blowing up right now... odd thing to have in bug report log,
but eh, easiest to just reply in e-mail.

Will get back on this soon.

On Thu, Jul 9, 2015 at 11:17 AM, Marc Philipp notifications@github.com
wrote:

What version of Gradle are you using -- and what version of JUnit does it
use?

It could be a regression introduced in #836
#836.


Reply to this email directly or view it on GitHub
#1178 (comment).

@EmteeW
Copy link
Author

EmteeW commented Jul 10, 2015

Build.gradle

testCompile "junit:junit:4+"

And the package manifest

Manifest-Version: 1.0
Implementation-Vendor: JUnit
Implementation-Title: JUnit
Implementation-Version: 4.12
Implementation-Vendor-Id: junit
Built-By: jenkins
Build-Jdk: 1.6.0_45
Created-By: Apache Maven 3.0.4
Archiver-Version: Plexus Archiver

On Thu, Jul 9, 2015 at 3:57 PM, Bob Saget aflred.g.fakename@gmail.com
wrote:

Sorry, work is blowing up right now... odd thing to have in bug report
log, but eh, easiest to just reply in e-mail.

Will get back on this soon.

On Thu, Jul 9, 2015 at 11:17 AM, Marc Philipp notifications@github.com
wrote:

What version of Gradle are you using -- and what version of JUnit does it
use?

It could be a regression introduced in #836
#836.


Reply to this email directly or view it on GitHub
#1178 (comment).

@EmteeW
Copy link
Author

EmteeW commented Jul 10, 2015

My gradle is a bit old, 2.2.1... I forgot I use a standalone and not the
IDE plugin's distribution due to a shortcoming of the plugin. I should go
update that and get back to you as well.

On Fri, Jul 10, 2015 at 4:43 PM, Bob Saget aflred.g.fakename@gmail.com
wrote:

Build.gradle

testCompile "junit:junit:4+"

And the package manifest

Manifest-Version: 1.0
Implementation-Vendor: JUnit
Implementation-Title: JUnit
Implementation-Version: 4.12
Implementation-Vendor-Id: junit
Built-By: jenkins
Build-Jdk: 1.6.0_45
Created-By: Apache Maven 3.0.4
Archiver-Version: Plexus Archiver

On Thu, Jul 9, 2015 at 3:57 PM, Bob Saget aflred.g.fakename@gmail.com
wrote:

Sorry, work is blowing up right now... odd thing to have in bug report
log, but eh, easiest to just reply in e-mail.

Will get back on this soon.

On Thu, Jul 9, 2015 at 11:17 AM, Marc Philipp notifications@github.com
wrote:

What version of Gradle are you using -- and what version of JUnit does
it use?

It could be a regression introduced in #836
#836.


Reply to this email directly or view it on GitHub
#1178 (comment)
.

@studiofuga
Copy link

Indeed, reverting to 4.11 solves the issue.

@aishahalim
Copy link
Contributor

Gradle 2.2 relies on junit 4.11 for its java plugin I believe so if you run

./gradlew test --debug

you'll see two log lines that specify the application and implementation classpaths. The application classpath will include the junit jar with the version your project specified and the implementation classpath includes junit-4.11 which is bundled with gradle itself. For some reason, when creating the test report, it uses the junit jar bundled with gradle, not the one you specified in the testCompile gradle directive.

I'm not exactly sure why that happens and tried looking for a way to set preference to junit versions with gradle's java plugins, but didn't look too hard for it (hoping someone can help with this perhaps?). Instead, an upgrade to gradle 2.13 solved the problem entirely since it bundles junit 4.12 with it.

Upgrading gradle might not be the best fix since we're still relying on gradle itself to be bundled with the junit version with which we want to run our test (to generate the test report without throwing the npe, or any other backwards incompatibility related problems).

@marcphilipp
Copy link
Member

marcphilipp commented May 31, 2016

As pointed out in #976 (comment) 4.12 broke serialization compatibility with earlier versions in ArrayComparisonFailure. The field fCause was removed in 4.12 but is expected by earlier versions. A fix would be to reintroduce the field but also use initCause() in order not to break serialization compability between 4.12 and 4.13.

@aishahalim
Copy link
Contributor

Ah, that makes sense -- to not have serialization incompatibility at all across (the minor) versions.

I'm not too familiar with the development process of this project -- since the issue is set as a milestone of 4.13, you'd expect the bugfix to be available for that version (and not back patched into 4.12)?

aishahalim added a commit to aishahalim/junit4 that referenced this issue May 31, 2016
…tCause()) to avoid npe and unused field warnings, respectively

Issue junit-team#1178, junit-team#976
aishahalim added a commit to aishahalim/junit4 that referenced this issue May 31, 2016
Add back field fCause, initialize and use in the constructor (via initCause()) to avoid npe and unused field warnings, respectively
Issue junit-team#1178, junit-team#976
@aishahalim
Copy link
Contributor

aishahalim commented May 31, 2016

It seemed like this fix would probably have to be folded in 4.13 so created a pullrequest on top of master: #1315

Tested with gradle 2.2, running a test that expected the arraycomparisonfailure thrown:

$ ./gradlew --version
------------------------------------------------------------
Gradle 2.2
------------------------------------------------------------

Build time:   2014-11-10 13:31:44 UTC
Build number: none
Revision:     aab8521f1fd9a3484cac18123a72bcfdeb7006ec

Groovy:       2.3.6
Ant:          Apache Ant(TM) version 1.9.3 compiled on December 23 2013
JVM:          1.8.0_72-internal (Oracle Corporation 25.72-b15)
OS:           Linux 3.13.0-32-generic amd64
  1. Built a junit jar by executing mvn package
  2. Copied it from target/ to a directory where my gradle project and local libraries lie (and renamed it to myunit.jar to be super careful
  3. Adjusted my gradle build file to pull this local junit lib:
$ ./gradlew dependencies
:dependencies

------------------------------------------------------------
Root project
------------------------------------------------------------

archives - Configuration for archive artifacts.
No dependencies

compile - Compile classpath for source set 'main'.
\--- commons-collections:commons-collections:3.2.2

default - Configuration for default artifacts.
\--- commons-collections:commons-collections:3.2.2

runtime - Runtime classpath for source set 'main'.
\--- commons-collections:commons-collections:3.2.2

testCompile - Compile classpath for source set 'test'.
+--- commons-collections:commons-collections:3.2.2
+--- :myunit:
\--- org.hamcrest:hamcrest-core:1.3

testRuntime - Runtime classpath for source set 'test'.
+--- commons-collections:commons-collections:3.2.2
+--- :myunit:
\--- org.hamcrest:hamcrest-core:1.3

BUILD SUCCESSFUL

Total time: 5.103 secs
  1. Execute the offending tests: ./gradlew test
  2. Test report shows no npe anymore but the actual cause:
arrays first differed at element [0]; expected:<1> but was:<5>
    at org.junit.internal.ComparisonCriteria.arrayEquals(ComparisonCriteria.java:78)
    at org.junit.internal.ComparisonCriteria.arrayEquals(ComparisonCriteria.java:28)
    at org.junit.Assert.internalArrayEquals(Assert.java:534)
    at org.junit.Assert.assertArrayEquals(Assert.java:418)
    at org.junit.Assert.assertArrayEquals(Assert.java:429)
    at MergeSortTest.sortShouldReturnSortedArray(MergeSortTest.java:12)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:498)
    at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
    at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
    at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:52)
    at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
    at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
    at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:88)
    at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:58)
    at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
    at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
    at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
    at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
    at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
    at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
    at org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.runTestClass(JUnitTestClassExecuter.java:86)
    at org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.execute(JUnitTestClassExecuter.java:49)
    at org.gradle.api.internal.tasks.testing.junit.JUnitTestClassProcessor.processTestClass(JUnitTestClassProcessor.java:69)
    at org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:48)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:498)
    at org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
    at org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
    at org.gradle.messaging.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32)
    at org.gradle.messaging.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:93)
    at com.sun.proxy.$Proxy2.processTestClass(Unknown Source)
    at org.gradle.api.internal.tasks.testing.worker.TestWorker.processTestClass(TestWorker.java:105)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:498)
    at org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
    at org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
    at org.gradle.messaging.remote.internal.hub.MessageHub$Handler.run(MessageHub.java:360)
    at org.gradle.internal.concurrent.DefaultExecutorFactory$StoppableExecutorImpl$1.run(DefaultExecutorFactory.java:64)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
    at java.lang.Thread.run(Thread.java:745)
Caused by: java.lang.AssertionError: expected:<1> but was:<5>
    at org.junit.Assert.fail(Assert.java:89)
    at org.junit.Assert.failNotEquals(Assert.java:835)
    at org.junit.Assert.assertEquals(Assert.java:120)
    at org.junit.Assert.assertEquals(Assert.java:146)
    at org.junit.internal.ExactComparisonCriteria.assertElementsEqual(ExactComparisonCriteria.java:8)
    at org.junit.internal.ComparisonCriteria.arrayEquals(ComparisonCriteria.java:76)
    ... 47 more

Let me know if there's something off. I was thinking of adding serialization tests but held off on it since it would probably require pulling down junit-4.11 and wrangling both packages across the execution?

@marcphilipp
Copy link
Member

since the issue is set as a milestone of 4.13, you'd expect the bugfix to be available for that version (and not back patched into 4.12)?

Since 4.12 has been released last December and 4.13 will be backwards compatible I don't see a point in shipping a 4.12.1 for this fix.

It seemed like this fix would probably have to be folded in 4.13 so created a pullrequest on top of master: #1315

Thanks for the pull request! I've added a comment on #1315.

aishahalim added a commit to aishahalim/junit4 that referenced this issue Jun 13, 2016
Add back field fCause, initialize and use in the constructor (via initCause()) to avoid npe and unused field warnings, respectively
Issue junit-team#1178, junit-team#976
sebasjm pushed a commit to sebasjm/junit4 that referenced this issue Mar 11, 2018
…1315)

* Add back field fCause, initialize and use it in the constructor (via initCause()) to avoid NPE and unused field warnings, respectively.
* Override getCause() to allow fallback to the deprecated fCause field.
* Run tests around possible forward incompatibility of the class from r4.11, 4.12.

Fixes junit-team#1178.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants