[
http://jira.codehaus.org/browse/SUREFIRE-734?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=265877#action_265877
]
Kristian Rosenvold commented on SUREFIRE-734:
---------------------------------------------
I tend to agree with option E, which is what will happen unless someone has a
different suggestion.
Alternately I think we might add a second summary mode (or even more?),
something like
testMethod1(o.a.m.MyTest) <message up to 60 chars>
The difference being that we abbreviate the common parts of the package name to
reduce the classname, which leaves room for a sensible part of the error
message.
It seems to me like we should stick to an 80 column total for the summary line.
I know this is strange, but even on my 30" screen, I get windows defaulting to
80x25.
> Need ability to remove/truncate failure messages from command-line test
> results
> --------------------------------------------------------------------------------
>
> Key: SUREFIRE-734
> URL: http://jira.codehaus.org/browse/SUREFIRE-734
> Project: Maven Surefire
> Issue Type: Improvement
> Components: Maven Surefire Plugin
> Affects Versions: 2.8
> Reporter: aaron pieper
> Priority: Minor
>
> The 2.8 version of the maven-surefire-plugin has changed the way test
> summaries are formatted at the command line. The summaries now include the
> failure message for each failing test. In some cases, this failure message
> corresponds to an exception message from a framework like Spring, which can
> be over 1000 characters long, as it includes details like which XML file was
> being read, which bean was being loaded, what the bean's type was, and so on.
> Including this failure message in the test summary obscures the method/class
> names, making the summary difficult to read.
> There are a few ways to potentially fix this problem in the
> maven-surefire-plugin:
> A) Add a special-case so that spring messages are truncated from the end of
> the first line
> B) Provide a configuration option, something like
> "maxFailureMessageLength=40" so that users could decide how long they want
> failure messages to be
> C) Provide a configuration option, something like
> "includeFailureMessages=false" so that users could omit failure messages
> D) Truncate all messages to a fixed amount
> E) Revert to the 2.7 behavior of always omitting failure messages
> Personally I like C and E the best but all of these ideas have pros and cons;
> I'm sure other people will have their own opinions/ideas for addressing this.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
