SUnit: Skipping tests?

Colin Putney cputney at wiresong.ca
Tue Mar 28 12:23:04 UTC 2006


On Mar 28, 2006, at 4:04 AM, Bert Freudenberg wrote:

> Just a general remark - there are other folks thinking about  
> refreshing SUnit, like Travis:
>
> 	http://www.cincomsmalltalk.com/userblogs/travis/blogView? 
> showComments=true&entry=3277650953
>
> Also, there seems to be a VW package called SUnitToo but I couldn't  
> find much info about it.


I've played with SUnitToo a bit. It's pretty cool. Travis doesn't try  
to make SUnit more like JUnit, but rather strips out the cross- 
Smalltalk compatibility layer of SUnit and re-implements it to take  
best advantage of modern VisualWorks. For me the interesting things  
were:

- Factored out the class/selector related stuff into separate class,  
test token. This is really handy if you've got a large suite, since  
it means the test runner doesn't have to keep the test case instances  
around just to keep track of what tests were run. That can save a lot  
of memory. (The work-around for memory issues in SUnit is to nil out  
all your ivars in #tearDown, but that's a real pain to do over and  
over again, and points to a flaw in the framework.)

- Instead of just producing a set of TestResults, suites broadcast  
the results via #triggerEvent:. Very handy for implementing UI,  
logging etc.

- Tests are always run in randomized order. Not sure I like this one.  
The intent is great - to help expose cross-test dependencies - but I  
find it makes *debugging* those cross-test dependencies really hard.  
What would be better is to randomize test order when a suite is  
created, then always run that suite in the same order. This would  
still let you detect cross-test interaction, but allow you to  
reproduce it reliably when it does crop up.

- General simplification. The first two points above allowed the  
implementation to get simpler, and SUnitToo has much less coupling  
between its classes.

For more detail, see:

http://www.cincomsmalltalk.com/userblogs/travis/blogView? 
showComments=true&entry=3278236086



More information about the Squeak-dev mailing list