-
Notifications
You must be signed in to change notification settings - Fork 260
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
IntelliJ outputs error messages twice #680
Comments
Some more tests show me that this is something internal to how IntelliJ reports tests errors (considering that AssertJ behaves the same way). Going to close this and just use JUnit for now, which doesn't double up. |
Thanks. I suspect that the cause is that we throw a I wouldn't be surprised if IntelliJ does the same for JUnit -- but only when the inputs are strings, since that's the only case in which JUnit creates a I'm going to reopen this for us to consider doing something better. That might mean talking to the IntelliJ people to ask them for a way to suppress the display of their "Expected" and "Actual" lines, or it might mean something else. |
For completeness, here's the behavior of Junit5, which does not raise ComparisonFailure: @Test
@Tag("demo")
public void testDuplicateDemoIntJUnit() {
int x = 5;
org.junit.jupiter.api.Assertions.assertEquals(10, x);
}
@Test
@Tag("demo")
public void testDuplicateDemoStringJUnit() {
String x = "foo";
org.junit.jupiter.api.Assertions.assertEquals("bar", x);
}
It does not have the double output issue, even on Strings. Hamcrest behaves similarly to JUnit. |
Thanks! The different behavior might depend not only on the type of exception thrown ( It's possible that a straight migration to the opentest4j exceptions would make things worse in some environments. Maybe we should first check with IntelliJ developers (and other tool owners) to ensure that they handle the opentest4j exceptions even under older versions of JUnit. |
JUnit 4.12 behavior: no double output, even when a ComparisonFailure is raised: @Test
public void testJunit4InJUnit4String() {
System.out.println("JUnit version: " + junit.runner.Version.id());
String x = "foo";
assertEquals("bar", x);
}
Truth has the same double output issue in JUnit 4.12. |
Huh, thanks. I think I also saw something in IntelliJ that looked for messages that match a specific text format. Perhaps it's detecting the JUnit format and dropping the output in that case. |
Oh, here's something interesting - AssertJ does not have duplicating behavior in JUnit4, and it raises junit ComparisonFailure for both int and String: @Test
public void testAssertJInJUnit4Int() {
int x = 5;
org.assertj.core.api.Assertions.assertThat(x).isEqualTo(10);
}
@Test
public void testAssertJInJunit4String() {
String x = "foo";
org.assertj.core.api.Assertions.assertThat(x).isEqualTo("bar");
}
(Mentioned above, but AssertJ has duplicate output behavior in JUnit5.) |
Thanks. I haven't organized the details of this in my head, but it might be that: |
Don't think it's quite the first - in the AssertJ issue I linked above, it raises the opentest4j |
There may be drawbacks to this that I'm not thinking of, but.... I would love to see this changed on the IntelliJ side. If the In the case of the "standard JUnit message format," I wouldn't mind if IntelliJ instead skipped displaying the message in favor of displaying only "Expected" + "Actual" + "<Click to see difference>." This doesn't matter to Truth, but it matters to AssertJ under JUnit 4 and to JUnit's own assertions (4 and 5 both, IIUC). |
I am working on IntelliJ 2019.3, with Truth 1.0 and Java 11.0.6, and running tests using Junit 5.6.0.
I'm trying to do test some basic assertions, such as checking the value of an int. However, IntelliJ is printing the messages twice:
Outputs:
This is rather annoying and unexpected behavior. If I test equality of Strings, the same behavior is shown, unless the string has multiple lines, in which case, only expected / but was appears.
Why is this happening? Is there a workaround / fix? Thanks!
The text was updated successfully, but these errors were encountered: