[rspec-users] thoughts on this?

Matt Wynne matt at mattwynne.net
Thu May 28 03:41:04 EDT 2009

On 28 May 2009, at 06:32, Ben Mabey wrote:

> 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.
> *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 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: 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? :p
> -Ben

This is brilliant, Ben. Please blog it for posterity.

My response was a bit more practical:

> 1. http://blog.objectmentor.com/articles/2009/04/13/x-tests-are-not-x-tests
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users

Matt Wynne

More information about the rspec-users mailing list