Defining BDD

590 views
Skip to first unread message

Johnno Nolan

unread,
Jan 28, 2011, 5:14:12 PM1/28/11
to Behaviour Driven Development
I've been observing the movement of BDD for a while now. (and
implementing aspects) but the whole concept is a teeny bit wooly.
I'm gonna talk about it at my local user group. We're going to try and
define what we think BDD is.

Here are some observations I can think of which I will try and get the
group specify the meaning of.

It's a testing thing,
It's a methodology.
It's given when then
It's all behaviour.
It's feature injection.
It's pull based.
It's outside-in.

Are there anymore observations? Is anything in there that should be
talked about with respect to BDD?
Why is there no definition of BDD, nothing prescriptive?

I want to answer these questions I'm hoping the members of this group
can give me some input to make the session useful.
So if anyone has any input it would be much appreciated.

regards

John[no]

Elizabeth Keogh

unread,
Jan 29, 2011, 5:35:45 AM1/29/11
to behaviordriv...@googlegroups.com
BDD is not primarily a testing thing. You happen to get tests out of
it afterwards, but there's usually still more testing that needs to be
done. It's much more about developing an understanding of what you're
about to produce.

This is at odds with the way in which most people do and think about
BDD, so if you can help me fix that, it would be great.

There is a definition of BDD; it just isn't widely available. Here it is:

“BDD is a 2nd generation, outside-in, pull-based,
multiple-stakeholder, multiple-scale, high-automation, Agile
methodology. It describes a cycle of interactions with well-defined
outputs, resulting in the delivery of working, tested software that
matters.”
- Dan North, 2009

Turns out that the strangest bit of BDD is that phrase,
"well-defined". Actually getting to that - and discovering the bits
you don't know about - is at the heart of BDD. The trouble with using
the word "test" when you do this is that everyone assumes you know
what it is you're testing, which of course, you don't. Hence the
"Given, When, Then" and other language, which help you have the
conversation with stakeholders and find out what's missing.

Except, of course, that there's always things you don't know you don't
know, hence the need for the fast feedback loops, especially
incremental releases.

Here's one of Dan's latest posts on the discovery aspect of BDD
(except it's bigger than BDD):

http://dannorth.net/2010/08/30/introducing-deliberate-discovery/

Hope that helps. If you want something prescriptive, here's some rules
to follow:

- Assume you've got it wrong.
- Have conversations to find out how wrong.
- When you know enough to get feedback on the rest, implement and release.
- Assume you've got it wrong.

If you like, you can use BDD tools to do that 2nd bit, which will
result in some nicely automated scenarios.

Cheers,
Liz.

> --
> You received this message because you are subscribed to the Google Groups "Behaviour Driven Development" group.
> To post to this group, send email to behaviordriv...@googlegroups.com.
> To unsubscribe from this group, send email to behaviordrivendeve...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/behaviordrivendevelopment?hl=en.
>
>

--
Elizabeth Keogh
l...@lunivore.com
http://lizkeogh.com
http://lunivore.com

Hadi Hariri

unread,
Jan 29, 2011, 1:50:56 AM1/29/11
to behaviordriv...@googlegroups.com
It's about communication 



Dan North

unread,
Jan 29, 2011, 11:42:44 AM1/29/11
to behaviordrivendevelopment
Also, this is the prod I needed to finally write up "Defining BDD" as a follow-up to "Introducing BDD." Basically taking that definition that Liz posted and unpacking it.

Turns out I'm better at talking about stuff than writing it down. I'm on it, promise.

Cheers,
Dan

Lee

unread,
Jan 29, 2011, 11:46:12 AM1/29/11
to behaviordriv...@googlegroups.com
I use BDD specs as a "todo list" as I pull requirements, I add items to my list. 

Johnno Nolan

unread,
Jan 29, 2011, 5:32:37 PM1/29/11
to Behaviour Driven Development
> I use BDD specs as a "todo list" as I pull requirements, I add items to my
> list.

I'm glad you said that. I'm looking at using BDD as a great tool for
're-writes'
I've had great success at reverse engineering the code and using RSpec
style 'it shoulds ' to document systems.



On Sat, Jan 29, 2011 at 10:42 AM, Dan North <d...@dannorth.net>
wrote:
> Also, this is the prod I needed to finally write up "Defining BDD"
as a
> follow-up to "Introducing BDD." Basically taking that definition
that Liz
> posted and unpacking it.

> Turns out I'm better at talking about stuff than writing it down.
I'm on
> it, promise.

Trouble is that BDD seems to evolve. Which leads onto Liz's rules

> - Assume you've got it wrong.
> - Have conversations to find out how wrong.
> - When you know enough to get feedback on the rest, implement and release.
> - Assume you've got it wrong.

Also

> >> There is a definition of BDD; it just isn't widely available. Here it is:
>
> >> “BDD is a 2nd generation, outside-in, pull-based,
> >> multiple-stakeholder, multiple-scale, high-automation, Agile
> >> methodology. It describes a cycle of interactions with well-defined
> >> outputs, resulting in the delivery of working, tested software that
> >> matters.”
> >>    - Dan North, 2009

Yup that's on wikipedia. But what exactly does that mean?
There's 7 attributes there that all need elaboration.
And what are the 'cycle of interactions'?


John Nolan

unread,
Jan 29, 2011, 5:56:09 PM1/29/11
to Behaviour Driven Development
Also 

> - Assume you've got it wrong.
> - Have conversations to find out how wrong.
> - When you know enough to get feedback on the rest, implement and release.
> - Assume you've got it wrong.

is going to be the format of my user group talk :P



--

Elizabeth Keogh

unread,
Jan 30, 2011, 12:10:47 PM1/30/11
to behaviordriv...@googlegroups.com
On Sat, Jan 29, 2011 at 3:32 PM, Johnno Nolan <johnn...@gmail.com> wrote:

>> >> There is a definition of BDD; it just isn't widely available. Here it is:
>>
>> >> “BDD is a 2nd generation, outside-in, pull-based,
>> >> multiple-stakeholder, multiple-scale, high-automation, Agile
>> >> methodology. It describes a cycle of interactions with well-defined
>> >> outputs, resulting in the delivery of working, tested software that
>> >> matters.”
>> >>    - Dan North, 2009
>
> Yup that's on wikipedia. But what exactly does that mean?
> There's 7 attributes there that all need elaboration.
> And what are the 'cycle of interactions'?

Here you go. 17 minutes in:

http://skillsmatter.com/podcast/java-jee/how-to-sell-bdd-to-the-business

Cheers,
Liz.

Franz Allan Valencia See

unread,
Jan 31, 2011, 1:44:05 AM1/31/11
to behaviordriv...@googlegroups.com

I am no BDD authority but I've always regarded (and describe to others that) BDD (and ATDD as well) is what TDD was supposed to be.

BDD for me is basically TDD with a reemphasis on the following - you verify behavior and not methods, and you write a "specification" instead of a test script (note: the specs may be implemented as test scripts underneath).

(OT: while ATDD for me is TDD with a reemphasis on writing your automated functional tests as specifications which is written from the start to define what the whole system is supposed to do (ie. Feature, use case, etc) and executed repeatedly until said behavior is implemented (and the bonus as always is that from then on,it acts documentation and regression testing)).

Cheers,
Franz

On 29 Jan 2011 06:23, "Johnno Nolan" <johnn...@gmail.com> wrote:

Dan North

unread,
Jan 31, 2011, 6:11:18 AM1/31/11
to behaviordrivendevelopment
Also

> >> There is a definition of BDD; it just isn't widely available. Here it is:
>
> >> “BDD is a 2nd generation, outside-in, pull-based,
> >> multiple-stakeholder, multiple-scale, high-automation, Agile
> >> methodology. It describes a cycle of interactions with well-defined
> >> outputs, resulting in the delivery of working, tested software that
> >> matters.”
> >>    - Dan North, 2009

Yup that's on wikipedia. But what exactly does that mean?
There's 7 attributes there that all need elaboration.
And what are the 'cycle of interactions'?

So I used to do a 1/2 day tutorial which basically unpacked those two sentences. There's a lot of signal in a very small space there :)

I'm planning to either make the tutorial slide deck available (still undecided about whether it is coherent on its own outside of the tutorial) and/or unpack that definition in an article. I'll probably do both.

Cheers,
Dan

Neel Lakshminarayan

unread,
Jan 31, 2011, 6:30:37 AM1/31/11
to behaviordriv...@googlegroups.com
I felt that BDD is more than TDD. I tried to capture that in this write-up.

http://neelnarayan.blogspot.com/2010/07/bdd-is-more-than-tdd-done-right.html

Neel

--
You received this message because you are subscribed to the Google Groups "Behaviour Driven Development" group.
To post to this group, send email to behaviordriv...@googlegroups.com.
To unsubscribe from this group, send email to behaviordrivendeve...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/behaviordrivendevelopment?hl=en.



--
Twitter:neelnarayan

Dan North

unread,
Jan 31, 2011, 6:56:08 AM1/31/11
to behaviordrivendevelopment
I really like that - that's an excellent write-up.

John Nolan

unread,
Jan 31, 2011, 7:00:42 AM1/31/11
to behaviordriv...@googlegroups.com
Brilliant - that talk is a good start. (thanks Liz)

The question at the end was the one I was asking throughout the talk. "What makes BDD different?"
The one thing that confused me was outside-in was linked to deliberate discovery (we got a definition of that) but we didn't get an outside-in definition.

I understand outside in to be the working in vertical-channels from a stakeholder perspective. From my software developer perspective my brain wires up outside-in to mean. "Start at what the software user uses and work through the application until 'done'."

Dan, your definition of Deliberate Discovery or at least the one I am taking from the talk[1] and blog entry[2], is that we understand from the perspective of the user. Working from the assumptions we have and delving into the stakeholder's domain until we reach a level of ignorance we are comfortable with. Is this the link with outside-in?

John[no]

[1] http://skillsmatter.com/podcast/java-jee/how-to-sell-bdd-to-the-business

--

Wes Williams

unread,
Jan 31, 2011, 10:00:37 AM1/31/11
to behaviordriv...@googlegroups.com
I think this definition leaves out a key piece, we are focusing on collaboration and learning. Having worked on a project that was using 'ATDD', in 2005 I think, we had the same goals then as BDD without the Given When Then language.  

I think the Given When Then language added a lot to help with the common language. My only concern is this is one of those 'best practices' that we use to guide advanced beginners, myself being one of those, and let that hold us back from the real goals, common understanding, increased knowledge (reduced ignorance might be better), and software that matters.

Dan North

unread,
Feb 1, 2011, 11:44:59 AM2/1/11
to behaviordrivendevelopment
Dan, your definition of Deliberate Discovery or at least the one I am taking from the talk[1] and blog entry[2], is that we understand from the perspective of the user. Working from the assumptions we have and delving into the stakeholder's domain until we reach a level of ignorance we are comfortable with. Is this the link with outside-in?

Hi Johnno,

The point of deliberate discovery is that at any point in time you are usually unaware along any number of axes, and that your ignorance of one particular area or fact is your current biggest constraint. (In that if you were armed with that information you would currently be going much faster, and only be constrained by the next thing you don't know about.)

You might be unaware of a technology that could help you go faster or a design that would make the solution simpler, or an important domain construct that ties together two things you've been struggling to understand, or a person in the organisation with tacit knowledge that, if you only knew it, would fundamentally change the way you were approaching this application.

Outside-in is about imagining the as-yet-unwritten app is a black box. You can only describe it in terms of the capabilities it will give its users, maybe in terms of inputs and outputs or the way a user - or another system - will interact with it. From this you can start to derive how it should probably behave in order to give this behaviour. Then you focus on one particular aspect, maybe the area of highest risk (if you're someone like Liz, who likes to get in to the scary stuff early on), or somewhere that looks familiar (if you're still a bit new to this and want to get a feel for how it works), and drill down into each successive layer (or subsystem, or bounded context - pick your metaphor) to see how it delivers capability to the layer above. You automate your understanding of what it should do, and iterate inwards/downwards to make the app meet the automated acceptance criteria. Then you do it again.

Eventually you run out of turtles.

Peter Bell

unread,
Feb 1, 2011, 3:37:38 PM2/1/11
to behaviordriv...@googlegroups.com

On Feb 1, 2011, at 11:44 AM, Dan North wrote:

Outside-in is about imagining the as-yet-unwritten app is a black box. <snip>

Eventually you run out of turtles.


Optimist. 

What if it really is "turtles all the way down"? :)

BTW, loving the "deliberate discovery" content.
 
Best Wishes,
Peter

fatur rahman

unread,
Feb 1, 2011, 9:29:24 PM2/1/11
to behaviordriv...@googlegroups.com
The key principal is in D, Driven.
It's about driving not shooting.

rgds
fatur

Tom Janssens

unread,
Feb 2, 2011, 6:29:02 AM2/2/11
to Behaviour Driven Development
I've made a comparison in the past, it's over on my blog:
http://www.corebvba.be/blog/post/The-advantage-of-using-BDD-over-TDD.aspx

The key points:
- when using BDD, you can start refactoring your app before
implementing it, by refactoring the stories
- once you define the behavior, it usually does not change anymore.
Since BDD tests the behavior and not the implementation (TDD), your
specs will probably never have to be changed.

On 2 feb, 03:29, fatur rahman <mfat...@gmail.com> wrote:
> The key principal is in D, Driven.
> It's about driving not shooting.
>
> rgds
> fatur
>
> On Wed, Feb 2, 2011 at 3:37 AM, Peter Bell <pe...@pbell.com> wrote:
>
> > On Feb 1, 2011, at 11:44 AM, Dan North wrote:
>
> > Outside-in is about imagining the as-yet-unwritten app is a black box.
> >> <snip>
>
> > Eventually you run out of turtles.
>
> > Optimist.
>
> > What if it really is "turtles all the way down"? :)
>
> > BTW, loving the "deliberate discovery" content.
>
> > Best Wishes,
> > Peter
>
> >  --
> > You received this message because you are subscribed to the Google Groups
> > "Behaviour Driven Development" group.
> > To post to this group, send email to
> > behaviordriv...@googlegroups.com.
> > To unsubscribe from this group, send email to
> > behaviordrivendeve...@googlegroups.com<behaviordrivendevelopment%2Bunsu...@googlegroups.com>
> > .

Dan North

unread,
Feb 2, 2011, 12:19:47 PM2/2/11
to behaviordrivendevelopment
I think you can over-think these things.

I'd like to avoid "BDD is better than TDD because..." or even "BDD is different from TDD (as originally envisioned) because..."

TDD is amazing. Its initial conception was to solve exactly what I've been trying to do with BDD. Originally it was described as variable scope (i.e. covering both the space of modern day TDD-in-the-small and what the ATDD/SBE folks are doing in the functional testing space). It's not the only way to come up with good design, and neither is BDD. They're just both useful to have in your back pocket as you go around trying to write decent software to solve useful problems.

The reason I started talking about the behaviour aspects of TDD was because I think it's such an amazing idea, and it was frustrating me that people I was coaching didn't see that, and instead tied themselves in knots trying to understand the complex domain of software testing. Then I realised they thought that understanding testing was some kind of prerequisite to benefiting from TDD, so that's when I tried just removing the word "test" from the conversation altogether.

Liz is spot on when she says BDD is about understanding the customer's need and letting her emerging understanding of that need drive the software she writes (and being able to prove that with an evolving suite of acceptance tests), while always assuming she doesn't quite understand what they want, and therefore always trying to gain greater understanding. But I bet that's what Kent Beck would say if you asked him what TDD was all about.


To unsubscribe from this group, send email to behaviordrivendeve...@googlegroups.com.

Rick DeNatale

unread,
Feb 2, 2011, 3:34:30 PM2/2/11
to behaviordriv...@googlegroups.com
On Wed, Feb 2, 2011 at 12:19 PM, Dan North <d...@dannorth.net> wrote:
> The reason I started talking about the behaviour aspects of TDD was
> because I think it's such an amazing idea, and it was frustrating me that
> people I was coaching didn't see that, and instead tied themselves in knots
> trying to understand the complex domain of software testing. Then I realised
> they thought that understanding testing was some kind of prerequisite to
> benefiting from TDD, so that's when I tried just removing the word "test"
> from the conversation altogether.
> Liz is spot on when she says BDD is about understanding the customer's need
> and letting her emerging understanding of that need drive the software she
> writes (and being able to prove that with an evolving suite of acceptance
> tests), while always assuming she doesn't quite understand what they want,
> and therefore always trying to gain greater understanding. But I bet that's
> what Kent Beck would say if you asked him what TDD was all about.

Yes, some folks seem to immediately grasp that test's in TDD really
are specifications rather than tests. Other's can't let go of their
preconceived notions about the temporal relationship between code and
tests, the separation of testers and coders, etc. etc.

And some of us, particularly those who have been doing TDD, whatever
we called it, for decades (many of us old 1st generation Smalltalkers)
realize that TDD is about a much broader scope than unit testing.

Terminology can have subtle effects. Erich Gamma used to talk about
how Kent "Test Infected" him.

And the fact that sUNIT, begat jUNIT begat Test::UNIT etc. tends to
reinforce a narrow view of where xUnit tools are useful. I recently
listened to a podcast where Kent was talking about JUnit and JUnit
max, and talked about using it in a variety of levels. I'm sure that
Kent himself didn't hear the discontinuity, but as someone who has
experienced trying to get others around that mental block I did.

And all that said, I find the flavor of specs written in Rspec to feel
a little higher level, more like specifications, and less like tests
than the same thing expressed in xUnit style.


--
Rick DeNatale

Blog: http://talklikeaduck.denhaven2.com/
Github: http://github.com/rubyredrick
Twitter: @RickDeNatale
WWR: http://www.workingwithrails.com/person/9021-rick-denatale
LinkedIn: http://www.linkedin.com/in/rickdenatale

Adam Sroka

unread,
Feb 2, 2011, 4:01:54 PM2/2/11
to behaviordriv...@googlegroups.com
On Wed, Feb 2, 2011 at 12:34 PM, Rick DeNatale <rick.d...@gmail.com> wrote:
> On Wed, Feb 2, 2011 at 12:19 PM, Dan North <d...@dannorth.net> wrote:
>> The reason I started talking about the behaviour aspects of TDD was
>> because I think it's such an amazing idea, and it was frustrating me that
>> people I was coaching didn't see that, and instead tied themselves in knots
>> trying to understand the complex domain of software testing. Then I realised
>> they thought that understanding testing was some kind of prerequisite to
>> benefiting from TDD, so that's when I tried just removing the word "test"
>> from the conversation altogether.
>> Liz is spot on when she says BDD is about understanding the customer's need
>> and letting her emerging understanding of that need drive the software she
>> writes (and being able to prove that with an evolving suite of acceptance
>> tests), while always assuming she doesn't quite understand what they want,
>> and therefore always trying to gain greater understanding. But I bet that's
>> what Kent Beck would say if you asked him what TDD was all about.
>
> Yes, some folks seem to immediately grasp that test's in TDD really
> are specifications rather than tests. Other's can't let go of their
> preconceived notions about the temporal relationship between code and
> tests, the separation of testers and coders, etc. etc.
>

yes...

> And some of us, particularly those who have been doing TDD, whatever
> we called it, for decades (many of us old 1st generation Smalltalkers)
> realize that TDD is about a much broader scope than unit testing.
>

and yes. Thank you, that was very well put.

> Terminology can have subtle effects. Erich Gamma used to talk about
> how Kent "Test Infected" him.
>
> And the fact that sUNIT, begat jUNIT begat Test::UNIT etc. tends to
> reinforce a narrow view of where xUnit tools are useful. I recently
> listened to a podcast where Kent was talking about JUnit and JUnit
> max, and talked about using it in a variety of levels. I'm sure that
> Kent himself didn't hear the discontinuity, but as someone who has
> experienced trying to get others around that mental block I did.
>

Anyone who hasn't already should check out the videos Kent did for the
Pragmatic Programmers:
http://pragprog.com/screencasts/v-kbtdd/test-driven-development
Even after doing TDD myself for over ten years now I was surprised at
some of what he does. And, you get to watch Kent code for nearly two
hours (feels like less, probably because he's explaining what he is
doing the whole time.) You can't beat $20 for that. Some of us spent a
lot more to go see him at conferences in the early days and probably
got less out of it.

> And all that said, I find the flavor of specs written in Rspec to feel
> a little higher level, more like specifications, and less like tests
> than the same thing expressed in xUnit style.
>

Over the last couple years I have done a lot of JUnit, some NUnit,
some RSpec, and a smattering of other things. TDDing Java and C# feel
very similar 80% of the time, and 20% of the time they really don't.
Ruby always feels very different. I have often wondered whether it
feels different because of the way I use RSpec or because it is Ruby.
I'm still not convinced either way, so I believe it must be a bit of
both. I never used Test::Unit (I did use the Perl equivalent for a few
years.) I learned Ruby using TDD/BDD and RSpec circa 2004 and have
never done Ruby any other way.

That said, I do agree that typical RSpecs feel a bit higher level than
typical xUnits, but I'm not convinced that that is more because of the
design of RSpec and not because of the design of Ruby. Ruby code, in
general, feels higher level to me, because Ruby makes it so easy to go
meta and leave the details hidden.

Rick DeNatale

unread,
Feb 2, 2011, 10:08:49 PM2/2/11
to behaviordriv...@googlegroups.com
On Wed, Feb 2, 2011 at 4:01 PM, Adam Sroka <adam....@gmail.com> wrote:
> Over the last couple years I have done a lot of JUnit, some NUnit,
> some RSpec, and a smattering of other things. TDDing Java and C# feel
> very similar 80% of the time, and 20% of the time they really don't.
> Ruby always feels very different. I have often wondered whether it
> feels different because of the way I use RSpec or because it is Ruby.

IMHO, a lot of it is due to the difference between statically typed
and dynamically typed languages. A few observations here:

1. When I read Michael Feather's "Legacy Code" book, I was struck by
how much of it dealt with fighting the static features of the language
(either Java or C++).
This also relates to Ward Cunningham's observation that it's a
good thing that Java IDEs have good support for refactoring, because
you have to do it so much
frequently in a statically typed language than in a dynamically
typed one, just to keep the type hierarchies under control. I'd say
there's a heavier interest rate
charge for technical debt in the regime of static typing.

2. Many of other patterns used in statically typed languages are
either changed subtly or drastically; or unnecessary in dynamically
typed languages: IOC/DI I'm looking at you.
http://weblog.jamisbuck.org/2007/7/29/net-ssh-revisited
http://weblog.jamisbuck.org/2008/11/9/legos-play-doh-and-programming

Adam Sroka

unread,
Feb 2, 2011, 10:43:02 PM2/2/11
to behaviordriv...@googlegroups.com
On Wed, Feb 2, 2011 at 7:08 PM, Rick DeNatale <rick.d...@gmail.com> wrote:
> On Wed, Feb 2, 2011 at 4:01 PM, Adam Sroka <adam....@gmail.com> wrote:
>> Over the last couple years I have done a lot of JUnit, some NUnit,
>> some RSpec, and a smattering of other things. TDDing Java and C# feel
>> very similar 80% of the time, and 20% of the time they really don't.
>> Ruby always feels very different. I have often wondered whether it
>> feels different because of the way I use RSpec or because it is Ruby.
>
> IMHO, a lot of it is due to the difference between statically typed
> and dynamically typed languages.

Yes, but there is more to it than that I think. I used Perl and Python
years before I discovered Ruby and they both feel a lot different than
it too. I also play with other languages whenever I can, usually just
for toy problems, but I can't think of anything that compares
favorably to Ruby + RSpec. At least not with respect to how seamlessly
and effortlessly an experienced coder can move from one level of
abstraction to the next. I have heard that Smalltalk does compare, but
I don't have any meaningful experience with it (Toy problems, as I
said.)

A few observations here:
>
>  1. When I read Michael Feather's "Legacy Code" book, I was struck by
> how much of it dealt with fighting the static features of the language
> (either Java or C++).

Yes. Most legacy code today is probably Java. Next to that it's
probably C++ or some other Microsoft thing. The vast majority of it is
statically typed though there are notable exceptions.

>     This also relates to Ward Cunningham's observation that it's a
> good thing that Java IDEs have good support for refactoring, because
> you have to do it so much
>     frequently in a statically typed language than in a dynamically
> typed one, just to keep the type hierarchies under control.  I'd say
> there's a heavier interest rate
>     charge for technical debt in the regime of static typing.
>

I wasn't aware of that quote, but it makes a lot of sense to me.

>  2. Many of other patterns used in statically typed languages are
> either changed subtly or drastically; or unnecessary in dynamically
> typed languages: IOC/DI I'm looking at you.
>     http://weblog.jamisbuck.org/2007/7/29/net-ssh-revisited
>     http://weblog.jamisbuck.org/2008/11/9/legos-play-doh-and-programming
>

Yes. Many patterns either avoid flaws in the language design or the
framework/library design. Even things that aren't so much patterns as
idioms or "syntactic sugar" fall into the category. Ruby has its
share, but it is relatively elegant.

Greg Young

unread,
Feb 2, 2011, 10:47:50 PM2/2/11
to behaviordriv...@googlegroups.com
How many of these problems with static languages were because the
static "metadata" weren't actually being used?

http://codebetter.com/gregyoung/2008/05/18/revenge-of-the-statically-typed-languages/

> --
> You received this message because you are subscribed to the Google Groups "Behaviour Driven Development" group.
> To post to this group, send email to behaviordriv...@googlegroups.com.
> To unsubscribe from this group, send email to behaviordrivendeve...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/behaviordrivendevelopment?hl=en.
>
>

--
Les erreurs de grammaire et de syntaxe ont été incluses pour m'assurer
de votre attention

Dan North

unread,
Feb 3, 2011, 6:02:52 AM2/3/11
to behaviordrivendevelopment
 2. Many of other patterns used in statically typed languages are
either changed subtly or drastically; or unnecessary in dynamically
typed languages: IOC/DI I'm looking at you.
    http://weblog.jamisbuck.org/2007/7/29/net-ssh-revisited
    http://weblog.jamisbuck.org/2008/11/9/legos-play-doh-and-programming

Amen to that.

When the picocontainer guys wrote the first cut of pico (a java ioc container) in about 2004, I thought I'd take a stab in ruby too, as an excuse to learn the language. I got feature parity with their container in about a couple of days (mostly learning ruby!), then I abandoned it on the grounds that a) it didn't seem like the kind of problem in ruby that you would bother firing up an ioc container for, and b) I was embarrassed at how small the codebase was.

It's interesting that no-one has seen the need to implement an ioc container for ruby since.

Cheers,
Dan
--

Jeff Sussna

unread,
May 12, 2011, 5:29:32 PM5/12/11
to behaviordriv...@googlegroups.com
How about this:

"BDD is a language for expressing desired or expected behavior at multiple levels in a way that all concerned parties can understand and execute against."

1. A language: I know that BDD can be expressed in various dialects, but the point is that it's a linguistic exercise. It's not fundamentally about wiki's or diagrams; it's about phrases and sentences.

2. Multiple levels: can be used all the way from high-level feature description to unit tests.

3. Concerned parties: at the feature level, the concerned parties are users, developers, testers, tech writers, etc. At the unit test level, concerned parties are developers and testers.

4. Understand and execute against: not only can testers understand the intent of a requirement, they directly generate a test from it.

In addition to tearing apart my premise, feel free to help me get rid of the dangling preposition :-).

Jeff

Andrew Premdas

unread,
May 12, 2011, 7:28:03 PM5/12/11
to behaviordriv...@googlegroups.com
On 12 May 2011 22:29, Jeff Sussna <j...@ingineering.it> wrote:
How about this:

"BDD is a language for expressing desired or expected behavior at multiple levels in a way that all concerned parties can understand and execute against."

BDD is a process not a language. One of the products of this process are bits of language that specify behaviour.
 
1. A language: I know that BDD can be expressed in various dialects, but the point is that it's a linguistic exercise. It's not fundamentally about wiki's or diagrams; it's about phrases and sentences.

No its much more than a linguistic exercise, its about development as well as specification, if you stop at the specification and don't continue into the development you'll never produce anything.
 
2. Multiple levels: can be used all the way from high-level feature description to unit tests.

Because its development it has to go through unit tests to the writing of code, and most importantly iterate rapidly. 

3. Concerned parties: at the feature level, the concerned parties are users, developers, testers, tech writers, etc. At the unit test level, concerned parties are developers and testers.

I would argue in BDD that there is no distinction between developers and testers, testers are developers and developers are testers. If you separate the activiities (and worse still the people doing the activities) then you are not doing BDD.
 
4. Understand and execute against: not only can testers understand the intent of a requirement, they directly generate a test from it.

BDD is not about producing requirements, its not about creating tests, its about developing hence Behaviour Driven DEVELOPMENT.
 
In addition to tearing apart my premise, feel free to help me get rid of the dangling preposition :-).

Jeff

Of course all this is IMO - feel free to tear back!

All best

Andrew 

--
You received this message because you are subscribed to the Google Groups "Behaviour Driven Development" group.
To post to this group, send email to behaviordriv...@googlegroups.com.
To unsubscribe from this group, send email to behaviordrivendeve...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/behaviordrivendevelopment?hl=en.



--
------------------------
Andrew Premdas

Jeff Sussna

unread,
May 13, 2011, 11:31:31 AM5/13/11
to Behaviour Driven Development
Except for the bit about testers and developers, I think we're in
violent agreement. Perhaps I should have said "BDD is centered around
a language". Yes, it's a process, but any process needs something to
hang its hat on. Otherwise it risks becoming meaningless, like ITIL.
In my experience, people start to grok BDD and get excited about, not
when you describe the process, but when you describe the language.

I completely agree it has to go all the way to development. Didn't
mean to imply otherwise. Just meant to say that you can use it to talk
about high-level things as well as low-level things. Also meant to use
testers as an example of those who need to execute based on the
desired behavior, not a prescriptive list. The fact that you can
generate test case stubs directly from Given-Then-When clauses is just
one example of "minimum cognitive distance".

I would actually say BDD has to go PAST development. Creating a
relevant and high-quality executable doesn't actually provide any
business value, unless you can deliver that value to the customer.
Product management, documentation writers, support folks all need to
participate. It would be interesting to explore generating release
notes directly from G-W-T clauses. So maybe we should call it
"Behavior-Driven Delivery".

Re "no distinction between testers and developers": at the risk of
consigning myself to the re-education camp, I'm sorry, I just don't
buy this one. Let's just say that I've never participated in a
development project where the presence or introduction of dedicated
testing people did not improve quality, both in terms of code
robustness and in terms of business value/relevance. I certainly agree
that over-the-wall relationships between test and dev are futile, and
that the two roles must be completely integrated and cheek-to-jowl in
terms of team participation.

Jeff

Andrew Premdas

unread,
May 13, 2011, 4:50:03 PM5/13/11
to behaviordriv...@googlegroups.com
On 13 May 2011 16:31, Jeff Sussna <j...@ingineering.it> wrote:
Except for the bit about testers and developers, I think we're in
violent agreement. Perhaps I should have said "BDD is centered around
a language". Yes, it's a process, but any process needs something to
hang its hat on. Otherwise it risks becoming meaningless, like ITIL.
In my experience, people start to grok BDD and get excited about, not
when you describe the process, but when you describe the language.

I completely agree it has to go all the way to development. Didn't
mean to imply otherwise. Just meant to say that you can use it to talk
about high-level things as well as low-level things. Also meant to use
testers as an example of those who need to execute based on the
desired behavior, not a prescriptive list. The fact that you can
generate test case stubs directly from Given-Then-When clauses is just
one example of "minimum cognitive distance".

I would actually say BDD has to go PAST development. Creating a
relevant and high-quality executable doesn't actually provide any
business value, unless you can deliver that value to the customer.
Product management, documentation writers, support folks all need to
participate. It would be interesting to explore generating release
notes directly from G-W-T clauses. So maybe we should call it
"Behavior-Driven Delivery".

Well I think its fair to say that development implies delivery. The most important point is that delivery must be frequent and must produce feedback, so we can iterate rapidly.
 
Re "no distinction between testers and developers": at the risk of
consigning myself to the re-education camp, I'm sorry, I just don't
buy this one. Let's just say that I've never participated in a
development project where the presence or introduction of dedicated
testing people did not improve quality, both in terms of code
robustness and in terms of business value/relevance. I certainly agree
that over-the-wall relationships between test and dev are futile, and
that the two roles must be completely integrated and cheek-to-jowl in
terms of team participation.

There is a difference between running a software project and doing BDD.  A well run BDD project will produce quality in code and business relevance. It may well be that a dedicated testers can add to this. Whether they can do this in a cost effective and timely manner will be highly project dependent. However all this has little to do with BDD. My point is that when you are doing BDD there should be no distinction between testers and developers. If you want to do other things as well as BDD, on your project well thats your choice.

All best

Andrew

Tom Janssens

unread,
May 16, 2011, 10:53:31 AM5/16/11
to behaviordriv...@googlegroups.com
Ok, here is my take, while we're at it ;-)

BDD is the lowest common denominator between business experts and application developers by which we can express the business value of application behavior using example specifications.

Thinking about this and typing this took me about 15 seconds, but acquiring this knwloedge took me a few years ;-)
Reply all
Reply to author
Forward
0 new messages