Archive for the ‘Review’ Category

As I mentioned in my last post I’ve recently taught a course in automated testing to a bunch of students at KYH. Before the course I spent some time looking for good course books for them. I looked at a few options and eventually decided on “The art of Unit Testing with examples in .Net” by Roy Osherove, and “The RSpec Book” by Chelimsky et al.

I chose the unit testing book because Roy does a good job of describing the basics of test driven development, including simple mocks and stubs. The book is very practical and is full of insight from experience and code examples.

I also looked at “Pragmatic Unit Testing in C# with NUnit” by Andrew Hunt and David Thomas. I’m a big fan of their book “The Pragmatic Programmer”, so I had high hopes for this one. Unfortunately I was rather disappointed with it. It talks about what good unit tests should look like, but not much about how you use Test Driven Development to create them.

I chose the RSpec Book because it has quite a bit of material about Cucumber and how it fits in to a Behaviour Driven Development process. I think the published literature on automated testing focuses too much on unit level tools, and there is not enough written about feature level tests and how to use them as part of the whole agile process.

I also looked at “Bridging the Communication Gap” by Gojko Adzic, which I think is an excellent introduction to how to use feature level tests as part of the agile process, but it is largely tool agnostic. There is a short chapter introducing some tools, including JBehave, a forerunner to Cucumber, Selenium and TextTest too. It’s a little out of date now though, and for this course I wanted something with more detail.

I hope these short book reviews are useful.

If you’re running a coding dojo, or if you’re an individual who likes to practice code kata, there are a number of websites which aim to help. In this post I want to review some of what’s out there.
The idea of the code kata was originally presented by Dave Thomas in his blog. This is the list of Kata exercises he originally suggested. The dates on the site say 2007 but it must have been at least a couple of years before that*. Some of these katas don’t actually involve writing any code, such as kata three. The focus is on general programming skills rather than TDD in particular.
The idea of practicing code kata in a group and calling it a Coder’s Dojo was presented by Laurent Bossavit and Emmanual Gaillot at XP2005. is their site for the community, and has some helpful information if you’re looking to join or set up a dojo. There is also a catalogue of Kata descriptions. In the past I’ve personally contributed quite a bit of material to this site, but I’ve recently become frustrated with the amount of spam on it.
This is an article rather than a whole site, but it gives one of the best summaries of a coding dojo that I’ve seen on the web.
Corey Haines set up this site in 2009 and his original intention seemed to be to publish a screencast of a kata performance each week. Unfortunately the most recent screencast on the site is from July 2010. There is a lot of good stuff on there to watch, though – notably versions of the StringCalculator kata in almost any programming language you can think of. I really like the idea of screencasts of katas, since for me katas are all about practicing the moves of TDD and becoming expert with your language and editor/IDE. I’m not half as interested in the code you end up with than the route you took to get there. I like that Corey and others comment on the various performances and people learn from watching each other.
As I understand it, Jon Jagger created this tool to help development teams improve their collaboration skills. He’s been round several conferences using it as a kind of game for learning about practices such as pair programming, clean code, TDD, and all the people issues related to working in a team. It’s a fun activity for a group of programmers to do together, but to get the most out of it I think you need a facilitator who will help you understand what was happening and what there is to learn from it.
This site still claims to be in beta, but there is quite a bit of material already. The philosophy seems to be to try to get people to have fun by playing with code, and also to learn new languages. There’s no particular emphasis on TDD. There is a catalogue of katas, and for each one it provides starter projects you can download into your IDE. When you think you’re done, it will check your solution for correctness and let you upload the code for public viewing. There doesn’t currently seem to be any support for uploading screencasts, or giving people comments and feedback on their solutions.
This site is also quite new, but seems very promising. The aim seems very much to encourage collaboration, feedback, and becoming better at TDD – key elements of a face-to-face coding dojo. It provides tools that analyse your performance of a kata, not at the level of ‘does the code work by the end’ but at the level of ‘what were the moves you made to get there’. Each time you run the tests it records the code before and after, and whether the tests passed or failed. There are tools to let you go through a kata performance, look at the moves made and suggest improvements to the performer.

At present the only language supported is Ruby, but that is a great language for practicing TDD in 🙂 There is also no catalogue of katas to try – it just points to

What sites have I missed?
There are a number groups holding regular coding dojos in various parts of the world, and many have their own websites. Several of these are also full of helpful information, but they’re not quite what I’m after. I’m looking for sites that are addressed to the whole online community. Please write me a comment and point out sites I should know about!

* Laurent and Emmanuel credited Dave Thomas with the idea in 2005 when they presented the coder’s dojo, Jeff Attwood credits him in and article dated 2008, and wikipedia says he published code katas before Jan 2006.

A little while ago, Fredrik Wendt and I put together a little survey and sent it to all the people we know who have attended coding dojo meetings here in Göteborg. There are several groups in the city which run these kinds of meetings from time to time. We wanted to know what kinds of things people are learning from practicing code katas in a group, and get some feedback and comments to help us to develop the groups we run.

The survey got 29 responses – thankyou to everyone who participated! I was very encouraged to see that the overwhelming majority – 90% – said they would recommend the dojo to other people who wanted to improve their programming skills. There were lots of comments too – I won’t include them all – but I particularly liked:

“Dojos make me relive the joy of red-green-refactor”

“you learn a lot from each other at these meetings”

“… planting seeds that have improved me as a programmer and a problem solver”

“I have started to think in terms of TDD”

The first question asked people which dojo(s) they had been to.

Which dojo(s) have you been to?

Fredrik and I set up JDojo@Gbg about a year ago, as an free coding dojo for Java programmers, sponsored by Iptor. We advertized it as a taught course – 5 sessions, once a month, come and learn TDD. We ran it twice together, and now Fredrik is continuing it together with Ola Berg.

The second sort of coding dojo going on in the town is various language user groups. It must be four years since I pestered Niclas Nilsson and CJ that we should do code Katas at Got.rb (Göteborg Ruby User Group). Inspired by the success of that group, and together with Andrew Dalke and Johan Lindberg, I set up GothPy (Gothenburg Python User Group) about two years ago. More recently, Jonas Nicklas set up Got.js (Göteborg javascript user group) and Jörgen Lundberg set up Scala Geats (Göteborg Scalaenthusiaster). So there are several small, language specific groups that meet and do dojo evenings occasionally, interspersed with other activities.

The third kind of coding dojo meetings going on is where people run them internally at their employer, which lots of people do from time to time. In addition, Fredrik and I are both facilitating these kinds of groups at clients, as part of our work coaching teams and encouraging them to be more agile.

I was pleased that people from all these sorts of groups filled in the survey, and that many people had been to more than one kind.

Most of the survey respondents had been to 4 or 5 dojo meetings:
Roughly how many dojo meetings have you been to?
We asked several questions about perceived skill level before and after participation in dojo meetings. We wanted to know what people thought they were learning, basically.

As you can see, people were fairly good at the programming language in question before the dojo(s), and only reported marginal improvements, 0.3 on average, on a five point scale.

When it comes to the IDE used in the dojo, again, we are looking at a modest improvement, also 0.3 on a five point scale.

Using Mock Objects is a topic that doesn’t always come up in dojo meetings, I personally have certainly had more of a focus on classic TDD. The feedback shows that people didn’t feel they were that good at it before the meetings, and not that much better afterwards – an average 0.5 increase on a 5 point scale. From some of the comments, I think this is an area to focus on more in future. To that end, we’re having a GothPy meeting next week looking at Mockist TDD 🙂

Refactoring is an essential part of Test Driven Development, and in fact any modern programmer’s toolbox. I was pleased to see that people thought the dojo had helped them to improve this skill too – 0.5 on a five point scale.

So it looks like going to a dojo encourages you to write unit tests more often – 0.6 (on a five point scale) more often on average.

This result is the most pleasing to me, since I think TDD is such an important skill, and it can be so difficult to get going with. People are moving from a low level of skill up to a medium level of skill – a whole 1 point (on a five point scale) on average! No-one is claiming to be a TDD expert yet though, I will have to repeat the survey in a few years and see if anyone is brave enough to claim that by then 😉

Fredrik and I are off to Agile Testing Days in a week or so, where we’ll be presenting a bit about what we’ve been doing at these various groups, and what we recommend for others starting their own coding dojos. We’ve learnt a lot by running these meetings, and had fun too. Hopefully these survey results might encourage you to find a coding dojo and improve your programming skills!

Roughly how many dojo meetings have you been to?

I’ve just heard that two of my proposals for XP2010 have been accepted, which means I will definitely be off to Trondheim in early June. I’ve heard Trondheim is very beautiful, and the XP conference it usually excellent, so I’m really looking forward to it. It will actually be my 8th XP conference!

I’m going to be running a half day workshop “Test Driven Development: Performing Art”, which will be similar to the one I ran at XP2009, (which I blogged about here). I’ve put up a call for proposals on the codingdojo wiki, so do write to me if you’re interested in taking part.

The other thing I’ll be doing is a lightning talk “Making GUI testing productive and agile”. This will basically be a brief introduction to PyUseCase with a little demo. Hopefully it will raise interest in this kind of approach.

Perhaps I’ll see you there?

Geoff has been working really hard for the past few months, writing pyUseCase 3.0. It has some very substantial improvements over previous versions, and I am very excited about it. He’s written about how it works here.

It’s a tool for testing GUIs with a record-replay paradigm, that actually works. Seriously, you can do agile development with these tests, they don’t break the minute you change your GUI. The reason for this is that the tests are written in a high level domain language, decoupled from the actual current layout of your GUI. The tool lets you create and maintain a mapping file from the current widgets to the domain language, and helps you to keep it up to date.

In a way it’s a bit like Robot, or Twist, or Cucumber, that your tests end up being very human readable. The main difference is the record-replay capability. Anyone who can use the application GUI can create a test, which they can run straight away. With these other tools, a programmer typically has to go away and map the user domain language of the test into something that actually executes.

The other main way in which pyUseCase is different from other tools, is the way it checks your application did the right thing. Instead of the test writer having to choose some aspects of the GUI and make assertions about what they should look like, pyUseCase just records what the whole GUI looks like, in a plain text log. Then you can use TextTest to compare the log you get today with the one you originally recorded when you created the test. The test writer can concentrate on just normal interaction with the GUI, and still have very comprehensive assertions built into the tests they create.

pyUseCase, together with TextTest, makes it really easy to create automated tests, without writing code, that are straightforward to maintain, and readable by application users. Geoff has been developing his approach to testing for nearly a decade, and I think it is mature enough now, and sufficiently far ahead of the competition, that it is going to transform the way we do agile testing.