False positive for “Squid:S2970 Add a call to ‘assertAll’ after all ‘assertThat’” when using AssertJ's Junit 5 SoftAssertionExtension

This rule incorrectly warns that ‘assertAll’ needs to be called for AssertJ assertions when using the SoftAssertionExtension Junit 5 extension (which calls it automatically). Please see the documentation for various ways for the “assertAll” to be called automatically: https://assertj.github.io/doc/#assertj-core-soft-assertions

I am seeing the false positive in both SonarQube v8.0.x and SonarJava v6.2.

Hello @sdavids, thanks for the feedback.

Indeed, this feature is not yet supported, I created a ticket (SONARJAVA-3324) to keep track of it.

I had a quick look at the other ways to avoid calling assertAll(), and it seems that we are supporting them correctly.



UPDATE: After reading the assertj docs, I’ve seen that is a deprecated mechanism.

Is the usage of the following extension,

public JUnitJupiterSoftAssertions softly = new JUnitJupiterSoftAssertions();

also supported correctly?

Hello @lucasvc,

At first glance, I would say that we will not support correctly this way writing a soft assertion.

Out of curiosity, were did you find the documentation stating that this mechanism is deprecated?

Hi @Quentin,

In the latest class javadoc.

Okay, I understand what is happening. My confusion was that they deprecated JUnitJupiterSoftAssertions but still suggest an example with it as an alternative (in the doc you just linked).

In fact, it seems that first, there is a deprecation message:

use SoftAssertionsExtension instead.

And then, the old description of the rule (that you can see in an older version of the doc):

Same as SoftAssertions , but with the following differences: […]

I admit that this is confusing…
All in all, it means that code such as:

public JUnitJupiterSoftAssertions softly = new JUnitJupiterSoftAssertions();

Is not supported by the rule, but is in fact the mechanism that is deprecated, not the other way around.

I hope it makes sense and I did not miss something!


We still see this error all the time in both SonarLint in IntelliJ (using the latest plugin version) as well as on SonarCloud when using the SoftAssertionsExtension. For example on SonarCloud you can see how we are constantly suppressing this warning across a bunch of different projects:

This has happened as recently as 10 days ago (as of 2020-12-21), for example here:

And as I mentioned, I can run SonarLint right now and get tons of java:S2970 warnings.


Hello @sleberknight,

This is indeed a problem, the rule still raises issues when the class containing the test is nested into another one using SoftAssertionsExtension, despite the fact that this is a valid use case. Ticket created: SONARJAVA-3650.

Thanks for the feedback!


This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.