java:S5841 invalid compliant solution

Thanks for the reply. Yes I can confirm that we’re on the same page.

I still think that a simple assertThat(list).doesNotContain("something") is a valid use-case on it’s own.

It just means that the test invoked the production code in a way that this specific “something” should not be there.

This is from a personal example:

@Test
public void visibleForTesting_annotationOnPackagePrivateMethod_allowed() {
    // given
    Path[] classes = {Paths.get(SAMPLES_PATH + "AnnotationOnPackagePrivateMethod.class")};

    // when
    BugCollection bugCollection = spotbugs.performAnalysis(classes);

    // then
    doesNotViolateVisibleForTestingRules(bugCollection);
}

private void doesNotViolateVisibleForTestingRules(BugCollection bugCollection) {
    assertThat(bugCollection.getCollection())
        .extracting("type")
        .doesNotContain(
            "VISIBLE_FOR_TESTING_ONLY_ON_PACKAGE_PRIVATE",
            "VISIBLE_FOR_TESTING_ONLY_ON_METHOD",
            "VISIBLE_FOR_TESTING_ACCESS_VIOLATION");
}

The private method doesNotViolateVisibleForTestingRules is extracted because it’s reused by another 15 tests.
But not all 15 tests are set up in the exact same way, some violate other non-related spotbugs rules, and others don’t violate anything.
Hence, making the necessity of isEmpty/isNotEmpty pointless - for my specific scenario.

Of course it would be possible to copy/paste the assertion itself on all tests, so I can adjust each test properly, according to the list size.
Or I could return the assertion object itself, and append each test with isEmpty/isNotEmpty, like this:
doesNotViolateVisibleForTestingRules(bugCollection).isEmpty().

But these options are just work needed to satisfy Sonarcloud rules, and do not provide any benefit to my tests, nor fix any issue.

I hope this makes sense and is understandable.

PS: I have other such examples, but I hope one is sufficient to make my point…
PS2: funny thing - I just saw this: [Java] Class members annotated with @VisibleForTesting should not be accessed from production code, which is exactly what my spotbugs custom plugin does…