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...
>
>> 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... ;-)
>
>> Concerning the relationship between unit tests and methods under 
>> tests: I would be very interested to
>> count the numbers of unit tests, which really test several methods at 
>> the same time. Meaning the ones
>> with different kind of assertions sparkled in between different 
>> methods sent.
>>
>> I do not think, that there are many - that is why I personally like 
>> to see unit tests more as 'method examples'.
>
> Yes, that would be an interesting thing to know. I know that for 
> example
> in the example you provide (BrowseUnitTest>>testMethodTesters), the
> class:selector: method identified as a tested method is just the 
> class-side
> initializer, and that a way to filter it out would be desirable. I 
> tried
> your code, and I agreed with your pros and  cons :
> it sure is slow ;-) .
>
> I couldn't come with a real exemple of a test testing several "real" 
> methods,
> so I don't know if they are common.
One nice example is Marcus Denkers test:

Base64MimeConverterTest >> testMimeEncodeDecode

	| encoded |

	encoded _ Base64MimeConverter mimeEncode: message.
	
	self should: [encoded contents = 'SGkgVGhlcmUh'].
     	 self should: [(Base64MimeConverter mimeDecodeToChars: encoded)
                       contents = message contents]

This one clearly tests both mimeEncode: and mimeDecodeToChars: in one 
test.
One nice aspect of method examples is, that you could decompose this 
test into two
method examples, actually by 2 refactorings: "extract method" (this one 
gives the
result automatically) and one "extract to result"

You end up with:
=======
testMimeEncode
	"self debug: #testMimeEncode"
	
	| encoded |

	encoded _ Base64MimeConverter mimeEncode: message.
	
	self should: [encoded contents = 'SGkgVGhlcmUh'].
	^encoded
and

testMimeDecode
	"self debug: #testMimeDecode"
	
	| decoded |

	decoded:= Base64MimeConverter mimeDecodeToChars: self testMimeEncode.
	self should: [decoded contents = message contents].
	^decoded
========

I don't know if you always want to decompose this kinds of tests into 
two, but I sure like that you could.
One of the main selling points of XUnit is, that it does not tell the 
tester at all how to write the tests,
but one of the main selling points of the Software Composition Group 
is, that you could compose and decompose things. ;-)

> 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)
> 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
>>
(snip)
>>  What do you think?
> as I said earlier, it works, and I agree with your points.
> Using these small tests could have the benefit of both testing the 
> methods
> and maybe provide some useful type feedback as you said, all in one.
> This sure seems interesting :-).
:-)
>
>> Another construction site which might be useful in the context of 
>> BrowseUnit is a coverage browser
>> "MethodsAsObjectsWrapper" using the fast MethodsAsObjects from 
>> Andreas.
>>
>> See http://kilana.unibe.ch:8888/@KKfWFsWqtFIwHOCc/DPiGCPTN
>>
>
> I have to look at that too, but I am actually behind a proxy which 
> prevents me
> from accessing web sites on ports number other than 80.
> (the sysadmin tells me that these could be evil sites run by non-root 
> users ...
> but what about evil root users then ? :-))
>
I'll send you that one privately.

Cheers,

Markus