Re: NUnit 2.5: What's In It Now

On Mon, Apr 7, 2008 at 12:00 PM, Charlie Poole
<[email protected]> wrote:
> Hi Kelly,
>
>  > I just want an exception that I can throw that means the Test
>  > exits without penalty.
>
>  Can't you just return?

I suppose. For me it's a question of expressiveness. Yes, returning is
incrementally faster than exception handling. It's just not as
expressive in my opinion.

>  > If the programmer is using a random number generator, or
>  > anything just a little complex like reading data files that
>  > someone else may be generating, then he loses total control
>  > over the input. That's part of what you run into doing data testing.
>
>  Agreed. The question is whether one should be encouraging programmers
>  to do things like that. Jim and Brad have answered absolutely no.
>  I have said "when testing a theory." You are saying "whatever the
>  programmer wants." These are different philosophical views.

I guess I'm pragmatic in favor of flexibility. If people can use tools
in different ways than the author might have intended, in ways that
are useful to them, why is that a bad thing?

>  > >  > Would your implementation of Assume be different than that?
>  > >
>  > >  No - but what I do with the exception may differ.
>  >
>  > That's why I asked for an extension point at that location in
>  > the code... If I can do it another way, then that's fine too.
>
>  I don't understand what point you mean. Exceptions are not handled
>  at all by the core of nunit. They are handled by extensions.

See my post to Gary a minute ago. In the Framework the Assert
exception is handled, I want to handle the Assume exception in a
similar way.

>  > I wrote the code... it's not like the last time where I was
>  > trying to get you to do it. All you have to do is accept my
>  > contribution. :-)
>
>  Where is the code? I must have missed something.

I emailed it to you. Would you like it again?

>  > Where I have difficulty is that it "feels" like an emotional
>  > response rather than a technical one.
>
>  There is a third category, that of goals and objectives. I think
>  you may be equating "non-technical" with "emotional" - as we
>  techies sometimes do.
>
>  That said, there comes to be an emotional level, arising
>  when one's argumets don't seem to be heard.

I admit to feeling a slight tinge of frustration, but I'm trying to
make my arguments on a technical basis... Ok, perhaps not just a
technical basis, but rather on the basis of expressiveness. That's not
exactly a technical argument either. :-)

When you have Theory with a Theory Explorer, then Assume rises to a
technical level.

>  > That is probably a
>  > limitation of the medium more than anything else, but I just
>  > can't grok your technical argument because it seems to be
>  > based on "I haven't thought about it enough yet" and not much
>  > more.
>
>  First off, I don't think I've even tried to make a technical
>  argument. I'm trying to operate at a somewhat higher
>  level in order to decide /whether/ to include a feature.
>  Technical arguments belong in the discussion of /how/ to
>  implement a feature - stuff like "Should we use an exception
>  or something else."

Ok. Fair enough. I guess I've been trying to goad you into a technical
argument, and it isn't working.

>  Secondly, as the guy who takes personal responsibility for
>  everythin that goes into a release, I feel that "I haven't
>  thought about it enough" is a darned good reason to delay
>  doing something.

Ok.

>  Thirdly, you are putting a lot of energy into getting
>  what you want done this month rather than next month,
>  and that seems a bit emotional to me too.

Ok. That's a fair observation.

>  > I'm done beating this dead horse. I'm sure we'll get it
>  > right in 3.0, or perhaps close to right in an Addin.
>
>  There is no reason it can't be done right - or the way
>  you want - in an Addin. In fact, if it can't be, then
>  it can't be done in 3.0, which will consist entirely of
>  addins. What you want - to the extent I grasp it - seems
>  to be perfectly easy to implement in the existing Addin
>  structure.

Ok, I could not figure out how to do it in the current structure
without changing the code in the nunit.framework, specifically in
ProcessException.

>  If you want to re-cast this discussion to "how can I do it"
>  rather than "why doesn't NUnit do X?" I'd be glad to help.

I'm super happy with that approach. How do I do what's now done in
ProcessException in an Addin?

>  > >  Your example works fine without Assume - just substitute  "if" for
>  > > "Assume.That"
>  >
>  > With that argument, then there is no need for Assume even
>  > with a full blown 3.0 Theory implementation. Unless it's just
>  > a semantic issue. My lack of emotion about BDD should be a
>  > clue how I feel about that sort of argument :-)
>
>  It was your example. :-) What I'm saying here is that you
>  have not managed to make me understand /how/ what you want
>  is different from an if statement.

It differs only in expressiveness. You could say exactly the same for
ExpectedException... because you can write a try catch block and do
your own Assert.Fail after the catch.

> > I did write it. I guess I integrated it too tightly into the
>  > core though. Perhaps I should take it up with Gary and see if
>  > he can incorporate my Assume into his Theory... if he hasn't
>  > done something similar already.
>
>  As I said, I may have missed something here. I knew you had written
>  some code, but I thought it was only on-the-job and not available for
>  us to see. If you let me know (again?) where it is, I'll take
>  a look and maybe that will clarify things.

Sure, I'll send it again to your individual address.

-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