r-lib / lintr

Static Code Analysis for R
https://lintr.r-lib.org
Other
1.2k stars 187 forks source link

Consistency fuzz testing? #2191

Open MichaelChirico opened 1 year ago

MichaelChirico commented 1 year ago

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:

Similar fuzzes could apply in the other cases:

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.

AshesITR commented 1 year ago

Interesting idea. Things to consider:

MichaelChirico commented 1 year ago

True. Let's see how relevant those turn out in practice. Another idea is to allow for a # nofuzz escape to skip certain tests if they're too onerous to accomodate.

MichaelChirico commented 1 year ago

we can also work on #2221 here by fuzzing the lint metadata & making sure tests fail.

MichaelChirico commented 11 months ago

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 <COMMENT> is meaningful, of course.