Re: SuiteAttribute, RowTest and IterativeTest

Hi Kelly, 

> >  > Right. And that's part of the problem with Theory  > 
> implementation 
> > in 2.5...
> >
> >  I don't think it has to be a problem. See my earlier  note on 
> > multiple results.
> 
> Well, maybe it can be done in 2.5, but could it be done in a 
> way that's forward compatible to what we want to do in 3.0? 
> That's key to me when deciding whether or not to do some 
> subset of the Theory functionality in 2.5. Unfortunately, it 
> involves a bit of design up front.

Or perhaps requirements? In a testing application, saying
"I'd like to be able to have a [Theory] attibute that
does x" isn't design. It's a story. It's easy to forget
that when the target audience is programmers.
 
> >  > It is... But what I said applies to the internal objects as well.
> >
> >  Why do you - in your user hat - care whether a given test 
> case  ( a 
> > child of iterativetest ) is in the tree or not? That seems  
> to be an 
> > implementation detail.
> 
> I guess the reason I care is that because Theory is different 
> from Test, it seems to me that the GUI for Theory might vary 
> slightly from that of Test... I'm trying to imagine what I 
> want that to be.

But what you're saying, if I cast it in story form, is "As
a test writer, I'd like the NUnit internal data structure
representing tests to contain a separate node for each
data point tested."  That makes no sense. You're doing
design here.

> >  > That's an interesting point.. . you're talking about the  > 
> > internal objects here, not the user's test code, right?
> >
> >  Yes. So if we were going to execute a test 50000 times,  
> we would not 
> > want to send 50000 test representations  to the client. We would 
> > rather send one, with a notation  that it's going to be 
> executed 50000 
> > times.
> 
> Ok, that's interesting and relevant.
> 
> >  > > 5000 or 50000 if you like.
> >  >
> >  > Right. But you might not know ahead of time.
> >
> >  True. If a test didn't know how many times it would be executed,  
> > then we would have to return something else. The simplest 
> is to  count 
> > test methods instead of cases at load time and only report  actual 
> > test case count after execution.
> 
> Works for me. This is part of what I was getting at when I 
> said that the GUI has to change a bit to accommodate the 
> differences in Theory vs. Test.

That example is not actually the gui. The gui will still just display
whatever count it receives - the gui doesn't do any counting. In fact,
the NUnit gui I fairly agnostic about tests and how they work.

But I take your point: if Theory is a whole new concept, it may call
for a whole new representation.

> >  > Let's decide what we want in the other thread, then once 
>  > we've 
> > decided where we want to go with things, we can discuss  > if some 
> > subset of that could be usefully implemented in the  > 2.5 
> time frame.
> >
> >  Yeah!!!
> 
> Same page achieved!
> 
> >  > As Yogi Berra said, "You've got to be very careful if 
> you  > don't 
> > know where you're going, because you might not get there."
> >  >
> >  > I think I want to let this thread die down for a bit until we  > 
> > get through the Theory thread on the Nunit3 list. Ok? I 
> think  > there 
> > is more concrete to discuss over there.
> >
> >  Sure.
> 
> You haven't replied to the other thread yet... tap. tap. tap... LOL.

I always try to answer all my "current nunit" stuff first. :-)

Charlie
 
> -Kelly
> 
> --------------------------------------------------------------
> -----------
> This SF.net email is sponsored by: Microsoft Defy all 
> challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> nunit-developer mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/nunit-developer
> 



-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/