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). 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
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/
On Mon, Sep 22, 2008 at 4:51 PM, Ashley Moran <ashley.moran at 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.rbThis should work right now with both ''rake spec'' and ''cucumber features''> > * 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/ > > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users >
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. Ashley -- http://www.patchspace.co.uk/ http://aviewfromafar.net/
On Mon, Sep 22, 2008 at 9:52 AM, David Chelimsky <dchelimsky at gmail.com>wrote:> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/rspec-users/attachments/20080923/3b11a807/attachment-0001.html>
On Tue, Sep 23, 2008 at 5:21 AM, Ashley Moran <ashley.moran at patchspace.co.uk> wrote:> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/rspec-users/attachments/20080923/30baff1a/attachment.html>
On Tue, Sep 23, 2008 at 2:07 PM, Brandon Keepers <brandon at opensoul.org> wrote:> > On Mon, Sep 22, 2008 at 9:52 AM, David Chelimsky <dchelimsky at gmail.com> > wrote: >> >> 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). >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 > > > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users >
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/
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? -- 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 >
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 >
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 -- http://www.patchspace.co.uk/ http://aviewfromafar.net/
Ashley Moran wrote:> 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