You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@maven.apache.org by "Michael Osipov (JIRA)" <ji...@apache.org> on 2015/09/06 22:46:18 UTC

[jira] [Closed] (SUREFIRE-734) Need ability to remove/truncate failure messages from command-line test results

     [ https://issues.apache.org/jira/browse/SUREFIRE-734?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michael Osipov closed SUREFIRE-734.
-----------------------------------
    Resolution: Auto Closed

This issue has been auto closed because it has been inactive for a long period of time. If you think this issue still applies, retest your problem with the most recent version of Maven and the affected component, reopen and post your results.

> Need ability to remove/truncate failure messages from command-line test results 
> --------------------------------------------------------------------------------
>
>                 Key: SUREFIRE-734
>                 URL: https://issues.apache.org/jira/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 was sent by Atlassian JIRA
(v6.3.4#6332)