On Fri, Aug 23, 2013 at 4:15 AM, Ilya I. [email protected] wrote:
using Cucumber is counterproductive as writing plain English
text and then parsing it with regular expressions is somewhat
overkill and error prone. I think anyone should use Cucumber
only if they have a strong reason to.
Agreed! I usually do my acceptance-level tests in straight Ruby.
(Though with the aid of gems like Capybara and so on for page content
access, click simulation, form filling, etc.) The Cucumber (tempted
to just say Cucu!) way would be to write:
When I build a new large, blue, left-handed veeblefetzer, with a
belt in the back
Then I’d have to create a step definition that has to parse the size,
color, handedness, and/or belting (or lack thereof) of a new
veeblefetzer, with those various things all being optional (else I’d
have to specify them when I don’t care), and look at whether I said
“create” or “build” to tell which it should do. Alternately, a BUNCH
of step defs so they’re not optional but key off the regex being
satisfied. By skipping Cucumber altogether, I can just write a normal
Ruby function call:
This is close enough to plain English that any non-geek should be able
to understand it just fine. I could even make the capitalization
“normal” if they want. Anyway, then I make a normal Ruby function
like “def when_i_make_a_veeblefetzer(options)” and have it parse them
as a plain old hash, getting anything unspecified from a hash of
defaults (such as how this one’s color and handedness don’t matter).
No need to futz around with complex regexes. Usually I can pass most
of the options-hash straight to either FactoryGirl or the class’s .new
method, other than filtering out “save” to determine whether to call
build or create.
My tests may have 99 problems, but maintaining hairy regexes ain’t one.
Dave A., the T. Rex of Codosaurus LLC,
secret-cleared freelance software developer
taking contracts in or near NoVa or remote.
See information at http://www.Codosaur.us/.