Mark Needham

Thoughts on Software Development

Archive for the ‘smalltalk’ tag

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.
    	true]
    		sunitOn: self class failure
    		do:
    			[:signal | 
    			self failures add: aTestCase.
    			signal sunitExitWith: false]]
    		sunitOn: self class error
    		do:
    			[: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:

    try 
    {
    	aTestCase.runCase()
    }
    catch(FailureException) 
    {
    	this.Failures.Add(aTestCase);
    }
    catch(ErrorException)
    {
    	this.Errors.Add(aTestCase);
    }
    this.Passed.Add(aTestCase);

    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.

Written by Mark Needham

May 29th, 2009 at 9:23 am

Posted in Coding Dojo

Tagged with , ,

Coding Dojo #15: Smalltalk

with 4 comments

We decided to play around with Smalltalk a bit in our latest coding dojo.

A lot of the ideas that I value the most in terms of writing software effectively seem to have originally come from the Smalltalk community and a colleague of mine has been reading Kent Beck’s TDD by Example book and was really keen to try out the language to see where Kent’s original ideas came from.

The Format

We only had 2/3 people for the dojo this week so we all spent a bit of time at the keyboard getting familiar with the way things worked. We projected to a wide screen television so the other guys could track what was doing on.

What We Learnt

  • One interesting thing for me was that the Smalltalk syntax reminded me a little bit of Ruby. We spent a little bit of time with irb open as well as the Smalltalk environment and compared what the code would look like for a few simple expressions in the different languages. Ruby seemed a little bit easier to understand for some of the expressions but I guess it has probably been influenced syntax wise by Smalltalk.

    To give a simple example that we tried out, this is how you’d print the values 1-10 to the screen:

    In Smalltalk:

    1 to: 10 do: [:i | Transcript cr; show: (i printString)].

    In Ruby:

    (1..10).each { |i| puts i }
  • We were following a simple introduction to Squeak, an open source implementation of Smalltalk. We were actually using Visual Works/Cincom Smalltalk which seems to differ a little bit. For example there was no ‘asString’ method on integer when we tried to execute the following bit of code:
    Transcript show: (1 asString)

    It leads to the error:

    Unhandled exception: Message not understood: #asString

    Instead we needed to use ‘printString like this:

    Transcript show: (1 printString)

    I’m sure there are probably some other differences but we only tried a few examples at the dojo.

  • The idea of the development environment being the same as the environment where the code runs was quite strange for me but we saw some benefits of it even in the small amount of code we wrote. On making one of our many syntax errors the IDE popped up with a message asking whether we wanted to debug that piece of code on the fly. Pretty cool if we’d understood the stack trace that followed a bit better!
  • I haven’t looked into the type systems of other languages that closely but I was quite surprised that looking the type of the value ‘1’ was ‘SmallInteger’ – it was much more strongly typed than I had expected. The ability to delve into the code of objects within the environment is really cool and we came across quite a bit of code which intrigued us to want to learn more.
  • The intention for this session wasn’t actually to learn Smalltalk the language, as I don’t think dojos are great for doing that, but rather to try and understand the concepts behind all expressions being about sending a message to an object which for me is what object orientation is all about.

    Chatting with Dave about object oriented design he spoke highly of Smalltalk as being the language where he learnt a lot about this and a couple of colleagues have said the same thing as well.

For next time

  • We just about got started with writing a little bit of Smalltalk code this week but next week I’d quite like to see if we can write a little application using Smalltalk. We’re particularly keen on working out how unit testing fits into the picture and it’d be quite cool to play around with seaside a bit as well.
  • Smalltalk is quite renowned for its refactoring browser so we’re quite keen to play around with that a bit and see what its like compared to some of the features available in IDEs nowadays

Written by Mark Needham

May 21st, 2009 at 7:05 pm

Posted in Coding Dojo

Tagged with ,