Re: NUnit 2.5: What's In It Now

On Tue, Apr 8, 2008 at 7:09 PM, Charlie Poole
<[email protected]> wrote:
> 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."

What I was thinking was that both Assume and Assert should be handled
by Test, DataTest, IterativeTest, etc., etc. independently of each of
them individually writing code to handle them. But that's not how the
current architecture works, apparently.

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

That is what I wanted. Apparently not what you want. That is a matter
of opinion, which is fine.

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

Agreed.

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

Right, got that now.

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

Potentially, since we don't know what types of tests there might be.
Is it true that ALL test types understand Assert or not? Do you have
to write code to understand Assert in each TestCase type?

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

It would be nice to have another choice of test result types, but
that's the only thing needed for Theory, and you've already talked
about adding it, I think.

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

What else would you have it do? I suppose you could collect together
the set of Theory runs that resulted in Assume being thrown, and
that's a good thing, in fact, I think I left a TODO: in the code I
sent you about that. What other things?

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

I think I would like that. It would also be nice if the other test
result types could be thrown directly. Assert.Ignore() for example?
Maybe that's already in there, I don't recall.

-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