Trying to get to grips with NCrunch, and starting to enjoy having it in my workflow.
Currently the code coverage icons also appear in my Unit Test class.
At the moment they are all there, and when you hover over them (at any line) they say "covered by 1 passing tests", left clicking the icon to show tests, gives a link to the current test you are looking at.
Also, n the icon column, at the first line of each test, a ">" icon appears. Hovering over this it tells me "Tests starting line XX" where is XX is the actual line. what is the point of this icon?
I found the "Instrument output assembly" config setting which switches them off, but it feels like something that NCrunch should figure out itself. For example, don't automatically instrument a class marked [TestClass]
Hi, thanks for posting and for taking the time to try out NCrunch!
As NCrunch monitors all test coverage throughout a solution, your test projects are included in this coverage. Tests do, physically, cover themselves. In many cases the coverage markers on the test can be useful as they allow you to easily analyse complicated test code to see where it is being executed. They also allow you to analyse performance issues inside the test. For this reason, the vast majority of people prefer to have the markers showing next to their test code.
If you find this confusing or it doesn't fit with your view on how the product should work, you are correct in your understanding that turning off the 'Instrument output assembly' option will remove the coverage markers from your test project.
On further investigation, you need this so that changing a Unit Test code automatically triggers a re-run of tests.
I think this seems like a good idea, but how quickly does the test suite run. Is it possible to configure when the rest run will trigger? eg. wait til compilable, wait til typing stops, wait 3 secs after last key press etc?
Yes - the instrumentation is required for impact analysis, so you'll find that switching it off will take away some of the intelligence of the engine in its test prioritisation.
There are a couple of settings you may find useful in changing the manner of build/test execution. Have a look at sliding build delay and custom engine modes.