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

Just making this crystal clear: this is a test development time feature.
Must be turned off during test passes.

I would not call them totally separated.

Let's say a test case failed. Don't you want to know what the state was
right there?


On Thu, Aug 7, 2008 at 12:34 PM, Laimonas Simutis <[email protected]> wrote:

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

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