Tests In The Spec Before Code?

connie

原文链接：http://blogs.msdn.com/micahel/ar ... SpecBeforeCode.aspx


A Diligent Reader writes:

A co-worker and I are having a bit a disagreement that I feel your talents may shed some light on.

We're currently writing an engineering design document which includes a high-level & low-level design of a software component. On completion, this design document is then handed off to another developer (or possibly the same one who wrote the document) to code the design. We've agreed to do a form of TDD where the developer who is coding the design will write the test code before writing any of the component code. We disagree on whether or not to include the high-level & low-level design of the test code in the design document.

My opinion is that the test code is an end product, we need to be clear that the application code is testable upfront, & that we need to know what the tests will/should cover. His opinion is that such information does not need to be included in the design document because it is up to the developer who will be writing the application code to determine what tests to write & how.

Have you ever come across a similar issue? If so, what do you recommend? Thanx.

First off, this isn't TDD. With TDD you write a failing test, write just enough code to make the test pass, then repeat. TDD is all about letting the tests guide the code you write, which in turn affects the tests you write.

Which is not to say their plan of action is a bad idea. It's just not TDD.

I definitely agree that test code is an end product, and that testability needs to be built in to the application from the start. I also agree that knowing what the tests will cover before starting coding is a Very Good Thing.

However, I think the details of the unit tests should be up to the person writing the code. Even if you really do manage to define class details down to the smallest detail (which is usually more trouble than it's worth), once coding actually starts guaranteed things will need to change. The coder needs the freedom to modify the unit tests as necessary to keep up with the code (and vice versa).

What the tests should cover, however, is different than what the tests actually do and how they do it. "What happens when I...?" questions certainly could be part of the design document. In fact, ours are integrated into the feature specification right alongside the other details about the feature.

I also feel compelled to ask whether this team has considered a more agile approach. I find that working in small chunks using just-in-time design works best for me. Many other people and teams have found the same to be true for them as well. I encourage them to look into Agile Programming (http://www.agilealliance.com/) if they haven't already done so.