On Tue, Sep 23, 2008 at 7:53 AM, Chad Humphries
<[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> wrote:
>> On Tue, Sep 23, 2008 at 4:21 AM, Ashley Moran
>> <[EMAIL PROTECTED]> 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@rubyforge.org
>> http://rubyforge.org/mailman/listinfo/rspec-users
>>
> _______________________________________________
> rspec-users mailing list
> rspec-users@rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>
_______________________________________________
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
