[rspec-users] [Cucumber, BDD] When not to use Cucumber?

Ben Mabey ben at benmabey.com
Sat Jan 24 12:12:20 EST 2009


See comments inline...

On 1/23/09 1:46 PM, James Byrne wrote:
> Ben Mabey wrote:
>
>    
>> So... I'm curious what people's thoughts are.  When writing acceptance
>> tests how do you choose which tool is best for the job?  I often hear
>> people complaining about the GWT syntax and they see no benefit of it
>> over the frameworks that provide contexts (i.e rspec, shoulda, etc).[1]
>> In what cases, if any, do you think the GWT gets in the way and how?  In
>> particular, if you are writing an app or lib whose customers/users are
>> all developers do you still think there is value in the GWT syntax that
>> Cucumber provides?
>>
>>      
>
> My own experience is quite limited, but I did start out trying to get
> what I desired done through TestUnit, then RSpec, then RSpec Story
> Runner and finally Cucumber. In the end it was Cucumber that clarified
> my approach for me, mainly by clearing away all (or at least most) of
> the nitty gritty details of configuring and using the tool itself.  I
> found that, coming from a non OO programming background, that the degree
> of mastery required of the other tools mentioned, together with the
> effort I had to make to get the tool to behave as I wished (desires that
> were often malformed by lack of understanding in any case), distracted
> considerably from the task at hand, programming the application.
>    

Interesting, thanks for sharing what your background is.  I have seen 
other developers who don't have a strong OO background struggle with the 
concepts of isolation have a really hard time understanding how and why 
to use rspec.  However, they seem to love Cucumber and it makes total 
sense to them.
> I have progressed on my current project far, far more since discovering
> Cucumber this past November than in all the time before.  The
> bifurcation between what and how seems far more natural to me with the
> Cucumber features/step definitions file split than with the unified
> expectation method/test steps of RSpec and the test method/assert
> statements of TestUnit.  Cucumber feature files just seem to permit one
> to concentrate solely on "what" in the one case and then, with the
> separate step definitions file, deal with the "how" in the other,
> without crossing the line between the two.
>    

Ahh.. that is a very good observation.  When I write examples in rspec I 
start out with the example description first (obviously) but then I like 
to jump straight to my expectation.  Meaning, I will say something like 
"dog.should be_happy" before I have even created the dog object.  I like 
to do this for the same reason- I first write what I want and then I go 
a line above and create the how/given.  A lot of people complain about 
the separation of code form story in plaintext features, but as you have 
pointed out that separation can be a very good thing.
> Given, When and Then seemed contrived and far too stiff to me to begin
> with.  However, I discovered that much of my initial discomfort arose
> from too vague a conception of what is was that was desired.  The
> benefit of GWT stylistic conventions is that it really does make one
> consider deeply where one is starting from, what one is actually trying
> to accomplish, and how, exactly, does one tell if it has been
> accomplished.
>    
> If this sort of self-analysis is so ingrained that one need not think of
> it then GWT probably does not provide a measurable benefit.  So, perhaps
> deeply experienced developers and programmers might not get as much from
> it as I have.
>
> On the other hand, I have frequently discovered in myself a lamentable
> tendency to believe that I understood what a problem was simply because
> I wanted to believe and not because of any demonstrable evidence to that
> effect. Sitting down and writing out what you believe to be the truth
> often reveals the flaws in ones assumptions.  The GWT litany seems to
> provide a very useful, if formulaic, examination of exactly what one is
> setting out to accomplish thereby sometimes raising the question of why
> it needs to be done at all.  I find that it thereby clears away much
> that is irrelevant to the question at hand.
>    

+1.  I totally agree with this.  When it is difficult for me to write 
scenarios I find that the reason is that I fail to really understand 
what I am trying to accomplish.  By flushing the acceptance criteria out 
in the GWT language I come out with a much better understanding of the 
problem and know exactly where to begin.
> I also hold to the opinion that when writing an end user application the
> only testing that can be consider definitive is what is described as
> integration or acceptance testing.  I accept that there are pragmatic
> reasons why, because of limited time and equipment resources, unit and
> functional tests are viewed as attractive alternatives.  But, that
> should not blind one the the fact that they really are alternatives,
> chosen because of environmental considerations and not because of
> inherent superiority.  The only test that means anything to an end user
> is one that shows the application works as intended in the environment
> it is deployed to.
>    

So here is where I disagree with you. :)  I do agree that all the user 
cares about in the end is that the desired outcome is reached and the 
business value is provided.  So with that mindset features are the only 
kind of tests a customer really cares about.  Unit tests however are 
more for the developer.  They aid in design and provide much more 
detailed documentation than the customer testes (acceptance tests).  I 
don't think that cucumber features help me design my objects that much 
better unless I have focused object level examples telling me where the 
pain points are in my design.  Eventually the customer will be greatful 
that you have unit tests (even if they don't know about them) because 
they will help lower the maintenace of the project by encouraging better 
design and providing tighter and more focused feedback on the smaller 
parts of the system.  IMHO, of course.


Thanks for the feedback,
Ben


More information about the rspec-users mailing list