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

Introduce predefined @Disabled*/@Enabled* variants #219

Closed
9 tasks done
ttddyy opened this issue Mar 31, 2016 · 26 comments
Closed
9 tasks done

Introduce predefined @Disabled*/@Enabled* variants #219

ttddyy opened this issue Mar 31, 2016 · 26 comments

Comments

@ttddyy
Copy link

ttddyy commented Mar 31, 2016

Overview

I just happened to have a test only failing on MS Windows machines and thought about JUnit Jupiter.

I could write a custom extension implementing ContainerExecutionCondition and TestExecutionCondition, but having a predefined @Disabled annotation such as @DisabledIfWindows or @Disabled(condition = IsWindowsEvaluator.class) to extend disabling feature might be handy.

Related Issues

Deliverables

  • system property matches a pattern
  • environment variable matches a pattern
  • ❌ current day of week matches one of the supplied enums
    • The team decided not to publish @EnabledOnDayOfWeek and @DisabledOnDayOfWeek.
  • current OS matches one of the supplied enums
  • current JRE version matches one of the supplied enums
  • Check for user configuration errors. For example, if a user declares @EnabledOnOs({}), that should result in an exception instead of a disabled result.
  • Introduce integration tests for each condition.
  • Write JavaDoc for each annotation.
  • Document in User Guide.
  • Document in Release Notes.
@ttddyy
Copy link
Author

ttddyy commented Mar 31, 2016

I just realized I should write like this to skip the test on windows machines for my use case.
assumeFalse(System.getProperty("os.name").toLowerCase().contains("win"))

However, I still think annotating such condition would be easier to detect than writing assumptions in body of the test methods.

@sbrannen sbrannen changed the title Preset of disabling tests conditionally Introduce predefined @DisabledIf/@EnabledIf variants Apr 24, 2016
@sbrannen
Copy link
Member

sbrannen commented Apr 24, 2016

@ttddyy, that's an interesting idea, and I in fact had a similar idea (hence the new subject).

I'm not sure that we will introduce such mechanisms in core JUnit 5, but I do imagine they will end up somewhere (perhaps in an add-on module or in an example project).

p.s. this would be similar to @IfProfileValue in Spring, only much more powerful. 😉

@sbrannen sbrannen self-assigned this Apr 24, 2016
@sbrannen sbrannen added this to the 5.0 Backlog milestone May 16, 2016
@sbrannen
Copy link
Member

sbrannen commented Jun 17, 2016

We have recently received a recommendation for introducing an annotation like @DisabledUntil( /* date */).

So that is also something to keep in mind.

I'm currently thinking we should support the following use cases.

  • system property matches a pattern
  • environment variable matches a pattern
  • current date/time matches some criteria

@smoyer64
Copy link
Contributor

I wanted to add a use-case to this issue that was described during the "Metrics-Driven Continuous Delivery in Practice [TUT5941]" session at JavaOne.

The presenter's company (Dynatrace) has developed a custom @ignore annotation which allows tests to be ignored only if the issue (in this case in Jira) it's testing against is still open. This seems like a pretty clever TDD trick too.

@sbrannen
Copy link
Member

Yep, that's also a clever use case.

But something like that is very specific to a particular technology. So I don't foresee that being implemented as a generic solution within JUnit itself.

@smoyer64
Copy link
Contributor

No ... but the "condition =" idea above would satisfy both this use case and the @DisableUntil use case.

sbrannen added a commit that referenced this issue Feb 3, 2018
sbrannen added a commit that referenced this issue Feb 3, 2018
This commit introduces conditional test execution support based
on JVM system properties via @EnabledIfSystemProperty and
@DisabledIfSystemProperty.

Issue: #219
sbrannen added a commit that referenced this issue Feb 3, 2018
This commit introduces conditional test execution support based on
OS environment variables via @EnabledIfEnvironmentVariable and
@DisabledIfEnvironmentVariable.

Issue: #219
sbrannen added a commit that referenced this issue Feb 3, 2018
This commit introduces conditional test execution support based
on common operating systems via @EnabledOnOs and @DisabledOnOs.

Issue: #219
sbrannen added a commit that referenced this issue Feb 3, 2018
This commit introduces conditional test execution support based
on JRE versions via @EnabledOnJre and @DisabledOnJre.

Issue: #219
sbrannen added a commit that referenced this issue Feb 3, 2018
sbrannen added a commit that referenced this issue Feb 3, 2018
This commit introduces conditional test execution support based
on JVM system properties via @EnabledIfSystemProperty and
@DisabledIfSystemProperty.

Issue: #219
sbrannen added a commit that referenced this issue Feb 3, 2018
This commit introduces conditional test execution support based on
OS environment variables via @EnabledIfEnvironmentVariable and
@DisabledIfEnvironmentVariable.

Issue: #219
sbrannen added a commit that referenced this issue Feb 3, 2018
This commit introduces conditional test execution support based
on common operating systems via @EnabledOnOs and @DisabledOnOs.

Issue: #219
sbrannen added a commit that referenced this issue Feb 3, 2018
This commit introduces conditional test execution support based
on JRE versions via @EnabledOnJre and @DisabledOnJre.

Issue: #219
sbrannen added a commit that referenced this issue Feb 3, 2018
@sbrannen
Copy link
Member

sbrannen commented Feb 3, 2018

This issue has been resolved in latest commits pushed to master.

@sbrannen sbrannen closed this as completed Feb 3, 2018
@ghost ghost removed the status: in progress label Feb 3, 2018
Andrei94 pushed a commit to Andrei94/junit5 that referenced this issue Jun 23, 2018
* Introduce @EnabledIf execution condition

Supply a JavaScript controlling whether the annotated
container or test is executed.

Closes junit-team#219
Andrei94 pushed a commit to Andrei94/junit5 that referenced this issue Jun 23, 2018
This commit introduces conditional test execution support based
on JVM system properties via @EnabledIfSystemProperty and
@DisabledIfSystemProperty.

Issue: junit-team#219
Andrei94 pushed a commit to Andrei94/junit5 that referenced this issue Jun 23, 2018
This commit introduces conditional test execution support based on
OS environment variables via @EnabledIfEnvironmentVariable and
@DisabledIfEnvironmentVariable.

Issue: junit-team#219
Andrei94 pushed a commit to Andrei94/junit5 that referenced this issue Jun 23, 2018
This commit introduces conditional test execution support based
on common operating systems via @EnabledOnOs and @DisabledOnOs.

Issue: junit-team#219
Andrei94 pushed a commit to Andrei94/junit5 that referenced this issue Jun 23, 2018
This commit introduces conditional test execution support based
on JRE versions via @EnabledOnJre and @DisabledOnJre.

Issue: junit-team#219
Andrei94 pushed a commit to Andrei94/junit5 that referenced this issue Jun 23, 2018
Andrei94 pushed a commit to Andrei94/junit5 that referenced this issue Jun 23, 2018
Andrei94 pushed a commit to Andrei94/junit5 that referenced this issue Jun 23, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

6 participants