Getting over the TDD hump
Chad mentioned that the first 2 hours of TDD are the hardest. Without a good pair by your side, the pain can stretch well beyond a couple of hours. Maybe I had a rare experience, but my first experience with TDD was successful and had very few bumps. Looking back, I don’t know what exactly we did right, but maybe the whole story might put things in focus.
Step 1: Gettin’ my learn on
I hear a lot of questions about how to do TDD, what exactly TDD means and how it works. Well, there’s a whole book on it. If you’re done with that one and you have more questions, well there’s this one that fills in the gaps.
I had read a lot on blogs about TDD, but let’s be honest. Blogs are great about focusing on a single topic, or a short introduction, but they don’t pull everything together in a single physical medium. There are very few writers quite as clear and concise as Kent Beck, the author of the original book. So if you hear any arguments about what TDD is, check out the original source. It’s very clearly defined. Without reading Kent Beck’s book, we were merely guessing on what TDD actually looked like.
Step 2: Team buy-in
Many of us in the team looked at XP and liked its values, principles and practices. Another Kent Beck book laid out in clear terms what some good values are, and the value of agreeing on values. Teams have values, implicit, de facto, or explicit. Our team agreed to have some explicit values (feedback, communication, courage, etc.) and take time on regular occasions to reflect on whether we adhered to our values.
We were pretty lucky that everyone on our team had an open mind, but then again, that’s who we tried to hire. We valued passion and open-mindedness to years of experience. And in that case, we were successful. Everyone agreed to try TDD, but no one mandated it. We all agreed that people had success with it and we were capable of success, so there was really nothing stopping each of us from trying except for fear. That’s where our “courage” value kicked in.
Step 3: A gentle introduction
We would have seriously crashed and burned if we tried to introduce ourselves to TDD against our existing legacy codebase. Nothing in our existing product was testable by any stretch of the imagination, and it seemed like that if we wanted to sneeze we needed the database up. In Kent Beck’s book, he introduces TDD in a pairing session tackling a simple problem, a bowling game.
Our team agreed to do something similar, and practice TDD on a simple problem. We decided the board game, “Connect Four” had simple enough rules for us to complete the game in a day. There were no rules for our practice except:
- We must program in pairs
- Code must be written test-first
We had no constraints on the interface of the game. My pair decided to use arrays and console output for the game, while other pairs went for a visual, WinForms experience.
At the end of the day, we got back together for a retrospective and compared code and tests. We also talked about what went well and didn’t go well, and what we could have done better. Finally, we all agreed we had a lot of fun doing it and wanted to have that much fun developing against our real-life codebase.
And they’re off
The bell sounded and the horses were out of the gates. From that point forward, the bulk of our work was done test-first style. We weren’t great at first, but that wasn’t the point. We had committed as a team to give TDD a fair shot, and our codebase thanked us for it. When we started, we had zero unit tests and we ended a year later with well over a thousand. At first we would have little “woo hoos” when we hit milestones at the hundreds. As our velocity increased, we only celebrated hitting 1000.
Along the way, we had many questions answered simply through practice. We tried different styles, stumbled through many smells. Through our dedication to constant feedback and communication, we drove through any barriers we had. If there was a wrong way to do things, we found it.
But since we committed as a team to work together to improve ourselves (and deliver more value more often), the journey was far easier than it would have been flying solo.