Is CCDD part of TDD?
Does test-driven development (TDD) entail what I'd like to call client-code driven development (CCDD)? Sells contrasted them in 2004, while admitting that what he called "client-driven development" (confusingly, since it more readily labels something else) may just be a degenerate case of TDD. Yesterday, Box noted what a good thing Sells's approach is. I agree.
Although CCDD -- which, in ad hoc form, must be just about as old as programming itself -- doesn't seem to be referenced explicitly in some common overviews of TDD, I find that in practice TDD entails CCDD.
In TDD, the software engineer follows this recipe for success:
1) write test A for a requirement
2) run test A, see it fail
3) implement production code
4) run test A, see it pass
5) go to 1, proceeding to test B
This appears simpliciter to define a fail-safe process for writing code. But if this is all you've got, as soon as you start, big questions arise about how to proceed that this recipe does not address. The rub is that step #1 assumes a test of something specific -- but what? Oftentimes, for me, the target production code is some method, but how was it chosen? The tests for method Foo() may drive the implementation of Foo(), but they cannot drive the need for Foo().
A wider scope is needed to choose which Foo() and which Bar() to create when and where. In a sense, one can stay true to the TDD dogma and say that higher-level tests -- ultimately, the user tests for stories and requirements -- have the necessary scope to drive all narrower decisions. My point is that, in practice, the meat of this process entails writing, over and over again, client-code calls to code that doesn't exist yet -- which forks a sub-process for the software engineer: these tendered client-code calls are the proximate causes of dependent units of code, whose implementations will be driven by their own tests.
In effect, tests will drive an implementation, which itself often "drives" the need for more code and thus more tests. CCDD is an intrinsic part of TDD.
Although CCDD -- which, in ad hoc form, must be just about as old as programming itself -- doesn't seem to be referenced explicitly in some common overviews of TDD, I find that in practice TDD entails CCDD.
In TDD, the software engineer follows this recipe for success:
1) write test A for a requirement
2) run test A, see it fail
3) implement production code
4) run test A, see it pass
5) go to 1, proceeding to test B
This appears simpliciter to define a fail-safe process for writing code. But if this is all you've got, as soon as you start, big questions arise about how to proceed that this recipe does not address. The rub is that step #1 assumes a test of something specific -- but what? Oftentimes, for me, the target production code is some method, but how was it chosen? The tests for method Foo() may drive the implementation of Foo(), but they cannot drive the need for Foo().
A wider scope is needed to choose which Foo() and which Bar() to create when and where. In a sense, one can stay true to the TDD dogma and say that higher-level tests -- ultimately, the user tests for stories and requirements -- have the necessary scope to drive all narrower decisions. My point is that, in practice, the meat of this process entails writing, over and over again, client-code calls to code that doesn't exist yet -- which forks a sub-process for the software engineer: these tendered client-code calls are the proximate causes of dependent units of code, whose implementations will be driven by their own tests.
In effect, tests will drive an implementation, which itself often "drives" the need for more code and thus more tests. CCDD is an intrinsic part of TDD.
Labels: software
posted by Brad Williams @ 10:33 AM
0 Comments:
Post a Comment
Subscribe to Post Comments [Atom]
<< Home