Re: SuiteAttribute, RowTest and IterativeTest

On Wed, Mar 12, 2008 at 7:41 PM, Charlie Poole
<[email protected]> wrote:
> 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.

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

I'll try to be clear.

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

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

Well, if I create a huge user object in my IEnumerator that generates
the parameters to the Theory, and that object is created by reading
XML files, that can make things slower than I want. This is an obvious
point which I'm sure you have. So if you don't grok what I'm saying,
I'm sure you still understand it.

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

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

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