Re: Test Driven Development Workflow

[John M. Dlugosz]

In "TDD" as the latest buzzword methodology, writing the tests first is what it means. Why would you need to do that? Because it substitutes for formal requirements. Perhaps it is a formalization of the "acceptance criteria" in an Agile process. Also, different teams may be writing and performing tests, in contrast to those writing the actual code.

More generally, having "critical test cases" defined as part of the design document doesn't mean you need running code for them. It just helps communicate the design and limitations. Test Cases might actually be Use Cases and communicate how the component will be used and what it's good for.

When doing it all myself, I've found that writing the code and (actual) test code together works well. I'll write the constructors and test them. Write a particular tightly-related group of functions and then test them. Repeat until done.

So ask yourself what needs to exist at what stage in the process, and make sure you have a good reason why. What is your process?

[chromatic]

Why would you need to do that? Because it substitutes for formal requirements.

I don't understand. Why would TDD substitute for formal requirements? Which parts of TDD are incompatible with working with formal requirements?

[John M. Dlugosz]

It's not that TDD is incompatible with having formal requirements. It's that "Agile" Scum/XP etc. refuse to use the "R" word. The role of having requirements needs to be filled by some other means. For example, the Acceptance Criteria written on the back of the Story Card. TDD and Agile are often used together. Without formal requirements going into a large effort (not a single "story" but a full design that will comprise many stories) something has to take the place of the Requirements. That is often the TDD process.

So if you are using pre-written test cases instead of a document of formal requirements, then it's important to do a good job of it and indeed to write them first.