As you’ve no doubt heard from another blog post/email/coworker if your an employee here at SEP, we’re beginning some TDD Study Groups here at SEP. One of the goals of the TDD Study Groups is to have some visible output from each of the groups, so we can spread some information further than just those in our meetings. As a result, you’ll be seeing more posts like this one in the weeks to come. I’m playing role of recorder for our group, so I’ll be doing my best to separate the results of the group from my own opinions (by making separate posts with different titles).
I know some of the other team members are planning to make some public posts about their experiences/opinions on the material, so expect some updates with links to their posts as they become available.
Background
As a bit of background info, we’ve split up all those interested into groups based on technology known, in our case ASP.NET MVC. Since we’re all on the same billable project team, our discussion tends, not only towards how we can improve our own development skills and how TDD is/isn’t the way to do this, but also towards the implications this has towards our project as a whole. With that in mind, let’s get down to what we did and felt about our first of six weeks of TDD Study groups.
Homework
Our “homework” for week one was to do some readings related to TDD/unit testing – listed below, and we decided coming to the meeting with our own personal goals/desires from TDD would help us get more out of our study groups, as well as discovering what’s stopping us from using TDD today.
Our Goals
- Apply TDD to Legacy Environment
- General TDD Crash Course
- New Way of Thinking/Getting Feedback
What’s Stopping You from Using TDD Today?
- Slow Build Time
- Slow Test Spin Up Time
Readings
- Fowler TestDrivenDevelopment
- Uncle Bob’s 3 Rules
- InfoQ article critiquing Uncle Bob on the applicability of TDD
- A discussion of where TDD is applicable, from Uncle Bob
- Unit Testing on Wikipedia
- Why Learning TDD Is Hard
Reading Discussion
When is doing the dumbest thing possible the right thing?
Some members suggested that things like making a method return a constant value really doesn’t provide any value, since the result is clearly wrong for any input other than this one. However, as one group member suggested, in cases where the desired equation is unknown, having a starting value, and working outwards handling more and more cases – refactoring a number into an equation. Making the tests drive to a proper implementation each step of the way.
How Important is it to see the test fail first?
Well, if you’re writing a test that you expect to fail, and it passes – you’re probably writing a bad test. Either that, or you’ve taken your previous implementation beyond the requirements of the previous test.
Programming Practice
The second hour of our session was spent practicing TDD from developed stories – in our case, a stockroom application that allows multiple locations, bins and a separate collection of items per bin. The last few minutes were devoted to discussing what we learned in the exercises for the day.
Note that since we didn’t complete the selected stories for the day, we didn’t take a lot of time to discuss lessons learned.
Lessons Learned
Pair Programming vs. Side-by-Side Programming
One of the key concepts that comes with TDD is the idea of Pair Programming. In our example, we found that the discussion on the abstractions being implemented were the most valuable, though we imagined that more of a side-by-side programming approach where we discussed only the parts we felt most warranted discussion would be more valuable – allowing the ‘navigating’ developer to provide a second pair of eyes when the ‘driver’ really does need some input.
(Rhyming) Quote of the Week
Pairing is a tool not a rule. – RMN
