[
Lists Home |
Date Index |
Thread Index
]
On Fri, 2004-02-20 at 16:21, Hunsberger, Peter wrote:
> Henrik Martensson <henrik.martensson@bostream.nu> writes:
>
<snip>
> >
> > There is a problem that _may_ crop up with use-case driven
> > development: it does not emphasize testing enough. (My
> > personal opinion, and I don't expect anyone else to buy it
> > right off the bat. Also, it depends on who is doing the
> > use-case driven development, of course.)
>
> Ok, I'll bite: I disagree. Part of the rational (at least our rational)
> for doing use cases is to document what the test case results should be.
This sounds like a good thing to me, regardless of whether the use-cases
or the tests drive the design.
> This may be dependant on who's doing the teaching, but I've always
> encountered an emphasis on test case driven development associated with
> use case driven design. There are test driven methodologies where the
> emphasis is even stronger, but I think those are associated more with
> physical models and implementation than with requirements and design
> modeling?
We may attach slightly different meanings to the terms "use-case driven"
and "test driven". (then again, maybe we don't.) I hope I don't botch
the following definitions too much:
When I think of test-driven methodologies I think foremost of Extreme
Programming, where the tests truly shape the design of the software.
Because the tests are automated, and are written before the code, they
ensure that the code is written in such a manner as to be testable. The
stories that XP use are a simplified, very informal kind of use-cases.
The stories don't directly shape the design, though they are of course
vitally important in capturing requirements.
RUP on the other hand, is use-case driven, at least by default. (RUP can
be used for test driven design too, but this is uncommon.) When you
design in RUP, you start with the use-cases. Usually you model visually,
using UML diagrams, and translate the use cases into a software design.
Depending on the particular RUP implementation, tools like GRASP
patterns may play a part here. Tests aren't written until after the code
has been written though, so they do not influence the design in the same
way, and they are not necessarily automated at all.
Working with a use-case driven methodology does not enforce any kind of
testing at all. On the other hand, test-driven methodologies do. (Well,
at least as long as everyone sticks to the agreement. I've been a bit
burned there recently...)
> >
> > However, this is not the same thing as saying there is a
> > problem with use-cases. Use-cases are a great tool and in
> > most cases they capture requirements much better than
> > traditional requirement specifications.
> >
> > Personally, I am rather strongly in favor of test driven
> > methodologies, and i consider use-cases an essential tool in
> > my methodology toolkit.
>
> There you go; two different tools, two different purposes...
Exactly. And the purpose of use-cases is slightly different depending on
whether the approach is use-case driven or test-driven. Which only goes
to prove that use-cases are flexible enough to be useful with more than
one approach to design issues.
<snip>
/Henrik
|
