TDD Randori and fishbowl

Organizers: Dave Nicolette, Rod Coffin

Objectives:
Give participants a feel for Test Driven Development (TDD) and an understanding of the benefits of TDD as compared with traditional methods of software development. The primary focus of this workshop will be on developing a practical understanding of TDD through hands-on application and group reflection. Other topics may be optionally pursued based on the interests of the group.

Intended Audience:
Intended audience is software developers who are interested in learning how to do test-driven development and gaining an understanding of the benefits of test-driven development. The programming challenges are not extreme, but the workshop is not an introduction to programming as such. No special materials or equipment will be required by participants.

Session Format:
The workshop format is a bit unorthodox in that it combines several techniques that enhance the interactive, hands-on learning experience: Experiential learning, randori-style dojo, pair programming, and fishbowl discussion format.

We have crafted the workshop around the principles of "experiential learning," a highly effective approach to collaborative, hands-on learning that lends itself very well to learning software development methods. For more details about experiential learning, please see Experiential Learning.

The hands-on portion of the workshop is based on the "randori" style coding dojo pioneered by Agile Finland. The randori format keeps the entire group actively engaged while maintaining focus on a single stream of work that is visible to everyone. A single workstation is positioned at the front of the room and is connected to an overhead projector. A pair works at the workstation, following the TDD cycle to build a sample application. The facilitators provide prioritized story cards for the application. The stories are designed to expose the need for particular TDD principles and techniques in the context of the evolution of the application. (We have used a fictitious video game as the sample application in past presentations.) Every five minutes, the pair switches. The navigator retires, the driver changes to the navigator position, and the facilitators choose a new driver from the group. There is no advance notice of which participant will become the next driver. It could be anyone. Just as in a randori-style dojo, the working pair must keep the observers up to date with what they are doing and why they are doing it. Observers may ask questions, make comments and suggestions, or heckle the pair at any time, continuously. It can be a very lively and highly interactive experience. There may or may not be sufficient time for all participants to pair; this is OK because the interactive nature of the randori keeps everyone actively engaged and attentive, and the point of view of an observer as opposed to a pair member adds value to the fishbowl discussion. For more details about the "randori" format, please see http://davenicolette.wikispaces.com/Randori.

To reinforce the lessons learned in the hands-on portion of the workshop, we facilitate a retrospective discussion. We use the fishbowl format for this portion of the workshop because the format enables a large group to engage in a well-focused discussion in a way that encourages each person to participate, while avoiding both the chaos of too many people talking simultaneously, and the problem of one person dominating the room. Our experience has been that the participants themselves tend to bring out all the key points we hope they would learn about, but if this does not occur naturally we are prepared to guide the discussion toward the right path. For more details about the "fishbowl" format, please see http://davenicolette.wikispaces.com/Fishbowl.

Primary Content:

  • The TDD cycle
    • write a test
    • make it compile
    • see that it fails for the right reasons
    • make the test pass
    • run all tests and ensure you haven't broken anything
    • refactor.

Optional Content: (Based on the interests of the group)

  • Differences between testing for validation and testing to "drive" development.
  • DRY principle – don’t repeat yourself
  • Evolutionary design vs predictive design, JEDI vs BDUF
  • Design debt / technical debt
  • Refactoring vs general changes
  • Test isolation
    • Isolate the code under test using stubs, mocks, etc.
    • Each test is independent of other tests
    • Tests can run in any order
  • Simplest thing that can work
  • Avoid premature optimization, YAGNI
  • Favor behavioral (state, black box) testing over implementation (white box) testing
  • The current project’s working test suite becomes the next project’s regression test suite (for the same application)
  • Good practices
    • test behavior, not implementation
    • isolate tests
    • tests should not depend on other tests
    • tests should run fast (because they are run often)
    • run all tests before integrating
    • use hard-coded expected value in assert statements
  • Using test doubles
    • Stubs, mocks, crash test dummies, etc.
  • Testing for expected failures
  • Agile practices that help TDD work more effectively
    • Continuous integration
    • Pair programming