I have a really great team that I’d like to help dive in to fully embracing TDD.
I’ve come across one serious play which looks like a nice intro: http://www.gargoylesoftware.com/ex/lego_tdd
I’m curious, what are some other approaches Coaches/Team Leads have tried?
Thanks @andycleff first time I have used. Created account a couple weeks ago. Just updated profile.
Mark
I’ll be writing a short article about another exercise I recently learned from Amitai Scheier (still getting used to his name change, ugh).
In short: illustrate the principle of TDD by using English words to compose a “story” (or sentence, poem, whatever). It’s great because you don’t need a ton of $$$$ lego kits, easily demonstrates a variety of pairing methods, and brings both tech & non-tech minds in a shared learning space.
Give me a day or two, or just tweet/email/text Amitai to explain 
z
I recently dipped into TDD while working on an Open Source project - pretty much an unwritten rule that you need tests with an OSS project so contributors understand how everything is implemented.
I’ve been saying it’s like a drug. It slowed down my velocity while adopting it, but overall ended up cutting debugging time in half and brought a lot of possible issues to the foreground much sooner.
I simply just started doing it at my day job. Refactored some of our architecture to allow for dependency injection and started adding tests to classes and objects in the code that I touched. Soon enough during code reviews and other discussions, my fellow team members have started saying “I need to start doing that” and “Can you show me how you might test this?”
The biggest argument and push back I get from developers is the time it will take to start writing tests. And it’s not the fact that it’s more effort. If it’s a legacy project, you’ll almost need to refactor to make the code more testable. So when a defect surfaces, should the team spend 1 week - 1.5 weeks refactoring the code to fix the bug and add tests when the bug can be fixed in an hour two? Most product owners, managers, clients, etc., all say “fix it ASAP!”.
I’ve found once a product owner or manager sees their team function at a particular velocity, dropping below that - even if it’s to add in something like testing - is normally frowned upon.
I’ve started to use this analogy from Uncle Bob Martin: What if you were a doctor and had a patient who demanded that you stop all the silly hand-washing in preparation for a surgery because it was taking too much time? Clearly, you want to listen to the patient, but the doctor should absolutely refuse to comply. Why? Because the doctor knows more than the patient about the risks of disease and infection. It would be unprofessional (never mind criminal) for the doctor to comply with the patient.
I am usually successful at finding a respected developer to champion the cause. I was a coder for years, which probably helps me explain the value of TDD to people - but I now haven’t coded for years so I do not try to TEACH TDD.
I usually have a respected (and interested) developer read a book, try it out, and champion the cause. That has worked for me most often.
The only time that didn’t work I brought in Ron and Chet for a week to teach that company all about TDD (and other XP practices).
I do like games in many situations, but I’m not sure teaching developers the value of TDD is a game thing. But I could be wrong.
I usually talk about the lifecycle of a defect, doing traditional 1995 style development vs what we can do today with TDD, CI, AT, etc.
99% of a time that is all I need to get the point across.
I am interested is seeing what people suggest for games. I am always looking for new ideas…
-don
http://www.peterprovost.org/blog/2012/05/02/kata-the-only-way-to-learn-tdd/ is a great place to start learning TDD.