Re: NUnit 2.5: What's In It Now

"Charlie Poole" <[email protected]> Tue, 8 Apr 2008 18:09:14 -0700
Newsgroups gmane.comp.windows.dotnet.nunit.devel
Message-ID <001a01c899de$56666640$6401a8c0@ferrari>
Hi Kelly, 

> >  I think how you've written the Assume.That() and the exception 
> > handling is good, but I think that we don't want Assumes to live in 
> > NUnitTestMethod - does it make sense for a user to write an 
> Assume in 
> > a vanilla unit test (i.e. not even a RowTest or a DataSource test?).
> 
> I don't know what you mean here... Assume and Assert are an 
> orthogonal concern to different Test types. I might be 
> missing something as my brain is a bit hammered today (dang 
> ole day job anyway).

I'm not getting what you mean by "orthogonal concern to different
test types."
 
> > I haven't looked at the 2.5
> > sources yet, but I'm assuming that there is a derived class 
> that the 
> > RowTest and DataSource creates, ParameterizedTestMethod? Maybe that 
> > class, or a Theory class deriving from that would be the 
> better place 
> > to put this - but this can be shipped with the Theory 
> extension, and 
> > doesn't have to be in the core/framework of NUnit, unless 
> there's some 
> > reporting mechanism missing (i.e. if we wanted a different way to 
> > report assumption failures, if we bothered putting that 
> functionality in).
> 
> If you only want Assume to be caught in Theory, then maybe 
> you can separate it into the separate kind of test. If you 
> want to maintain orthogonality, then Assume catching has to 
> go into the core. (if I understand things right). It's the 
> catching of the AssumeException that needs a new extension 
> point, not the throwing of it.
> Specifically, in ProcessException:

IFF you want every test type - now and future - in NUnit to
understand the AssumeException and handle it in the same way,
then you would need to modify the core nunit test runner.

Currently, there are no extension points that modify the
behavior of a test at runtime and designing one would be
a big deal - best deferred to 3.0 IMO.

Current extension points all operate at Load time except
for EventListener, which can't affect test behavior. The 
way to impact runtime in this architecture is to create
a special test type at load time, which then does its
thing upon test execution.

Personally, I don't think it's desirable to allow an
extension to affect every conceivable type of test,
whether existing now or written later on. This could
be very confusing to users.

The core of NUnit understands a very small set of 
concepts. You can run a test. It gives a result.
The result may be success, failure, or a few other
things. The way to handle this issue within the 
core of NUnit is to try to figure out whether we
have a new return type or not and what it is. The
fact that it comes from some exception is the
job of a particular type of test.

> >  if (!TypeOfFileIsB(fi))
> >    return;
> 
> I don't think it's as expressive. That's all. It also reports 
> the test as having succeeded, rather than just not being 
> applicable, which is a difference that doesn't jive with 
> Theory... (although that's what my Assume does too because 
> there isn't a test result type that's really appropriate to 
> the result yet.)

My issue with the expressiveness of this is with any implementation 
that treats the exception as a success. Assume.That doesn't express
success for me. In an implementation where it did something else,
then I might find it expressive.

> I think it's a matter of pragmatism. Is it useful to Assume 
> in data tests, or even regular tests? I think it may be in 
> some rare conditions. Others may not agree. That's fine, it's 
> just an opinion.

In regular tests, your Assume.That would mean something like
Succeed.If. That may be useful. If so we'll add it. In fact,
we already have a request for Assert.Succeed.

Charlie
 
> -Kelly
> 
> --------------------------------------------------------------
> -----------
> This SF.net email is sponsored by the 2008 JavaOne(SM) 
> Conference Register now and save $200. Hurry, offer ends at 
> 11:59 p.m., Monday, April 7! Use priority code J8TLD2. 
> 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