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
--
>> >> 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.
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
Also
Yup that's on wikipedia. But what exactly does that mean?
> >> 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
There's 7 attributes there that all need elaboration.
And what are the 'cycle of interactions'?
--
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.
--
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?
Outside-in is about imagining the as-yet-unwritten app is a black box. <snip>
Eventually you run out of turtles.
To unsubscribe from this group, send email to behaviordrivendeve...@googlegroups.com.
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
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.
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
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.
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
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
--
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
--
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
--
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.
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.