SUnit vs. examples and all that Jazz

Markus Gaelli gaelli at emergent.de
Tue Aug 15 09:24:25 UTC 2006


On Aug 15, 2006, at 10:37 AM, Klaus D. Witzel wrote:

> On Mon, 14 Aug 2006 17:47:52 +0200, Markus Gaelli wrote:
>> Hi Klaus,
>> On Aug 14, 2006, at 1:54 PM, Klaus D. Witzel wrote:
> ...
>> Yes. It is about understanding.
>> And I claim, that for understanding an entity you need to be able  
>> to read it in its context.
>
> This is not reality (we talk about software and its code, don't  
> we?). Neither can you force the software developer to read  
> something nor can you force any person to understand something. s/ 
> you/I/ and set I := Markus, I'd agree.
>
>> SUnit just does not give me context of the tested methods and  
>> classes. So I need to read it. With SUnit I need to know the "how"  
>> _before_ I could understand the _what_. This is not so good OO  
>> i.m.h.o.
>
> Yes, something better is needed. How about little stories on the  
> whatabouts, perhaps animated. Good example:
> - http://connect.larc.nasa.gov/squeak.html
>
>> I claim that the value of examples are underestimated in OO  
>> programming.
>> Think of a language dictionary like Websters, where you can  
>> understand each word, by reading it in an exemplified use. We all  
>> learn by example.
>
> You all minus: #Klaus (perhaps). I only learn when I'm able to do  
> it by myself or, when I have to explain it to another person (one  
> subsumes the other). Besides of that, I can only store information.

"Example isn't another way to teach. It is the only way to teach." -  
A. Einstein

Sure, creating the example yourself is more helpful than reading it  
from someone else.
But while I am redoing it or explaining it, I need it as concrete as  
possible. Maybe there are different types of personalities but think  
for example types: having the concrete types of classes and methods  
seems to be wanted in many cases - a no brainer if you had examples  
for them.

>
>>>> Also - we would not find it easily as an example for instance  
>>>> specific behavior.
>>>
>>> I didn't claim that. But, because of what?
>>
>> Damien asked about a paper about instance specific _behavior_.
>> Marcus understood that...
>
> I'm sorry this was not the question. See how hard communication is?  
> I asked for the *cause* (like in: because) for your "would not find  
> it easily as an example for instance specific behavior". My quesion  
> was not about the people you mentioned.

? I thought I gave an example of a not well understood concept  
(Behavior) where it would not be necessary of anybody to send an  
according test - as it is glass-clear where to find it. (Behavior  
(category examples))

>
>>>> 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".
>>
>> Aehm, here I was fuzzy and should have said that it is actually  
>> exemplifying two things, at least for me:
>>
>> - How to create a behavior
>> - How to plug it in
>> Interesting that you would also add the subclassing aspect, this  
>> would be a technical detail for me (boldly spoken, of course...  
>> too much traits stuff going around in our group I guess... ;-) )
>
> Unless you're a friend of "nil subclass: #MyOwnRoot", in St you're  
> always subclassing, aren't you? So this cannot be not a technical  
> detail. It's like breathing.

So traits are like...??? ;-)

>
>>>> 	|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).
>>
>> Don't think so for above example. Treat examples as factories -  
>> actually you can find a lot of examples of examples ;-) following  
>> this factory aspect in Squeak. They are all commands - thus  
>> directly executable, which is nice. Why adding another level of  
>> indirection here?
>
> (...)
> Perhaps I'm too rigid with "... self new ... more: ..". Will think  
> it over.
>
>> Having the mantra of "an example for each concept"  in mind also  
>> helps us in coming up with better designs -  we are already  
>> starting to discuss if subclassing is a concept necessary for  
>> plugging in behavior or if is is mere implementation issue - this  
>> discussion is good (though I don't have the time to pursue it...)
>
> This would be interesting to find out. There are perhaps pattern  
> when subclassing is necessary and when that's not the case? Keep me  
> up to date, if possible, please.
>
> ...
>>>> ===============
>>>> 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?
>>
>> I'd say try to exemplify the main concepts your architecture is  
>> relying on - think API's. This should lead to a very high  test  
>> coverage and better understanding.
>
> Have criteria for "better understanding" at hand? This is too  
> subjective, IMO. "interviewer: did you understand this concept?  
> candidate: yes!".
>
> Whether or not something is understood can only be found out if  
> candidate is using "it" after getting to known "it". This is where  
> "to understand something" begins, here where I am.

I am absolutely with you that for understanding doing is better than  
reading! But I am also saying that reading is easier and I might only  
need to read the headlines, if the headlines are linked in a  right  
context.

>
>> To emphasize this claim even more, I'd say that in the end your  
>> acceptance tests / (checked examples of API's) reflecting the  
>> typical outside usage your system are enough.
>
> Sure.
>
>> Of course we are all programmers, so we are using this low-level  
>> Squeak stuff, and for doing so we need to understand it. So our  
>> acceptance tests / examples should exists also for low level stuff.
>
> I have never made any distinction between low and other level in  
> software systems, only between provider and user of an interface.  
> Is that what you mean?

Yes.

>
>>>
>>>> - 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).
>>
>> One advantage of viewing tests as checked examples / factories is  
>> above explained documentation value:
>> People like Damien might look into Behavior (examples) category to  
>> find out what is already there...
>
> If you always keep test cases and other "test supporting" methods  
> in your image: yes. But that is an illusion.
>
>> An other advantage (reuse of this technique ;-) is the _possible_  
>> reuse of these instances in different contexts.
>
> Okay, tell me one example where a test method has been reused (not  
> [re]factored!), please.

Could tell you lots! See below.
>

>> Other arguments include cohesion of test and code, principle of  
>> last surprise (examples and tests are one of a kind (commands /  
>> factories), tests just come with some assertions), no parallel  
>> test hierarchy, ah, and no need for static typing your instance  
>> variables - the set of examples should include all possible  
>> concrete types these variables can take. (Same argument for method  
>> parameters btw.)
>
> Sure.
>
>>> 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:).
>>
>> I'd like to have a browser, where you could fold in and out code,  
>> so if you liked you could see above "exampleCompileThisIsATest"  
>> inlined (maybe even edit it there).
>
> + (1 big) perhaps Stefan's Christo can be a start here?

I'd love to see this in Squeak too. Browsers should be able to  
summarize software!

Another student here, Rafael Wampfler, is building a tool for VW  
where you can do this. His tool called 'Eg' is an implementation of  
the ideas I presented.
Maybe we can meet for beer here in Bern and discuss this with a  
concrete prototype.
I keep some of my answer here, but I really think that face to face  
would be better. :-)

>
>>> "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 >>
>>
>> no helper methods which are only used by other tests. But if these  
>> "helper methods" also exemplify the usage of other real methods -  
>> why not?
>
> Because I do not pay my employees (and freelancers) for inventing  
> test helper methods. It's Okay for (re)factoring test methods, but  
> that is where the story ends here.
>
> By nature of definition, all test methods are unique!
>
> Rule of thumb: the more you have (or like) to invest into test  
> methods, the less the subject (the testee) is understood.
>
>> Certainly I agree that methods doing some real work always should  
>> be factored into the real code.
>
> Ahh, my rule of thumb at work :)
>
>> As been suggested in our taxonomy paper Stefan Reichert uses the  
>> fifth pane in Christo to display tests right to the methods they  
>> are calling.
>> He has not (yet? ;-) introduced the idea of an exemplified method,  
>> rather all methods called in the test now can display this test as  
>> an example.
>>
>> Besides Stefan went a bit further in an other direction concerning  
>> this linkage of methods and tests, and also introduced a fifth  
>> pane the other way round: A test also displays all methods called  
>> by it to its right.
>
> Yes, I've seen that and Stefan did a tremendous job-very good work.

Indeed!

>
> /Klaus

Cheers,

Markus



More information about the Squeak-dev mailing list