What design models to create before TDD

modelingtdduse-case

Summary:

What models and diagrams have you included and/or delivered in your TD -design vs -development, and why?

Details:

New 4-developer project, in a shop where we're gradually making progress in getting management to graduate from "buy in" to "action" in the TDD adoption/expectation. I'm (a developer) wanting test-driven design for the new project. Management's willing to allow test-driven development — after some models and diagrams are created (these will complement UI mockups to convey detailed design to the customer before significant development begins).

So, given that context, what models and diagrams would you consider reasonable? This project's deliverable is a webapp which is neither trivial nor overly complex. We have a requirements document (vague at times, but a good start for writing tests against).

But the TDD experience I've had so far (one very-low-defect project I solo'd w/ TDD, and some design-maturing peer test authoring here and there) leaves me wanting to proceed next to test-driven design.

The process of creating the models/diagrams (it's looking like we'll deliver some class models and a few high-level use cases and sequence diagrams) seems to give us (developers) no design insight that TDD wouldn't, and they're technical/complex enough that I fear any non-developer will effectively ignore them (read: blindly accept them) when they're presented them.

Where do you draw the line between including and excluding models and diagrams in TD -design vs -development?

Best Answer

There is a military saying: "Plans are nothing, planning is everything." If the diagrams create a useful communication with customer about how the system design is envisioned, and what areas it is intended to encompass and how it will proceed, then the practice of planning is worthwhile.

What TDD suggests is that that design be subject to change when the rubber meets the road on coding. The question is how important it will be to communicate those changes back when they happen. But in complex architectures, some up front planning is valuable, even in the context of TDD, as long as you realize that is planning, not fixed plans. The thinking that lead to the original design is something that can be referenced to understand what the TDD has discovered and how things need to change to accommodate it.

Afterwards, you can look back and point out to management how much the final product differed from the up-front planning and see what changed, and perhaps be able to point out that nailing down design early on didn't contribute as much as they thought.

Related Topic