[Subject(typeof(Foo))]
public class fake {
Because of = () => _result = Foo.DoIt();
It should_return_true = () => _result.ShouldBeTrue();
static bool _result;
}
public static class Foo {
public static bool DoIt() {
return false;
}
}
Setup MSpec/NCrunch to run the specification.
When the specification fails open the NCrunch Tests window and right-click the assertion "should return true" and select "Show coverage for selected test only".
I would expect this to show the DoIt() method as being covered by the test (red dot), however it does not (black dot).
If you choose to show coverage for the entire specification (fake), DoIt() is properly shown as being covered.
The code coverage for the DotIt method isn't shown when you choose to isolate coverage for the test, as this method is covered only by the fixture and not by the test. You'll find that if you were to add additional specs/testmethods to this class, the DoIt method would only be called once. This is because it is essentially a fixture-level method.
The correct way to handle this if you wish to see coverage for both the fixture and the child tests is to do what you've described - choose to isolate code coverage on the fixture rather than the test.
From a testing library agnostic perspective I agree with you, MSpec Because and Establish are technically the same SetUp in other testing frameworks and run once per fixture. From an MSpec-specific perspective I still feel like the current behavior is going to be incorrect the vast majority of the time.
MSpec assertions ("It should...") are generally extremely short and should contain no logic besides the assertion. If I right click on a failing assertion and select show coverage, 100% of the time I want to see the coverage for the Establish and Because as well. The way I most often run into this issue is I intuitively right-click on the red x next to the It indicating the exception thrown during the assertion and select show coverage, which then shows me nothing except the It itself being covered, when what I really wanted to see is the path taken through the Establish/Because.
I accept that this improvement may be difficult and/or not worth your time to implement, but I disagree that the current behavior is the most intuitive or correct when using MSpec with NCrunch.
Thanks for sharing this. Mechanically, MSpec actually runs all the individual 'It' cases together - it is impossible to separate them .. which is quite different from other test frameworks, so I'm actually inclined to agree with you on this.
I'll need to have a think about what the correct approach is here, and the best way to implement it. Thanks for again sharing your thoughts.