Hi, thanks for sharing this code sample.
In this instance, the code coverage data shown by NCrunch is physically correct, because it represents the true path of execution of each test.
Note that the ClassInitialize attribute doesn't work when applied on base classes under MSTest, so it is not executed by the fixture. Moving this method onto the MappingTests class will give you a more meaningful result (NCrunch will report Mapper.cs as covered by MappingTests.*, which is the fixture itself).
Because you've worked around this limitation by calling the ClassInit method directly from your inherited TestInitialize, the coverage of contents of this method thus falls under the actual tests themselves, rather than their fixture. Because the entry to the method is gated by a static boolean flag (_classInitCalled), the method will only be executed by the first test to execute within the test runner's application domain. Every test executed later within the same domain will simply ignore the method because the boolean flag has already been set.
You can actually reproduce this behaviour using a debugger. Try running the whole fixture with a debugger attached and a breakpoint set on the ClassInit method - you'll notice the method gets called only once, and only by the first test to run. NCrunch is recording and reporting this exactly as it happens.
The confusion here stems from the difference between what I like to called 'physical' code coverage, and 'logical' code coverage. Physical code coverage is representative of the actual code path executed by a test when it runs, where logical code coverage is representative of all elements of code that contribute to the execution result of a test. Differentiating between these types of code coverage requires an in-depth understanding of the code itself and how it is designed to work - such an understanding is currently computationally impractical for a tool such as NCrunch, so NCrunch's code coverage is physical.