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
|