Re: SuiteAttribute, RowTest and IterativeTest

Hi Kelly, 

 
> Before replying to this post, read all the way to the end... :-)

OK. Whoops... :-)

Actually, I did, but I'll put a few comments inline after
snipping bunches of stuff...
 
> 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.
 
> I can differentiate between the GUI and the objects...

I know you can in general, I just wasn't sure if we were
clear which one we were talking about in earlier posts.
 
> 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.
 
> >  > It isn't a feature so much, but it would potentially lead to  > 
> > slower Loads than might otherwise be possible.
> >
> >  I can't see that. The slowest part of loading is the reflection -  
> > that's been measured. If you build 5000 tests from one method,  you 
> > should still only need to reflect on that method once. If  you're 
> > doing it 5000 times, that's just an implementation error.
> 
> If you invoke user code, that is no longer necessarily the case.

Why would that be so? I don't see it.
 
> >  You will have a lot of overhead transmitting those 5000 
> tests  to the 
> > user and getting them all into the gui. And the user  will 
> have a lot 
> > of personal overhead in looking at 5000 test  cases - which 
> is why I 
> > don't think you should be doing this.
> >
> >  Long story short: If you design it right, it will only be  
> > inefficient when you are generating large numbers of tests, 
>  which I 
> > think is a bad idea. Instead, you should be executing  one test 
> > multiple times.
> 
> 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.
 
> > since we  only know 
> > what a test answers when the interface is called,  you can 
> say it has 
> > 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.

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

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

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/