Place the following MSpec classes in separate files.
[Subject(typeof(fake))]
public class fake {
protected Behaves_like<FailSpecificationBehavior> a_failure;
}
[Behaviors]
public class FailSpecificationBehavior {
It should_fail = () => true.ShouldBeFalse();
}
Setup NCrunch/MSpec and allow the test to run.
Now open the NCrunch Tests window and select the test and right-click on it and select "Go to selected test".
I would expect this to navigate to the specification (possibly to the Behaves_like assertion), not to the assertion implementation in the underlying behavior. The vast majority of the time I navigate to a test it's because I want to debug or edit something in the specification, not the behavior implementation. The current behavior means that there's no way to navigate to the actual specification using NCrunch.
I agree with you. The navigation to tests, especially in this situation, is not ideal. I'll try to explain why.
NCrunch itself is a language agnostic tool that extracts its test location and code coverage data using the debugging information generated by the compiler. The debug information only contains line numbers of physical lines of code, and does not contain the actual line numbers of class or method declarations. Because of this, it isn't possible for NCrunch to 'find' the true declaration of some tests - because they are inheriting or delegating structures that do not have debug information representing them.
In this specific case, NCrunch is navigating you to the closest line of code with debugging information that relates to the test you've written. It isn't the right spot - it's just the closest one we have enough information to get to.
To solve this problem properly would involve the introduction of some kind of partial C# compiler that is able to parse C# code and identify the location of specific elements within this code. There are some exciting developments coming in VS2014 in the form of Roslyn, which I hope will make it possible to improve how NCrunch currently handles this.