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
|