You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@maven.apache.org by "Tibor Digana (JIRA)" <ji...@apache.org> on 2015/06/16 00:16:00 UTC
[jira] [Updated] (SUREFIRE-1127) Failsafe project does not fail in
verify phase when a test case object errors during initialization
[ https://issues.apache.org/jira/browse/SUREFIRE-1127?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Tibor Digana updated SUREFIRE-1127:
-----------------------------------
Fix Version/s: 2.19
> Failsafe project does not fail in verify phase when a test case object errors during initialization
> ---------------------------------------------------------------------------------------------------
>
> Key: SUREFIRE-1127
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1127
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Failsafe Plugin
> Affects Versions: 2.18
> Environment: JDK 1.8.0_05 on Windows 7 used to recreate
> Reporter: Bret Goldsmith
> Assignee: Tibor Digana
> Fix For: 2.19
>
> Attachments: failsafe-test.zip
>
>
> Sample project attached.
> When running a "mvn verify" - the attached project will succeed, even though there is an integration test that should obviously fail.
> The integration test case does not initialize correctly (it will throw a null pointer exception in one of its object initializers), which should be a test failure and therefore a project failure.
> I've traced this down to the fact that the generated failsafe-summary.xml file contains an empty failureMessage element:
> {code:xml}
> <?xml version="1.0" encoding="UTF-8"?>
> <failsafe-summary result="254" timeout="false">
> <completed>0</completed>
> <errors>0</errors>
> <failures>0</failures>
> <skipped>0</skipped>
> <failureMessage></failureMessage>
> </failsafe-summary>
> {code}
> And so the failsafe verifier doesn't consider the project a failure. The message seems to be blank because when the failsafe plugin is writing the results, it uses the org.apache.maven.plugins.surefire.AbstractSurefireMojo.executeAfterPreconditionsChecked method to write out the first forked exception, which then calls org.apache.maven.surefire.suite.RunResult.failure() method, which then calls getStackTrace() on the exception.
> The getStackTrace() method looks like this:
> {code:java}
> private static String getStackTrace( Exception e )
> {
> if ( e == null )
> {
> return null;
> }
> ByteArrayOutputStream out = new ByteArrayOutputStream();
> PrintWriter pw = new PrintWriter( out );
> e.printStackTrace( pw );
> return new String( out.toByteArray() );
> }
> {code}
> And it specifically is doing a toBytearray on the output stream without flushing or closing the printwriter first. At least with my JVM 1.8.0_05 version, this seems to be a problem as the printwriter still maintains the trace description in a buffer.
> When I put a breakpoint on this and specifically flush or close the printwriter before the toByteArray, the project fails as expected.
> I'm not sure why this is failsafe specific, but a surefire version test case (also included in the attachment project) fails appropriately.
> I think a simple patch is to update RunResult.java to close the printwriter before getting the resulting stacktrace string. i.e.
> {code:java}
> private static String getStackTrace( Exception e )
> {
> if ( e == null )
> {
> return null;
> }
> ByteArrayOutputStream out = new ByteArrayOutputStream();
> PrintWriter pw = new PrintWriter( out );
> try {
> e.printStackTrace( pw );
> } finally {
> pw.close();
> }
> return new String( out.toByteArray() );
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)