http://robertlally.com/post/bdd-not-so-much
Matt W.
On Wed, May 27, 2009 at 8:19 PM, Matt W. [email protected] wrote:
shrug
I think he’s being too literal and missing the substance of the
practice by criticizing its veneer. I personally don’t use BDD as a
path to customer communication; in the majority of my projects I’m the
primary ‘customer,’ so it’s to help me think, not somebody else.
I also don’t use “should” in my specs. I don’t care about
should-vs.-assert. I use active, immediate language. My failure to
use “should” doesn’t make my specs any less functional, and as I’m not
required to submit them to any BDD experts for grading, no one
suffers.
For that matter, I’ve never found that the semantic argument about
“What is BDD?” vs. “What is TDD?” has ever made any practical
difference to my code. I like RSpec because it helps me think in
English about what I’m going to do before I do it. So does Cucumber.
Both are better at different sorts of problems. The mental model of
coding practice that they facilitate is useful to me and makes better
code. I really don’t care what anyone calls it.
I also don’t understand his apparent assumption that using a
“structured textual format” for functional specs means it’s the only
thing one uses. Sometimes I make diagrams to understand my design
thoughts better. Sometimes I do mind maps. Sometimes I write long
rambling blog posts (http://tinyurl.com/d6w4t8). And I still use
RSpec and Cucumber. They’re not exclusive of each other. They’re all
useful. They all shine different lights on the same cave wall.
Finally, and most relevant: I personally don’t understand vodka. It
doesn’t taste like anything to me. I do not accept that a vodka
martini is truly a martini. It will never work for me, and I tell my
friends frequently that their ‘martini’ is a misuse of the word and
that they can’t possibly like what they’re drinking.
I am, of course, wrong. This could be really obnoxious of me,
except… Well, who cares? While I’m babbling on, they’ve got a
martini in their hand and they’re enjoying it. Thus, they win.
–
Have Fun,
Steve E. ([email protected])
ESCAPE POD - The Science Fiction Podcast Magazine
http://www.escapepod.org
Stephen E. wrote:
On Wed, May 27, 2009 at 8:19 PM, Matt W. [email protected] wrote:
shrug
I’ll add a sigh as well…
Robert says his “problem is with the definition of BDD itself”. He
points out that no one can really agree on what BDD is exactly, which is
true to a certain extent. However, he then makes arguments against BDD
using his poor understanding of it.
snip
For that matter, I’ve never found that the semantic argument about
“What is BDD?” vs. “What is TDD?” has ever made any practical
difference to my code. …
I think Robert makes valid observations. If you ask anyone on this list
what BDD is you will get different answers even though we are a very
homogeneous bunch when it comes to the tools we use. ( I think Steve
just illustrated this point. 
) Now, if you ask people on the BDD
Google G. list you will get far different answers and people will
have a hard time agreeing on terminology. I think this, more than
anything, is what Robert is frustrated about. BDD has changed and
evolved over the years and people are at different stages of
understanding it. It is hard to pin down what an idea is when it is
evolving and being fine tuned. Additionally, like Steve pointed out, it
can mean different things in different contexts. Despite this being a
valid observation he makes the wrong conclusion that this confusion over
what IS BDD is a bad thing and therefore means “BDD isn’t AN answer.” I
think this line points out his flawed logic the best:
“So what is the output of BDD: User Acceptance Tests? Functional Tests?
Unit Tests? System Tests? A system design? The design of individual
units? It depends on who you talk to.”
Well… guess what, this exact things applies to TDD:
“So what is the output of TDD: User Acceptance Tests? Functional Tests?
Unit Tests? System Tests? A system design? The design of individual
units? It depends on who you talk to.”
You can ask people on the TDD list what TDD is and guess what- you will
get different answers!! So, by Robert’s logic TDD isn’t AN answer
either. This reminds me of the recent TDD tests are not unit tests
debacle. I think Michael Feathers summed up the controversy pretty
well[1]. In the end you have to realize, and accept, that people will
have different ideas and terminology about the same practice. That
doesn’t invalidate the practice though.
I also don’t understand his apparent assumption that using a
“structured textual format” for functional specs means it’s the only
thing one uses. Sometimes I make diagrams to understand my design
thoughts better. Sometimes I do mind maps. Sometimes I write long
rambling blog posts (http://tinyurl.com/d6w4t8). And I still use
RSpec and Cucumber. They’re not exclusive of each other. They’re all
useful. They all shine different lights on the same cave wall.
I picked up on this as well, and this goes back to my statement about
him making arguments against BDD with a poor definition of it. Robert
seems to have the misconception that as BDD has evolved different ways
of writing tests that these ways are mutually exclusive. From what I can
gather he seems to think that one must phrase all of your tests as
customer facing tests when using Cucumber, and you are not allowed to
use RSpec or Test::Unit at all. From his post:
"TDD, as a design methodology, forces you to write code that is used by
two different clients: the tests and the final application. This is one
of the ways that it helps promote flexibility. It gives you an early
look at ‘how exactly am I going to use this class/object’. BDD
frameworks don’t look or work like the code that will be calling the
final code, so there really is no benefit here. Take easyb as an
example, it doesn’t even use the same language as the code you’re
writing (assuming the common use case of using easyb as a BDD framework
for Java development).
TDD highlights pain points when writing tests, if it is hard to write a
test for, your code probably needs a little work. BDD frameworks such as
Cucumber, can quite happily support specs written in terms of ‘the
system’ or ‘the application’ and you have to write grotesque code to
make it work under the covers. This doesn’t make Cucumber a bad tool,
just the wrong tool for the job of designing code."
He has very good points about how TDD is a design methodology, but he is
misinformed about the use of BDD tools in this regard. I view RSpec as
my design tool to be used in the exact way he as described. Why do you
think we are calling them “code examples”?!? I agree with him about
Cucumber not being fit for a design tool on that kind of level. I don’t
see Cucumber providing me the same type of detailed design cues that I
get from RSpec. However, Cucumber helps me make sure that I am only
designing (with RSpec) code that actually needs to be designed. It helps
me write software, not code or as Dan N. likes to say “software that
matters”. Can you do the same thing with an xUnit framework with high
level acceptance tests? Sure you can, but those tests won’t be nearly as
nice of a communication tool to the customers or, IMO, provide as good
of application level documentation.
Anyways… that is my take on it. I would also recommend reading this
post from Dan N. on this list about his frustrations over
misconceptions of what BDD is:
http://rubyforge.org/pipermail/rspec-users/2008-February/005696.html
I’m hoping that the publication of The RSpec Book will help with these
types of misconceptions. It has in it, IMO, the culmination of a lot of
thinking behind what BDD is and will be a great reference to point
people to who are grappling with understanding BDD regardless of
programming language. Maybe we should send Robert a free copy to help
educate him? 
-Ben
http://blog.objectmentor.com/articles/2009/04/13/x-tests-are-not-x-tests
On Wed, May 27, 2009 at 8:19 PM, Matt W. [email protected] wrote:
My response was too long, I just posted to my blog.
http://www.continuousthinking.com/2009/5/28/bdd-not-so-much-really
I’m serious about the book club though.
–
Zach D.
http://www.continuousthinking.com (personal)
http://www.mutuallyhuman.com (hire me)
http://ideafoundry.info/behavior-driven-development (first rate BDD
training)
@zachdennis (twitter)
On 28 May 2009, at 06:32, Ben M. wrote:
I’ll add a sigh as well…
when it is evolving and being fine tuned. Additionally, like Steve
Well… guess what, this exact things applies to TDD:
people will have different ideas and terminology about the same"TDD, as a design methodology, forces you to write code that is used
write a test for, your code probably needs a little work. BDD
Why do you think we are calling them “code examples”?!? I agree with-Ben
This is brilliant, Ben. Please blog it for posterity.
My response was a bit more practical:
http://blog.mattwynne.net/2009/05/28/bdd-joy-in-10-easy-steps/
rspec-users mailing list
[email protected]
http://rubyforge.org/mailman/listinfo/rspec-users
Matt W.