Re: TDD/BDD and Use cases.
- From: "andrewmcdonagh" <andrewmcdonagh@xxxxxxxxx>
- Date: 30 Jan 2007 15:45:31 -0800
On Jan 30, 11:34 pm, Robert Martin <uncle...@xxxxxxxxxxxxxxxx> wrote:
On 2007-01-29 22:24:18 -0600, "Daniel T." <danie...@xxxxxxxxxxxxx> said:
I just saw Dave Astels' google TechTalk about behavior driven
development [http://preview.tinyurl.com/mx4p2] and I couldn't help but
wonder what connection it has, if any with UML use cases.
I must admit, I am one of the people he talks about who viewed TDD as
more of a verification procedure than a specification procedure, so I
never made the connection before. When I saw his presentation,
especially the method names, I immediately thought about use cases and
how they may relate.
Any thoughts?
I am in the process of preparing a blog on this topic right now. Watchhttp://blog.objectmentor.comover the next day or so.
In short, although BDD is semantically equivalent to TDD (as Moore
state machines are semantically equivalent to Mealy state machines) the
difference in syntax has a profound effect on the way we think. In TDD
we write tests. In BDD we write specifications.
Here, for example, is a partial specification for the (infamous)
BowlingGame. The language is Ruby, and the BDD tool is RSpec.
context "When a gutter game is rolled" do
setup do
@g = Game.new
20.times {...@xxxxxx 0}
end
specify "score should be zero" do
@g.score.should == 0
end
specify "game should be complete" do
@g.complete?.should_be true
end
end
context "When all ones are rolled" do
setup do
@g = Game.new
20.tim...@xxxxxx 1}
end
specify "score should be 20" do
@g.score.should == 20
end
specify "game should be complete" do
@g.complete?.should_be true
end
end
The similarity between these specifications and the usual unit tests
for the BowlingGame is clear. What is not clear is the profound effect
that this subtle difference has on the way we think. We think about
these specifications AS specifications. It's hard to see this in the
BowlingGame, because it's such a small example. But the way we
structure the specs is different from the way we structure tests. That
difference in structure causes a difference in the design of the
application as well. This is something that has to be exerienced to be
understood.
Now, do these specs correspond to use cases? You can see by the
BowlingGame specs above that the correspondence is weak. It would be
strange, for example, to have a "Gutter Game" use case; but it is
natural to have a spec corresond to a gutter game.
Use cases describe the way that a system responds to user gestures.
Specs describe individual system states. Notice how the context of the
spec drives the system into a particular state whose attributes are
then specified. These two kinds of description are related, but I
don't think they are semantically equivalent.
--
Robert C. Martin (Uncle Bob) | email: uncle...@xxxxxxxxxxxxxxxx
Object Mentor Inc. | blog: www.butunclebob.com
The Agile Transition Experts | web: www.objectmentor.com800-338-6716 |
Agreed, and that JUnit 4 uses Annotations instead of looking for
methods called 'test....' and classes no longer need to derive from
'TestCase', it is one step closer to BDD.
Unfortunately though JUnit did need to keep its links with Unit
Testing and so there are still plenty of Test nomenclature....
Andrew
.
- Prev by Date: Re: Booch's book feels too philosophical rather than practical?
- Next by Date: Re: Booch's book feels too philosophical rather than practical?
- Previous by thread: Re: TDD/BDD and Use cases.
- Next by thread: Hot to implement a Scheduler following the requirements...
- Index(es):
Relevant Pages
|
