Hi Lukas,

Am 2008-05-23 um 16:53 schrieb Lukas Renggli:

> Hi Tobias,
>
>>  That was one of our most important goals. Within SwaLint, one is  
>> able
>>  to use results from other test (and plug-ins, as well) to  
>> generate one's
>>  own results.
>
> I don't think I understand. Can you give an example where tests depend
> on each other?

This is true for all Disharmony category plug-ins.

E. g., see
 >>
SLDisharmonyPlugIn>>godClass: aSLClassTestObject

	aSLClassTestObject shouldBeClass.
	^ self successResult:
		(((aSLClassTestObject resultOf: #accessToForeignData) > #few) &
			((aSLClassTestObject resultOf: #weightedMethodCount) >= #veryHigh) &
			((aSLClassTestObject resultOf: #tightClassCohesion) <= (1/3)))
<<

where #few and #veryHigh correspond to thresholds and
#accesToForeignData, #weightesMethodCount and #tightClassCohesion
  are the symbols of tests offered by the SLClassMetricsPlugIn.
   Note that resultOf: triggers lazy evaluation, i. e. if the results  
of this tests
are already available, they are returned. Otherwise, they are computed,
cached, and then returned.

>
>> At the moment, we provide Boolean, Integer, Percentage, and
>> Uniformity results. These results may have thresholds, so you can  
>> 'ask', e.
>> g. whether the ATFD (access to foreign data, a class metric) for  
>> the class
>> your test is currently processing is greater than 'high'.
>
> But a metric is not a test in itself, right? A test consists of
> metrics and thresholds.

It depends. It is possible to assign any kind of threshold to any
kind of result. We provide some default ones. E. g. the SLNumericResult
provides the low, average, high, and  veryHigh “threshold family”  as  
well
as these ones, which we named “fewMany” threshold:
	none one two three few several many tooMany.
Most of them are computed on an “average and standard deviation”
approach. There values, in turn, can be saved to the preferences.

This is actually independent of whether a test makes use of metrics  
or not.
On the other hand, the metrics cannot as easily be used as we like to  
use
them when no thresholds are in place.

So, to clarify your statement: No, a does not need to consists of  
metrics and
thresholds. Moreover, a test simply should return a result (as a  
descendant
of SLResult) based on its input subject.

>
>>    One example would be the UI.
>
> OBRefactory has a nice UI.
>
> http://www.lukas-renggli.ch/blog/ob-rb-3

There are some nice parts in there. Actually, what I thought of was the
SmallLint’s UI, not an OmniBorwser tool. Besides, correct me if I’m  
wrong,
but this tool was not available last October, was it?

>>    We encountered a problem concerning several SmallLint rules.  
>> These rules
>> simply
>>  failed in the sense of that a debugger popped up.  Sadly, all  
>> other test
>> results were gone
>>  then.
>
> I fixed that in the latest version of the refactoring browser.

Thats nice. We’ll check that in order to update our default  
preferences to
enable them by default.

>
>>> How do you do the scoping?
>>
>>  What do you mean by scoping?
>
> SmallLint has sophisticated scoping tools. You can run in on the
> image, on a package, on a class, on a class hierarchy, etc.

We use a notion of Test Objects (descendants of SLTestObject).
It is a tree-based approach of nested test objects. Currently, we  
support
test objects ranging from systems (i. e., multiple categories, e. g.  
a package)
to methods an variables.
    If you know about another more fine or coarse abstraction, feel  
free to add
them to the SLTestObject hierachy

So long,
	-Tobias
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: Signierter Teil der Nachricht
Url : http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20080523/743bef52/PGP.pgp