Re: Fwd: Assume

Hi Kelly,

> Dang old reply-to field anyway...

FWIW, I deal with it using Outlook by removing the Reply button and
only leaving Reply to All.
 
> I envision the exception being eaten by NUnit, and not being 
> passed back up through the GUI or to the user... there might 
> be a case to be made here, but I think silently succeeding 
> fits best with the theory of Theories. :-)

I think that's what I said. But... 

> > My problem is that the meaning of the Syntax is not what a normal 
> > human (at least I) thinks it should mean. Taken alone, 
> Assume seems to 
> > say either "you don't have to check for this"
> > or "it's an error if you get a zero value".
> 
> The word comes from the Theory paper.

Which is why it makes sense to me only in the context of a Theory

> If you can think of a 
> different word, like maybe Precondition.That(...) that works 
> better, I'm ok with that. I don't like that Assert and Assume 
> start with the same three letters from an intellisense point 
> of view anyway.
> 
> > Taken as a part of the statement of a Theory, it can have a 
> different 
> > meaning, which makes sense in that context. It's a subtle 
> distinction, 
> > but a real one I think.
> 
> The BDD folk have made a lot out of a pretty subtle thing, so 
> paying attention to the words used is clearly very important 
> to some people.

Clearly a bad example for me, but I take your point.

> > I do (and did) understand how this would be a useful 
> feature but would 
> > rather not be driven by expediency. Why not use some other 
> verb than 
> > Assume, saving it for use in the context of Theories? 
> Alternatively, 
> > why are you generating random data that includes invalid values. :-)
> 
> Because it's easier to generate random values without 
> thinking about what might be legal in a particular context. 
> That is, you can more easily generate random values in a 
> general way if you don't have to worry about the specifics of 
> a particular test... I'm usually a generalizer, so I tend to 
> pay attention to such issues earlier on that maybe I should, 
> YAGNI and all...

Generalizing in the implementation (for example, using the 
same underlying builder, fixture and test case) makes a
lot of sense.

Generalizing in the user interface can also make sense in
some situations - but it's usually not a one-to-one mapping
with the implementation. In this situation, the naming of
classes and methods an the way we mark tests with attributes
constitutes a user interface. If we use the same naming
for things the user considers different that's a bad
use of generalization.

There can be a situation where we want to influence users
to think about things in a different way, which is probably
the case with Theories. In such a situation, we might force
some sort of generalization that the typical user is not
initially comfortable with - coupled with writing a lot
of articles,etc. Using Assume with Iterative test doesn't
seem to me to fall in that category, however.

It would be nice to hear some other opinions on this matter,
rather than just yours and mine, wouldn't it? Folks?

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/