[rspec-users] plans for cucumber

David Chelimsky dchelimsky at gmail.com
Tue Sep 23 08:58:23 EDT 2008


On Tue, Sep 23, 2008 at 7:53 AM, Chad Humphries
<chad.humphries at gmail.com> wrote:
> I have one question outside of rspec land in regards to cucumber.
> I've used it with test unit, test spec, and rspec without issue.
> Will it still be a relatively easy require to use on projects  outside
> of rspec?  More specifically, is the plan to have it replace story
> runner within rspec, or to replace it and stay a separate gem?

For exactly the reasons you cite, as of now, the plan is to extract
story runner to its own gem and keep cucumber a separate gem.

David

> --
> Chad
>
> On Tue, Sep 23, 2008 at 8:44 AM, David Chelimsky <dchelimsky at gmail.com> wrote:
>> 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/
>> _______________________________________________
>> rspec-users mailing list
>> rspec-users at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/rspec-users
>>
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>


More information about the rspec-users mailing list