I thought I’d jot down my experiences with planning and presenting an Introduction to Test Driven Development recently, as when I was looking for inspiration for the session on the web there didn’t seem to be much out there. There’s plenty on TDD, but not on how to introduce it, so here’s my experience for anybody who’s interested.
All this started when Fran Hoey announced that he wanted to set up the Chester Devs group. I got in touch and offered to do a session based around getting hands on with some form of exercise. After a little constructive discussion, it became clear that really the first session should be An Introduction to Test Driven Development, as all the exercises I was considering would need some experience of TDD, and we were unsure how familiar the group would be with the technique. The only problem being that I didn’t have anything of that sort prepared!
So, what to do…? I first off started randomly putting down thoughts about what I wanted to cover (if I were being really pretentious, I would consider this driving the session by selecting tests with which to judge whether the session succeeded, thus generating the Introduction to TDD by TDD… and while it would be a nice self-referential tick-in-the-box, I don’t really think this happened). What I really wanted was a hands-on session as I’d experienced several such meetings with the London Software Craftsmanship Community and found these to be an excellent way to learn; nothing beats getting your hands dirty and working with the techniques yourself. We also had a time limit of about an hour and a half for the session, so it had to be reasonably compact.
Wanting to get wider input for the session, I contacted Sandro Mancuso of the London Software Craftsmanship Community looking for ideas, and he in turn put me onto Alastair Smith who had recently done a similar session for the Cambridge Software Craftsmanship Community. They both gave valuable input, firstly on really focusing the session on TDD, and also being prepared for developers who had not previously seen TDD struggling to take it on board in such a short session. All good advice! I squirrelled it away…
The other major part of my preparation was to re-read Kent Beck’s Test Driven Development book in detail for the nth time. This formed the basis for the presentation and the ideas to put across. I found that even though I’d read the book several times before, there were still very valuable nuggets of information in there that I’d either forgotten or overlooked. I really don’t think the presentation would be half of what it was without this source of good quality information. I found it interesting that when you’re reading books to then use them as a basis to tell others about their content, you digest them a lot more carefully. I also re-read the introduction to Growing Object-Oriented Software Guided by Tests by Steve Freeman and Nat Pryce. Again this is a great source of inspiration, but did go a little further that I really needed for simply an introduction to TDD. There’s no way I wanted to try to include flushing out of object designs and mocking in this introductory session.
I also needed an exercise to undertake during the session, and it was Fran who actually came up with the best suggestion for this. I was a little unsure at first, but we ended up investigating the Greed Kata and it turned out to be pretty good for the job. In its simplest form, it’s a collection of 8 rules for scoring a single roll of 5 dice (the full dice game would not be implemented). The rules were pretty elementary and so would be easy to understand in the session, I didn’t want to have to go into long and detailed explanations about the rules during the session and this fitted the bill nicely. It was also simple enough that the participants could focus on the TDD techniques and wouldn’t be distracted by the puzzle. I practised the kata several times before the session, to make sure I understood it well enough, but I did always have a nagging doubt at the back of my mind that opening it up to a number of other keen, sharp developers would find some corner of the kata that I hadn’t explored.
So, I had the bulk of the research in place, so now I needed to plan the structure for the session. I was painfully aware of the hour and a half time limit, and that TDD is a huge topic, and that if we went over time we would probably lose the devs to tiredness after a long day. For this reason, I decided to take a chance on giving the shortest possible introduction to TDD so we could get the devs working on the Greed Kata and then we could discuss it at the end. I opted for giving out some simple rules for TDD, and these formed the first 3 slides of the presentation:
- Don’t design a solution up front, instead write the next test
- Goals for the session being to experience TDD and not necessarily to complete the exercise.
I would ask the room to indulge me in doing things this way, and by doing this we would then have an experience of TDD which we could discuss. Furthermore, it would avoid overloading the attendees with information that they would then probably be still trying to digest when doing the exercise and may confuse matters. I was also aware that this might backfire, and the group might just not have a clue what to do. For this reason I prepared 3 things:
- I was willing to talk the group through the first test
- I was prepared to do the first test on my laptop using the projector (or possibly even the full Greed Kata)
- I had prepared Kent Beck’s Fibonacci example as an alternative to show, so that the group might pick up the idea of what to do with the Greed Kata
Ideally I was hoping that after the group had had some time with the Kata we would just discuss it, but just in case the group didn’t have too much to say, I prepared some slides that tried to explain why I had asked for the particular steps to be followed. For example, in asking people not to design a solution up front, I was asking them to place working code before design; and in writing the simplest failing test, they would be using a divide and conquer technique to solve the problem. This made the presentation nice and circular and tied the rules I would ask people to accept to an explanation. It would also allow some deeper thinking about TDD should it not fall out from the discussion.
On the day itself, we turned up at Chester Uni (our hosts) and found an excellent room set aside for us with some delicious sandwiches provided. Definitely a good start.
After Fran had introduced the session, I was given the floor and fired up the slides. I started with asking about the experience the group had with TDD, and it turned out that we had a roughly 50/50 split with TDDers and newbies, with a couple of people who had some intermediate knowledge (knew about tests, but hadn’t used them for full TDD). This was good as we would be able to pair people up neatly for the exercise. I explained my background: 3+ years’ experience with TDD, and I didn’t claim to be any kind of expert and that I was still learning. I also explained the format for the session in that I would be asking people to take on-board some simple rules, and to trust me in doing so. This would allow us to experience TDD and then we could discuss it as a group. This was part of a little Expectation Management just in case some people in the room were too shocked by the paradigm shift from traditional design-first development to TDD; I wasn’t here to sell TDD, just encourage us to experience it and make up our own minds. As it turned out, either it worked pretty well, or we didn’t have anybody who was too upset by the idea. At least it made me feel a little easier that I wasn’t cornering people and forcing them into TDD.
We went through the first slides and as far as I could tell everybody understood, so we discussed the exercise and paired people up. We had a few problems with people not having a complete dev environment, missing things like test frameworks, but either by managing the pairing or by other means we got everybody on a working machine and got them started.
By just milling around between the pairs, it was clear that not everybody knew where to start. So after a few minutes I paused the exercise and we had a two minute discussion about what the first test would be – one of the things I had planned for. Some people were trying to handle error cases first and throw exceptions and the like, and while these may be good tests to start with in the real world, I gently suggested that we didn’t need to do these for the exercise. There were also pairs who were just working their way through the sheet top to bottom. This would give the first test as being ‘rolling a single 1 scores 100’, but with a bit of discussion within the group we came round to a slightly simpler initial test being ‘a bad hand scores nothing’.
As the pairs got on with the exercise, it seemed to me that the paring of a TDDer with a newbie was helping, and the pairs were turning into mini mentoring sessions. I guess we were lucky with that and it certainly made the session run more smoothly. There were a few hiccups in implementations I saw but nothing unexpected for a group is had been given a rapid brain dump followed by an exercise they’d never seen before. It was clear that choosing the next simplest test was not easy and pairs would often miss steps, for example a couple of pairs had tested that the code could score 100 for the first die being 1, but not for any subsequent dice, or had not tested for two single 1s before moving on to triples. There were some other silly points for example, more than one pair were managing to roll zeros with their dice, which when pointed out they rapidly put right. All in all, I think the Greed Kata worked out fine on this occasion. It didn’t have any real gotchas and the pairs were able to get up and running with it quite rapidly. I think I’d use it again for a similar session.
I lost track of time slightly but brought the exercise to a close after about 40 minutes or so. Most pairs had made some progress with the kata and were around the point of dealing with the requirements for scoring triples. We had a brief discussion of how people felt about it, which I wanted the attendees to drive so I simply asked for comments (I didn’t want to lead the discussion down any particular route). I should have taken notes as we probably had about half a dozen comments, but the ones I can remember were:
- It’s hard – I guess this is quite a standard reaction. I know I found it difficult when first trying to follow the true TDD way.
- Can you write bad code with TDD? – My response was: Yes, and the skill is in refactoring, and it’s a tricky area and one in which I feel I’m still learning.
- It’s difficult to know what the next simplest failing test is. – Again, a classic experience for newbies, and I think I recommended starting with small examples like the one we were working on as it takes time to hone your skills
Though the discussion was going well, and the group were even batting ideas back and forth between themselves rather than going via me, after a while the ideas slowed down so I returned to the slides I had prepared. I think these were useful in that it allowed a little more explanation of what we had been doing to come out, and for the whole exercise to be put in context. I’m not sure the group noticed so much, but I didn’t relate the explanations I was giving to the Greed Kata so much, but this was partly due to the Greed Kata being only a very simple exercise and also because the explanations were really for those initial general TDD rules. So instead of using the Greed Kata, when I needed an example, I would speak about a theoretical real-world project. An example of this would be one of the explanations of ‘not coming up with a design first’:
‘Many people have been on a project where you set off with some grand plan to implement some architecture, and you do so, and when you then begin to test it you find a case that you didn’t account for, so you put in a hack and damage your architecture and move on, but then you find another case, and this really doesn’t work so you hack your architecture even more, this continues until the architecture is completely compromised – the TDD alternative of making it work first by making the tests pass, and then adding the architecture in afterwards (by refactoring) always ensures that the architecture is fit for purpose.’
I’m not sure that it really matters, but I have a nagging feeling that it would be better if the example could better illustrate the points I was trying to make. The fact that this was only an introduction to TDD probably allows me to get away with it. Anyway, I’ll be on the look-out for inspiration in this area and may include it should I do this session again.
My final slides were encouraging people to explore TDD in a wider way. I stressed that the session we’d just covered was only an introduction. I referred people to other Katas online and to various blogs and books that I considered worthwhile reading. I also gave a link to a solution to the Greed Kata I had done, stressing that this wasn’t any kind of model solution but that it was just there for reference and comparison to other people’s efforts. I even mentioned that I thought I’d made a ‘deliberate mistake’ in there… There’s certainly something I’m debating with myself as to whether I kept as close as possible to the spirit of TDD. I’ll leave it to the interested reader to investigate and find out.
That’s about it really. From my perspective I think the session went pretty well, though I think it’s really the attendees that should have the final word. I’d certainly run the session again and would recommend this approach to anybody else thinking of doing something similar – and by this I mean please feel free to use any of this material in running your own sessions. If anybody does have any thoughts or experiences to share, then I’d be glad to hear them.