Continuing with my series of answers to questions that were asked during my webcast last week…

Do the “checkers” (algorithms that find specific defect patterns) find defects in unit testing code?

If you want them to, yes.

First off, as I described in my talk, we deduce which code you want analyzed by monitoring the process that makes a clean build: by watching every invocation of the C# compiler during a clean build we know precisely which source code is being compiled, which assemblies are being referenced, and so on. If you don’t want your test code analyzed, don’t build it while the build capture system is running, and it won’t be analyzed. If you do want your test code analyzed, do build it.

Second, we have a feature called “Components” which allows you to separate defects sources into different logical groupings. This way in our defect presentation tool you can say “I only want to see defects found in the testing component”, and so on.

There are definitely some subtleties to consider when looking for defects in test code. For example, if you have a test which contains:

while(i++ < 10);
{ 
  Test.Assert(Bar(foo));
}

then that test has a genuine “stray semicolon” defect. (Of course the C# compiler will note this one as well, but that’s not germane to my point. The point is that this is clearly a case where the test is not behaving as desired and an analysis tool can determine that.)

By contrast, I’ve seen test code like this:

  Test.ExpectException<ArgumentNullException>(Bar(null));

The static analyzer will likely report that Bar is being called improperly, but that’s the whole point. It can be tricky to detect that this is an “intentional defect” and suppress it. Testing code tends to have a high concentration of intentional defects.