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…