Context
I am using an On-premise SonarQube instance and we have recently upgraded to version 9.7.1 (build 62043). Within our Quality Profiles, we see new rules that have been marked as [DEPRECATED].
While it is logically that that happens, I have a few questions about a few specific ones:
“Failed unit tests should be fixed” C#
“Skipped unit tests should be either removed or fixed” C#
As mentioned here deprecated rules most likely will have a replacement rule. You can see this in the detail page, see screenshot of an unrelated random deprecated rule:
Generally, deprecated rules have replacements, but not always. Sometimes rules get deprecated because we realize we don’t believe in them anymore, and that’s the case with these.
Probably these rules don’t have a deprecated section because there’s no recommended replacement. We’re simply giving you warning before we drop them. With no replacement, there’s nothing to put into a deprecated section so it’s simply omitted.
Thanks for the answer. And the answer to point 1. If it has no replacement rule does that mean there is also no Deprecated section on the detail page? Like in the first screenshot?
As I also see other rules with no replacement where there is a section.
e.g. “EnableAutoConfiguration” should be fine-tuned" - Java
Okay, you caught me. I was hoping I wouldn’t have to expose the dirty underbelly here, but it seems that I do.
The rules you’re asking about are “common” rules (which you can see in the rule keys), which are provided by the server and thus “maintained” (and I use the term extraordinarily loosely here) by the SonarQube team rather than by the relevant languages teams.
The languages teams have strict procedures and standards for rule descriptions that have been… overlooked by the server team.
Thanks for the explanation.
It’s not a problem, I was just wondering if there was something I overlooked.
As far as I am concerned we can close this thread.
Although I am still kind of curious why it was decided to discontinue these rules, as they seem beneficial to the health of an application. Since I wasn’t relying of SQ to provide this feedback to me, rather the test execution process is responsible for this, it’s not that important to me that it’s in SQ.
Fair question. In large part it’s about the way they were implemented - server-side and thus owned by the SonarQube (and SonarCloud) team instead of the relevant language teams. That means they’re not really maintained, & certainly not customized per language. The thinking is that what’s valuable to each language can be reintroduced later if needed.
