Hi Markus,

on Mon, 14 Aug 2006 12:12:07 +0200, you wrote:
> On Aug 14, 2006, at 11:13 AM, Klaus D. Witzel wrote:
> On Mon, 14 Aug 2006 10:55:29 +0200, Marcus Denker <denker at iam.unibe.ch>
>> wrote:
>>> And have a look at BehaviorTest>>#testChange
>>
>> This test is a *very* good one, 100% pure[tm] object-oriented :)
>
> I disagree.

I don't.

> Whereas the _tested_ stuff is great, we don't know what kind of test it  
> is, without reading it.

Why would reading a test method make it any better or worther? Perhaps you  
meant something like "understand it". That would be a quality that we  
cannot enforce on the software developer.

> Also - we would not find it easily as an example for instance specific  
> behavior.

I didn't claim that. But, because of what?

> Certainly this is the way SUnit tests are supposed to look like, but who  
> says, that SUnit is the best way (pure[tm] object-oriented) of testing?

Agreed. But also: who says that it doesn't?

> I'd categorize this test as a "method test" focusing on
> 	Behavior >> compile: aString

I'd have to agree if it wouldn't use #subclass: and  
#primitiveChangeClassTo:; if you remove these two we'd be in sync with  
"focus is on compile: aString testing".

> (See our Unit Test Taxonomy Paper below)

Thanks for the pointer.

> I found it more object-oriented, if the test would be explicit about  
> what it is showing and looked like:
> ===============
> Behavior class (examples) >> exampleCompileThisIsATest
> 	"I return a sample behavior of thisIsATest ^2
> 	So I do not only exemplify an instance of this class, but also of  
> compile: aString
> 	(As there is no annotation a la self test:[], an extended OmniBrowser  
> could assume that it is the last method called, which is exemplified.)
> 	Browse for _real senders_ of me, to see me in context"
>
> 	|aBehavior|
> 	aBehavior := self new.
> 	aBehavior compile: 'thisIsATest  ^ 2'.
> 	^aBehavior

Hhm[0.5*OT]: I'm not a friend of sequences of St code which begin with "  
:= self new; more: "; as soon as "self new" is over you're most likely on  
the wrong side (reuseability, extensibility, overridability).

> Model class (examples) >> examplePlugInstanceBehavior
> 	|aModel|
> 	aModel := self new.
> 	self precondition: [self should: [aModel thisIsATest] raise:  
> MessageNotUnderstood].
> 	aBehavior := Behavior exampleCompileThisIsATest.
> 	aBehavior superclass: self.
> 	aBehavior setFormat: self format.
> 	aModel primitiveChangeClassTo: aBehavior new.
> 	self assert: model thisIsATest = 2.
> 	^aModel
> ===============
> I think this way
> - is more object oriented and you could browse the class side of  
> Behavior to see how its instances can be applied

Hhm[0.5*OT], depends. How many "browse this and that" will we tolerate  
until we'd agree on "this one is an easy to understand test or method or  
whatsoever". Seriously, what number do you suggest?

> - you could reuse this instance specific behavior in more tests

Reuse, yes! (I understand you meant potentially reused). But we should not  
discuss that "this and that has potential for being reused" unless there  
are already ~= 1 users (proof of concept exists, at least).

> - shows, that we might miss a single method to plug this instance  
> specific behavior as
> 	aBehavior superclass: self.
> 	aBehavior setFormat: self format.
> 	aModel primitiveChangeClassTo: aBehavior new.
>   is a bit verbose and could be subsumed into a single

Hhm, matter of taste here? I prefer verbose tests, unless there is an  
already implemented method which I can reuse (which is not the case here,  
I mean #superclass: - #setFormat: - #primitiveChangeClassTo:).

"You shall not write *new* methods just in support of tests, they are  
superflous and do by no means reflect the testee's situation." Now how  
about this?

  "Object >>
> changeClassTo: aBehavior" method. Thus the latter example would  
> exemplify this method.

Sure, no problem with your approach.

> Thanks for this nice example, I think I can reuse it for academic  
> purposes... ;-)

You are welcome :)

/Klaus

> Cheers,
>
> Markus