Should we use FxCop on UnitTest assemblies?

Question

We use FxCop for all of our projects. For our UnitTests I am not sure it is worth it. We end up with many suppresses:

[SuppressMessage("Microsoft.Performance", "CA1822:MarkMembersAsStatic", Justification = SuppressJustifications.CA1822MethodIsUsedExternallyAsNonStatic)]
[SuppressMessage("Microsoft.Usage", "CA1806:DoNotIgnoreMethodResults", MessageId = "Cantaloupe.Seed.Security.RijndaelEncryption", Justification = SuppressJustifications.CA1806MethodIsCalledForExceptionThrowingTest)]

What are people's thoughts on FxCop on Unit test code?

Answer 1

When I teach our unit test / TDD class, I usually tell people to write test code following the same principles as they would when writing prober production code. However, I acknowledge that some of the FxCop rules may generate too much noise.

Couldn't you use a suitable subset of the FxCop rules for the test code?

Answer 2

not worth the effort; FxCop is for production coding standards, not internal test code

(however, it doesn't hurt to give it a run-through and a once-over every now and then, in case it tells you something useful...)

Answer 3

Yes but you don't have to be a maniac about it. You're tests are your maintenance coder's best friend. If your tests aren't easy to read your maintenance coder will have a hard time of things. I think it helps encourage better habits, unit test code does not have a permissive license to be sloppy.

Answer 4

GO ahead if you have time on your hands. Its not a bad idea to make the cop take a look at all your code.