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?

Daniel T. wrote:

> 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.

	Dan North, the guy who cooked BDD up, told me that BDD was started as
a way to teach TDD to novices, what to do, how to get started etc. This
resulted in BDD, so it's more or less a better way to do TDD, so any
connection use cases have with TDD they also have with BDD (IMHO), but
perhaps you should drop Dan a line :) http://dannorth.net

		FB

-- 
------------------------------------------------------------------------
Lead developer of LLBLGen Pro, the productive O/R mapper for .NET
LLBLGen Pro website: http://www.llblgen.com
My .NET blog: http://weblogs.asp.net/fbouma
Microsoft MVP (C#) 
------------------------------------------------------------------------

On Jan 30, 4:24 am, "Daniel T." <danie...@earthlink.net> wrote:
> 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.

Like TDD, BDD is a devlopment best practice. I'd never really 
considered a link between BDD and UML use cases before, but then I 
very rarely use use cases. In fact I can't remember the last time I 
used use cases, 5+ years ago or something.

>
> 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.

BDD is, to a significant extent an exercise in Neuro-Linguistic 
Programming. It tries to shed the test nomenclature of TDD and frame 
our activities in a language that provokes specification oriented 
thoughts as opposed to verification oriented ones.

BDD doesn't, however, specify what happens before we hit the code. 
That's up to the team and the wider process. I'd be interested in 
reading about any experiences you have with Use Cases and BDD.

--
Regards,

Tim Haughton

http://agitek.co.uk
http://blogitek.com/timhaughton

On Jan 30, 4:24 am, "Daniel T." <danie...@earthlink.net> wrote:

> 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.

Like TDD, BDD is a devlopment best practice. I'd never really
considered a link between BDD and UML use cases before, but then I
very rarely use use cases. In fact I can't remember the last time I
used use cases, 5+ years ago or something.

> 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.

BDD is, to a significant extent an exercise in Neuro-Linguistic
Programming. It tries to shed the test nomenclature of TDD and frame
our activities in a language that provokes specification oriented
thoughts as opposed to verification oriented ones.

BDD doesn't, however, specify what happens before we hit the code.
That's up to the team and the wider process. I'd be interested in
reading about any experiences you have with Use Cases and BDD.

--
Regards,

Tim Haughton

http://agitek.co.uk
http://blogitek.com/timhaughton

On Jan 29, 9:24 pm, "Daniel T." <danie...@earthlink.net> wrote:
> 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?

Use cases relate to Executable Acceptance Tests, not to Unit Tests.

There's a disinclination to use Use Cases in the agile community 
because they're seen as being too close to "Big Bang" requirements 
specification. If you try to do evolutionary development of use cases, 
you wind up with something that looks awfully like FIT tests.

I'm mildly surprised that nobody has tried to put the two together. Or 
at least if they have, I haven't heard of it.

You might want to look at FIT:

fit.c2.com
www.fitnesse.org
Fitnesse Yahoo group
Fitlist Yahoo group (may not be active yet)

John Roth

On 2007-01-29 22:24:18 -0600, "Daniel T." <daniel_t@earthlink.net> 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.  Watch 
http://blog.objectmentor.com over 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 {@g.roll 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.times{@g.roll 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: unclebob@objectmentor.com
Object Mentor Inc.� � � � � ��| blog:��www.butunclebob.com
The Agile Transition Experts��| web:���www.objectmentor.com
800-338-6716� � � � � � � � ��|

On Jan 30, 11:34 pm, Robert Martin <uncle...@objectmentor.com> wrote:
> On 2007-01-29 22:24:18 -0600, "Daniel T." <danie...@earthlink.net> 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 {...@g.roll 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...@g.roll 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...@objectmentor.com
> 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

Robert Martin <unclebob@objectmentor.com> wrote:

> 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.

Frans suggested I check out Dan North's blog and I must say I found it 
very interesting. (http://dannorth.net/introducing-bdd/) Especially the 
part headed "BDD provides a 'ubiquitous language' for analysis."

I get the sense that he is thinking something along the lines I am when 
he shows how a "story template" can be broken down into a series of 
"acceptance criteria" that directly translate into BDD specifications. 
Granted he said "story template" rather than "use case" but from how he 
describes story templates I don't see a world of difference.

I recall when I read "Extreme Programming Explained" (Beck) he commented 
on the importance of deriving tests from the customer's perspective. I 
can see where BDD gives more of that sort of sense.

Hi there.

One of my colleagues at ThoughtWorks directed me to this thread, so I
thought it might be useful to describe what I'm trying to achieve with
BDD (and subscribe to the list at the same time :)

It started out in 2003 as a linguistic exercise to make coaching TDD
easier, by changing the vocabulary to focus on behaviour (or
executable specifications) as opposed to writing tests. In the
intervening time, it has grown into a full methodology, incorporating
analysis and testing-as-in-testing (i.e. defining and automating
acceptance criteria in the form of scenarios).

Frameworks like rspec are a great way to express behaviour-based
intent at a code level, and in fact the rspec project was started as a
response to Dave Astels' excellent article on the TDD aspects of BDD.

I've been a bit lax in terms of writing up mine and others'
experiences of BDD "in the large", which was brought home to me when I
presented a session on it at the recent Software Architecture Workshop
in Switzerland.

I'm in the middle of writing up a post on how stories and acceptance
criteria work in the context of BDD, because I think its real
strengths lie in the interactions it defines between analysts,
testers, developers and business folks. We have found on a number of
projects that extending the idea of "behaviour" into the entire
development process - "it's all behaviour" - have  led to some quite
profound changes in the way business and technical people interact.

To get back on topic, a story in BDD terms is more formal and
structured than a traditional XP "promise of a conversation" because
it is expected to do more work. I discovered when I was presenting
this that the way BDD defines a story seems to be quite aligned with
Alistair Cockburn's style of use case (as opposed to the Rational
behemoth version), although possibly a bit more fine-grained and a bit
more structured.

As Bob says, a "specification" has all sorts of system-level
connotations, and a "use case" sounds like a purely business
interaction. In BDD terms, they are both just "behaviour", just at
different levels.

In terms of semantic equivalence, I would say BDD is equivalent to TDD
plus acceptance-test driven planning plus DDD. That's certainly where
I took all my inspiration from (read: got all my ideas) anyway!

I'll hopefully have the blog post out some time next week, which will
explain how a BDD story works. I'll try to make appropriate references
to Alistair's style of use case, although I'll probably end up leaving
it to people who know more about use cases than me.


On Jan 31, 2:35 am, "Daniel T." <danie...@earthlink.net> wrote:
> Robert Martin <uncle...@objectmentor.com> wrote:
> > 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.
>
> Frans suggested I check out Dan North's blog and I must say I found it
> very interesting. (http://dannorth.net/introducing-bdd/) Especially the
> part headed "BDD provides a 'ubiquitous language' for analysis."
>
> I get the sense that he is thinking something along the lines I am when
> he shows how a "story template" can be broken down into a series of
> "acceptance criteria" that directly translate into BDD specifications.
> Granted he said "story template" rather than "use case" but from how he
> describes story templates I don't see a world of difference.
>
> I recall when I read "Extreme Programming Explained" (Beck) he commented
> on the importance of deriving tests from the customer's perspective. I
> can see where BDD gives more of that sort of sense.

"Dan North" <tastapod@gmail.com> wrote:

> One of my colleagues at ThoughtWorks directed me to this thread, so I
> thought it might be useful to describe what I'm trying to achieve with
> BDD (and subscribe to the list at the same time :)
> 
> It started out in 2003 as a linguistic exercise to make coaching TDD
> easier, by changing the vocabulary to focus on behaviour (or
> executable specifications) as opposed to writing tests. In the
> intervening time, it has grown into a full methodology, incorporating
> analysis and testing-as-in-testing (i.e. defining and automating
> acceptance criteria in the form of scenarios).

I seem to recall reading about "acceptance tests" as opposed to "unit 
tests" in that acceptance tests are test specified by the customer 
rather than the developer. They were still executable, but they didn't 
necessarily all have to pass every time. I wish I could remember which 
XP book I read about them in.

How do they figure into this new way of looking at unit testing?

Daniel T. wrote:

> I seem to recall reading about "acceptance tests" as opposed to "unit
> tests" in that acceptance tests are test specified by the customer
> rather than the developer. They were still executable, but they didn't
> necessarily all have to pass every time. I wish I could remember which
> XP book I read about them in.

That was in the original "white book", /XP Explained: Embrace Change/ by 
Kent Beck.

It referred to the specific practices of the C3 project. For example, they 
always integrated by going to a specific integration machine and copying 
their changes in.

The practices have since upgraded to require an integration token (a rubber 
chicken, for example), passed around a team to prevent simultaneous 
integrations. And the rule "customer tests may be fuzzy and may fail" has 
been refined. Once a customer test passes it latches, and its fuzziness 
latches to a given performance level. Developers run it with the suite of 
unit tests, between big edits, and before checking in. If it fails, they 
revert and try again.

-- 
  Phlip
  http://www.greencheese.us/ZeekLand <-- NOT a blog!!! 

"Phlip" <phlipcpp@yahoo.com> wrote:
> Daniel T. wrote:
> 
> > I seem to recall reading about "acceptance tests" as opposed to "unit
> > tests" in that acceptance tests are test specified by the customer
> > rather than the developer. They were still executable, but they didn't
> > necessarily all have to pass every time. I wish I could remember which
> > XP book I read about them in.
> 
> That was in the original "white book", /XP Explained: Embrace Change/ by 
> Kent Beck.
> 
> It referred to the specific practices of the C3 project. For example, they 
> always integrated by going to a specific integration machine and copying 
> their changes in.
> 
> The practices have since upgraded to require an integration token (a rubber 
> chicken, for example), passed around a team to prevent simultaneous 
> integrations. And the rule "customer tests may be fuzzy and may fail" has 
> been refined. Once a customer test passes it latches, and its fuzziness 
> latches to a given performance level. Developers run it with the suite of 
> unit tests, between big edits, and before checking in. If it fails, they 
> revert and try again.

OK, so the question still remains. We have acceptance tests and unit 
tests. As I understand it, acceptance tests check to make sure the 
program performs adequately according to what the customer has 
specified. Now, with BDD I'm being told that the unit tests are 
"specifications". What does that mean for acceptance tests?