Format: Workshop
Duration: From 60 to 120 minutes. (The longer the exercise duration the deeper the learning.)
Abstract
Test Driven Development (TDD) is a simple technique that is difficult to master. While it is often easy to write a test, it's not all that easy to write a good test. In this workshop we explore how good our tests really are; how well they represent our requirements, how well they express our intent, and how disciplined we are with our TDD prowess. Participants to this session will pair up for a programming exercise, learning to judge how understandable our tests are and to improve them - and to avoid the pitfalls of ambiguous, difficult to understand and incomplete tests. Note that we need laptop computers set up with a programming environment for this session so do bring yours if you have one.
Detailed description & timetable
This is an experiential workshop where the participants are engaged, pair programming on computers for most of the session. The rough outline of the session looks like this:
(60-minute version)
10 min - Introduction, organizing into pairs, handing out assignments
40 min - Programming exercise with pair rotation in the middle
10 min - Debriefing the exercise with the whole group
(90-minute version)
10 min - Introduction, organizing into pairs, handing out assignments
30 min - Programming exercise, followed by pair rotation
30 min - Programming exercise, followed by pair rotation
10 min - Refactoring our tests based on feedback gained through pair rotation
10 min - Debriefing the exercise with the group
(120-minute version)
10 min - Introduction, organizing into pairs, handing out assignments
40 min - Programming exercise, followed by pair rotation
40 min - Programming exercise, followed by pair rotation
15 min - Refactoring our tests based on feedback gained through pair rotation
15 min - Debriefing the exercise with the group
We'll organize into pairs in such a manner that we have an even number of pairs. This may imply that some pairs will have more than two people but we really don't want anyone to program alone so we'd rather have some threesomes than singles. An additional restriction with the organization is that for each pair programming in language X, there needs to be a matching pair that understands language X. In other words, we want an even number of pairs doing Java, an even number of pairs doing Ruby, etc. This is to facilitate rotation between the pairs during the exercise, which turns out to be quite essential for the learning experience.
This workshop is not an original idea of the presenters. It draws its inspiration and most of its design from a workshop conducted at the XP Day 6 conference, in London (2006) by Nat Pryce and Steve Freeman. After attending that session back in 2006, Lasse has used the same learning experience in his work as a consultant and a trainer, having found it an excellent vehicle for facing the quality of your tests and learning where and how they fall short.
Logistics
As this workshop involves all participants pair programming simultaneously, we expect participants to bring their own laptops. Naturally not everyone will have a laptop with them but we hope to get enough people with computers so that we can accommodate everyone who's interested in getting their hands dirty. This has worked in the past for half a dozen of other workshops so there's no reason to expect otherwise for this time either.
Biography
Ola Ellnestam came in contact with Agile in the year 2000 after reading Extreme Programming Explained. At the time he didn't know what kind of impact that particular book would have on him and the software industry. Fueled by many new thoughts he began his Agile journey which later led him to start a company specializing in XP and Scrum. Today he is working with clients that are working with or would like to be working with Agile methods. This often puts him in situations where he has to defend, promote and question the values and practices behind Agile which he has become very familiar with. Ola is also one of the driving forces behind 'Agile Sweden', Sweden's biggest Agile network.
Lasse Koskela works as a coach, trainer, consultant and programmer, spending his days helping clients and colleagues at Reaktor create successful software products. He has trenched in a variety of software projects ranging from enterprise applications to middleware products developed for an equally wide range of domains. In the recent years, Lasse has spent an increasing amount of time giving training courses and mentoring teams on-site, helping them improve their performance and establish a culture of continuous learning. When not working with clients, Lasse hacks on open source projects, moderates discussions at JavaRanch, or writes about software development — most recently a book on Test Driven Development. He is one of the pioneers of the Finnish agile community and speaks frequently at international conferences.
Comments (3)
Jul 23, 2009
Vasco Duarte says:
In this session and others it would be important for the organizers to add a sec...In this session and others it would be important for the organizers to add a section called "material for workshop" that would list the material the facilitators need from the participants and the organizers.
Overall it is quite difficult to comment the content of this type of sessions because there's very little detail. Can you describe what you expect the participants to learn from the session? (without disclosing all the "surprises"?)
Jul 28, 2009
Markus Hjort says:
I agree with Vasco. Could you for example add link to description of original wo...I agree with Vasco. Could you for example add link to description of original workshop or something?
Aug 07, 2009
Lasse Koskela says:
Markus, the original workshop didn't reveal much more of the "proceedings" than ...Markus, the original workshop didn't reveal much more of the "proceedings" than this description and if we list the learning objectives in much more detail than in the abstract, we're risking a participant missing on the moment of revelation because he's altering his normal behavior to match what he knows about the exercise. Obviously this is just speculation and a hypothetical risk.
What if I'll send you guys the details via email - would that suffice?
(the original workshop is here)