[ANN] BrowseUnit v4 preview: feedback needed
Markus Gaelli
gaelli at emergent.de
Tue Mar 2 17:26:44 UTC 2004
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>
More information about the Squeak-dev
mailing list
|