Re: Roadmap Updated

Hi Kelly, 

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

Sure, just like you need to create TestSuites and TestMethods
using the info on the types and methods. RowTest is created
exactly the same way - the data itself is contained in the
metadata of the assembly.
 
> >  > 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?

It's not "proposed" just something I made up. But it's a very simple
way to express the equivalent of RowTest and I might implement it.
 
> >  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.

No, my point is that it is new. Unlike BDD. :-)

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

Could be. :-)
 
> 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. :-)

I was sure you didn't.

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

It's just a question of finding the words.

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

Okay. I'll look forward to the next post.

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/