# Extenability of S2699? (Tests should include assertions) **URL:** \ **Category:** Suggest new features\ **Tags:** rule-changes, java\ **Created:** [June 28, 2018, 7:15am UTC](https://community.sonarsource.com/t/extenability-of-s2699-tests-should-include-assertions/581 "2018-06-28T07:15:14Z")\ **Posts on this page:** 8\ **Page:** 1
**Author:** ![TobiX](https://dub1.discourse-cdn.com/sonarsource/user_avatar/community.sonarsource.com/tobix/32/175_2.png) [@TobiX](https://community.sonarsource.com/u/TobiX)\ **Post date:** [June 28, 2018, 7:15am UTC](https://community.sonarsource.com/t/extenability-of-s2699-tests-should-include-assertions/581/1 "2018-06-28T07:15:14Z")
Hi, (This is sorta followup to [Redirecting to Google Groups](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. WDYT? Regards, Tobias ---
**Author:** ![Alexandre\_Gigleux](https://dub1.discourse-cdn.com/sonarsource/user_avatar/community.sonarsource.com/alexandre_gigleux/32/26_2.png) [@Alexandre\_Gigleux](https://community.sonarsource.com/u/Alexandre_Gigleux)\ **Post date:** [October 12, 2018, 8:38am UTC](https://community.sonarsource.com/t/extenability-of-s2699-tests-should-include-assertions/581/5 "2018-10-12T08:38:39Z")
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](https://jira.sonarsource.com/browse/SONARJAVA-2927) Regards ---
**Author:** ![Alexandre\_Gigleux](https://dub1.discourse-cdn.com/sonarsource/user_avatar/community.sonarsource.com/alexandre_gigleux/32/26_2.png) [@Alexandre\_Gigleux](https://community.sonarsource.com/u/Alexandre_Gigleux)\ **Post date:** [March 21, 2019, 9:29am UTC](https://community.sonarsource.com/t/extenability-of-s2699-tests-should-include-assertions/581/6 "2019-03-21T09:29:13Z")
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? Thanks ---
**Author:** ![LorenzoBettini](https://dub1.discourse-cdn.com/sonarsource/user_avatar/community.sonarsource.com/lorenzobettini/32/2576_2.png) [@LorenzoBettini](https://community.sonarsource.com/u/LorenzoBettini)\ **Post date:** [April 11, 2019, 8:38am UTC](https://community.sonarsource.com/t/extenability-of-s2699-tests-should-include-assertions/581/8 "2019-04-11T08:38:56Z")
Hi 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 ---
**Author:** ![LorenzoBettini](https://dub1.discourse-cdn.com/sonarsource/user_avatar/community.sonarsource.com/lorenzobettini/32/2576_2.png) [@LorenzoBettini](https://community.sonarsource.com/u/LorenzoBettini)\ **Post date:** [April 18, 2019, 9:34am UTC](https://community.sonarsource.com/t/extenability-of-s2699-tests-should-include-assertions/581/9 "2019-04-18T09:34:34Z")
anyone please? ---
**Author:** ![TobiX](https://dub1.discourse-cdn.com/sonarsource/user_avatar/community.sonarsource.com/tobix/32/175_2.png) [@TobiX](https://community.sonarsource.com/u/TobiX)\ **Post date:** [April 24, 2019, 8:27am UTC](https://community.sonarsource.com/t/extenability-of-s2699-tests-should-include-assertions/581/10 "2019-04-24T08:27:02Z")
It can be set when defining a quality profile, the same way as any other rule properties: ![grafik](https://europe1.discourse-cdn.com/sonarsource/uploads/sonarcommunity/original/2X/d/d22b263b3a8aa56344dab070973718a06fd99dc0.png) ---
**Author:** ![saberduck](https://dub1.discourse-cdn.com/sonarsource/user_avatar/community.sonarsource.com/saberduck/32/27_2.png) [@saberduck](https://community.sonarsource.com/u/saberduck)\ **Post date:** [July 17, 2019, 8:51am UTC](https://community.sonarsource.com/t/extenability-of-s2699-tests-should-include-assertions/581/11 "2019-07-17T08:51:46Z")
Split this topic on July 17, 2019, 8:51am UTC 3 posts were split to a new topic: [S2699 Support custom annotations as assertions](https://community.sonarsource.com/t/s2699-support-custom-annotations-as-assertions/11966) ---
**Author:** ![boly38](https://dub1.discourse-cdn.com/sonarsource/user_avatar/community.sonarsource.com/boly38/32/77633_2.png) [@boly38](https://community.sonarsource.com/u/boly38)\ **Post date:** [March 16, 2022, 11:29am UTC](https://community.sonarsource.com/t/extenability-of-s2699-tests-should-include-assertions/581/12 "2022-03-16T11:29:58Z")
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.) [https://community.sonarsource.com/t/how-to-mark-custom-methods-as-assertion-methods-in-c/31437](https://community.sonarsource.com/t/how-to-mark-custom-methods-as-assertion-methods-in-c/31437) > 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: > > - ASSERT > - CHECK > - EXPECT > - MUST > - SHOULD > - VERIFY > - VALIDATE