Hi, thanks for posting!
At the moment, it is not possible to configure NCrunch to behave in the way you are asking for.
However, implementing such behaviour in the product is by no means impossible, and could be
suggested as a feature.
Though I would first urge you to take a closer look at the benefits you receive from having coverage information on your tests themselves. Code coverage conveys much more information that just trying to paint targets on uncovered lines. It tells you a great deal about how your code behaves.
For example, let's say that you have a utility method in your test assembly being used by several different tests. Based on a new requirement, you need to make changes to this method. Being able to see which tests are making use of the method (or individual lines within it) could be useful in guiding your changes.
Being able to see the path of code executed is also very useful for troubleshooting unexpected behaviour in tests. It is quite possible that a test is giving a false pass and being able to see its path of execution can often make this obvious.
Furthermore, the coverage markers also provide performance information that can help with identifying and resolving bottlenecks in tests.
Finally, if an assertion fails inside test code, the markers are necessary for showing this exception information inline. If a test fails without any markers, there will be no X to tell you where it blew up - you'd need to analyse this exclusively using the Tests Window.
I understand that the above points may not be advantageous to the way in which you work or the way in which you choose to use NCrunch. My intention in designing the product has always been for it to tell you more about how your code is behaving, as opposed to painting targets on coverage gaps. Considering such a goal, the visual pollution caused by the markers seems like a small price to pay in exchange for the many benefits.
