Tuesday 3rd July, 2012
2:45pm to 4:30pm
One-line description: What would happen if you really did let Tests Drive your Development?
Session format: Workshop (75 mins)
Abstract:"TDD" is probably the highest profile and most widely adopted technical practice from the Agile toolkit.
But, I see a lot of this sort of thing:
• Think up a design
• Write a bunch of tests that say the design exists
• Write the implementation
• Test, debug, test, debug, test, debug, test, debug, debug, test, debug, test, debug
• Write a TODO saying to refactor
That's not really TDD. In this session we will try doing this:
• Add a test
– The very simplest test you can think of
• See it fail
• Make all tests pass
– By writing the least code possible
- design thinking goes here
• Repeat until done
With some very strict rules in place about what the "simplest" test and the "least" code are, to force the Tests to really Drive the Development.
Audience background: Programmers
NB This is a hands-on session so attendees should bring a laptop or be prepared to share. No specific language or tools need be installed beforehand but attendees should bring a machine on which they can do programming of some kind within an automated unit test environment.
Benefits of participating: Gain an appreciation of the possibilities of TDD as a design tool. Gain an understanding of the kinds of problem-solving strategies that other programmers use in applying TDD
Previous attendees at these sessions have said things like this: "I’d highly recommend [TDD as if You Meant It] as something to do on a relatively regular basis to help refresh your TDD muscle memory" — Rob Bowley
Materials provided:a few slides outlining the maximum-discipline interpretation of TDD and describing a simple and familiar problem domain to address
Process:Work in pairs with pauses for reflection and a show-and-tell at the end.
Never knowingly succumbed to the tyranny of positive thinking bio from Twitter
Sign in to add slides, notes or videos to this session