Hi Stephane,
Yes SonarQube/SonarCloud/SonarLint provide such rules. The main problem is that every rule takes time to maintain, i.e. bug fix, migration when we change parsers, etc… There is also the cost in term of user experience. As we add more and more rules SonarQube/SonarCloud/SonarLint become more difficult to configure.
This is why we prefer to postpone rules which we can’t activate by default, and focus instead on consensual high value rules (ex: detecting None dereference). It is only a matter of priority.
If we find a way to make this rule consensual by detecting specific code patterns we will of course increase its priority.
We try to avoid this as much as possible. In our experience developers stop using static analysis tools when they see too many False Positives. You can learn more about our philosophy towards False Positives in this blog post.
SonarQube/SonarCloud/SonarLint were not initially designed to analyze test code. Rules are tuned for main code and will raise many False Positives on test code. Usually we recommend to configure where main and test code are located. That way we analyze only main code.
That being said, we started last year to add rules which will run only on test code. For now they exist only in java. This is a first attempt to gather feedback on how test code should be analyzed.
If you want test code to be analyzed you can vote and comment on this thread.
I hope this answers your questions.