Back in May, when I was just getting started on my current team, we had an instructor in to do most of a week training on Java, with the last couple of days devoted to TDD training. As the Java training progressed, I wrote down some thoughts in the process of trying to define what success would look like for the TDD portion — what would make us happy?
Here are some of the things I was thinking, that week in May…
I’d like to spend more time on best practices and figuring out how to really tie these practices to day-to-day reality, and less on a description of the basic process.
- What differences are there when using TDD for modifying existing code versus writing new code?
- Where does writing acceptance tests/integration tests fit in? Is this outside the red, green, refactor cycle? Invite the instructor to take a look at our architecture and give him an overview of the kind of testing we’ve done so far… hear his thoughts on holes or weaknesses, inefficiencies, in our testing strategy?
- How to maintain the discipline to do TDD in the face of deadlines/schedule pressure – Is pair programming a good way of dealing with this? How do you answer for the apparent inefficiency of “two people working on one thing”?
- How does the “refactor” phase interact with the concept of code ownership? Should anybody be able to commit any code, because this is needed to support refactoring? Or are some restrictions wise? What effects has the instructor seen in shops that have code ownership controls versus shops that don’t? (My feeling is that the concept of code ownership can tend to work mightily against a clean, well-factored system and that we should rely on the tests to show if a refactoring has broken something… I’d like to know if there are other aspects of the issue that I’m not seeing though)
- How do you mesh up-front architectural analysis with TDD well? James Coplien is vocal about the importance of this:
I’ve seen a lot of Agile projects crash and burn after about their third external iteration for lack of good architectural foundations. It doesn’t take much architecture to shape the whole — just enough to keep Conway’s Law happy and to lay a foundation for the interface — but it takes much more than Ron Jeffrie’s fabled “ten minutes of design.” Maybe a sprint’s worth is enough to get started.
- Martin Fowler sees value in some architectural analysis too:
“So my advice is to begin by assessing what the likely architecture is. If you see a large amount of data with multiple users, go ahead and use a database from day 1. If you see complex business logic, put in a domain model. However in deference to the gods of YAGNI, when in doubt err on the side of simplicity. Also be ready to simplify your architecture as soon as you see that part of the architecture isn’t adding anything.”
Could be helpful
- An instructor-demoed example showing a large refactoring performed TDD-style (in Agile Java the big refactorings were where I had more trouble seeing how to use TDD and I started making a bunch of changes while I had a red bar, not knowing how long it would take to get back to a stable state or if I was going down a dead end)
- Another such exercise that’s hands-on, where we practice doing a large refactoring (perhaps in groups of twos)
Other Undefined Expectations
- How much hands-on TDD experience do we wish for? Or, is actually doing it during class not what we want? (for some in the class, they’ve never done it and it could be a really powerful experience to actually do it… but then others of us have….)