Mailing-List: contact issues-help@maven.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@maven.apache.org
Date: Sun, 1 Oct 2017 14:01:07 +0000 (UTC)
From: =?utf-8?Q?Stig_Rohde_D=C3=B8ssing_=28JIRA=29?= <jira@apache.org>
To: issues@maven.apache.org
Message-ID: <JIRA.12937055.1454683800000.246794.1506866467759@Atlassian.JIRA>
In-Reply-To: <JIRA.12937055.1454683800000@Atlassian.JIRA>
References: <JIRA.12937055.1454683800000@Atlassian.JIRA> <JIRA.12937055.1454683800308@jira-lw-us.apache.org>
Subject: [jira] [Commented] (SUREFIRE-1226) Surefire trims all stack trace
 elements except those in the test that failed
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
archived-at: Sun, 01 Oct 2017 14:01:15 -0000


    [ https://issues.apache.org/jira/browse/SUREFIRE-1226?page=3Dcom.atlass=
ian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=3D1=
6187391#comment-16187391 ]=20

Stig Rohde D=C3=B8ssing commented on SUREFIRE-1226:
----------------------------------------------

Thanks for responding [~tibor17].

You identify these two requirements:
* Users want trimStackTrace to trim only lines before the test method is re=
ached, so it is possible to identify which line in a unit under test threw =
an exception.
* Users want trimStackTrace to trim lines before and after the test method =
is reached when those lines are e.g. Hamcrest or AssertJ lines.

The documentation for trimStackTrace says it will "trim the stack trace in =
the reports to just the lines within the test".

For versions 2.13-2.18.1, trimStackTrace supported the first requirement, b=
ut not the second, by interpreting "lines within the test" to mean "lines d=
eeper in the stack trace than the test method".

2.19 changes the behavior so the first requirement is not supported, but th=
e second is, by interpreting "lines within the test" to mean "lines contain=
ing the location of the test".

I agree that trimStackTrace can't fulfill both requirements, but from 2.13-=
2.18.1 it fulfilled requirement 1 and not 2, and now it fulfills requiremen=
t 2 but not 1. Even if the documentation has been here since 2012, the inte=
rpretation of it has clearly changed.

I think both requirements (and interpretations of trimStackTrace) are equal=
ly valid, but the pre-2.19 behavior is the least harmful because it errs on=
 the side of printing too many lines (e.g. the extra Hamcrest lines) rather=
 than too few (the trimmed lines inside the unit under test).=20

We're trying to argue that switching to the 2.19 behavior is an odd tradeof=
f, because users with requirement 2 are now saving a few trace lines compar=
ed to before, but users with requirement 1 end up with a misleading trace. =
Also keep in mind that users with requirement 1 is going to be anyone who g=
ets an unexpected exception in a test from outside the test method, so this=
 is likely to affect a lot of users.

There's also a visibility issue since trimStackTrace is on by default, and =
as this thread shows at least a few people have run into trouble because th=
e new behavior is unexpected. The factor of surprise could be reduced by in=
serting lines in the trace notifying about deleted lines, as [~jglick] sugg=
ests, even if reverting to the 2.18.1 behavior is not feasible.=20

My preferred solution would be reverting to the 2.18.1 behavior. If this is=
 not possible it would be good to add the extra lines suggested by [~jglick=
] so it's at least visible what's happening.=20

The more flexible trimStackTrace in 3.0 sounds great. We will probably work=
 around this issue until then by disabling trimStackTrace.

> Surefire trims all stack trace elements except those in the test that fai=
led
> -------------------------------------------------------------------------=
---
>
>                 Key: SUREFIRE-1226
>                 URL: https://issues.apache.org/jira/browse/SUREFIRE-1226
>             Project: Maven Surefire
>          Issue Type: Bug
>          Components: Maven Surefire Plugin
>    Affects Versions: 2.19
>            Reporter: Jiri Locker
>            Assignee: Tibor Digana
>            Priority: Minor
>         Attachments: mvn_stacktrace.tar.gz
>
>
> This looks like a re-occurrence of SUREFIRE-992 but now the stack trace i=
s even more trimmed.


--
This message was sent by Atlassian JIRA
(v6.4.14#64029)