Extenability of S2699? (Tests should include assertions)


(This is sorta followup to https://groups.google.com/forum/#!topic/sonarqube/Mznxgg5Ek-c)

Currently, someone needs to extend Sonar-Java whenever S2699 needs to support a new assertion framework or a new feature of an existing assertion framework. Wouldn’t it be better if assertion frameworks could annotate their annotation methods/classes somehow, so Sonar-Java could automatically support new assertions, if a project uses a current version of a such-extened assertion framework.


Regards, Tobias

Hello @TobiX,

We finally decided to go for adding a parameter allowing a user to configure extra assertion frameworks.

Here is the ticket: https://jira.sonarsource.com/browse/SONARJAVA-2927


Hello @TobiX,

FYI, SonarJava 5.11 is implementing SONARJAVA-2927 and should cover your needs.

Can you give it a try and come back to us if required?


1 Like

I have a similar problem (since AssertJ Swing API methods are not recognized as assertions).
The rule mentions the parameter “customAssertionMethods” but how can I pass a value for that parameter? In particular, I’d like to pass such an argument from the POM of the Maven project…
thanks in advance

anyone please?

It can be set when defining a quality profile, the same way as any other rule properties:


1 Like

3 posts were split to a new topic: S2699 Support custom annotations as assertions

If you don’t have the way/right to update QualityProfile (ex. shared quality profile…),
then there is another way/workaround to include project dedicated test assertions.

You will have to rename your custom assert methods with at least one keyword detected by sonar.

This post with C# issue were very usefull for me (and this works in another langage like java too.)

The detection of assertions is based on string comparation. If the method name contains any of these keywords (case insensitive), then it’s considered to be an assertion:

  • MUST