| [epf-dev] Another Unpublished Capability Pattern - Design Solution no TDD |
|
hiho, There was another side topic of discussion about how strict
OpenUP treats a certain aspect of the process. And that is, does the process
“enforce” TDD. Version 0.9 of the process had the work on developer tests
going on in parallel with the implementation of the solution. Then there
was Concept: Test-first Design promoting the technique. The default version 1.0 has a very explicit TDD workflow in
the Capability Pattern: Develop Solution. A Guideline: Test-first Design
was also added to give more detail on the technique. There has been discussion that some places just adopting
agile techniques might not have the tool support and habits that work with
TDD. Do we want to have the process so explicitly prescribing the technique
that someone will look at it and say “well, I don’t see myself
working that way, so I guess it is not the process for me”? With that in mind, I created a Capability Pattern with the
element name develop_solution_no_tdd. Each version of the Develop
Solution Increment capability pattern has an overview of the workflow in the Main
Description. The default one has very explicit TDD verbiage along the
lines of “The tests are run up front and, in failing,
clearly define the criteria to determine if the implementation works as
intended.” The non-TDD one is more casual saying “Once
the organization of the technical solution is clear, the development and
testing of the implementation ensues.” Like the Iteration Template described in a previous message,
this non-default CP is in the repository and not in the default published
site. But it supports the notion that OpenUP promotes TDD and that is the
preferred way to build software, but it is not enforced such that non-TDD implementation
should be characterized as “not doing OpenUP”. I am distinctly out on a limb here and I welcome feedback. Even if we agree that there should be a non-enforced-TDD
version of this capability pattern, I think my first draft needs work.
Below I have pasted the standard 1.0 version of the workflow and then my
non-TDD one. As you can see, the default one has benefited from some good
work by Jim Ruehlin stressing that the design can be revisited for refactoring once
the tests pass. That nuance is lost on my crappy version.
----------------- b Current drafty Non-TDD version
Standard develop_solution
|
