[ANN] BrowseUnit v4 preview: feedback needed

Romain Robbes rrobbes at info.unicaen.fr
Wed Mar 3 10:11:58 UTC 2004


Le 2 mars 04, à 18:26, Markus Gaelli a écrit :

> 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"... ;-)

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...

> 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.

> 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. 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.


>
> 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

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 ?
it sure seems interesting. Concerning the composition of unit tests, 
could
you come up with an example (you seem to like them anyways ;-) )?

> Please find attached a "not really ready for prime time but what the 
> hack" spike solution thingie, with which you can,

[snip]
> 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?
>

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 :-).


> 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 -

Yes, why not...


> 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 ? :-))

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

Uh oh, I'm afraid I'm not short either ;-).

Cheers,
	Romain




More information about the Squeak-dev mailing list