TestRule to disable specific other TestRules when debugging without modification to the test class #956
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| * @return true if the current JVM was started in debug mode, false | ||
| * otherwise. | ||
| */ | ||
| private boolean isDebugging(final List<String> arguments) { |
There was a problem hiding this comment.
Since this is used in a constructor, please make it static
There was a problem hiding this comment.
Agreed, didn't spot that.
|
Fantastic. One typo though. After you fix that, could you please squash commits? See https://github.com/junit-team/junit/wiki/Pull-Requests for instructions. @junit-team/junit-committers any objections to this change? |
|
Dig it. Looks great as an idea, and a shallow read-through of the code also looks fine. |
launched in debug mode. This feature is immediately useful with @Timeouts by disabling them during debugging allowing developers time to debug at their leisure without the test terminating abruptly. Timeouts or time sensitive logic in the code under test is not handled by this feature and may make this unuseful in some circumstances. The important benefit of this feature is that you can suspend rules without any making any modifications to your test class to remove them during debugging. Anecdotally removing timeouts for debug purposes often results in developers forgetting to restore them (including myself!).
|
Fixed typo, well spotted. Squashed branch history into 1 commit. |
kcooney
added a commit
that referenced
this pull request
Jul 25, 2014
TestRule to disable specific other TestRules when debugging without modification to the test class
|
Thanks! |
|
Forgot to ask: would you please add this to the release notes? |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This pull request is an alternative to #904. I prefer this change over #904 because it is cleaner code, it may be use for debugging problems beyond than of Timeout's, it's easier to test and maintain and it preserves backwards compatible in doing so.
This feature is immediately useful with @Timeouts by disabling them during debugging allowing developers time to debug at their leisure without the test terminating abruptly.
Timeouts or time sensitive logic in the code under test is not handled by this feature and may make this unuseful in some circumstances. Similarly any other uses are limited to behaviour within it's control.
The most attractive benefit of this feature is that you can suspend rules without any making any modifications to your test class to remove them during debugging. Anecdotally removing timeouts for debug purposes often results in developers forgetting to restore them (including myself!).
This feature somewhat relates to issue #738
The DisableOnDebug rule exposes an isDebugging() method accessible to tests. I saw no harm in doing this and thought there might be some interesting uses with the Assume feature or disabling other code paths that cannot easily be debugged. e.g. above I alluded to time sensitive logic in user code that we can't control, isDebugging() may be combined with user code to manage that.
I've tried to keep as close to the JUnit projects conventions but please let me know if there is anything you'd prefer to be changed.