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

Not sure how others feel about this, but I find the behavior of NUnit
Assert call having something to do with debugger very very "weird".
Aren't the two completely unrelated concepts? It seems to me that this
behavior would be needed if the code was not written with testing
first, but instead already existed and now the tests are being written
for it. You end up debugging the test flow because you are not sure
what fails where.

I would say adding this feature would just encourage bad
behavior/practice in unit testing...

On Thu, Aug 7, 2008 at 2:27 PM, Charlie Poole
<[email protected]> wrote:
> 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
>
>

-------------------------------------------------------------------------
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=/