Re: NUnit 2.5: What's In It Now

"Charlie Poole" <[email protected]> Thu, 10 Apr 2008 12:28:30 -0700
Newsgroups gmane.comp.windows.dotnet.nunit.devel
Message-ID <01d801c89b41$10274e10$6401a8c0@ferrari>
Hi Kelly, 

> >  > How do I, as a casual user, learn that I can't call  > 
> Assume.That 
> > inside of a Test? I could assume that it would in  > a 
> particular way, 
> > and it wouldn't. How do I discover that  > fact as a casual user?
> >
> >  The test would give an error due to the unexpected exception.
> 
> That would help, IF the error were specific enough... something like
> 
> "Assume is not supported within [Test], it is for use with 
> [Theory] only."

It would say UnexpectedExcepton: AssumeException with any message
you had provided and a stack trace. The user might have to wonder
about it a bit before realizing that Assume is throwing the
exception. That's a drawback, but I can't think of any other way
to do it without lettin NUnit know that Assume exists.

NUnit doesn't know anything about Assert either, btw.
 
> If we're doing it for csUnit and MSTest, why would MbUnit be 
> a second class citizen? Just curious. Is it because it's 
> hard, or confusing, or what?

csUnit and MS Unit tests provide only one type of test. So
emulating them just requires an addin with a new test type.
At least on the surface, mbUnit seems to provide many types
of tests, so it's probably easier to emulate them separately,
rather than to emulate "mbUnit" as a whole.

Additionally, there seems to be no advantage for NUnit in
emulating mbUnit as a framework, as opposed to emulating
the individual fixture types.

> >  There
> >  are three levels we could do this at:
> >
> >  1) Have attributes and tests that look like MbUnit's
> >  2) Simulate loading of mbUnit tests, execute their actual
> >    asertions and interpret the results.
> >  3) Write some sort of adapter that runs the tests under
> >    the actual mbUnit runner and interpret the resultss.
> 
> I was thinking along the lines of 3.

It's certainly possible.
 
> >  (1) is how Andreas' RowTest works - as well as MbUnit's
> >     emulation of NUnit.
> 
> Kind of weird to have NUnit run MbUnit to simulate running 
> NUnit... :-)

One reaso why emulating All of mbUnit doewsn't make sense to me.
 
> >  (2) is how my csUnit and (in process) vsts addins work.
> >  (3) is how Gallio works
> >
> >  For now, I'm sticking to (1) and (2) but we may go farther 
>  in NUnit 
> > 3.0.
> 
> I wouldn't expect anything on this line until 3.0. Adding 
> some data-driven stuff in 2.5 is really good, but not 
> emulation of MbUnit.

I may add one or two fixture-type emulations, merely as a way
of exercising the addin facility. Or maybe not - it depends on time.

> Let's get it out. :-)   Then Gary and I can play around with Theory in
> Addin land.

Continue to do it now as well - there may be changes needed in 2.5
to make it work.
 
Charlie

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



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