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

voodoorai2000 voodoorai2000 at gmail.com
Sat Jan 24 07:02:33 EST 2009




Brent Snook wrote:
> 
> My current recipe for testing spread is to automate the acceptance
> scenarios
> using a tool like story runner/cucumber and then use specs for targeted
> integration and unit level testing. The automated acceptance scenarios
> cover
> the main scenarios that the customer cares about while more specialised
> cases (or more technical aspects) are covered at the spec level. The specs
> will typically gravitate towards the white box end of the scale
> (describing
> the internals in more detail).
> 


Hi, I think this is the most used approach nowadays, high level testing with
features and more specific testing, that end users don't care about at the
spec level.  However, I prefer the distinction between, declarative stories
and imperative stories, which I think can be applied to these two levels
also.

For example, the end user or the business person, most probably gets bored
of reading a very long imperative story of clicking links and filling out
forms, plus other setup steps that might seem unnecessary to him, but are
needed sometimes due to a not fully correct design. Whilst a developer will
appreciate an imperative story as it tells him/her exactly what to do.

In my opinion, even at the spec level we can use the philosophy behind steps
(re-usability) to reduce the redundancies inherent to spec definitions. 
Trivial cases of you should see this in the page (view specs), or this
object should have this attribute set to true (model specs), happen all the
time, and seem like a great place to use variables inside step definitions.  

Other cases are more complex and the use of regular expressions to
encapsulate them all, can certainly be very difficult, maybe the type of an
attribute is a datetime and needs to be parsed, thus not being completely
re-usable to say a boolean field. 

Still we could account for this variations by checking the type of the
attribute, at the expense of increasing the complexity of the step.  This is
where the argument continues, people support the view of writing repetitive
specs considering that they are clearer.  I still have doubts about this. 
In my opinion this will certainly be a complex problem to solve, but once we
tackle it a number of times, it will become trivial, we'll figure out an
elegant step_helper to deal with this situations, and move on to the next
hard problem.

The hardest problem seems to be agreeing on a language to write the stories
including minimal variations in the syntax and grammar of our steps, to be
able to come up with a re-usable set of step definitions out-of-the-box, a
set of steps that will allow us to write stories and jump straight to the
failing nature of a step, due to it not being implemented, once its
implemented the step will be passing, without further need to write trivial
step definitions.  This would be a great time saver and allow us to
concentrate on harder problems very specific to our application that are not
accounted for in the general step definitions.

In conclusion, when not to use cucumber? never.  Always use cucumber,
everyone always use cucumber, lets find this hard problems to re-use steps
and tackle them together, find a solution and move on to the next
road-blocker.  Use Rspec but as the underlying language to make cucumber
work, not to divide your application into model view controller specs,
separate your tests into user and developer features/steps.  
Distributed testing is a must to use cucumber effectively, and the use of
mocks is also unrefutable[1], but only as an alternative to an inability to
test something in a classical way[2] 

Rai

[1]http://rubyconf2008.confreaks.com/testing-heresies.html
[2]http://martinfowler.com/articles/mocksArentStubs.html


-- 
View this message in context: http://www.nabble.com/-Cucumber%2C-BDD--When-not-to-use-Cucumber--tp21628693p21639914.html
Sent from the rspec-users mailing list archive at Nabble.com.



More information about the rspec-users mailing list