[ANN] BrowseUnit v4 preview: feedback needed

Markus Gaelli gaelli at emergent.de
Fri Mar 5 11:48:16 UTC 2004


Hi Romain,

>>
>> So if you had a method example for creating a SMSqueakMap,
>> and one building on this for adding an account object, (and whatever 
>> is missing ... ;-)
>> you could easily write the test / method example
>> for the SMSqueakMap >> accountWithName: aName.
>>
>> Right?
>>
>
> I see what you mean,
not sure... ;-)
> but I think you can do that with setUp and tearDown
> methods, too ... but of course these methods are not categorised as 
> test selectors,
> and so are not usable for now in my tool.

Usually you don't put assertions in the setUp. So the subcomponents you 
build like that are not tested.
At least as long as you don't have abstract per- and postconditions in 
your real methods.

So I give you a better example: Assume you want to test SMSqueakMap >> 
accountsByInitials
This involves a Map with some accounts in it. So you first we test the 
creation of an account.
A suggested method example for that could look like:

	SMAccountTest >> testNewMrFoo
		|anAccount|
		anAccount:= SMAccount new signature: 'Mr. Foo'; email: 
'user at foo.bar'; initialis: 'mf'.
		self deny: anAccount isAdmin.
		self assert: anAccount advogatoId isEmpty.
		^anAccount

Now you could test SMSqueakMap >> addObject: with the following method 
example:

	SMSqueakMapTest >> testAddAccounts
		|aMap|
		aMap:= SMSqueakMapTest new testCreateMap.
		aMap
			addObject: SMAccountTest new testNewMrFoo;
			addObject: SMAccountTest new testNewMrBar.
		...someAssertions...
		^aMap

And finally
	SMSqueakMapTest >> testAccountsByInitials
		|aMap someSortedAccounts|
		aMap := SMSqueakMapTest new testAddAccounts.
		someSortedAccounts:= aMap accountsByInitials.
		self assert: (someSortedAccounts first initials = 'mb').
		self assert: (someSortedAccounts last initials = 'mf').
		^someSortedAccounts

Certainly the more assertions you can make abstract and move in the 
code,
the more stable this tests get when they are changing.
So this method examples do not have to include any assertions at all
iff their methods under test have them.

Thanks for listening and helping me to phrase what I'd like to see... 
;-)
And please shoot! Critics are very welcome.

Cheers,

Markus




More information about the Squeak-dev mailing list