-
Notifications
You must be signed in to change notification settings - Fork 3.3k
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
Allow members annotated with both @ClassRule and @Rule to be static #932
Conversation
* Requires the validated member to be non-static | ||
*/ | ||
class RequireDeclaredNonStaticStrategy extends ValidatorStrategy { | ||
RequireDeclaredNonStaticStrategy(ValidationErrorAdder fValidationErrorAdder) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
style-nit: we don't start parameter names with 'f'
Thanks for the contribution. Unfortunately, github doesn't make it easy for me to comment on the refactoring independent from the functional change. I like having the changes separate, but let's worry about doing that once we resolve the issues. |
Thanks for the detailed review! I've made all but one of your suggested changes (see the inline comment about getAnnotation vs getAnnotations above). I'm never sure whether to amend commits and force push, or append commits and then rebase once everyone's happy: I've done the former here, I hope that's okay. I was a bit hesitant about putting all the validators into nested classes - I actually originally wrote them like that, but I felt it made the parent class a bit ungainly. It's not so bad now the Builder is a lot smaller, though. Also note that I've introduced a fourth commit, for making the static MethodRule validation message more precise (so it didn't get lost in the refactoring), and I've added a couple of tests for it. A couple of small changes I have left in the refactoring (but possibly shouldn't have done):
|
interface RuleValidator { | ||
/** | ||
* Examine the given member and add any violations of the strategy's validation logic to the given list of errors | ||
* @param member The member (field or member) to examine |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
style-nit: extra space before @
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oops - not sure how that got there. Fixed
Wow, fantastic turn around! A few minor issues. Don't worry about merging commits at this time (unless it makes it easier for you); let's do it right at the end. Unfortunately, you have merge conflicts (possibly due to #921). Note that as of that pull, we no longer use the "f" prefix for fields. |
Okay - I've rebased (and got rid of all the fFields - yay!) and addressed your comments. Since I was rebasing anyway, I've made the changes in the amended commits. I've left notes on each of your comments, explaining what I've done if it wasn't trivial. |
/** | ||
* @param annotationType The class of annotation to return | ||
* @param <T> The type of the annotation to return | ||
* @return The annotation on the model element of the given type, or null |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If the choice is between either having a method description or having a @return
tag, I always prefer having a method description. The first sentence of the method Javadoc is used in the class overview.
Incidentally, I generally use @code{null}
in Javadoc when referring to null
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done - it did all seem a bit repetitious :)
@@ -1,10 +1,14 @@ | |||
package org.junit.runners.model; | |||
|
|||
import static org.hamcrest.CoreMatchers.*; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We don't use wildcard imports. They tend to cause problems when new static methods are added to a class
(but thank you very much for adding a test; I wouldn't have bothered because it's trivial, but it's nice to have)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, sorry, fixed; I hadn't realised IntelliJ had done that.
Sweet. Nervously excited that I can merge this tonight |
Okay, I've updated that last commit. Hopefully that's got it this time - thanks for being patient with me! |
Allow members annotated with both @ClassRule and @rule to be static
@rowanhill Thank you for being patient! Could you please update the release notes to mention this commit? |
Sure thing. The release notes are now updated. Thanks again! |
Thanks. I updated the release notes to warn about static fields/methods annotated with |
Hi,
This is the change discussed in #793 to allow static members annotated with both
@ClassRule
and@Rule
(whereas currently, all@Rule
members must be non-static).Although the change is relatively small, I've significantly refactored
RuleFieldValidator
(and renamed it toRuleMemberValidator
). I've kept these two steps in separate commits, with one final commit to actually change the behaviour.My changes include:
RuleFieldValidator
from an enum to a class. I couldn't see why it was an enum: it's values were never used in that sense, and they don't really seem to semantically be an enumeration.RuleFieldValidator
toRuleMemberValidator
, since we validate both methods and fields@ClassRule
members, if and only if they're also annotated as@Rule
.I've referred to
@Rule
annotated members as 'test rules' in a few places, as that wording already seemed to be present in the codebase, but I'm not sure if that's strictly correct terminology (since aTestRule
can be annotated with@ClassRule
).I think that covers everything - let me know if anyone has questions, or if anything needs altering for this PR to be accepted.
Thanks,
Rowan