CA1822 is incorrectly applied to [TestMethod] async Task methods in Release Mode?

Question

I am working with a custom RuleSet, one that has CA1822 turned on as an error.

I have a TestMethod, that is async, so it returns a Task. This method does not use any fields, so code Analysis flags rule CA1822, mark it as static. But MSTest can not call a static async Task method (not listed in test explorer). So it seems like a flaw in the logic for Code Analysis. I am fairly new to C#, so I am trying to follow code analysis as best I can, putting suppression in when I feel like I should break the rules. But this is the first time I have found myself thinking that the rule is just flat out wrong.

[TestMethod]
public async Task TestMethod1()
{
    await Task.Delay(10);
}



Severity    Code    Description Project File    Line    Suppression State
Error   CA1822  The 'this' parameter (or 'Me' in Visual Basic) of 'UnitTest1.TestMethod1()' is never used. Mark the member as static (or Shared in Visual Basic) or use 'this'/'Me' in the method body or at least one property accessor, if appropriate.   

Am I missing something with the rule? Or is this just enough of a corner case that it was not tested?

Trying out some more conditions, it only seems to be a problem in release mode. In debug mode, it never flags CA1822. If my testMethod is not async, then the rule never applies in debug or release mode.

So I guess I should mention this is in studio 2015 enterprise RC3.

That to me suggests that it is a corner case in the RuleSet, but I would like to hear what other people think.

Answer 1

The rule is from the performance set, and from a performance perspective, it'd be faster to make the rule static. There may be a 1000 reasons, it being a unit test method in this case being one of them, that may cause you to not apply this rule though.

I've personally turned off this rule for most projects. In many cases it leads to bad object oriented design, even if it executes a little faster. The little remark from the docs:

In some cases, the failure to access the current object instance represents a correctness issue.

Which is in general a more correct remark, though it doesn't apply in this case.