[ANN] BrowseUnit v4 preview: feedback needed
Markus Gaelli
gaelli at emergent.de
Fri Mar 5 17:22:48 UTC 2004
Hi Colin,
> I'm not really sure why,
so there is hope ;-)
> but I have a vague feeling that composing tests isn't a good idea. Why
> do you want to make the same assertions over and over? Once per run is
> enough, no?
If you have composed method examples/tests, you could enhance
BrowseUnit/XUnit to only run the necessary high level tests, so that
all included tests are checked along the way and are not executed stand
alone.
Thus you
- reduce testing time
- get your assertions failing -> find your bugs in the most specific
context
- improve our design: we might think about providing methods in you
real program which we can exemplify to get some nice objects:
- To stick to the SM example, I would say that we are missing some
dedicated instance creators of SMAccount,
like SMAccount class >> signature: email: initials:
I admit that my testNew was a kind of hack :-)
- might thus get rid of some test artifacts / helper methods (not sure
about this one)
How could this be done? Say we somehow tag the unit tests which are
method examples. Then we should be able to detect their call graphs.
And then only call the necessary ones to cover the whole graph.
On the other hand your cache idea blends well with method examples:
I don't know yet when you want to flush the cache, but you surely could
imagine method examples like
SMAccountTest >> testSignatureEmailInitialsMrFoo
mrFoo notNil ifTrue: [^mrFoo].
mrFoo:= SMAccount signature: 'Mr. Foo' email: 'foo at bar.org' initials:
'mf'.
...someAssertions...
^mrFoo
If you did method examples like that, you even would not need to sort
them first. Cool.
Don't know about mean side effects though, which could make them
invalid.
The usual fun with caches...
Thanks a lot for your comments, and
Cheers,
Markus
>
> I tend to want to factor "set up" type things into #setUp,
> TestResources, or helper methods in the test. So here's your SM
> example:
>
> SMAccountResource>>setUp
> foo := SMAccount new signature: 'Mr. Foo'; email: 'foo at user.com';
> initialis: 'mf'.
> bar := SMAccount new signature: 'Mr. Bar'; email: 'bar at user.com';
> initialis: 'mb'.
>
> SMAccountResource>>fo o
> ^ foo
>
> SMAccountResource>>bar
> ^ bar
>
>
> SMAccountTest>>testAdmin
> self deny: SMAccountResource current foo isAdmin.
>
> SMAccountTest>>testAdvogatoId
> self assert: SMAccountResource current foo advogatoId isEmpty
>
>
> SMSqueakMapTest>>setUp
> map := self createMap.
>
> SMSqueakMapTest>>addAccounts
> map
> addObject: SMAccountResource current foo.
> addObject: SMAccountResource current bar.
>
> SMSqueakMapTest>>testAddAccounts
> self addAccounts
> "do some assertions"
>
> SMSqueakMapTest>>testAccountsByInitials
> self addAccounts.
> sortedAccounts := map accountsByInitials.
> self assert: (sortedAccounts first initials = 'mb')
> self assert: (sortedAccounts last initials = 'mf')
More information about the Squeak-dev
mailing list
|