-
Notifications
You must be signed in to change notification settings - Fork 185
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
Consistency fuzz testing? #2191
Comments
Interesting idea. Things to consider:
|
True. Let's see how relevant those turn out in practice. Another idea is to allow for a |
we can also work on #2221 here by fuzzing the lint metadata & making sure tests fail. |
Another idea for the fuzz/metatesting suite, based on #2402 -- inject comments in random places in the test code and ensure the linters keep working. Have to exclude linters where |
One concern I have about the consistency cleanups in this release (#2039, #2046, #2190) is there's no mechanism to ensure future improvements/new linters continue to keep "up to code" & enforce the same consistency.
One approach that seems doable is to have a GHA that fuzzes our test suite. For example, for #2190, that means:
expect_lint()
calls using "function(...)" or\(...)
in thecontent=
argument (text matching should be enough, but we could also usegetParseData()
here...).s/function/\/g
ands/\/function/g
function(...)
and\(...)
Similar fuzzes could apply in the other cases:
%>%
and|>
$
and@
Some exceptions will need to be carved out, e.g. for cases where intentionally only one alternative is meant to be linted, and we might need some work to make the fuzzing robust to changes in an expected lint message. But overall this approach seems pretty doable to me.
If run with randomness, I'd also run it periodically, not on push/merge, since a failure might not be caught up-front & surfacing that failure on "someone else's" PR would be bad form.
The text was updated successfully, but these errors were encountered: