📄 java-frontend/src/test/java/org/sonar/java/ast/JavaAstScannerTest.java:308-311
should_propagate_SOError previously asserted logTester.logs(Level.ERROR) had exactly one entry (hasSize(1)) and that logs.get(0) started with "A stack overflow error occurred while analyzing file". This commit changes it to hasSize(12) and only checks .first().

The production code is unchanged: the StackOverflow path in JavaAstScanner.scan calls LOG.error(String.format(LOG_ERROR_STACKOVERFLOW, inputFile), error) exactly once per file (JavaAstScanner.java:189), and ThreadLocalLogTester.logs() returns one entry per LOG.error call (a stack trace is NOT split into separate entries). Since this PR only edits the test, the number of error logs emitted by scanning a single file did not change — so a value of 12 instead of 1 is unexplained.

The likely cause is log pollution: the logTester instance is accumulating ERROR logs from other test methods (or globally), meaning the test now depends on test execution order / count rather than on the single expected log line. Asserting hasSize(12) is a brittle magic number that will break whenever a new test is added or order changes, and .first() only validates 1 of the 12 entries — weakening the original guarantee that ONLY the stack-overflow error was logged.

Verify why 12 entries appear. If it is pollution, the logTester should be reset / scoped per test and the assertion restored to hasSize(1). Do not hardcode an unexplained count.

📄 java-checks-testkit/src/test/java/org/sonar/java/checks/verifier/CheckVerifierTest.java:37
The diff replaces two explicit static imports with import static org.assertj.core.api.Assertions.*;. Wildcard imports are generally discouraged (and flagged by Sonar's own rules) because they obscure which symbols are used and can cause name-collision surprises. Since this PR is titled "Fix Quality Gate", introducing a wildcard import is at odds with that goal. Prefer listing the explicit static imports actually used (assertThat, catchThrowable, assertThatCode/assertThatThrownBy).

📄 java-frontend/src/test/java/org/sonar/java/classpath/ClasspathForMainTest.java:412-417
In empty_binaries_..._should_not_fail_on_sonarlint, the chain uses .withFailMessage(EXCEPTION_SHOULD_HAVE_BEEN_RAISED).doesNotThrowAnyException(). The constant value is "Exception should have been raised", which is the exact opposite of what doesNotThrowAnyException() checks. If the lambda unexpectedly throws, the failure output will read "Exception should have been raised" — directly contradicting the test intent and confusing whoever diagnoses the failure. Either drop withFailMessage here (AssertJ's default message already reports the unexpected exception) or use a message like "Analysis exception was raised but analysis should not fail".

📄 java-checks-testkit/src/test/java/org/sonar/java/checks/verifier/CheckVerifierTest.java:76-79 📄 java-checks-testkit/src/test/java/org/sonar/java/checks/verifier/CheckVerifierTest.java:98-101 📄 java-checks-testkit/src/test/java/org/sonar/java/checks/verifier/CheckVerifierTest.java:109-112 📄 java-checks-testkit/src/test/java/org/sonar/java/checks/verifier/CheckVerifierTest.java:195-198 📄 java-checks-testkit/src/test/java/org/sonar/java/checks/verifier/CheckVerifierTest.java:208-211 📄 java-checks-testkit/src/test/java/org/sonar/java/checks/verifier/CheckVerifierTest.java:220-223 📄 java-checks-testkit/src/test/java/org/sonar/java/checks/verifier/CheckVerifierTest.java:232-235 📄 java-checks-testkit/src/test/java/org/sonar/java/checks/verifier/CheckVerifierTest.java:245-248 📄 java-checks-testkit/src/test/java/org/sonar/java/checks/verifier/CheckVerifierTest.java:258-261 📄 java-checks-testkit/src/test/java/org/sonar/java/checks/verifier/CheckVerifierTest.java:311-314 📄 java-checks-testkit/src/test/java/org/sonar/java/checks/verifier/CheckVerifierTest.java:331-334 📄 java-checks-testkit/src/test/java/org/sonar/java/checks/verifier/CheckVerifierTest.java:387-390
In all the converted tests, .withFailMessage(SHOULD_HAVE_FAILED) (or "Should have failed") is chained before .isInstanceOf(AssertionError.class).hasMessage(...). In AssertJ, withFailMessage overrides the failure message for ALL subsequent assertions on that object, not just the "did it throw" check. So if the verifier throws an AssertionError but with an unexpected message, .hasMessage(...) will fail and report "Should have failed" instead of the standard expected-vs-actual diff. This is a regression from the original try/catch code, where assertThat(e).hasMessage(...) produced a clear message diff, making these tests harder to debug when they fail.

Suggested fix: use assertThatThrownBy(verifier::verifyIssues).isInstanceOf(AssertionError.class).hasMessage(...) without withFailMessage, or drop withFailMessage so only the "no exception thrown" case relies on AssertJ's default message (which already states the code did not raise a throwable). If you want a custom message for the no-throw case specifically, assertThatThrownBy already produces a clear "Expecting code to raise a throwable" message.

📄 java-frontend/src/test/java/org/sonar/java/ast/JavaAstScannerTest.java:138-140 📄 java-frontend/src/test/java/org/sonar/java/ast/JavaAstScannerTest.java:146-148 📄 java-frontend/src/test/java/org/sonar/java/ast/JavaAstScannerTest.java:303-306
The new assertThatCode(...).withFailMessage(...) calls override the failure message with a generic static string. For doesNotThrowAnyException() (lines 138-140, 146-148), if an exception IS thrown the report will print only "Should not have failed" and hide the actual stack trace/exception that caused the failure, making diagnosis harder than the previous fail("Should not have failed", e) which preserved the cause.

Similarly at lines 303-306, withFailMessage("Should have triggered a StackOverflowError and not reach this point.") is attached to .isInstanceOf(...).hasMessage("boom"); if the message assertion fails the report will misleadingly say the SOError was not triggered. Prefer .as(...) (a description that supplements rather than replaces the mismatch detail) or omit the custom message so AssertJ reports the real discrepancy.