Le 3 mars 04, à 19:21, Markus Gaelli a écrit :

> Hi Romain,
>
>> The avantage of this method is that you see the presence (or absence) 
>> of tests
>> "right now", without even clicking ... (and it was easier to do, too 
>> ;-) ).
>> But having some tabs in the browser could be neat to ... IIRC 
>> visualwork's browser
>> has for example tabs such as "code critic", etc ... So integrating 
>> Ken's recent tab work
>> in the Browser might be a good solution, but it might be quite 
>> difficult considering
>> the size and complexity of the existing code in the Browser...
> I prefer to see some specific method a bit larger than two methods, 
> especially if they are then displayed incompletely.
> But maybe I am biased, as I am working in VW also from time to time...

The main point is to know easily that a method is tested, so using 
colors,
it's doable too. The trouble is then to add tabs to the browser ...

>>
>>> And it is a bit slow I think. But on the other hand I can also 
>>> understand that you do not want to cache...
>>>
>>
>> It's mainly because it is work in progress, too (I wanted to see if 
>> people were interested
>> before going too far). On the other hand I use PackageInfo stuff 
>> which is not cached either
>> (using PackageInfo>>methods is a bit slow), and as I heard that Avi 
>> has projects to
>> add state to PackageInfo, maybe this could become faster without me 
>> doing anything ;-).
>> I am also continually building PluggableTextMorphs, so that doesn't 
>> help either.
> Sure. Postpone the performance enhancements to the very end.
> And also, if something is good and new, it is probably slow... ;-)

You have an example in mind ? ;-)

>> But I see that it can be useful to test certain
>> complex behaviors. I think they are some kind of "macro" tests, and 
>> that we shall
>> take into account that there are at least two degrees of tests.
> Exactly. My current taxonomy of squeak unit tests:
>
> Each Squeak unit test can be seen either as
>
> - a method example
> 	- either identifiable as only one message of the package-under-test 
> is sent directly
> 		+ all assertions happen after this sent. One could use BrowseUnit to 
> identify them.
> 		Example see: AnalyzerTest >> testExternalReferenceOf
> 	- or at least two messages of the package under test sent, probably 
> it is the last of them
> 		+ all assertions happen after this send. Do not know how to identify 
> automatically.
> 		Example see: BrowseUnitTest>>testMethodTesters
> - or a combinations of method examples
> 	- sibling method examples
> 		Same method is tested in different scenarios
> 		+ assertions are scattered.
> 	  	Example see: BCCMTest >> test01metaclassName
> 	- cascaded method examples
> 		Different levels of a scenario are built and tested + assertions are 
> scattered
> 		Example see: Base64MimeConverterTest >> testMimeEncodeDecode
> 	- independent method examples
> 		Example see: BCCMTest >> test08BCCMhierarchy
> 	- other, yet to be named ones...
> (snip)

So there's quite different ways to exploit those things ...
Considering the slowness of your stuff (and mine's :-)), I thought that 
by
using SystemChangeNotification and caching that could become acceptable.

>> IIRC you mentionned the type thingie a while ago, thinking you could 
>> integrate it
>> in BrowseUnit. Do you have a piece of code doing it, so I could 
>> integrate it ?
> I will have a look on this.
>> it sure seems interesting. Concerning the composition of unit tests, 
>> could
>> you come up with an example (you seem to like them anyways ;-) )?
> See the MIME example above

In your example you decomposed a unit test, but do you think you can 
compose
them ? what would that be useful for ?

	Romain