[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