[rspec-users] plans for cucumber

David Chelimsky
2008-09-23T12:44:14Z

On Tue, Sep 23, 2008 at 4:21 AM, Ashley Moran
<ashley.moran at patchspace.co.uk> wrote:
>
> On 23 Sep 2008, at 02:35, David Chelimsky wrote:
>
>> This should work right now with both ''rake spec'' and
''cucumber features''
>
> It does, but only as "cucumber features" if I do "cucumber
> features/descriptions/xyz.feature" it doesn''t find the the
step file on it''s
> own.

"the step file" assumes a one to one mapping of feature files to step
files. I tend to reuse steps across features, so this has little value
for me, personally. I think it is a constraint that might serve some
people''s needs well, but not everybody''s.

> Ben''s TextMate Cucumber bundle reflects this, as it''s
"go to alternate file"
> command creates steps one level down from the descriptions.
>
> Kyle''s "story" command uses the structure
stories/stories and stories/steps
> so I''m used to working that way.

While I appreciate that some people like to work this way, I don''t
think everyone does and I don''t think cucumber should be enforcing
conventions based on this.

What I think *would* make sense is to offer up some
configuration/mapping scheme that allows you to manage this in a
number of different ways.

For example, we could add something like autotest uses - if a
.cucumber file exists it gets loaded before anything else, and it can
be used to describe mappings as autotest does:

Autotest.add_hook :initialize do |at|
  at.add_mapping %r%features/(.*).feature% do |filename, match|
    at.files_matching %r%features/#{match}.rb
  end
end

Something along those lines could help satisfy everyone''s needs, no?
WDYT?

> My stories folder always had extra dirs, so I find the layout:
>  features/
>    descriptions/
>      apply.feature
>      open.feature
>      start.feature
>      stop.feature
>      zoom.feature
>    matchers/
>    steps/
>    support/
>
> MUCH easier to follow than:
>  features/
>    apply.feature
>    matchers/
>    open.feature
>    start.feature
>    steps/
>    stop.feature
>    support/
>    zoom.feature
>
> This is just how I use it anyway - maybe I''m alone in adding extra
folders
> like that.  But I still find the nested structure much more logical than
the
> partially flat one.

I see where you''re coming from in terms of visibility. I tend to use
something like this:

features/
  reservations/
  schedules/
  steps/
  supplies/
  support/

Admittedly, steps and support are not like reservations, schedules and
supplies, but this has worked just fine for me so far.

FWIW,
David

>
> Ashley
>
> --
> http://www.patchspace.co.uk/
> http://aviewfromafar.net/