From aslak.hellesoy at gmail.com Thu Aug 7 14:26:04 2008 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Thu, 7 Aug 2008 14:26:04 -0400 Subject: [rspec-devel] [ANN] Cucumber Message-ID: <8d961d900808071126q12071a0s354f4554a569ffbd@mail.gmail.com> Nice vegetable, nice tool. It's my reimplementation of the story runner, addressing several shortcomings of the current one. And I'm calling them features instead of stories now, because that is what they are. http://github.com/aslakhellesoy/cucumber/ (The home page) http://gojko.net/2008/08/06/cucumber-next-generation-ruby-bdd-tool/ (Thanks Gojko) Take a look - it's taking shape. Aslak From aslak.hellesoy at gmail.com Fri Aug 8 09:58:59 2008 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Fri, 8 Aug 2008 09:58:59 -0400 Subject: [rspec-devel] [ANN] Cucumber In-Reply-To: <8d961d900808071126q12071a0s354f4554a569ffbd@mail.gmail.com> References: <8d961d900808071126q12071a0s354f4554a569ffbd@mail.gmail.com> Message-ID: <8d961d900808080658x6644e902oa6957a1dcf7ac93b@mail.gmail.com> I have pushed some updates to the documentation. Especially Rails instructions (which describe Cucumber generators) should be useful for some of you. Aslak On Thu, Aug 7, 2008 at 2:26 PM, aslak hellesoy wrote: > Nice vegetable, nice tool. > > It's my reimplementation of the story runner, addressing several > shortcomings of the current one. And I'm calling them features instead > of stories now, because that is what they are. > > http://github.com/aslakhellesoy/cucumber/ (The home page) > http://gojko.net/2008/08/06/cucumber-next-generation-ruby-bdd-tool/ > (Thanks Gojko) > > Take a look - it's taking shape. > > Aslak > From deanwampler at gmail.com Fri Aug 8 11:48:34 2008 From: deanwampler at gmail.com (Dean Wampler) Date: Fri, 8 Aug 2008 10:48:34 -0500 Subject: [rspec-devel] [ANN] Cucumber In-Reply-To: <8d961d900808080658x6644e902oa6957a1dcf7ac93b@mail.gmail.com> References: <8d961d900808071126q12071a0s354f4554a569ffbd@mail.gmail.com> <8d961d900808080658x6644e902oa6957a1dcf7ac93b@mail.gmail.com> Message-ID: <6cf2a94f0808080848s278ba290k86fd460e68085c10@mail.gmail.com> Aslak, Thanks for the great demo of Cucumber at Agile 2008. dean On Fri, Aug 8, 2008 at 8:58 AM, aslak hellesoy wrote: > I have pushed some updates to the documentation. Especially Rails > instructions (which describe Cucumber generators) should be useful for > some of you. > > Aslak > > On Thu, Aug 7, 2008 at 2:26 PM, aslak hellesoy > wrote: > > Nice vegetable, nice tool. > > > > It's my reimplementation of the story runner, addressing several > > shortcomings of the current one. And I'm calling them features instead > > of stories now, because that is what they are. > > > > http://github.com/aslakhellesoy/cucumber/ (The home page) > > http://gojko.net/2008/08/06/cucumber-next-generation-ruby-bdd-tool/ > > (Thanks Gojko) > > > > Take a look - it's taking shape. > > > > Aslak > > > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > -- Dean Wampler http://www.objectmentor.com http://www.aspectprogramming.com http://aquarium.rubyforge.org http://www.contract4j.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From jake.howerton at gmail.com Fri Aug 8 12:37:57 2008 From: jake.howerton at gmail.com (Jake Howerton) Date: Fri, 8 Aug 2008 12:37:57 -0400 Subject: [rspec-devel] [ANN] Cucumber In-Reply-To: <6cf2a94f0808080848s278ba290k86fd460e68085c10@mail.gmail.com> References: <8d961d900808071126q12071a0s354f4554a569ffbd@mail.gmail.com> <8d961d900808080658x6644e902oa6957a1dcf7ac93b@mail.gmail.com> <6cf2a94f0808080848s278ba290k86fd460e68085c10@mail.gmail.com> Message-ID: <218a05e40808080937h4b56357dhe91b244f60d0cbb0@mail.gmail.com> Aslak, Is it the intention to only be able to do one scenario per feature? If I add a second scenario, I get a syntax error. If so, how are you going to organize hundreds of features? In my existing stories I typically call it something like "Managing Widgets" and then put the scenarios for all features related to that idea within that singular story file. -Jake On Fri, Aug 8, 2008 at 11:48 AM, Dean Wampler wrote: > Aslak, > Thanks for the great demo of Cucumber at Agile 2008. > dean > > > On Fri, Aug 8, 2008 at 8:58 AM, aslak hellesoy wrote: > >> I have pushed some updates to the documentation. Especially Rails >> instructions (which describe Cucumber generators) should be useful for >> some of you. >> >> Aslak >> >> On Thu, Aug 7, 2008 at 2:26 PM, aslak hellesoy >> wrote: >> > Nice vegetable, nice tool. >> > >> > It's my reimplementation of the story runner, addressing several >> > shortcomings of the current one. And I'm calling them features instead >> > of stories now, because that is what they are. >> > >> > http://github.com/aslakhellesoy/cucumber/ (The home page) >> > http://gojko.net/2008/08/06/cucumber-next-generation-ruby-bdd-tool/ >> > (Thanks Gojko) >> > >> > Take a look - it's taking shape. >> > >> > Aslak >> > >> _______________________________________________ >> rspec-devel mailing list >> rspec-devel at rubyforge.org >> http://rubyforge.org/mailman/listinfo/rspec-devel >> > > > > -- > Dean Wampler > http://www.objectmentor.com > http://www.aspectprogramming.com > http://aquarium.rubyforge.org > http://www.contract4j.org > > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From aslak.hellesoy at gmail.com Fri Aug 8 12:59:43 2008 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Fri, 8 Aug 2008 12:59:43 -0400 Subject: [rspec-devel] [ANN] Cucumber In-Reply-To: <218a05e40808080937h4b56357dhe91b244f60d0cbb0@mail.gmail.com> References: <8d961d900808071126q12071a0s354f4554a569ffbd@mail.gmail.com> <8d961d900808080658x6644e902oa6957a1dcf7ac93b@mail.gmail.com> <6cf2a94f0808080848s278ba290k86fd460e68085c10@mail.gmail.com> <218a05e40808080937h4b56357dhe91b244f60d0cbb0@mail.gmail.com> Message-ID: <8d961d900808080959p3102b865s805c3627aadffced@mail.gmail.com> On Fri, Aug 8, 2008 at 12:37 PM, Jake Howerton wrote: > Aslak, > Is it the intention to only be able to do one scenario per feature? If I > add a second scenario, I get a syntax error. No, you can have as many scenarios as you want, and in fact you're encouraged to. I fixed a parser bug yesterday. It was a little finnicky with whitespace. Try to get the latest code. If it still fails to parse, please send me the feature file and I'll fix any remaining parser bugs. > If so, how are you going to organize hundreds of features? In my existing > stories I typically call it something like "Managing Widgets" and then put > the scenarios for all features related to that idea within that singular > story file. You can use the new "FIT table" feature to have several similar scenarios with different values, or you can split them up in several files. Check out the examples to see the tables in action. Cheers, Aslak > -Jake > On Fri, Aug 8, 2008 at 11:48 AM, Dean Wampler wrote: >> >> Aslak, >> Thanks for the great demo of Cucumber at Agile 2008. >> dean >> >> On Fri, Aug 8, 2008 at 8:58 AM, aslak hellesoy >> wrote: >>> >>> I have pushed some updates to the documentation. Especially Rails >>> instructions (which describe Cucumber generators) should be useful for >>> some of you. >>> >>> Aslak >>> >>> On Thu, Aug 7, 2008 at 2:26 PM, aslak hellesoy >>> wrote: >>> > Nice vegetable, nice tool. >>> > >>> > It's my reimplementation of the story runner, addressing several >>> > shortcomings of the current one. And I'm calling them features instead >>> > of stories now, because that is what they are. >>> > >>> > http://github.com/aslakhellesoy/cucumber/ (The home page) >>> > http://gojko.net/2008/08/06/cucumber-next-generation-ruby-bdd-tool/ >>> > (Thanks Gojko) >>> > >>> > Take a look - it's taking shape. >>> > >>> > Aslak >>> > >>> _______________________________________________ >>> rspec-devel mailing list >>> rspec-devel at rubyforge.org >>> http://rubyforge.org/mailman/listinfo/rspec-devel >> >> >> >> -- >> Dean Wampler >> http://www.objectmentor.com >> http://www.aspectprogramming.com >> http://aquarium.rubyforge.org >> http://www.contract4j.org >> >> _______________________________________________ >> rspec-devel mailing list >> rspec-devel at rubyforge.org >> http://rubyforge.org/mailman/listinfo/rspec-devel > > > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From ben at benmabey.com Fri Aug 8 13:52:43 2008 From: ben at benmabey.com (Ben Mabey) Date: Fri, 08 Aug 2008 11:52:43 -0600 Subject: [rspec-devel] [ANN] Cucumber In-Reply-To: <8d961d900808080959p3102b865s805c3627aadffced@mail.gmail.com> References: <8d961d900808071126q12071a0s354f4554a569ffbd@mail.gmail.com> <8d961d900808080658x6644e902oa6957a1dcf7ac93b@mail.gmail.com> <6cf2a94f0808080848s278ba290k86fd460e68085c10@mail.gmail.com> <218a05e40808080937h4b56357dhe91b244f60d0cbb0@mail.gmail.com> <8d961d900808080959p3102b865s805c3627aadffced@mail.gmail.com> Message-ID: <489C87EB.6040700@benmabey.com> > You can use the new "FIT table" feature to have several similar > scenarios with different values, or you can split them up > in several files. Check out the examples to see the tables in action. > > Cheers, > Aslak > I must of missed the "FIT table" feature at my previous glances at cumber. That is awesome!! You have truly given me a reason to mess around with this at work now. ;) I'm curious on why you have changed 'Story' to 'Feature'. Have you found that more customers relate to that wording better, or what is the motivation? Thanks for all your work on this, Ben Mabey http://www.benmabey.com/ From jake.howerton at gmail.com Fri Aug 8 14:36:50 2008 From: jake.howerton at gmail.com (Jake Howerton) Date: Fri, 8 Aug 2008 14:36:50 -0400 Subject: [rspec-devel] [ANN] Cucumber In-Reply-To: <8d961d900808080959p3102b865s805c3627aadffced@mail.gmail.com> References: <8d961d900808071126q12071a0s354f4554a569ffbd@mail.gmail.com> <8d961d900808080658x6644e902oa6957a1dcf7ac93b@mail.gmail.com> <6cf2a94f0808080848s278ba290k86fd460e68085c10@mail.gmail.com> <218a05e40808080937h4b56357dhe91b244f60d0cbb0@mail.gmail.com> <8d961d900808080959p3102b865s805c3627aadffced@mail.gmail.com> Message-ID: <218a05e40808081136l1adf62efide5883044477293a@mail.gmail.com> Your newest changes fixed my parse errors. Thanks. Jake On Fri, Aug 8, 2008 at 12:59 PM, aslak hellesoy wrote: > > > I fixed a parser bug yesterday. It was a little finnicky with > whitespace. Try to get the latest code. > If it still fails to parse, please send me the feature file and I'll > fix any remaining parser bugs. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From aslak.hellesoy at gmail.com Fri Aug 8 17:34:00 2008 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Fri, 8 Aug 2008 17:34:00 -0400 Subject: [rspec-devel] [ANN] Cucumber In-Reply-To: <489C87EB.6040700@benmabey.com> References: <8d961d900808071126q12071a0s354f4554a569ffbd@mail.gmail.com> <8d961d900808080658x6644e902oa6957a1dcf7ac93b@mail.gmail.com> <6cf2a94f0808080848s278ba290k86fd460e68085c10@mail.gmail.com> <218a05e40808080937h4b56357dhe91b244f60d0cbb0@mail.gmail.com> <8d961d900808080959p3102b865s805c3627aadffced@mail.gmail.com> <489C87EB.6040700@benmabey.com> Message-ID: <8d961d900808081434k36953ca6q79e3da6447b067db@mail.gmail.com> On Fri, Aug 8, 2008 at 1:52 PM, Ben Mabey wrote: > >> You can use the new "FIT table" feature to have several similar >> scenarios with different values, or you can split them up >> in several files. Check out the examples to see the tables in action. >> >> Cheers, >> Aslak >> > > > I must of missed the "FIT table" feature at my previous glances at cumber. > That is awesome!! You have truly given me a reason to mess around with > this at work now. ;) > > I'm curious on why you have changed 'Story' to 'Feature'. Have you found > that more customers relate to that wording better, or what is the > motivation? > A story is first and foremost a tool for planning. It represents a piece of valuable functionality and a future conversation about fleshing out the details. When they have moved through the Scrum/XP/Kanban board from the backlog to done done done, they are thrown away. At this time they have transmogrified into a running, tested feature - (or rather added to new or existing features). Software consists of (hopefully valuable) features - not stories. Stories are just temporary artifacts that feed the augmentation of features in the software. Let's say you have a backlog of 10 stories. Stuff people want to do. When the stories are implemented, what you have is perhaps 4 features, which have increased in scope over time. The features stick (in the code and in the Cucumber feature files). The stories are forgotten and that's ok. I hope this clarifies a bit what I mean. Aslak > Thanks for all your work on this, > > Ben Mabey > http://www.benmabey.com/ > > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From lists-rspec at shopwatch.org Wed Aug 13 15:09:36 2008 From: lists-rspec at shopwatch.org (Jay Levitt) Date: Wed, 13 Aug 2008 15:09:36 -0400 Subject: [rspec-devel] [ANN] Cucumber In-Reply-To: <8d961d900808071126q12071a0s354f4554a569ffbd@mail.gmail.com> References: <8d961d900808071126q12071a0s354f4554a569ffbd@mail.gmail.com> Message-ID: <48A33170.3080003@shopwatch.org> aslak hellesoy wrote: > Nice vegetable, nice tool. (Sorry, Fozzie, I didn't know those pickles were loaded!) Where do you want bugs reported? The first thing I noticed is that installing webrat as a gem isn't enough; you have to install it as a plugin, or the features that depend on it will fail. I'm new to webrat, but I *think* that shouldn't be the case, reading the docs.. Jay Levitt > > It's my reimplementation of the story runner, addressing several > shortcomings of the current one. And I'm calling them features instead > of stories now, because that is what they are. > > http://github.com/aslakhellesoy/cucumber/ (The home page) > http://gojko.net/2008/08/06/cucumber-next-generation-ruby-bdd-tool/ > (Thanks Gojko) > > Take a look - it's taking shape. > > Aslak > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel From ben at benmabey.com Wed Aug 13 16:10:09 2008 From: ben at benmabey.com (Ben Mabey) Date: Wed, 13 Aug 2008 14:10:09 -0600 Subject: [rspec-devel] [ANN] Cucumber In-Reply-To: <48A33170.3080003@shopwatch.org> References: <8d961d900808071126q12071a0s354f4554a569ffbd@mail.gmail.com> <48A33170.3080003@shopwatch.org> Message-ID: <48A33FA1.5080809@benmabey.com> Jay Levitt wrote: > aslak hellesoy wrote: >> Nice vegetable, nice tool. > > (Sorry, Fozzie, I didn't know those pickles were loaded!) > > Where do you want bugs reported? The first thing I noticed is that > installing webrat as a gem isn't enough; you have to install it as a > plugin, or the features that depend on it will fail. I'm new to > webrat, but I *think* that shouldn't be the case, reading the docs.. > I generally keep a local version of webrat in all of my projects (rails and merb ones) for the same reason I keep versions of rspec and rspec-rails in my rails projects. So I think using it as a plugin/local gem is really the norm. -Ben From ben at benmabey.com Tue Aug 19 20:38:26 2008 From: ben at benmabey.com (Ben Mabey) Date: Tue, 19 Aug 2008 18:38:26 -0600 Subject: [rspec-devel] running only a select group of specs Message-ID: <48AB6782.70406@benmabey.com> Hi all, I've started to use the nullDB adapter quite a bit on one of my rails app's spec suite. In fact, I have it as my default adapter and only turn the real DB adapter on when I have a spec that absolutely requires it. I call these functional specs and I include my Functional module: share_as :Functional do before :all do ActiveRecord::Base.establish_connection(:test) end after :all do ActiveRecord::Base.establish_connection(:adapter => :nulldb) end end With that said, I am now finding myself wanting to run my unit and functional specs separately at times... So I would like to be able to do: rake spec # run all rake spec:unit rake spec:functional I know the easy thing would be to just create separate unit and functional directories.. but that is something that I would like to avoid. Besides, that is easy and I like pain. :) So... what would be a good way to accomplish this? I thought that if I somehow tagged my specs I could run them conditionally. So I modified my version of rspec so that I can get access to my example group options.. meaning, I can now say: describe "some thing", :functional => true do ... end And in my spec_helper I have: config.before(:all) do if example_group_options[:functional] ActiveRecord::Base.establish_connection(:test) end end config.after(:all) do if example_group_options[:functional] ActiveRecord::Base.establish_connection(:adapter => :nulldb) end end Now that I have essentially tagged my specs, is there an easy way I could modify the runner to only run certain specs? Maybe easy isn't a good word... is there a clean way to do this? Thanks in advance for any input, Ben From pergesu at gmail.com Tue Aug 19 20:46:25 2008 From: pergesu at gmail.com (Pat Maddox) Date: Tue, 19 Aug 2008 20:46:25 -0400 Subject: [rspec-devel] running only a select group of specs In-Reply-To: <48AB6782.70406@benmabey.com> References: <48AB6782.70406@benmabey.com> Message-ID: <810a540e0808191746k58033963t7ee67fdc6d2a58f5@mail.gmail.com> On Tue, Aug 19, 2008 at 8:38 PM, Ben Mabey wrote: > I know the easy thing would be to just create separate unit and > functional directories.. but that is something that I would like to > avoid. Besides, that is easy and I like pain. :) Why do you want to avoid that? I think it's superior from an organizational standpoint, and doesn't require screwing with the runner. Pat From joshknowles at gmail.com Tue Aug 19 20:56:49 2008 From: joshknowles at gmail.com (Josh Knowles) Date: Tue, 19 Aug 2008 20:56:49 -0400 Subject: [rspec-devel] running only a select group of specs In-Reply-To: <48AB6782.70406@benmabey.com> References: <48AB6782.70406@benmabey.com> Message-ID: On 8/19/08, Ben Mabey wrote: > I know the easy thing would be to just create separate unit and > functional directories.. but that is something that I would like to > avoid. Besides, that is easy and I like pain. :) I don't see the disadvantage to creating additional directories/tasks. We have the following directories underneath RAILS_ROOT/spec * controllers * daemons * helpers * lib * models * observers * presenters * queues * sql * views -- Josh Knowles phone: 509-979-1593 email: joshknowles at gmail.com web: http://joshknowles.com From ben at benmabey.com Tue Aug 19 22:15:51 2008 From: ben at benmabey.com (Ben Mabey) Date: Tue, 19 Aug 2008 20:15:51 -0600 Subject: [rspec-devel] running only a select group of specs In-Reply-To: <810a540e0808191746k58033963t7ee67fdc6d2a58f5@mail.gmail.com> References: <48AB6782.70406@benmabey.com> <810a540e0808191746k58033963t7ee67fdc6d2a58f5@mail.gmail.com> Message-ID: <48AB7E57.3040901@benmabey.com> Pat Maddox wrote: > On Tue, Aug 19, 2008 at 8:38 PM, Ben Mabey wrote: > >> I know the easy thing would be to just create separate unit and >> functional directories.. but that is something that I would like to >> avoid. Besides, that is easy and I like pain. :) >> > > Why do you want to avoid that? I think it's superior from an > organizational standpoint, and doesn't require screwing with the > runner. > > Pat > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > I actually keep going back and forth on this. I like having all of my specs for a given object in the same file... When I'm specing out some behavior and I realize that I really need to use the DB I like being able to just declare it inline and not have to cut my spec and paste it into another file in another dir. Make sense? Also, I think reading the specs that way is less confusing... On the other hand I can see the organizational benefits of having two directories. It may also help enforce the separation of the two kinds of specs. So, perhaps I will just use multiple directories since it would be less trouble down the road... Thanks Pat and Josh for your thoughts. Ben From mailing_lists at railsnewbie.com Tue Aug 19 23:54:24 2008 From: mailing_lists at railsnewbie.com (Scott Taylor) Date: Tue, 19 Aug 2008 23:54:24 -0400 Subject: [rspec-devel] running only a select group of specs In-Reply-To: <810a540e0808191746k58033963t7ee67fdc6d2a58f5@mail.gmail.com> References: <48AB6782.70406@benmabey.com> <810a540e0808191746k58033963t7ee67fdc6d2a58f5@mail.gmail.com> Message-ID: <7911F3A0-E724-422D-8407-722C640F0597@railsnewbie.com> On Aug 19, 2008, at 8:46 PM, Pat Maddox wrote: > On Tue, Aug 19, 2008 at 8:38 PM, Ben Mabey wrote: >> I know the easy thing would be to just create separate unit and >> functional directories.. but that is something that I would like to >> avoid. Besides, that is easy and I like pain. :) > > Why do you want to avoid that? I think it's superior from an > organizational standpoint, and doesn't require screwing with the > runner. Well, it does seem like you'd need to screw with the running just a little bit if you plan spec/integrationmodels and spec/unit/models to use the ModelExampleGroup, and so on... Scott From pergesu at gmail.com Wed Aug 20 01:00:26 2008 From: pergesu at gmail.com (Pat Maddox) Date: Wed, 20 Aug 2008 01:00:26 -0400 Subject: [rspec-devel] running only a select group of specs In-Reply-To: <7911F3A0-E724-422D-8407-722C640F0597@railsnewbie.com> References: <48AB6782.70406@benmabey.com> <810a540e0808191746k58033963t7ee67fdc6d2a58f5@mail.gmail.com> <7911F3A0-E724-422D-8407-722C640F0597@railsnewbie.com> Message-ID: <810a540e0808192200m2e2e0073j78106bcdd07eae5e@mail.gmail.com> On Tue, Aug 19, 2008 at 11:54 PM, Scott Taylor wrote: > > On Aug 19, 2008, at 8:46 PM, Pat Maddox wrote: > >> On Tue, Aug 19, 2008 at 8:38 PM, Ben Mabey wrote: >>> >>> I know the easy thing would be to just create separate unit and >>> functional directories.. but that is something that I would like to >>> avoid. Besides, that is easy and I like pain. :) >> >> Why do you want to avoid that? I think it's superior from an >> organizational standpoint, and doesn't require screwing with the >> runner. > > Well, it does seem like you'd need to screw with the running just a little > bit if you plan spec/integrationmodels and spec/unit/models to use the > ModelExampleGroup, and so on... Right now, what happens is the example group factory looks at the path to the spec and sees if it matches some known type. For example, it takes spec/models/user_spec.rb and parses out models. Then it looks to see if it knows of an example group type registered to the key :model. So if you follow a naming structure like spec/models/unit spec/models/integration then it'll still work fine. Moving them around will not work though: spec/unit/models spec/integration/models I don't know whether or not it's desirable to make it work automatically for this other dir structure (which makes more sense in my eyes anyway). At any rate, the approach I've used is to have a spec_helper.rb in that file that sets the default example group class. So spec/unit/models/spec_helper.rb has Spec::Example::ExampleGroupFactory.default Spec::Rails::Example::ModelExampleGroup So while you're right that you do have to do something in order to make it work, there is at least a reasonable, official way of doing so. Pat From zach.dennis at gmail.com Wed Aug 20 21:55:56 2008 From: zach.dennis at gmail.com (Zach Dennis) Date: Wed, 20 Aug 2008 21:55:56 -0400 Subject: [rspec-devel] running only a select group of specs In-Reply-To: <48AB7E57.3040901@benmabey.com> References: <48AB6782.70406@benmabey.com> <810a540e0808191746k58033963t7ee67fdc6d2a58f5@mail.gmail.com> <48AB7E57.3040901@benmabey.com> Message-ID: <85d99afe0808201855v752f8004o6fdfcd3f0a3e9442@mail.gmail.com> On Tue, Aug 19, 2008 at 10:15 PM, Ben Mabey wrote: > Pat Maddox wrote: >> On Tue, Aug 19, 2008 at 8:38 PM, Ben Mabey wrote: >> >>> I know the easy thing would be to just create separate unit and >>> functional directories.. but that is something that I would like to >>> avoid. Besides, that is easy and I like pain. :) >>> >> >> Why do you want to avoid that? I think it's superior from an >> organizational standpoint, and doesn't require screwing with the >> runner. >> >> Pat >> _______________________________________________ >> rspec-devel mailing list >> rspec-devel at rubyforge.org >> http://rubyforge.org/mailman/listinfo/rspec-devel >> > > I actually keep going back and forth on this. I like having all of my > specs for a given object in the same file... When I'm specing out some > behavior and I realize that I really need to use the DB I like being > able to just declare it inline and not have to cut my spec and paste it > into another file in another dir. Make sense? Also, I think reading > the specs that way is less confusing... > I agree with Ben. Different directories works, but it definitely isn't my preferred route if there is way to cleanly and simply keep all examples for a particular object together. I like cohesiveness in my specs, and spreading examples out across separate files (and directories) for one object seems to decrease some amount of value. I think we can do better. A suggestion OTOMH is: describe SomeModel, :use_db => true do end describe SomeModel, :use_db => false do end And pick false as the default if :use_db isn't supplied. This kind of configurable capabilities can apply to more than just the database as well. I'd envision a config could look like: Spec::Runner.configure do |config| config.use_db do |val| unless val # do everything to disallow database access end end config.use_userdefined_thingy do |val| unless val # do everything to disallow user defined thingy end end end This would keep things flexible and allow for project specific behaviour. WDYT? -- Zach Dennis http://www.continuousthinking.com http://www.mutuallyhuman.com From ben at benmabey.com Wed Aug 20 22:35:36 2008 From: ben at benmabey.com (Ben Mabey) Date: Wed, 20 Aug 2008 20:35:36 -0600 Subject: [rspec-devel] running only a select group of specs In-Reply-To: <85d99afe0808201855v752f8004o6fdfcd3f0a3e9442@mail.gmail.com> References: <48AB6782.70406@benmabey.com> <810a540e0808191746k58033963t7ee67fdc6d2a58f5@mail.gmail.com> <48AB7E57.3040901@benmabey.com> <85d99afe0808201855v752f8004o6fdfcd3f0a3e9442@mail.gmail.com> Message-ID: <48ACD478.2080707@benmabey.com> Zach Dennis wrote: > On Tue, Aug 19, 2008 at 10:15 PM, Ben Mabey wrote: > >> Pat Maddox wrote: >> >>> On Tue, Aug 19, 2008 at 8:38 PM, Ben Mabey wrote: >>> >>> >>>> I know the easy thing would be to just create separate unit and >>>> functional directories.. but that is something that I would like to >>>> avoid. Besides, that is easy and I like pain. :) >>>> >>>> >>> Why do you want to avoid that? I think it's superior from an >>> organizational standpoint, and doesn't require screwing with the >>> runner. >>> >>> Pat >>> _______________________________________________ >>> rspec-devel mailing list >>> rspec-devel at rubyforge.org >>> http://rubyforge.org/mailman/listinfo/rspec-devel >>> >>> >> I actually keep going back and forth on this. I like having all of my >> specs for a given object in the same file... When I'm specing out some >> behavior and I realize that I really need to use the DB I like being >> able to just declare it inline and not have to cut my spec and paste it >> into another file in another dir. Make sense? Also, I think reading >> the specs that way is less confusing... >> >> > > I agree with Ben. Different directories works, but it definitely isn't > my preferred route if there is way to cleanly and simply keep all > examples for a particular object together. I like cohesiveness in my > specs, and spreading examples out across separate files (and > directories) for one object seems to decrease some amount of value. I > think we can do better. A suggestion OTOMH is: > > describe SomeModel, :use_db => true do > end > > describe SomeModel, :use_db => false do > end > > And pick false as the default if :use_db isn't supplied. This kind of > configurable capabilities can apply to more than just the database as > well. I'd envision a config could look like: > > Spec::Runner.configure do |config| > config.use_db do |val| > unless val > # do everything to disallow database access > end > end > > config.use_userdefined_thingy do |val| > unless val > # do everything to disallow user defined thingy > end > end > end > When would your config block be ran? Before or after example groups? As I currently have it implemented I can create before and after blocks on the config like so: config.before(:all) do if example_group_options[:use_db] ActiveRecord::Base.establish_connection(:test) end end config.after(:all) do if example_group_options[:use_db] ActiveRecord::Base.establish_connection(:adapter => :nulldb) end end So perhaps a mixture of the two used like so would be ideal: config.before(:all, :use_db => true) do ActiveRecord::Base.establish_connection(:test) end config.after(:all, :use_db => true) do ActiveRecord::Base.establish_connection(:adapter => :nulldb) end The before and after blocks would essentially do pattern matching on the example groups. Meaning, they would only be executed if the example group's options matched what is defined on config. This is no different from how you can already specify which example group types should use certain before and after blocks. Going back to my original question though.. with something like above in place could you leverage the same pattern matching functionality in the runner? Well.. I'm sure you could, but as Pat said, is the value gained really worth screwing with the runner? OTOMH, specifying which example groups to be ran could perhaps be defined in a rake task like so: Spec::Rake::SpecTask.new(:db_specs) do |t| t.spec_opts = ['--options', "\"#{RAILS_ROOT}/spec/spec.opts\""] t.spec_files = FileList['spec/**/*_spec.rb'] t.example_group_options = {:use_db => true} end This could allow a user to organize there specs how ever they like on the filesystem and then rely on this tagging mechanism to run only certain specs at certain times... WDYT? -Ben From zach.dennis at gmail.com Thu Aug 21 09:52:25 2008 From: zach.dennis at gmail.com (Zach Dennis) Date: Thu, 21 Aug 2008 09:52:25 -0400 Subject: [rspec-devel] running only a select group of specs In-Reply-To: <48ACD478.2080707@benmabey.com> References: <48AB6782.70406@benmabey.com> <810a540e0808191746k58033963t7ee67fdc6d2a58f5@mail.gmail.com> <48AB7E57.3040901@benmabey.com> <85d99afe0808201855v752f8004o6fdfcd3f0a3e9442@mail.gmail.com> <48ACD478.2080707@benmabey.com> Message-ID: <85d99afe0808210652o43657768jbbbd60fc58fc21a8@mail.gmail.com> On Wed, Aug 20, 2008 at 10:35 PM, Ben Mabey wrote: > Zach Dennis wrote: >> On Tue, Aug 19, 2008 at 10:15 PM, Ben Mabey wrote: >> >>> Pat Maddox wrote: >>> >>>> On Tue, Aug 19, 2008 at 8:38 PM, Ben Mabey wrote: >>>> >>>> >>>>> I know the easy thing would be to just create separate unit and >>>>> functional directories.. but that is something that I would like to >>>>> avoid. Besides, that is easy and I like pain. :) >>>>> >>>>> >>>> Why do you want to avoid that? I think it's superior from an >>>> organizational standpoint, and doesn't require screwing with the >>>> runner. >>>> >>>> Pat >>>> _______________________________________________ >>>> rspec-devel mailing list >>>> rspec-devel at rubyforge.org >>>> http://rubyforge.org/mailman/listinfo/rspec-devel >>>> >>>> >>> I actually keep going back and forth on this. I like having all of my >>> specs for a given object in the same file... When I'm specing out some >>> behavior and I realize that I really need to use the DB I like being >>> able to just declare it inline and not have to cut my spec and paste it >>> into another file in another dir. Make sense? Also, I think reading >>> the specs that way is less confusing... >>> >>> >> >> I agree with Ben. Different directories works, but it definitely isn't >> my preferred route if there is way to cleanly and simply keep all >> examples for a particular object together. I like cohesiveness in my >> specs, and spreading examples out across separate files (and >> directories) for one object seems to decrease some amount of value. I >> think we can do better. A suggestion OTOMH is: >> >> describe SomeModel, :use_db => true do >> end >> >> describe SomeModel, :use_db => false do >> end >> >> And pick false as the default if :use_db isn't supplied. This kind of >> configurable capabilities can apply to more than just the database as >> well. I'd envision a config could look like: >> >> Spec::Runner.configure do |config| >> config.use_db do |val| >> unless val >> # do everything to disallow database access >> end >> end >> >> config.use_userdefined_thingy do |val| >> unless val >> # do everything to disallow user defined thingy >> end >> end >> end >> > > When would your config block be ran? Before or after example groups? > As I currently have it implemented I can create before and after blocks > on the config like so: > > config.before(:all) do > if example_group_options[:use_db] > ActiveRecord::Base.establish_connection(:test) > end > end > > config.after(:all) do > if example_group_options[:use_db] > ActiveRecord::Base.establish_connection(:adapter => :nulldb) > end > end > > So perhaps a mixture of the two used like so would be ideal: > > config.before(:all, :use_db => true) do > ActiveRecord::Base.establish_connection(:test) > end > > config.after(:all, :use_db => true) do > ActiveRecord::Base.establish_connection(:adapter => :nulldb) > end > > The before and after blocks would essentially do pattern matching on the > example groups. Meaning, they would only be executed if the example > group's options matched what is defined on config. This is no different > from how you can already specify which example group types should use > certain before and after blocks. > > Going back to my original question though.. with something like above in > place could you leverage the same pattern matching functionality in the > runner? > Well.. I'm sure you could, but as Pat said, is the value gained really > worth screwing with the runner? > > OTOMH, specifying which example groups to be ran could perhaps be > defined in a rake task like so: > > Spec::Rake::SpecTask.new(:db_specs) do |t| > t.spec_opts = ['--options', "\"#{RAILS_ROOT}/spec/spec.opts\""] > t.spec_files = FileList['spec/**/*_spec.rb'] > t.example_group_options = {:use_db => true} > end > > This could allow a user to organize there specs how ever they like on > the filesystem and then rely on this tagging mechanism to run only > certain specs at certain times... > > WDYT? > I like it. It keeps things flexible and simple. -- Zach Dennis http://www.continuousthinking.com http://www.mutuallyhuman.com From wycats at gmail.com Mon Aug 25 14:41:53 2008 From: wycats at gmail.com (Yehuda Katz) Date: Mon, 25 Aug 2008 11:41:53 -0700 Subject: [rspec-devel] spec.opts Message-ID: <245fb4700808251141x2a795f41i81fb7b9ce183de67@mail.gmail.com> I spoke to dchelimsky this morning and am bringing our conversation to the list. Effectively, I asked why we don't automatically require spec/spec.opts (which I wanted in order to be able to yank require 'spec_helper' from my specs, because require 'spec_helper' and require '../spec_helper' results in two requires, which sucks). David thought it was a good idea, but had questions about running the specs from someplace other than your app root, and suggested that I bring the conversation here. Thoughts? -- Yehuda Katz Developer | Engine Yard (ph) 718.877.1325 -------------- next part -------------- An HTML attachment was scrubbed... URL: From pergesu at gmail.com Mon Aug 25 15:22:32 2008 From: pergesu at gmail.com (Pat Maddox) Date: Mon, 25 Aug 2008 15:22:32 -0400 Subject: [rspec-devel] spec.opts In-Reply-To: <245fb4700808251141x2a795f41i81fb7b9ce183de67@mail.gmail.com> References: <245fb4700808251141x2a795f41i81fb7b9ce183de67@mail.gmail.com> Message-ID: <810a540e0808251222m5e754b2v92b0eaeb15e0d42f@mail.gmail.com> On Mon, Aug 25, 2008 at 2:41 PM, Yehuda Katz wrote: > I spoke to dchelimsky this morning and am bringing our conversation to the > list. > > Effectively, I asked why we don't automatically require spec/spec.opts > (which I wanted in order to be able to yank require 'spec_helper' from my > specs, because require 'spec_helper' and require '../spec_helper' results in > two requires, which sucks). Doesn't File.expand_path solve this issue? Pat From wycats at gmail.com Mon Aug 25 15:28:27 2008 From: wycats at gmail.com (Yehuda Katz) Date: Mon, 25 Aug 2008 12:28:27 -0700 Subject: [rspec-devel] spec.opts In-Reply-To: <810a540e0808251222m5e754b2v92b0eaeb15e0d42f@mail.gmail.com> References: <245fb4700808251141x2a795f41i81fb7b9ce183de67@mail.gmail.com> <810a540e0808251222m5e754b2v92b0eaeb15e0d42f@mail.gmail.com> Message-ID: <245fb4700808251228n44f34885m79970b52b828e6fe@mail.gmail.com> Sure... if you want to do stuff like: require File.expand_path(File.join(File.dirname(__FILE__), "..", "spec_helper"))) This is super-unDRY and I'd like to be able to have this happen automatically without having to do spec -O spec/spec.opts ... Is there a reason not to try and find spec/spec.opts and load it automatically? -- Yehuda On Mon, Aug 25, 2008 at 12:22 PM, Pat Maddox wrote: > On Mon, Aug 25, 2008 at 2:41 PM, Yehuda Katz wrote: > > I spoke to dchelimsky this morning and am bringing our conversation to > the > > list. > > > > Effectively, I asked why we don't automatically require spec/spec.opts > > (which I wanted in order to be able to yank require 'spec_helper' from my > > specs, because require 'spec_helper' and require '../spec_helper' results > in > > two requires, which sucks). > > Doesn't File.expand_path solve this issue? > > Pat > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > -- Yehuda Katz Developer | Engine Yard (ph) 718.877.1325 -------------- next part -------------- An HTML attachment was scrubbed... URL: From dchelimsky at gmail.com Mon Aug 25 17:41:03 2008 From: dchelimsky at gmail.com (David Chelimsky) Date: Mon, 25 Aug 2008 16:41:03 -0500 Subject: [rspec-devel] spec.opts In-Reply-To: <245fb4700808251228n44f34885m79970b52b828e6fe@mail.gmail.com> References: <245fb4700808251141x2a795f41i81fb7b9ce183de67@mail.gmail.com> <810a540e0808251222m5e754b2v92b0eaeb15e0d42f@mail.gmail.com> <245fb4700808251228n44f34885m79970b52b828e6fe@mail.gmail.com> Message-ID: <57c63afe0808251441x73b0b844qdf7a86d50a5c58a4@mail.gmail.com> On Mon, Aug 25, 2008 at 2:28 PM, Yehuda Katz wrote: > Sure... if you want to do stuff like: > > require File.expand_path(File.join(File.dirname(__FILE__), "..", > "spec_helper"))) > > This is super-unDRY and I'd like to be able to have this happen > automatically without having to do spec -O spec/spec.opts ... > > Is there a reason not to try and find spec/spec.opts and load it > automatically? > I don't object to looking for spec/spec.opts. My only concern is that if you are sitting in a different directory it won't get picked up (unless we start traversing up the path, something I would strongly object to), so you won't always get the same results unless you always work from the same directory, which would lead to its own brand of confusion. What if we were to add an rspec_options method (or similar) that you could wrap around the contents of spec_helper.rb: rspec_options do ... end This could ensure that even if the file is loaded more than once, it is only processed once. > -- Yehuda > > On Mon, Aug 25, 2008 at 12:22 PM, Pat Maddox wrote: >> >> On Mon, Aug 25, 2008 at 2:41 PM, Yehuda Katz wrote: >> > I spoke to dchelimsky this morning and am bringing our conversation to >> > the >> > list. >> > >> > Effectively, I asked why we don't automatically require spec/spec.opts >> > (which I wanted in order to be able to yank require 'spec_helper' from >> > my >> > specs, because require 'spec_helper' and require '../spec_helper' >> > results in >> > two requires, which sucks). >> >> Doesn't File.expand_path solve this issue? >> >> Pat >> _______________________________________________ >> rspec-devel mailing list >> rspec-devel at rubyforge.org >> http://rubyforge.org/mailman/listinfo/rspec-devel > > > > -- > Yehuda Katz > Developer | Engine Yard > (ph) 718.877.1325 > > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From wycats at gmail.com Mon Aug 25 18:02:12 2008 From: wycats at gmail.com (Yehuda Katz) Date: Mon, 25 Aug 2008 15:02:12 -0700 Subject: [rspec-devel] spec.opts In-Reply-To: <57c63afe0808251441x73b0b844qdf7a86d50a5c58a4@mail.gmail.com> References: <245fb4700808251141x2a795f41i81fb7b9ce183de67@mail.gmail.com> <810a540e0808251222m5e754b2v92b0eaeb15e0d42f@mail.gmail.com> <245fb4700808251228n44f34885m79970b52b828e6fe@mail.gmail.com> <57c63afe0808251441x73b0b844qdf7a86d50a5c58a4@mail.gmail.com> Message-ID: <245fb4700808251502q40178686x240d8f6a2d81212d@mail.gmail.com> On Mon, Aug 25, 2008 at 2:41 PM, David Chelimsky wrote: > On Mon, Aug 25, 2008 at 2:28 PM, Yehuda Katz wrote: > > Sure... if you want to do stuff like: > > > > require File.expand_path(File.join(File.dirname(__FILE__), "..", > > "spec_helper"))) > > > > This is super-unDRY and I'd like to be able to have this happen > > automatically without having to do spec -O spec/spec.opts ... > > > > Is there a reason not to try and find spec/spec.opts and load it > > automatically? > > > > I don't object to looking for spec/spec.opts. My only concern is that > if you are sitting in a different directory it won't get picked up > (unless we start traversing up the path, something I would strongly > object to), so you won't always get the same results unless you always > work from the same directory, which would lead to its own brand of > confusion. Remember that this is only happening for people who are using spec.opts, and we can be sure we make this limitation clear. For most users, this would produce no changes. > What if we were to add an rspec_options method (or similar) that you > could wrap around the contents of spec_helper.rb: > > rspec_options do > ... > end #ifdef rspec /me cries This could ensure that even if the file is loaded more than once, it > is only processed once. I'm doing something like that now, but it makes me really unhappy. > > > > -- Yehuda > > > > On Mon, Aug 25, 2008 at 12:22 PM, Pat Maddox wrote: > >> > >> On Mon, Aug 25, 2008 at 2:41 PM, Yehuda Katz wrote: > >> > I spoke to dchelimsky this morning and am bringing our conversation to > >> > the > >> > list. > >> > > >> > Effectively, I asked why we don't automatically require spec/spec.opts > >> > (which I wanted in order to be able to yank require 'spec_helper' from > >> > my > >> > specs, because require 'spec_helper' and require '../spec_helper' > >> > results in > >> > two requires, which sucks). > >> > >> Doesn't File.expand_path solve this issue? > >> > >> Pat > >> _______________________________________________ > >> rspec-devel mailing list > >> rspec-devel at rubyforge.org > >> http://rubyforge.org/mailman/listinfo/rspec-devel > > > > > > > > -- > > Yehuda Katz > > Developer | Engine Yard > > (ph) 718.877.1325 > > > > _______________________________________________ > > rspec-devel mailing list > > rspec-devel at rubyforge.org > > http://rubyforge.org/mailman/listinfo/rspec-devel > > > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > -- Yehuda Katz Developer | Engine Yard (ph) 718.877.1325 -------------- next part -------------- An HTML attachment was scrubbed... URL: From zach.dennis at gmail.com Tue Aug 26 22:21:39 2008 From: zach.dennis at gmail.com (Zach Dennis) Date: Tue, 26 Aug 2008 22:21:39 -0400 Subject: [rspec-devel] as_null_object Message-ID: <85d99afe0808261921t226471d8t10cff645162f0eb3@mail.gmail.com> I noticed #as_null_object got added to Spec::Mocks::Methods. As soon as I saw it, it immediately seemed to be preferable over the :null_object parameter. Is this the case? -- Zach Dennis http://www.continuousthinking.com http://www.mutuallyhuman.com From dchelimsky at gmail.com Tue Aug 26 22:29:35 2008 From: dchelimsky at gmail.com (David Chelimsky) Date: Tue, 26 Aug 2008 21:29:35 -0500 Subject: [rspec-devel] as_null_object In-Reply-To: <85d99afe0808261921t226471d8t10cff645162f0eb3@mail.gmail.com> References: <85d99afe0808261921t226471d8t10cff645162f0eb3@mail.gmail.com> Message-ID: <57c63afe0808261929h15f21990hf8edb5c924194863@mail.gmail.com> On Tue, Aug 26, 2008 at 9:21 PM, Zach Dennis wrote: > I noticed #as_null_object got added to Spec::Mocks::Methods. As soon > as I saw it, it immediately seemed to be preferable over the > :null_object parameter. Is this the case? I prefer it, but preference is ... a matter of preference :) I don't think we'll deprecate support for the :null_object option, if that's what you're asking. From zach.dennis at gmail.com Wed Aug 27 20:43:59 2008 From: zach.dennis at gmail.com (Zach Dennis) Date: Wed, 27 Aug 2008 20:43:59 -0400 Subject: [rspec-devel] plugins/ directory Message-ID: <85d99afe0808271743o4c14849bk450332f9964430c8@mail.gmail.com> Is there any special reason why plugins/ (for mock frameworks) is kept outside of lib/ or was it just for keeping it separate since it literally is plugin code for third-party libraries? -- Zach Dennis http://www.continuousthinking.com http://www.mutuallyhuman.com From dchelimsky at gmail.com Thu Aug 28 07:59:59 2008 From: dchelimsky at gmail.com (David Chelimsky) Date: Thu, 28 Aug 2008 06:59:59 -0500 Subject: [rspec-devel] plugins/ directory In-Reply-To: <85d99afe0808271743o4c14849bk450332f9964430c8@mail.gmail.com> References: <85d99afe0808271743o4c14849bk450332f9964430c8@mail.gmail.com> Message-ID: <57c63afe0808280459g48c71bbfi48273563c2980172@mail.gmail.com> On Wed, Aug 27, 2008 at 7:43 PM, Zach Dennis wrote: > > Is there any special reason why plugins/ (for mock frameworks) is kept > outside of lib/ or was it just for keeping it separate since it > literally is plugin code for third-party libraries? This is not an either/or question: there *is* a special reason, and it is to keep plugin code separated :) Do you feel it should be under lib? From zach.dennis at gmail.com Thu Aug 28 08:38:47 2008 From: zach.dennis at gmail.com (Zach Dennis) Date: Thu, 28 Aug 2008 08:38:47 -0400 Subject: [rspec-devel] plugins/ directory In-Reply-To: <57c63afe0808280459g48c71bbfi48273563c2980172@mail.gmail.com> References: <85d99afe0808271743o4c14849bk450332f9964430c8@mail.gmail.com> <57c63afe0808280459g48c71bbfi48273563c2980172@mail.gmail.com> Message-ID: <85d99afe0808280538i7fcf3469q5ae5bd8959d82b8a@mail.gmail.com> On Thu, Aug 28, 2008 at 7:59 AM, David Chelimsky wrote: > On Wed, Aug 27, 2008 at 7:43 PM, Zach Dennis wrote: >> >> Is there any special reason why plugins/ (for mock frameworks) is kept >> outside of lib/ or was it just for keeping it separate since it >> literally is plugin code for third-party libraries? > > This is not an either/or question: there *is* a special reason, and it > is to keep plugin code separated :) > > Do you feel it should be under lib? > I don't know. I was more curious than I am thinking it should change. I was trying to find where the Spec::Mocks::Space class was used, and I wasn't expecting it to not be in lib/. Then the hamster wheel started to turn and I decided to ask. Thanks, -- Zach Dennis http://www.continuousthinking.com http://www.mutuallyhuman.com