- Operating system:macOS Ventura
- SonarLint plugin version: 126.96.36.199615
- Programming language you’re coding in: Java
- Is connected mode used: No
And a thorough description of the problem / question:
If you define reusable classes for unit testing following gradle standards in ‘testFixtures’ and those classes make use of junit assertions (e.g., org.junit.jupiter.api.Assertions.assertTrue), Sonarlint flags a bug that “Assertions should not be used in production code”.
Hey @cssprs ,
It seems to me that in this case, you are reaching the current limit of our rule classification. Rule java:S5960 is explicitly trying to identify the wrong use of assertions in production code… Buch such calls are always going to be valid when designing a testing frameworks.
Unfortunately, there is no way to let our analyzer know that it is analyzing a project aiming at tests… and so this rule is non-sensical in this context. I would encourage you to ignore the issues and mark them as won’t fix (or disable the rule).
Thank you for your reply, but I’m not sure I understand the limitation here. SonarQube is somehow correctly recognizing that actual tests should not be subject to the same rules as production code. Are you doing this based on the location of the class files in the directory hierarchy or based on the presence of annotations in the source code such as @Test? My assumption was you were doing it based on well-known test locations and that you could apply the same rules/logic to classes in testFixtures which is also a well-known location. The rule itself seems like a sensible rule, so I would prefer not to disable it just because of this limitation.
Hey @cssprs ,
Thanks for your patience. Let me try to clarify.
It is based on the location of the files in the directory hierarchy.
I’m unfortunately not familiar with test fixtures. Since rule categories (MAIN vs TEST) are mutually exclusive (we don’t plan to change this mechanism for the time being) and your test fixtures are recognized as MAIN code (as rule S5960 is executed), would you prefer to have the java analyzer behaving as automatically identifying test fixture as test code? (And so only execute test-related rule)
You can read more about testFixtures here. Yes, since testFixtures should not be deployed to production, I believe they should be considered as TEST code and not MAIN in your parlance.