[rspec-users] thoughts on this?

Ben Mabey ben at benmabey.com
Thu May 28 01:32:09 EDT 2009

Stephen Eley wrote:
> On Wed, May 27, 2009 at 8:19 PM, Matt Wynne <matt at mattwynne.net> wrote:
>> http://robertlally.com/post/bdd-not-so-much
> *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.

> 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 Groups 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 North 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 North on this list about his frustrations over 
misconceptions of what BDD is: 

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? :p


1. http://blog.objectmentor.com/articles/2009/04/13/x-tests-are-not-x-tests

More information about the rspec-users mailing list