Hi Romain,

thanks. I think it is a very good idea to exploit the connection 
between the tests and the packages and
not to rely on brittle naming conventions. I am not sure about the 
panes, I would prefer some tabs
or dropdowns. For me the space for the test method and for the methods 
under test is a bit small.
But maybe this takes some "training 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...

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'.
They really exemplify the usage of a certain method _and_ assure its 
quality. What they are missing right now,
is to return the possibly changed receiver, parameters and return 
values of their methods under test.

They should return at least the result of their method under test. 
Because then you could

- _compose_ unit tests
- identify their method under test
- use them to annotate types for the method under test

Please find attached a "not really ready for prime time but what the 
hack" spike solution thingie, with which you can,
(if you have the refactoring browser installed)
- refactor unit tests to identify their method under test.
  (If there is only one candidate using your solution, this could
be automated or maybe even unnecessary)
- then ask the test, on which method it focuses on.

It also includes some refactored unit tests of the squeak base system.
---
As an example you first open the tweaked RBBrowser via
ExtractToResultRefactoringBrowser openBrowser (yeah its a hack...!)

you can then go to your test

BrowseUnitTest >> testMethodTesters
	| m |
	m := MethodReference class: MethodReference selector: #testers.
	self assert: (m testers anySatisfy: [:mref | mref methodSymbol = 
#testMethodTesters]) .

BrowseUnit itself gives two candidates of methods under test:
- MethodReference class >> class: c selector: m
- MethodReference >> testers

In this case I would really say, that the focus of this test is on the 
last method #testers,
as you also indicated by naming the test testMethodTesters.

So you could select the "m testers" part, then menu: 
RB-selection->extract to result
With this little trick, now you know exactly which method was tested 
here. Your test now looks like:

testMethodTesters
	| m aResult |
	m := MethodReference class: MethodReference selector: #testers.
	aResult := m testers.
	self assert: (aResult anySatisfy: [:mref | mref methodSymbol = 
#testMethodTesters]).
	^aResult

The exploitation of this is not built into the UI, but you can ask now:
(BrowseUnitTest selector:  #testMethodTesters) methodReferenceUnderTest
Which is also not fast right now, as it does some running and parsing.

Current problems:
- needs RB
- bad integration in the RB
- slow
- no GUI
- can only compose tests which test methods where the return value is 
interesting
(the test should deliver the whole enchilada (receiver, parameters, 
result)
in a kind of "MethodUnderTestResult class"
Pros:
- think it is a nice idea ;-)
- I think it fits well together well with BrowseUnit

  What do you think?

We could then go and mark/paint the methods in dark green,
which have dedicated unit tests, the ones which are called only or are 
undecided in
some green/yellow, the ones which are called somewhere deep during the 
test in yellow and all the rest in red -
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

Sorry for this long mail, did not have the time to write it shorter ;-) 
and - of course -

Cheers

Markus

-------------- next part --------------
A non-text attachment was scrubbed...
Name: Eg-TestExperiments-mga.5.mcz
Type: application/octet-stream
Size: 8285 bytes
Desc: not available
Url : http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20040302/7d39cb83/Eg-TestExperiments-mga.5.obj
-------------- next part --------------


Am Dienstag, 02.03.04 um 15:47 Uhr schrieb Romain Robbes:

> Hi folks,
>
> As I am doing quite some radicals changes on the next version of 
> browseunit,
> and as I know some people are using it, I'd like to have their 
> feedback on this
> prototype for the next version.
>
> For this version I wanted BrowseUnit to be more package-focused than
> class-focused. So now you can for example run your tests for an entire 
> package,
> and run slint for an entire package too (except of course that the RB 
> seems to be broken
> in 3.7 ...).
>
> Also the scheme for searching links between tests and tested methods is
> now different, relying not on the name of the methods, but rather on 
> the
> messages sent by it. This is so more robust and fits better in the 
> package-orientation
> I want to give.
>
> The downside of this is that now the tests are harder to generate, so 
> I mainly would like
> to know if the added functionality counterbalances this. The preferred 
> way to write your
> code is now "test-first", so XP folks will be happy (especially since 
> the
> debugger-stub method creation is now in 3.7).
>
> I've added a little howto at the start of the app to help you see the 
> differences.
> Please note that I have joined two files :
>
> - Ned's recent SeparateClassCommentPane as I rely on it, having heavily
> "rape'n'pasted" some of it's code ;-). So file it in first in a recent 
> Squeak 3.7 image.
>
> - And of course my own code for you to test it ;-).
>
> Both files are gzipped changesets.
>
> Thanks in advance for your feedback, as I'd like to know if I should
> continue to work on this release.
>
> 	Romain
>
> <BrowseUnitv4.cs.gz> <SeparateClassCommentPane-nk.cs.gz>