Re: How do I debug break in case of assertion failure?

Hi Igor,
 
I believe people is just used to the behavior of
System.Diagnostics.Debug.Assert(). Besides, while developing tests, it helps
a lot to have a automatic break mechanism; in case of failure, the test
developer can easily check values and verify what is going on. With such
mechanism in place, the following steps are collapsed in a single one:

1) Run tests for the first time
2) Verify where exactly the failure was
3) Open a debugger
4) Place a break point
5) Run tests again

While using NUnit, I was expecting to find something like:
 
Assert.BreakOnFailure = true;
 
It's default value would be false. Once I'm done with development of the
tests, I could just remove or comment out this line.


IMHO, In the way you're saying, you're pushing NUnit users to write tests in
a specific way, which is fine. That the adoption a little less attractive
though.
 
First of all, I like your suggestion. Would you submit a feature request?
 
But on the last part, I should clarify a bit. Mainstream Microsoft users are
relative late-comers to NUnit.  So, while NUnit may seem to push those folks
in odd directions, they are the directions that the developers and early
adopters expected it to push.
 
Those early adopters were not primarily MS users, but were folks familiar
with this style of testing in other platforms. NUnit (and testing) was
pretty well ignored by the community around MS for many years, so folks in
that community have not had a lot of input into what NUnit does. As more
"mainstream" folks start to use NUnit, there's a need to balance between
it's original goals and their expectations. We will probably never add any
features that members of that original community would consider a bad
practice. OTOH - and your suggestion may be a case in point - we could add
things that those folks consider as merely unnecessary.
 
Unfortunately, though making such a feature available will likely mean that
those folks will never learn how unnecessary the debugger really is most of
the time. That's too bad, but it's probably inevitable.
 
Charlie

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/

_______________________________________________
Nunit-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/nunit-users