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

[James Byrne]

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.

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.

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.

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.

Libraries and utilities have a different audience and their testing is 
perhaps better handled solely in unit and functional tests, but I cannot 
say so with any conviction.
-- 
Posted via http://www.ruby-forum.com/.