[rspec-users] plans for cucumber
David Chelimsky
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
Ashley Moran
On Sep 22, 2008, at 2:52 pm, David Chelimsky wrote:
> 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/
David Chelimsky
<ashley...@patchspace.co.uk> wrote:
>
> On Sep 22, 2008, at 2:52 pm, David Chelimsky wrote:
>
>> 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
This should work right now with both 'rake spec' and 'cucumber features'
Ashley Moran
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.
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.
Brandon Keepers
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).
This is good news.
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 fits into the praise category…
I tried using stories many times, but was never happy with them. They always felt like too much work, too clunky, and not quite complete.
I finally looked into cucumber last week and immediately loved it. Within a couple hours I had several features written for an existing application. By the end of the next day, our whole team was writing cucumber features, and enjoying it! Cucumber seems to have brought back an excitement to testing that I haven't felt for a while (since my first few weeks with RSpec).
As aways, good work!
Brandon
Brandon Keepers
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 agree. I tried nesting too without any luck.
Brandon
aslak hellesoy
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
>
>
David Chelimsky
<ashley...@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
> 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
Chad Humphries
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?
--
Chad
David Chelimsky
<chad.hu...@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
Ashley Moran
On 23 Sep 2008, at 13:44, David Chelimsky wrote:
> 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
DyingToLearn
> Maybe it's worth doing a quick survey of everyone here that uses
> classic/cucumber stories - how *do* you structure your story/feature
> directory?
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