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

I feel that way too, although I would be willing to consider
some behavior that helped legacy testing, if it could be done
without encouraging the same thing on new work.

As my earlier note indicates, however, I'm really not sure
this is very useful /even/ to those with a legacy mindset.
The break is happening at the wrong time and place for me to 
want to ever use it, even in those cases where I would use the
debugger.

Charlie

> -----Original Message-----
> From: Laimonas Simutis [mailto:[email protected]] 
> Sent: Thursday, August 07, 2008 12:34 PM
> To: Charlie Poole
> Cc: [email protected]
> Subject: Re: [Nunit-users] 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=/