Re: Roadmap Updated

On Wed, Mar 12, 2008 at 6:43 PM, Charlie Poole
<[email protected]> wrote:
> Hi Kelly,
>  > In theory, I agree. The issue is whether the current
>  > architecture supports this, or do we need an architecture change?
>
>  Yes, it does. That was kind of my point. :-)

Ok... :-)

>  > I don't know why you would need to for RowTest, but I would
>  > see no problem running it every time for IterativeTest...
>
>  There is no generation for row test - the data is just there.

You still have to create the internal test objects for each row... I
thought that was what we were talking about.

>  > Give me an example where you couldn't implement a Theory in that way.
>  > In reading the Theory papers, they seem to implement it that
>  > way. What do you think I'm missing?
>
>  If you use a data-driven approach to prove a theory, that's Theory.
>  If you use if for something else, that's not the case.
>
>  Example - Say I'm testing farenheight to celsius conversion...
>  The syntax is invented - and hopefully clear...
>
>  [Test(32,0)][
>  [Test(212,0)]
>  [Test(-40,-40)]
>  public void CanConvertFarenheitToCelsius(int f, inf c)
>  {
>   Assert.That( FarenheitToCelsius(f), Is.EqualTo( c ) );
>  }

Stupid question, does this work today? Or is this something proposed?

>  Nothing theory-like about that. It's just an easier
>  way to write three tests.

Ok, I think I get where you're going.

>  [Test]
>  public void FarenheitToCelciusToFarenheitGivesOriginalValue(
>         [Values(-40,0,32,212,500)]val)
>  {
>   Assert.That(
>         CelciusToFarenheit( FarenheitToCelcius( val ) ),
>         Is.EqualTo( val ) );
>  }
>
>  That's a theory. And I didn't even use the word. :-)

Ok, like I've said before, Theory isn't ALWAYS new, just a new way to
talk about things. It's like BDD a bit in that sense.

>  > The intent of Theory is to state a mathematical theorem that
>  > the code should fulfill in all circumstances. That's a pretty
>  > powerful idea.
>
>  Yes!!!

Ok, I get it.

>  > You could drop down and do Dykstra proofs of each of these
>  > theorems against your code, but that is heavy. A lighter way
>  > to indicate that your theorem is likely true is to run a lot
>  > of different example data sets against the Theory. This
>  > doesn't prove anything, but it does give a good indication
>  > that you're on the right track.
>
>  Exactly. It's amazing that we suddenly agree!

I don't know that we ever disagreed. I think it is just that in this
limited medium, it's hard to communicate sometimes.

The only area where my thinking has evolved in the last few days is in
when the tests need to be constructed to fully support all kinds of
Theories.

>  > RowTest and IterativeTest are two styles of providing those
>  > example data sets to your Theory.
>
>  Precisely. And I'd like to retain that precision in our discussion.
>  Testing a Theory against a finite set of examples requires two
>  things: a Theory and a way to express or generate examples.

Exactly.

>  RowTest and IterativeTest can serve in the second role, but
>  it would be incorrect to say that they somehow "are" Theory.
>  More precisely, it was incorrect when you said it. :-)

Did I say that? If I did, then I didn't mean it. :-)

>  > Are there other ways?
>  > Possibly.
>
>  Indeed. And before going on, I'll say that it's sufficient
>  that you can /imagine/ that there might be other ways for
>  this to be an important distinction - a separtion of concerns
>  that we need to deal with.

Yup.

>  > You might, for example have an IterativeTest that
>  > computes code coverage on the fly, and continues to generate
>  > a valid Next() in the IEnumerable with new semi-random data
>  > values until all or most of the code was covered.
>
>  Yes.

This is the new point that I think I "got" today.

>  > That would be kind of interesting. You couldn't do that with
>  > the current IterativeTest because the list is generated
>  > apriori...
>
>  Which is what I've been griping about.

Ok, I am on the same page on this point now. Sorry for being so dense. :-)

>  > so that would require a different kind of
>  > IterativeTest that recomputed Next after each test was run.
>  > Nevertheless, I think all of Theory is covered if you can
>  > produce the right set of values to pass into parameterized tests.
>
>  Whoops. There you go again. Sounds like you're saying that
>  IterativeTest == Theory. I'm hoping what you mean to say is
>  that "all of a particular theory" is covered by the data.

It's one way of driving a Theory. It's not the only way. See the
posting on NUnit 3 list.

>  To put a finer point on my point... IF you are saying
>  that IterativeTest is /sufficient/ to produce an implementation
>  of Theories, I am in complete agreement. That's just not
>  an interesting statement to me. I'd like to know what
>  other sorts of techniques might be /useful/ in that
>  implementation.

I don't think IterativeTest is even sufficient to do all of the
interesting things you might want to do. It's just one way of coming
up with data to test out your Theory.

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