Re: NUnit 2.5: What's In It Now

> > > Assert could be implemented such that if it were successful,> > > it could append the successful assertion to an output> > > reporting mechanism, while still throwing exceptions for> > > failure. You already have to catch other exceptions anyway as you say.> >> > Sounds like a possibility.> > I would think you would want a separate "stream" for successful> Asserts from unsuccessful Asserts anyway.> > > > I think it is very bad to continue execution after an> > > Assertion has failed. That changes what assert has meant for> > > thirty plus years in the C/C++/C# world. That would be like> > > putting a game boy console in place of the steering wheel,> > > accelerator and breaks of a car IMHO.> >> > Not sure where you got that. There are no plans to continue> > after a failure.> > That's what it sounded like Gary was suggesting. I think it would be a bad idea.> > -Kelly> 
Yep, that's what I took Charlie to be suggesting. I think for data-driven driven tests this is good for now, but as Charlie says, we could perhaps use Assert.Warn(), or as Jeff Brown suggests, could put this into a separate context (in an Assert.Multiple() block)
 
I do think (after what you've been saying on the NUnitv3 list) that changing normal Assert to continue always is a bad idea.
 
Cheers,
Gary
_________________________________________________________________
Amazing prizes every hour with Live Search Big Snap
http://www.bigsnapsearch.com

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone

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