Extending S2699? (Tests should include assertions)

67 views
Skip to first unread message

Tobias Gruetzmacher

unread,
Jun 6, 2018, 7:50:21 AM6/6/18
to SonarQube
Hi,

I wonder if it would be possible to add a simple method to extend AssertionsInTestsCheck with "custom" assertions? Currently, this rule supports a list of hard coded test frameworks and assertion methods. At my company we have some custom assertions (which internally call JUnit in the end). Would it be possible to maybe tag some classes/methods with some annotation (or implement some naming scheme?), so that S2699 detects them as assertions?

Regards, Tobias

Andrei Epure

unread,
Jun 7, 2018, 10:11:10 AM6/7/18
to SonarQube
Hi Tobias,

Thanks for reaching out. We currently don't have any plans to add parameters to this rule (we generally avoid adding parameters to existing rules).

However, we would appreciate if you could provide us with a reproducer of your case, in order to evaluate it and maybe add it to our future plans.

Kind regards,
Andrei

P.S.: Starting June 11th we'll have a new awesome forum. Details here

Andrei Epure | SonarSource

Software Developer

https://sonarsource.com


Are you using SonarLint in your IDE?


Tobias Gruetzmacher

unread,
Jun 8, 2018, 4:39:50 AM6/8/18
to SonarQube
Hi Andrei,

thanks for your answer. I understand that you don't want to add parameters to that rule, but maybe add a generic extension mechanism, so that it can pick up future (and internal) test frameworks?

For example we have a custom compareTester (tries to verify the comparable contract):

    CompareToTester.forClass (Integer.class)
                   
.forceEqualsConsistency (true)
                   
.addSortedLessInstances (new Integer (1), new Integer (2), new Integer (3))
                   
.addEqualInstances (new Integer (4), new Integer (4))
                   
.addSortedGreaterInstances (new Integer (5), new Integer (6), new Integer (7))
                   
.testCompareTo ();

I wouldn't mind adding an annotation to the testCompareTo method to designate it as an assertion-type method. Maybe have some kind of @Assertion annotation, which I could add to our internal test classes/methods and future open source test frameworks can use to tag their assertion method/classes, so you don't have to maintain the list in Sonar-Java?

Regards, Tobias
Reply all
Reply to author
Forward
0 new messages