How to teach a training course on TDD?

Question

I've been asked to run an internal training course for a handful of our developers on Test Driven Development. What advice do you have for me, as someone who has never given a training course before?

I'd like advice on the delivery of training, as well as your thoughts on what content I should include.

Anybody who has been on a similar training course and had positive or negative experiences should also feel free to chime in with their thoughts.

I'm thinking that the course would take place over two days. Is that about right?

Answer 1

Hands on exercises and lots of them. Most programmer learn from doing better than from looking at example.

Make sure that your lesson builds up to an example that shows why TDD is useful (so they get the benefits).

Edit: (following comments)

• Do not talk for too long at a time (10 minutes or so) and intersperse with exercises.
• Make sure exercises do not depend on the last exercise being finished.
• Ask questions to get people involved (and don't let only one person answer...).

Answer 2

Training is a difficult skill to master but with a few simple techniques you should be able to deliver a useful course.

Check your presentation skills - there are many guides to improving both your speaking and physical body language which will make you a much more engaging speaker. Slides should be visual and give a high-level view of what you're discussing, rather than detailed notes - these should be on separate handouts.

Make sure people understand why this subject is useful and how they will benefit - get them interested!

If possible, include regular practical sessions where your developers will write appropriate code to check their understanding.

Take regular breaks to allow people to rest.

Best of luck!

Answer 3

If I had to teach TDD, I'd give a short (10 minutes (reduced from 1 hour thanks to suggestions in comments)) presentation on basic concepts as well as potential benefits, and then make everybody pair program in constant rotation (with me as part of that rotation) for the next two days through some example problems.

Because some things are innately harder to test than others, I would work through problem types in this order:

1. Static methods such as mathematical functions (Fibonacci)
2. Stateful but standalone, simple objects (Data structures, Bowling game)
3. Object interactions, like a business logic layer that depends on a data access layer (start with hand-coded mocks before you introduce a mocking framework)

For me, one of the biggest benefits of TDD is that it's faster to write and run a test than it is to launch the UI, click through the right screen, enter the sample data and trigger an event. A calculator GUI is a great example to demonstrate this to people.

---

Some more general comments on training courses / presentations:

• Everybody should feel like they can ask a question at any time, no matter how stupid they think the question is.
• Nervous presenters tend to repeat themselves, give circular explanations/arguments, and say "um" alot. Don't be scared to close your mouth for a while while you think of the best thing to say next, everyone needs time to think through what you've just been saying.
• Don't voice assumptions about your audience ("Now you're going to think this is a waste of time", "You've done this before, right?", "I can see you're getting bored") - if you're wrong they will just turn off. Ok, you'll have to make some assumptions about what kind of programming experience they've got already in order to pitch your talk at the right level, but don't come across as thinking you know everything.
• If people get things wrong, try to be encouraging (see "Compliment Sandwich").
• If people start getting argumentative, just acknowledge that they have a valid point (regardless of whether they do ;) ) and that you'll "look into it" or "talk to them offline straight after".
• Last but not least don't just read out your powerpoint bullets. People can read, you should have 5-50x as many words to say about a slide as what's written on the slide.

Answer 4

Some suggestions:

1. Ask people what are their expectations in the begining and try orient the training in that direction.
2. There should be lot of interaction during the training. Ask questions and give chocolates to people who answer.
3. Hands-On is a must. Try to have hands-on on both the days.
4. Ask people about their experience from their work and try to relate your teaching to that or how they could have solved their problem using your techniques.

All the best!

Answer 5

Personally: avoid too much Powerpoint - death by slides is always a danger otherwise!

Also: any notes / exercises you make - ideally make them your own - I have previously inherited notes from courses (which were run brilliantly by the individual who originally gave the course), but was suprised to find that its hard to replicate the original performance - my timing and explanations sometimes didn't flow : until I re-worked everything for myself - and the fact that I was more familiar with order of explanations, introductions and exercises help me relax that I hadn't forgotten anything or had spent too much or too little time on particular pieces.

Well written exercises : with working and tested solutions are always a boon to keep the class interested.

Try and keep exercises independant of each other: or if they are necessarily dependant on each other, make sure you have pre-built solutions ready to provide them to any stragglers - you don't want to lose people, who for whatever reason didn't finish the last exercise and can't start the next one.

Also: make time for jokes. (or have some funny Dilbert cartoons / youtube videos on standy :) )

oh - and make sure you retain control over all air conditioning and thermostatic controls...as a last resort you might need to keep the conditions just below comfortable slumber-temperature...

Answer 6

With regard to TDD: My first and foremost advice would be to not come over as a religious zealot.

Don't tell people that TDD is the only way to create good software.

Don't tell them everything they have been doing before is outdated and suspicious in the "new world".

Tell them you want to present a new technique that can help create good software and which can offer them increased reliability and better quality if done right (because you can also screw up TDD in a big way)

If you regard the other advice given in this thread I'm sure you will give an interesting and worthwhile presentation!

Answer 7

When I was an instructor I relies on a few techiniqies to keep things moving along: 1. Know more than you intend to present on the subject (you'll feel more cofident answering questions)

1. Never read a Power Point slide word for word. If you must use them, then make them short and sweet and exapnd on what is in the slide as you talk.

2. Be interesting - don't talk in a monotone, use real life examples that make sense to your target audience. Since these are co-workers you can mine a whole realm of problems that have happened inthe past and show how TDD might have avoided that particular disaster. Try to make the examples something that won't insult your actual students though, nobody wants to be publically humiliated.

3. Hand's on is best. But plan the examples carefully to build up a body of knowledge. I often found it helpful to start the exercise and after letting them flounder a bit, start a discussion as to what they had tried and why it didn't work and ease the discussion towards what would work, then back to the exercise.

4. Have a final example that each person has to work through as a sort of final exam. If you have the time to develop the exercises, assign each person a different final task and have them each present what they did.

5. For one of the first exercises, have them do an exercise without using TDD. Have one group (especially if you have anyone already a little experienced in it) do the same exercise with TDD. Apply their tests to the other students answers. Show that it didn't take them twice as long to complete their code either. Or have one group come up with an exercise for this that will hit you cold as well as the students. You do the TDD version, and one group of volunteers (not inthe group that made the suggestion), do the non-TDD version. Compare times and results. Apply your tests to their solution as well, it's even better if you find a problem in their code with your test.

6. Call on everyone, nobody gets to sleep in my classes. If someone appears to not be paying attention, ask them a question.

7. If everyone is looking glazed over take a break. A minimum of a break an hour. If this doesn't cure the glazed look, ask them if there is something they aren't getting. If they aren't getting what are you saying one way, don't say it again the same way! Approach it from a differnt angle (another reason to know more than you intend to present).

8. Don't let anyone be a persistent disruptive influence on the class. If someone won't particpate or a keeps being overly antagonistic or won't do the work or whatever, kick him or her out of the class and send a note to his or her suprevisor explaining why.