maven-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dan Berindei (JIRA)" <>
Subject [jira] [Commented] (SUREFIRE-1426) Fork crash doesn't fail build with -Dmaven.test.failure.ignore=true
Date Thu, 05 Oct 2017 09:52:00 GMT


Dan Berindei commented on SUREFIRE-1426:

The system property maven.test.failure.ignore is not about masking your user error nor system
error. This is about ignoring events coming from JUnit reflecting exception like Assumption|AssertionError
or ordinal exception caught by JUnit thrown by you test code.

Then why does the build fail with {{-Dmaven.test.failure.ignore=false}} and pass with {{-Dmaven.test.failure.ignore=true}}?

I am no more willing to mask OutOfMemoryError and not to mask wrong configuration because
otherwise running tests would not makes sense!

And yet Surefire *does* mask an OutOfMemoryError in the fork, if it happens in the Surefire
code and not in the user code.

Then why you executed mvn test if you do not expect to run tests?

That's exactly what I want, to run tests. But if I made a mistake and Surefire cannot run
the tests, I want to know so I can fix that mistake.

And why you use maven.test.failure.ignore which everybody knows that it is highly unrecommended
in good s/w development 

Why exactly is {{-Dmaven.test.failure.ignore}} so highly unrecommended? Could it be because
it ignores all user and system errors, not just test failures?

Jenkins can read test results from the XMLs and mark the build as unstable or failed, so {{-Dmaven.test.failure.ignore=false}}
would work perfectly well in this scenario *if* it ignored only test failures and not all
the errors that happen in the fork process.

and why you simply did not skip tests -DskipTests if you do not like writing and maintaining
tests and you do not like high quality of s/w?

What did I say to make you draw that conclusion? The fact that in a build with 20k+ tests
I want more information than "no test failed" vs "at least one test failed"?

> Fork crash doesn't fail build with -Dmaven.test.failure.ignore=true
> -------------------------------------------------------------------
>                 Key: SUREFIRE-1426
>                 URL:
>             Project: Maven Surefire
>          Issue Type: Bug
>          Components: process forking
>            Reporter: Dan Berindei
>            Assignee: Tibor Digana
>         Attachments: surefire-1426-test.tar.gz
> We have a reactor with many modules, and also a few random test failures. We want to
run the tests of all the modules even if a test failed in the core module, so we use {{mvn
-Dmaven.test.failure.ignore=true}}. {{mvn --fail-at-end}} only builds the modules that do
not depend on the module with a failed test.
> The problem is that fork crashes like this one are written to the surefire reports, so
Jenkins ignores them:
> {noformat}
> org.apache.maven.surefire.booter.SurefireBooterForkException: There was an error in the
forked process
> Unable to load category: stress
> 	at org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(
> 	at org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(
> 	at
> 	at
> 	at org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeProvider(
> 	at org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAfterPreconditionsChecked(
> 	at org.apache.maven.plugin.surefire.AbstractSurefireMojo.execute(
> 	at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(
> 	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(
> 	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(
> 	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(
> 	at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(
> 	at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(
> 	at
> 	at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(
> 	at org.apache.maven.DefaultMaven.doExecute(
> 	at org.apache.maven.DefaultMaven.doExecute(
> 	at org.apache.maven.DefaultMaven.execute(
> 	at org.apache.maven.cli.MavenCli.execute(
> 	at org.apache.maven.cli.MavenCli.doMain(
> 	at org.apache.maven.cli.MavenCli.main(
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(
> 	at java.lang.reflect.Method.invoke(
> 	at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(
> 	at org.codehaus.plexus.classworlds.launcher.Launcher.launch(
> 	at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(
> 	at org.codehaus.plexus.classworlds.launcher.Launcher.main({noformat}

This message was sent by Atlassian JIRA

View raw message