Re: NUnit 2.5: What's In It Now

You can capture a stack trace at will using the
System.Diagnostics.StackTrace class.
 
The trick will be filtering and pruning the trace down so that showing
traces for multiple asserts does not get out of hand.  The traces should
effectively be scoped within the context of the Assert.Multiple as if a
catch block appeared there (but it does not).
 
In principle, we could just cut the trace down to one line: the location of
the assert that failed within the Assert.Multiple block.
 
As for syntax, we have a few options such as:
 
using (Assert.Multiple)
{
    // more asserts
}
 
Assert.Multiple(delegate
{
    // more asserts
}
 
(or the same thing using the lamdba syntax)
 
 
In terms of actual implementation, there's a hack for this feature in MbUnit
v2 that a couple of people seem to be using now.  We will be adding the
feature more formally in MbUnit v3 soon.
 
I started messing around with this idea a year or two ago along with a few
others to assist with grouping related asserts anhd providing more
contextually relevant information on the whole.
 
Jeff.

  _____  

From: Vaughn, Clifton [mailto:[email protected]] 
Sent: Friday, April 11, 2008 12:30 PM
To: Jeff Brown; [email protected]
Subject: RE: [nunit-developer] NUnit 2.5: What's In It Now



The challenge with this approach, and I'm all for it btw, is that you lose
the context information (stack trace) so you can go to the offending line of
code.  Unless of course your assert.Multiple just caught the exception and
then outputted it so that it can be used in VS or other tool.

 

Thanks 

cliff 

  _____  

From: [email protected]
[mailto:[email protected]] On Behalf Of Jeff
Brown
Sent: Friday, April 11, 2008 2:13 PM
To: [email protected]
Subject: Re: [nunit-developer] NUnit 2.5: What's In It Now

 

I call this feature Assert.Multiple.  It creates a context within which
multiple assertion failures are allowed.

When the context is exited, all asserts are reported together.

 

This allows you to glue together many asserts that are really about
verifying some more complex state piecewise.

 

Jeff.

 

  _____  

From: [email protected]
[mailto:[email protected]] On Behalf Of Erlis
Vidal
Sent: Friday, April 11, 2008 10:10 AM
To: [email protected]
Subject: Re: [nunit-developer] NUnit 2.5: What's In It Now

Hi everyone,

 

I'm reading your posts and I would like to give you this idea, because maybe
this could help. 

 

If we can "disable" the break on failing behavior within a method call, and
then the option for "enable" it again, maybe this could help. It's the
programmer's choice. This could help in the case I'm testing in a loop the
inputs values and the expected results. With some mechanism to retrieve the
results (failing or success) after re-enable the default behavior you could
have what you are looking for. Maybe the "enable" method could return a kind
of report class. If the code never was "enabled" then NUnit print the report
class at the end of the execution.

 

I hope I can help you guys; I really appreciate your job.

Sincerely 

Erlis

 

 

  _____  

From: [email protected]
[mailto:[email protected]] On Behalf Of Charlie
Poole
Sent: Thursday, April 10, 2008 5:10 PM
To: 'Gary Evans'; [email protected]
Subject: Re: [nunit-developer] NUnit 2.5: What's In It Now

 

Hi Gary,

 

For example, you write 

   Assert.That( 2 + 2 , Is.EqualTo( 5) );

I'd like the test result that says "Expected: 4 But was: 5" to go back to
NUnit

without throwing an AssertionException.

 

Why you ask?

 

Because then, if you wrote

  Assert.That( 2+2, Is.EqualTo( 4) );

I could give NUnit that successful result, and continue with the test.

 

Reporting of successful asserts is a long-standing request and reporting

failure via an exception seems wrong to me, since failures are expected

in a test framework.

 

That would not change how other exceptions are reported, however.

 

Any ideas?

 

 

Charlie

 


  _____  


From: [email protected]
[mailto:[email protected]] On Behalf Of Gary
Evans
Sent: Thursday, April 10, 2008 2:05 PM
To: [email protected]
Subject: Re: [nunit-developer] NUnit 2.5: What's In It Now

Hi guys,

> "Reporting test results without exceptions" has been on the work plan
> for a while. If I knew how to do it the workplan would say something
> specific. I'm not above putting something on a plan that I have not
> yet figured out how to do.
> 

What sort of results are you after reporting? Currently we either have the
case where no exception is thrown, and if the method is decorated with an
ExpectedException then there's a failure, and the converse (if an exception
is thrown and we don't have an ExpectedException attribute).
 
I'd like to see the results of multiple asserts, and maybe for an assertion
failure report that its failed without breaking out of the test (this may
replace a lot of the data-driven testing stuff)
 
Cheers,
Gary


  _____  


News, Sports, Entertainment and Weather on your mobile. Text MSN to 63463
Now. <http://mobile.uk.msn.com/pc/msn_content.aspx>

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