Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

4.6-rc-2: JUnit 5 test engine exceptions in initialization are not propagated and do fail the Test task #4476

Closed
mkobit opened this issue Feb 22, 2018 · 4 comments · Fixed by #4480
Assignees
Milestone

Comments

@mkobit
Copy link
Contributor

mkobit commented Feb 22, 2018

JUnit 5 supports extensions automatic registration via ServiceLoader (https://junit.org/junit5/docs/current/user-guide/#extensions-registration-automatic). If in the same projects resources then

Expected Behavior

They should be included.

Current Behavior

They are not included, and an internal exception occurs but the build does not fail.

Context

Migrating from JUnit 5 plugin to Gradle support. The project I am working on uses service loading feature by defining extensions in the same project test resources.

Steps to Reproduce (for bugs)

This is supported in the current JUnit 5 Gradle plugin (https://junit.org/junit5/docs/current/user-guide/#extensions-registration), but does not appear to be working in the migration.

  1. Create an extension. For example:

    package mkobit;
    import org.junit.jupiter.api.extension.BeforeEachCallback;
    import org.junit.jupiter.api.extension.ExtensionContext;
    
    class MyDumbExtension implements BeforeEachCallback {
      @Override
      public void beforeEach(final ExtensionContext context) throws Exception {
        System.out.println("We should fail");
        throw new RuntimeException("Things should fail!");
      }
    }
  2. Add an extry to a file META-INF/services/org.junit.jupiter.api.extension.Extension in the resources directory. In my project, this is in src/test/resources/META-INF/services/org.junit.jupiter.api.extension.Extension

    mkobit.MyDumbExtension
    
  3. Enable auto registration with system property systemProperty('junit.jupiter.extensions.autodetection.enabled', 'true')

  4. Run tests, see internal exception and build succeeds

  5. Extension is not included

Repo example at https://github.com/mkobit/gradle-4.6-junit-5-issue

Your Environment

Gradle 4.6.1

Scan: https://scans.gradle.com/s/zojscmisf4icq

@mkobit mkobit changed the title 4.6-rc-2: JUnit 5 does not load extensions with SeviceLoader and an internal failure that doens't fail build 4.6-rc-2: JUnit 5 does not load extensions with SeviceLoader and an internal failure that doesn't fail test task Feb 22, 2018
@oehme oehme added this to the 4.7 RC1 milestone Feb 22, 2018
@oehme
Copy link
Contributor

oehme commented Feb 22, 2018

@mkobit thanks for the report! The repo is empty, did you forget to push your example?

@blindpirate
Copy link
Collaborator

blindpirate commented Feb 22, 2018

Thanks for reporting. This is because your class is package-private and java.util.ServiceLoader cannot instantiate it. An internal exception is not handled properly.

Of course you can change your class to public as a workaround. Anyway Gradle should take this situation into consideration. I'll fix it soon.

blindpirate added a commit that referenced this issue Feb 22, 2018
This fixes #4476

Previously in Gradle, test execution are class-based, which means a "TestClassStart" event will
be emitted before all test cases and a "TestClassEnd" event will be emitted after all test cases
(no matter they're failed or successful). In JUnit 5, if an exception occurs before "TestClassStart"
event (e.g. exceptions in test engine initialization), some event assertions will be violated.

In this situation, this PR will emit corresponding "TestClassStart/TestClassEnd" event to make
Gradle test event infrastructure happy.
mkobit added a commit to mkobit/gradle-4.6-junit-5-issue that referenced this issue Feb 22, 2018
@mkobit
Copy link
Contributor Author

mkobit commented Feb 22, 2018

Sorry! Mistakenly did not push up the example.

I think @blindpirate figured out the unhandled exception and my mistake with the ServiceLoader example. I think I may have had a different case for the extension not being discovered, so let me try and reproduce that, too.

@mkobit
Copy link
Contributor Author

mkobit commented Feb 22, 2018

Ok, I tried to reproduce the other not getting discovered issue, and I haven't been able to. I'll adjust the title of this issue to reflect the discovered problem.

@mkobit mkobit changed the title 4.6-rc-2: JUnit 5 does not load extensions with SeviceLoader and an internal failure that doesn't fail test task 4.6-rc-2: JUnit 5 test engine exceptions in initialization are not propagated and do fail the Test task Feb 22, 2018
blindpirate added a commit that referenced this issue Feb 27, 2018
This fixes #4476

Previously in Gradle, test execution are class-based, which means a "TestClassStart" event will
be emitted before all test cases and a "TestClassEnd" event will be emitted after all test cases
(no matter they're failed or successful). In JUnit 5, if an exception occurs before "TestClassStart"
event (e.g. exceptions in test engine initialization), some event assertions will be violated.

In this situation, this PR will emit corresponding "TestClassStart/TestClassEnd" event to make
Gradle test event infrastructure happy.
blindpirate added a commit that referenced this issue Mar 5, 2018
This fixes #4476

Previously in Gradle, test execution are class-based, which means a "TestClassStart" event will
be emitted before all test cases and a "TestClassEnd" event will be emitted after all test cases
(no matter they're failed or successful). In JUnit 5, if an exception occurs before "TestClassStart"
event (e.g. exceptions in test engine initialization), some event assertions will be violated.

In this situation, this PR will emit corresponding "TestClassStart/TestClassEnd" event to make
Gradle test event infrastructure happy.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants