Hi Tim,

Static initialisers are a difficult one to catch with NCrunch's code coverage tracking (and therefore impact detection). This is because of the manner in which the CLR executes them.

Static fields are generally initialised the first time the containing class is accessed during runtime, through the class static constructor. This access can happen due to related code being executed, or perhaps through reflection. It can happen well before the test is actually intended to be executed. Because NCrunch's code coverage system only marks out lines that are physically executed by the CPU after the test has marked its execution as started, there is a high chance that these lines won't be included in the test because they were actually executed earlier in the run. There is also the potential for inconsistent behaviour here, as it's possible for the fields to be initialised during the run of an entirely different test that might not be related to target code. Remember that NCrunch will re-use test processes to execute multiple tests where possible, and a class static constructor can only execute once per application domain.

The core issue here is actually a matter of perspective. Logically, the code is covered by the test. The behaviour of the test depends on it. However, physically, the code is not actually executed during the test. If you stepped through your code with a debugger, the code would not be touched with any of the test entry methods in the call stack.

NCrunch is only capable of tracking physical code coverage. To make the jump to tracking logical coverage, we would need to conduct a very complex and very expensive analysis of your code to establish everything it depends on, and probably hook this up with some kind of probability system to handle things like events tied to externals or O/S callbacks deep inside the system. Such an analysis would eliminate the advantages of impact detection, as it would take so long that you might as well just run all the tests anyway. Thus we end up in a situation where impact detection can never be perfect, we just hope it's good enough to be useful most of the time. The situation you've uncovered here isn't something that we're able to efficiently cover with our existing impact detection system, so I would recommend using the 'Run all tests automatically' engine mode in this scenario instead.

I'll take a closer look, but can't make promises. It would be tragic if the solution to this increased all instrumentation times by 20% or something.

Could you perhaps use a property instead?

A static property would be very different in terms of coverage tracking and impact detection, because its value would be initialised and assigned when the property is called, instead of in the class static constructor. If you use a property, the coverage and impact detection hole is gone. Actually, it's probably better practice too, because it means that if there is an exception thrown when the value is initialised, you'll catch it during the test instead of inside some unknown routine where the exception reporting is less clear.