Mark Needham

Thoughts on Software Development

Coding Dojo #16: Reading SUnit code

with 2 comments

Continuing on from last week’s look at Smalltalk, in our latest coding dojo we spent some time investigating the SUnit testing framework, how we would use it to write some tests and looking at how it actually works.

The Format

We had 3 people for the dojo this week and the majority was spent looking at the code on a big screen and trying to understand between us what was going on. We only had the dojo for about 90 minutes this week. Normally we go for around 3 hours.

What We Learnt

  • An interesting thing which I noticed during this session was the idea of protocols which are used to organise a set of methods that a class’ instance respond to. I think these are intended more for humans than for the computer which I think is a really cool idea – I am strongly of the belief that programming languages provide a mechanism for communicating our intent with ourselves and with the other people on our team.
  • As a result of looking at the description of the ‘initialize-release’ protocol for Object I became intrigued about the way that objects are removed by the garbage collection. We weren’t able to find out exactly how Visual Works does garbage collection but I learnt a little bit about the way that garbage collection works in general using three different approaches – mark and sweep, copying collector and reference count.
  • Another thing which I found interesting was the way that Smalltalk handles exceptions – we came across this when looking at how XUnit handles passing and failing test cases. Since Smalltalk only has messages and objects there is no explicit of an exception so as I understand it objects have the ability to respond to an error signal being sent to them.

    (TestResult runCase:aTestCase)

    	| testCasePassed |
    	testCasePassed := [[aTestCase runCase.
    		sunitOn: self class failure
    			[:signal | 
    			self failures add: aTestCase.
    			signal sunitExitWith: false]]
    		sunitOn: self class error
    			[:signal | 
    			self errors add: aTestCase.
    			signal sunitExitWith: false].
    	testCasePassed ifTrue: [self passed add: aTestCase]

    The above is the code block we spent a bit of time looking at which I think in C# world would look a bit like this:


    It seems easier to understand to me having exceptions as a language construct but I haven’t done much Smalltalk so maybe that’s just a preference for what’s familiar.

  • It took us a bit of Googling to work out how to start the SUnit TestRunner in VisualWorks but the way to do it eventually turned out to be quite simple. Typing the following code into the workspace window does it:
    TestRunner open

For next time

  • If we continue in Smalltalk world for another week then we’ll probably play around with SUnit a bit more and perhaps get onto seaside. If not then we’ll be back to the Java modeling I imagine.
Be Sociable, Share!

Written by Mark Needham

May 29th, 2009 at 9:23 am

Posted in Coding Dojo

Tagged with , ,

  • DCam

    The FailureException catch block is actually nested inside the ErrorException catch block. It’s because of the “]]” on the first sunitExitWith: false line.

    From a SmallTalk point of view, the first sunitOn: message is sent to the [aTestCase runCase. true] block, and the second sunitOn: message is sent to the block which includes the first sunitOn: call. I wish VisualWorks would have laid it out to make that obvious, but I don’t think it paid attention to the []s.

    I am making any sense?

  • I think I follow the explanation of how it would work in Smalltalk although I’ve forgotten exactly how it would read if we did a C# comparison.

    Which call would the FailureException be catching an exception of?