Re: NUnit 2.5: What's In It Now

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.

Actually, I don't find it more expressive - which is probably why
we aren't agreeing. To me, it looks as if it ought to do something
more than just return, so I waste energy trying to figure it out.
Then I learn it's just a way for the test to succeed. I guess
expressiveness is a matter of 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?

That's what I said - that you have a different view. I didn't say
it was a bad thing, did I?

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

They are handled by NUnitTestCase, which is not part of the 
core of NUnit - it's just another extension like you might write.
 
> >  > 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?

Got it now.
 
> >  > 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.

I don't understand that.

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

ProcessException is in nunit.core, in TestMethod or TestCase - 
I forget which at the moment. But it's not truly "core" - that
is it's not part of the stuff we extend. Rather, it is itself
an extension. When you write your own extension, with your own
test case, then you can handle any exception you like in any
way you like.

In principle, this is no different from the exceptions that
signal a failure. There is no place in NUnit that recognizes
those exceptions for all tests. NUnitTestMethod recogizes the
particular exception that it knows about. CsUnitTestMethod - 
to take one example - recogizes a completely different exception.

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

By creating a test case that contains the code to process that
kind of exception.
 
> >  > >  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.

OK, then the discussion turns on whether one finds it 
expressive in the sense you are using it.
 
> > > 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.

No need now - I found it and responded separately

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