That makes sense. If the code is in a standard [SetUp] method, then it will be executed as part of the test .. so there'll be no coverage separation between the test and the setup.
I may be able to suggest a test structure that can help with working around this. It involves treating the test fixture as a scenario, and the tests within the fixture as requirements measured over the results of this scenario. For example:
Code:
public class WhenIClickTheBigRedButton
{
private FormWithBigRedButton subject;
[TestFixtureSetUp]
public void ExecuteScenario()
{
subject = new FormWithBigRedButton();
subject.ClickBigRedButton();
}
[Test]
public void FormShouldTurnRed()
{
Assert.That(subject.BackgroundColor, Is.EqualTo(Colors.Red));
}
[Test]
public void FormShouldGrowLarger()
{
Assert.That(subject.Width, Is.GreaterThan(300));
Assert.That(subject.Height, Is.GreaterThan(250));
}
}
... In this way, the setup code is always separated from the tests - giving much flexibility. You can also further extend the scenario using inheritance, allowing for much more diverse and complex scenario constructions complete with code re-use.
Anyway, I'll need to think more about allowing tests to manipulate their own coverage outside of normal execution flow. There is potential for such a feature to become dangerous (i.e. if you were to accidentally check-in your debug code, this could create some VERY interesting issues for team members working on the same codebase). There may be better ways to peg this down so that such a modification is transient and will only appear for the life of the NCrunch session - rather than being embedded in the code..
Cheers,
Remco
