Introduce JUnitSingleArguments bug checker
#816
Conversation
Mutation testing report by Pitest. Review any surviving mutants by inspecting the line comments under Files changed. |
|
Looks good. All 6 mutations in this change were killed.
Mutation testing report by Pitest. Review any surviving mutants by inspecting the line comments under Files changed. |
Venorcis
force-pushed
the
vkoeman/junit-arguments-single
branch
from
3af06e2
to
10dfe9d
Compare
|
Looks good. All 6 mutations in this change were killed.
Mutation testing report by Pitest. Review any surviving mutants by inspecting the line comments under Files changed. |
Venorcis
force-pushed
the
vkoeman/junit-arguments-single
branch
from
cacc565
to
8645037
Compare
|
Looks good. All 6 mutations in this change were killed.
Mutation testing report by Pitest. Review any surviving mutants by inspecting the line comments under Files changed. |
1 similar comment
|
Looks good. All 6 mutations in this change were killed.
Mutation testing report by Pitest. Review any surviving mutants by inspecting the line comments under Files changed. |
Venorcis
force-pushed
the
vkoeman/junit-arguments-single
branch
from
8645037
to
efd3a9a
Compare
|
Looks good. All 6 mutations in this change were killed.
Mutation testing report by Pitest. Review any surviving mutants by inspecting the line comments under Files changed. |
...prone-contrib/src/test/java/tech/picnic/errorprone/bugpatterns/JUnitSingleArgumentsTest.java
Show resolved
Hide resolved
|
Kudos, SonarCloud Quality Gate passed! |
|
Looks good. All 6 mutations in this change were killed.
Mutation testing report by Pitest. Review any surviving mutants by inspecting the line comments under Files changed. |
| @Override | ||
| public Description matchMethodInvocation(MethodInvocationTree tree, VisitorState state) { | ||
| if (ARGUMENTS_ARGUMENTS.matches(tree, state) && tree.getArguments().size() <= 1) { | ||
| return describeMatch(tree, SourceCode.unwrapMethodInvocation(tree, state)); |
There was a problem hiding this comment.
This would cause a compilation error w.r.t. the return type, right? 🤔
There was a problem hiding this comment.
Yeah, I wasn't sure how we deal with the fix suggestions. AFAIK not all suggestions necessarily lead to directly compiling code? We can ofc. remove it here and just flag instead 🤷🏻♂️
There was a problem hiding this comment.
We try either produce compilable code or only flag the issue, with a strong preference for the former (as the latter really introduces quite a bit more friction). That said, especially some of the Refaster rules can in special circumstances break the code.
For this case we could:
- Simplify the factory method if it has a single return statement, using similar logic we use in
JUnitValueSource. - Only flag otherwise.
(But that's considerably more complicated than the current proposal, so if you're like "uuuuuh", I get that. Don't mind having a stab; would just take a bit of time.)
There was a problem hiding this comment.
Yeah understood. In the most common use case we 'only' need to replace <Arguments> with <T> in the method definition. Perhaps it's relatively easy to add the suggestion for this use case and still resort to flagging any other occurrences (they would be weird but you never know 😛 ).
There was a problem hiding this comment.
Indeed, that's the lines along which I'm thinking 👍
(Both inside Picnic and for the upcoming integration test framework against open-source repos we run Error Prone in a loop until it no longer makes any changes, which can only work if each intermediate state compiles successfully.)
There was a problem hiding this comment.
I've looked a bit closer at this topic, and the logic in JUnitValueSource shows that there are quite a lot of details to consider:
- There are different ways in which the
Argumentscan be wrapped in a top-level collection/stream/array. - The factory method can have multiple return statements.
- The return type could change from
MonadType<Arguments>orArguments[]toMonadType<Object>orObject[], but ideally we're more specific. - Only if all
Argumentsinstances have exactly one value can we do the unwrapping (in case of variability we should likely emit a separate warning). - Ideally we do all this in a way that reuses relevant pieces of logic from
JUnitValueSource.
I'm likely missing a few other details. Happy to dive deeper into this, but it'll be a while before I find the time to really sit down for this.
Adds a bugchecker that flags uses of JUnit
Arguments when only a single (or in a weird edge case no) argument is used.An example can be seen in the diff of the
MethodMatcherFactoryTest😄