TDD Bootcamp

Revision as of 11:34, 31 January 2008 by Clarman (talk | contribs)


The TDD bootcamp is an experience-driven workshop, not lecture driven. The "written" materials of the course are normally a few posters on the wall and the agenda. The workshop may be supplemented with learning aids from the Agile TDD and Refactoring course, or may follow that course.

While it may be possible to lecture on TDD and refactoring for days on end, our observations on TDD adoption is that the primary problems are two-fold:

  • First and foremost, developers have been trained to write the code first and manually debug to test their solutions. Replacing this changed habit with one that requires more forethought, discipline, and more code, cannot be done through lecture. It must be done through practice for an extended period of time. The bootcamp is an alternate approach to “sit side-by-side” instruction (which has a low adoption rate) or the “use consultants for ½ your team” (which has a high adoption rate).
  • Second, many of the developers are working with large, poorly coded (for unit testing at least) applications.

Doing TDD to build a Stack simply does not address the issues they'll have when they try to work on their code, nor does simply saying "snip the dependencies".

The design of this bootcamp assumes:

  • While lecture is valuable, experience is more valuable.
  • While knowledgeable instructors are valuable, encouraging the students to find the knowledge on web, on their own, is more valuable.
  • You are able to explain the "why" behind your advice.

The theme of the bootcamp is to dare people to do things differently than they did last week--TDD is just one part of that. They don't think working off the main trunk or a project branch will work? OK, how about we just try it for two weeks? They don't think they can check in every 30 minutes? Ok, just try it. They don't think they can evolve towards the software architecture they have in mind with YAGNI? Maybe, let's try it YAGNI for a while, ruthlessly.

Having at least the shell of a working CI site helps immensely but is not a prerequisite.


  • Intros
  • TDD is not unit testing: The deep motivation and benefits of TDD
  • Why we’re here
    • investment in quality
    • current SW not acceptable---you and others
    • who is responsible for the quality of the s/w you write?
    • What do you do to ensure it?
  • What to test?
  • Test tools selection
  • Test, TDD and refactoring
  • Lessons learned