Let's make this official. We're planning to replace the RSpec Story
Runner with Cucumber. The rspec-1.1.5 release will still include the
Story Runner (several fixes since the last release). So if you're not
already using stories and you want to start, start with cucumber
(http://github.com/aslakhellesoy/cucumber).
For those of you already using stories, we're going to take steps to
make this as simple as possible.
1. We're going to do one more release with things as they are
currently structured (with Story Runner as part of the gem/plugin).
2. Aslak has posted the current migration path at
http://github.com/aslakhellesoy/cucumber/wikis/migration-from-rspec-stories
and we'll work to make it simpler if we can.
3. Story Runner will be released as a separate gem/plugin that you are
free to use, however we're not putting any additional development
effort into it once cucumber is released. It will be up on github and
anyone who wishes to use/maintain it is free to do so.
Feel free to respond with questions/concerns (praise is welcome too!).
We're really excited about Cucumber and all the benefits it brings
(see http://blog.davidchelimsky.net/2008/9/22/cucumber), and we want
to make the transition as easy as we can for the pioneers among you
who are already using stories.
Cheers,
David
_______________________________________________
rspec-users mailing list
rspec...@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
> Feel free to respond with questions/concerns (praise is welcome too!).
> We're really excited about Cucumber and all the benefits it brings
> (see http://blog.davidchelimsky.net/2008/9/22/cucumber), and we want
> to make the transition as easy as we can for the pioneers among you
> who are already using stories.
I'm using Cucumber quite happily, I think it's great it's going into
RSpec
I'd like to make a suggestion about the file layout though, I prefer
this structure:
project/
features/
descriptions*/
xyz.feature
steps/
xyz.rb
* I'm open to better suggestions
I think that's a bit more symmetrical than having steps one level
below features.
WDYT?
Ashley
--
http://www.patchspace.co.uk/
http://aviewfromafar.net/
This should work right now with both 'rake spec' and 'cucumber features'
> 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.
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.
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.
Hey all,
Let's make this official. We're planning to replace the RSpec Story
Runner with Cucumber. The rspec-1.1.5 release will still include the
Story Runner (several fixes since the last release). So if you're not
already using stories and you want to start, start with cucumber
(http://github.com/aslakhellesoy/cucumber).
Feel free to respond with questions/concerns (praise is welcome too!).
We're really excited about Cucumber and all the benefits it brings
(see http://blog.davidchelimsky.net/2008/9/22/cucumber), and we want
to make the transition as easy as we can for the pioneers among you
who are already using stories.
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.
Wow - thanks Brandon!
Let me know if you want it removed from here:
http://github.com/aslakhellesoy/cucumber/wikis/home
Aslak
> As aways, good work!
>
> Brandon
>
>
"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
--
Chad
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
> 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?
Hi David
I think some sort of feature->step file matching would be good.
Kyle's system[1] of "stories/stories/feature/topic.story" expanding to
"feature, topic, feature/topic" works well as a default I think. (I
just like the way the story command works, I guess I'm kinda hoping
the cucumber tool will work as a drop-in replacement.)
> 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.
Doesn't seem a huge leap to go to
features/
descriptions/
reservations/
schedules/
supplies/
steps/
support/
;o)
Although I agree, it shouldn't be forced on anyone.
Maybe it's worth doing a quick survey of everyone here that uses
classic/cucumber stories - how *do* you structure your story/feature
directory?
Ashley
[1] http://github.com/pd/story/tree/master
I'd have to *vote* for the current way cucumber lays out the
directoroy structure. However, I am happy to change my ways if the
community decides it should change.
Just my 2 cents