Brent Snook wrote:
the internals in more detail).
Hi, I think this is the most used approach nowadays, high level testing
features and more specific testing, that end users don’t care about at
spec level. However, I prefer the distinction between, declarative
and imperative stories, which I think can be applied to these two levels
For example, the end user or the business person, most probably gets
of reading a very long imperative story of clicking links and filling
forms, plus other setup steps that might seem unnecessary to him, but
needed sometimes due to a not fully correct design. Whilst a developer
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
(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
time, and seem like a great place to use variables inside step
Other cases are more complex and the use of regular expressions to
encapsulate them all, can certainly be very difficult, maybe the type of
attribute is a datetime and needs to be parsed, thus not being
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.
where the argument continues, people support the view of writing
specs considering that they are clearer. I still have doubts about
In my opinion this will certainly be a complex problem to solve, but
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
The hardest problem seems to be agreeing on a language to write the
including minimal variations in the syntax and grammar of our steps, to
able to come up with a re-usable set of step definitions out-of-the-box,
set of steps that will allow us to write stories and jump straight to
failing nature of a step, due to it not being implemented, once its
implemented the step will be passing, without further need to write
step definitions. This would be a great time saver and allow us to
concentrate on harder problems very specific to our application that are
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
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
mocks is also unrefutable, but only as an alternative to an inability
test something in a classical way
View this message in context:
Sent from the rspec-users mailing list archive at Nabble.com.