What design models to create before TDD?

Question

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?

Answer 1

I, personally, don't think my design documentation would change with TDD versus another mode of development. I'd start with the high level Use Cases and slowly work down until I have very specific functional Use Case documents (along with all the other accompanying documentation like Class Diagrams, Activity Diagrams, etc.).

Once you have those White Box Use Cases...you should know two things:

1. What the code should do.
2. What the code SHOULDN'T do.

You can then code your application to do the things it should...and code your tests to make sure that it doesn't do the things it shouldn't.

Answer 2

TDD shouldn't rely on fixed model and diagrams, otherwise you limit or break its process of refactoring.

So if you really need models, I would use some high level diagrams like sequence diagrams to ilustrate your app's navigation (which have less chance of changing than your class diagram).

Another point is that high level artifacts can help your customer on creating test routines to validate your system's functions.

Answer 3

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.

Answer 4

Since you need to generate some documentation that you don't think anyone really cares about, you should think about what will really help your development team:

• In the Domain Driven Design mode, create some documents that show your fundamental model objects. Do what you can to get unclear concepts ironed out and terminology agreed upon. Both these problems cause "waste" in the development cycle, whether it's TDD or not.

• Discuss where the greatest risks are for the projects. Are there some diagrams, and the discussions that will precede and follow them, that can help mitigate these risks?

• (I made this one up) Design a basic set of "fixture data" for your test. What is the minimal set of data that captures all the important relationships and cases? This is a non-traditional artifact, so you probably don't already have this. But it will take a while to develop. Once you have it, it will speed-up your test writing, and it may actually have the side-effect of being a useful communication document. I made a mini poster of our fixture data on our last project to ease writing tests.