From mhennemeyer at gmail.com Sat Jan 3 08:44:37 2009 From: mhennemeyer at gmail.com (mhennemeyer) Date: Sat, 3 Jan 2009 05:44:37 -0800 (PST) Subject: [rspec-devel] Ruby 1.9 and constant lookup rules Message-ID: <21264451.post@talk.nabble.com> Hi David, the patch that i wrote was (only) ought to include an enclosing modules' scope into groups that are defined inside the module (by calling describe). The problem that your example addresses is that methods and constants that are defined inside a group are not accessible by subsequent examples or nested groups. Please regard the following examples (they are passing): Also available as a pastie: http://pastie.org/351501 module Foo module Bar class ClassInEnclosingModule; end def method_in_enclosing_module; end describe "Class and Method defined in enclosing module are accessible, so Examples" do it "does automatically get access to the context of Foo::Bar" do Foo::Bar end it "does automatically get access to ClassInEnclosingModule" do ClassInEnclosingModule.new end it "does automatically get access to method_in_enclosing_module" do method_in_enclosing_module end describe "that live inside a nested group" do it "does automatically get access to the context of Foo::Bar" do Foo::Bar end it "does automatically get access to ClassInEnclosingModule" do ClassInEnclosingModule.new end it "does automatically get access to method_in_enclosing_module" do method_in_enclosing_module end end end describe "Method and Class defined in group are not accessible, so examples" do class ClassDefinedInGroup; end def method_defined_in_group; end it "does automatically get access to the context of Foo::Bar" do Foo::Bar end it "does not automatically get access to ClassDefinedInGroup" do lambda {ClassDefinedInGroup.new}.should raise_error(/uninitialized/) end it "does not automatically get access to method_defined_in_group" do lambda {method_defined_in_group}.should raise_error(/undefined/) end describe "that live inside a nested group" do it "does automatically get access to the context of Foo::Bar" do Foo::Bar end it "does not automatically get access to ClassDefinedInGroup" do lambda {ClassDefinedInGroup.new}.should raise_error(/uninitialized/) end it "does not automatically get access to method_defined_in_group" do lambda {method_defined_in_group}.should raise_error(/undefined/) end end end end endmodule Foo module Bar class ClassInEnclosingModule; end def method_in_enclosing_module; end describe "Class and Method defined in enclosing module are accessible, so Examples" do it "does automatically get access to the context of Foo::Bar" do Foo::Bar end it "does automatically get access to ClassInEnclosingModule" do ClassInEnclosingModule.new end it "does automatically get access to method_in_enclosing_module" do method_in_enclosing_module end describe "that live inside a nested group" do it "does automatically get access to the context of Foo::Bar" do Foo::Bar end it "does automatically get access to ClassInEnclosingModule" do ClassInEnclosingModule.new end it "does automatically get access to method_in_enclosing_module" do method_in_enclosing_module end end end describe "Method and Class defined in group are not accessible, so examples" do class ClassDefinedInGroup; end def method_defined_in_group; end it "does automatically get access to the context of Foo::Bar" do Foo::Bar end it "does not automatically get access to ClassDefinedInGroup" do lambda {ClassDefinedInGroup.new}.should raise_error(/uninitialized/) end it "does not automatically get access to method_defined_in_group" do lambda {method_defined_in_group}.should raise_error(/undefined/) end describe "that live inside a nested group" do it "does automatically get access to the context of Foo::Bar" do Foo::Bar end it "does not automatically get access to ClassDefinedInGroup" do lambda {ClassDefinedInGroup.new}.should raise_error(/uninitialized/) end it "does not automatically get access to method_defined_in_group" do lambda {method_defined_in_group}.should raise_error(/undefined/) end end end end end Output: Macbook:OutBox macbook$ /opt/local/bin/ruby1.9 -v ruby 1.9.0 (2008-07-25 revision 18217) [i686-darwin9] Macbook:OutBox macbook$ /opt/local/bin/ruby1.9 rspec-ruby19-scoping.rb ............ Finished in 0.028068 seconds 12 examples, 0 failures Macbook:OutBox macbook$ Matthias -- View this message in context: http://www.nabble.com/Ruby-1.9-and-constant-lookup-rules-tp21237683p21264451.html Sent from the rspec-devel mailing list archive at Nabble.com. From dchelimsky at gmail.com Sat Jan 3 09:43:44 2009 From: dchelimsky at gmail.com (David Chelimsky) Date: Sat, 3 Jan 2009 08:43:44 -0600 Subject: [rspec-devel] Ruby 1.9 and constant lookup rules In-Reply-To: <21264451.post@talk.nabble.com> References: <21264451.post@talk.nabble.com> Message-ID: <57c63afe0901030643m2a6d8b9exeb329587635dd078@mail.gmail.com> On Sat, Jan 3, 2009 at 7:44 AM, mhennemeyer wrote: > > Hi David, > > the patch that i wrote was (only) ought to include an enclosing modules' > scope into groups that are > defined inside the module (by calling describe). > The problem that your example addresses is that methods and constants > that are defined inside a group are not accessible by subsequent examples or > nested groups. Please regard the following examples (they are passing): > > Also available as a pastie: http://pastie.org/351501 Looking at this more closely this is not really the behaviour we want for enclosing modules. We want to replicate the behaviour we have now in ruby 1.8, which is that examples can access: * from the enclosing module ** constants ** classes ** modules * from the enclosing example group ** constants ** classes ** modules ** methods With the patch you've provided we get: * from the enclosing module ** constants ** classes ** modules ** methods * from the enclosing example group ** nada So we're getting methods defined in the module, which we don't want. The likelihood of collisions grows with this and violates the principle of least surprise. This is why we stopped including described modules in the object in which they are executed. And we're *not* getting anything defined in the group. I'm thinking we need a different strategy here, but I only have vague ideas at this point and none of them feel efficient. I'll follow up with some concrete proposals, but welcome any thoughts in the mean time. Cheers, David From mhennemeyer at gmail.com Sat Jan 3 13:55:08 2009 From: mhennemeyer at gmail.com (mhennemeyer) Date: Sat, 3 Jan 2009 10:55:08 -0800 (PST) Subject: [rspec-devel] Ruby 1.9 and constant lookup rules In-Reply-To: <57c63afe0901030643m2a6d8b9exeb329587635dd078@mail.gmail.com> References: <57c63afe0812311444k65203703tacad8a5c11504dbd@mail.gmail.com> <21264451.post@talk.nabble.com> <57c63afe0901030643m2a6d8b9exeb329587635dd078@mail.gmail.com> Message-ID: <21267971.post@talk.nabble.com> What do you think about a compatibility specific example suite? One that passes if executed with ruby 1.8 and fails with ruby 1.9. If we had this, it would be easier to see if an implementation matches the desired behavior. My first examples, focused at the current topic would be as follows: (Pastie: http://pastie.org/351682) module Foo module Bar module ModuleInEnclosingModule;end class ClassInEnclosingModule;end def method_in_enclosing_module;end CONSTANT_IN_ENCLOSING_MODULE = 0 describe "Class and Module and Const defined in enclosing module are accessible and Methods are not, so Examples" do it "does automatically get access to the context of Foo::Bar" do ModuleInEnclosingModule end it "does automatically get access to ClassInEnclosingModule" do ClassInEnclosingModule.new end it "does automatically get access to CONSTANT_IN_ENCLOSING_MODULE" do CONSTANT_IN_ENCLOSING_MODULE end it "does not automatically get access to method_in_enclosing_module" do lambda {method_in_enclosing_module}.should raise_error(/undefined/) end describe "that live inside a nested group" do it "does automatically get access to the context of Foo::Bar" do Foo::Bar end it "does automatically get access to ClassInEnclosingModule" do ClassInEnclosingModule.new end it "does automatically get access to CONSTANT_IN_ENCLOSING_MODULE" do CONSTANT_IN_ENCLOSING_MODULE end it "does automatically get access to method_in_enclosing_module" do lambda {method_in_enclosing_module}.should raise_error(/undefined/) end end end describe "Method and Class and Module and Method defined in group are accessible, so examples" do module ModuleDefinedInGroup;end class ClassDefinedInGroup; end def method_defined_in_group; end CONSTANT_DEFINED_IN_GROUP = 0 it "does automatically get access to the context of Foo::Bar" do ModuleDefinedInGroup end it "does automatically get access to ClassDefinedInGroup" do ClassDefinedInGroup.new end it "does automatically get access to CONSTANT_DEFINED_IN_GROUP" do CONSTANT_DEFINED_IN_GROUP end it "does automatically get access to method_defined_in_group" do method_defined_in_group end describe "that live inside a nested group" do it "does automatically get access to the context of Foo::Bar" do ModuleDefinedInGroup end it "does automatically get access to ClassDefinedInGroup" do ClassDefinedInGroup.new end it "does automatically get access to CONSTANT_DEFINED_IN_GROUP" do CONSTANT_DEFINED_IN_GROUP end it "does automatically get access to method_defined_in_group" do method_defined_in_group end end end end end Assuming that these examples would pass with both 1.8 and 1.9. Would that be the desired behavior? Matthias -- View this message in context: http://www.nabble.com/Ruby-1.9-and-constant-lookup-rules-tp21237683p21267971.html Sent from the rspec-devel mailing list archive at Nabble.com. From dchelimsky at gmail.com Sat Jan 3 14:50:05 2009 From: dchelimsky at gmail.com (David Chelimsky) Date: Sat, 3 Jan 2009 13:50:05 -0600 Subject: [rspec-devel] Ruby 1.9 and constant lookup rules In-Reply-To: <21267971.post@talk.nabble.com> References: <57c63afe0812311444k65203703tacad8a5c11504dbd@mail.gmail.com> <21264451.post@talk.nabble.com> <57c63afe0901030643m2a6d8b9exeb329587635dd078@mail.gmail.com> <21267971.post@talk.nabble.com> Message-ID: <57c63afe0901031150w49c6ce6dg2a42f14488f344f8@mail.gmail.com> On Sat, Jan 3, 2009 at 12:55 PM, mhennemeyer wrote: > > What do you think about a compatibility specific example suite? > One that passes if executed with ruby 1.8 and fails with ruby 1.9. > If we had this, it would be easier to see if an implementation > matches the desired behavior. > My first examples, focused at the current topic would be as follows: > > (Pastie: http://pastie.org/351682) Looks good. I modified the docstrings a bit and committed this to http://github.com/dchelimsky/rspec/tree/master/examples/ruby1.9.compatibility/access_to_constants_spec.rb. Once cucumber supports 1.9, we'll move that content to cucumber scenarios (lots of moving parts here!) Cheers, David From dchelimsky at gmail.com Sun Jan 4 11:41:21 2009 From: dchelimsky at gmail.com (David Chelimsky) Date: Sun, 4 Jan 2009 10:41:21 -0600 Subject: [rspec-devel] [ANN] RSpec-1.1.12 - RC1 Message-ID: <57c63afe0901040841m655f4eb2i835833d5ee581778@mail.gmail.com> Hey all, I'm getting ready to do a 1.1.12 release of rspec and rspec-rails. Given the history of release-related compatibility problems, I offer you release candidate gems, which you can acquire thusly: [sudo] gem install dchelimsky-rspec -v 1.1.11.5 --source http://gems.github.com [sudo] gem install dchelimsky-rspec-rails -v 1.1.11.5 --source http://gems.github.com Release notes can be seen under Maintenance at: http://github.com/dchelimsky/rspec/tree/master/History.txt http://github.com/dchelimsky/rspec-rails/tree/master/History.txt NOTE: This will be the last release of rspec-rails that supports rails < 2.0 If you are so inclined, please grab these gems, use them, and let me know if everything is AOK. Cheers, David From luislavena at gmail.com Sun Jan 4 11:50:37 2009 From: luislavena at gmail.com (Luis Lavena) Date: Sun, 4 Jan 2009 14:50:37 -0200 Subject: [rspec-devel] [ANN] RSpec-1.1.12 - RC1 In-Reply-To: <57c63afe0901040841m655f4eb2i835833d5ee581778@mail.gmail.com> References: <57c63afe0901040841m655f4eb2i835833d5ee581778@mail.gmail.com> Message-ID: <71166b3b0901040850y12f0203cp651b50378aeda487@mail.gmail.com> On Sun, Jan 4, 2009 at 2:41 PM, David Chelimsky wrote: > Hey all, > > I'm getting ready to do a 1.1.12 release of rspec and rspec-rails. > Given the history of release-related compatibility problems, I offer > you release candidate gems, which you can acquire thusly: > > [sudo] gem install dchelimsky-rspec -v 1.1.11.5 --source http://gems.github.com > [sudo] gem install dchelimsky-rspec-rails -v 1.1.11.5 --source > http://gems.github.com > > Release notes can be seen under Maintenance at: > > http://github.com/dchelimsky/rspec/tree/master/History.txt > http://github.com/dchelimsky/rspec-rails/tree/master/History.txt > > NOTE: This will be the last release of rspec-rails that supports rails < 2.0 > > If you are so inclined, please grab these gems, use them, and let me > know if everything is AOK. > Thank you David for the head's up. One of the problems that github gems generates is related to gem dependencies (once again). Luis at KEORE (D:\Users\Luis\projects\oss\oci\dsl2) $ gem install dchelimsky-rspec --source http://gems.github.com Successfully installed dchelimsky-rspec-1.1.11.5 1 gem installed Luis at KEORE (D:\Users\Luis\projects\oss\oci\dsl2) $ gem install dchelimsky-rspec-rails --source http://gems.github.com ERROR: Error installing dchelimsky-rspec-rails: dchelimsky-rspec-rails requires rspec (= 1.1.11.5, runtime) As you can see, dchelimsky-rspec-rails marked 'rspec' as runtime dependency, not dchelimsky-rspec. This forces users to download the repo and build the gem locally. Regards, -- Luis Lavena AREA 17 - Perfection in design is achieved not when there is nothing more to add, but rather when there is nothing more to take away. Antoine de Saint-Exup?ry From dchelimsky at gmail.com Sun Jan 4 12:10:01 2009 From: dchelimsky at gmail.com (David Chelimsky) Date: Sun, 4 Jan 2009 11:10:01 -0600 Subject: [rspec-devel] [ANN] RSpec-1.1.12 - RC1 In-Reply-To: <71166b3b0901040850y12f0203cp651b50378aeda487@mail.gmail.com> References: <57c63afe0901040841m655f4eb2i835833d5ee581778@mail.gmail.com> <71166b3b0901040850y12f0203cp651b50378aeda487@mail.gmail.com> Message-ID: <57c63afe0901040910x4e5942f8lf52ffc8fb27fb77f@mail.gmail.com> On Sun, Jan 4, 2009 at 10:50 AM, Luis Lavena wrote: > On Sun, Jan 4, 2009 at 2:41 PM, David Chelimsky wrote: >> Hey all, >> >> I'm getting ready to do a 1.1.12 release of rspec and rspec-rails. >> Given the history of release-related compatibility problems, I offer >> you release candidate gems, which you can acquire thusly: >> >> [sudo] gem install dchelimsky-rspec -v 1.1.11.5 --source http://gems.github.com >> [sudo] gem install dchelimsky-rspec-rails -v 1.1.11.5 --source >> http://gems.github.com >> >> Release notes can be seen under Maintenance at: >> >> http://github.com/dchelimsky/rspec/tree/master/History.txt >> http://github.com/dchelimsky/rspec-rails/tree/master/History.txt >> >> NOTE: This will be the last release of rspec-rails that supports rails < 2.0 >> >> If you are so inclined, please grab these gems, use them, and let me >> know if everything is AOK. >> > > Thank you David for the head's up. > > One of the problems that github gems generates is related to gem > dependencies (once again). > > > Luis at KEORE (D:\Users\Luis\projects\oss\oci\dsl2) > $ gem install dchelimsky-rspec --source http://gems.github.com > Successfully installed dchelimsky-rspec-1.1.11.5 > 1 gem installed > > Luis at KEORE (D:\Users\Luis\projects\oss\oci\dsl2) > $ gem install dchelimsky-rspec-rails --source http://gems.github.com > ERROR: Error installing dchelimsky-rspec-rails: > dchelimsky-rspec-rails requires rspec (= 1.1.11.5, runtime) > > As you can see, dchelimsky-rspec-rails marked 'rspec' as runtime > dependency, not dchelimsky-rspec. > > This forces users to download the repo and build the gem locally. Thanks for this info. I also see that rubygems is having trouble uninstalling github-generated gems - at least this one: $ gem list dchelimsky *** LOCAL GEMS *** dchelimsky-rspec (1.1.11.5) $ sudo gem uninstall dchelimsky-rspec ERROR: While executing gem ... (Gem::InstallError) Unknown gem dchelimsky-rspec >= 0 AWESOME! > > Regards, > -- > Luis Lavena > AREA 17 > - > Perfection in design is achieved not when there is nothing more to add, > but rather when there is nothing more to take away. > Antoine de Saint-Exup?ry > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel From aslak.hellesoy at gmail.com Sun Jan 4 12:19:29 2009 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Sun, 4 Jan 2009 18:19:29 +0100 Subject: [rspec-devel] [ANN] RSpec-1.1.12 - RC1 In-Reply-To: <57c63afe0901040910x4e5942f8lf52ffc8fb27fb77f@mail.gmail.com> References: <57c63afe0901040841m655f4eb2i835833d5ee581778@mail.gmail.com> <71166b3b0901040850y12f0203cp651b50378aeda487@mail.gmail.com> <57c63afe0901040910x4e5942f8lf52ffc8fb27fb77f@mail.gmail.com> Message-ID: <8d961d900901040919x629532f5wa3c240488c8d00c8@mail.gmail.com> On Sun, Jan 4, 2009 at 6:10 PM, David Chelimsky wrote: > On Sun, Jan 4, 2009 at 10:50 AM, Luis Lavena wrote: > > On Sun, Jan 4, 2009 at 2:41 PM, David Chelimsky > wrote: > >> Hey all, > >> > >> I'm getting ready to do a 1.1.12 release of rspec and rspec-rails. > >> Given the history of release-related compatibility problems, I offer > >> you release candidate gems, which you can acquire thusly: > >> > >> [sudo] gem install dchelimsky-rspec -v 1.1.11.5 --source > http://gems.github.com > >> [sudo] gem install dchelimsky-rspec-rails -v 1.1.11.5 --source > >> http://gems.github.com > >> > >> Release notes can be seen under Maintenance at: > >> > >> http://github.com/dchelimsky/rspec/tree/master/History.txt > >> http://github.com/dchelimsky/rspec-rails/tree/master/History.txt > >> > >> NOTE: This will be the last release of rspec-rails that supports rails < > 2.0 > >> > >> If you are so inclined, please grab these gems, use them, and let me > >> know if everything is AOK. > >> > > > > Thank you David for the head's up. > > > > One of the problems that github gems generates is related to gem > > dependencies (once again). > > > > > > Luis at KEORE (D:\Users\Luis\projects\oss\oci\dsl2) > > $ gem install dchelimsky-rspec --source http://gems.github.com > > Successfully installed dchelimsky-rspec-1.1.11.5 > > 1 gem installed > > > > Luis at KEORE (D:\Users\Luis\projects\oss\oci\dsl2) > > $ gem install dchelimsky-rspec-rails --source http://gems.github.com > > ERROR: Error installing dchelimsky-rspec-rails: > > dchelimsky-rspec-rails requires rspec (= 1.1.11.5, runtime) > > > > As you can see, dchelimsky-rspec-rails marked 'rspec' as runtime > > dependency, not dchelimsky-rspec. > > > > This forces users to download the repo and build the gem locally. > > Thanks for this info. I also see that rubygems is having trouble > uninstalling github-generated gems - at least this one: > > $ gem list dchelimsky > > *** LOCAL GEMS *** > > dchelimsky-rspec (1.1.11.5) > $ sudo gem uninstall dchelimsky-rspec > ERROR: While executing gem ... (Gem::InstallError) > Unknown gem dchelimsky-rspec >= 0 > > AWESOME! > Time to buy a new laptop or reinstall the OS? > > > > > > Regards, > > -- > > Luis Lavena > > AREA 17 > > - > > Perfection in design is achieved not when there is nothing more to add, > > but rather when there is nothing more to take away. > > Antoine de Saint-Exup?ry > > _______________________________________________ > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From luislavena at gmail.com Sun Jan 4 12:20:14 2009 From: luislavena at gmail.com (Luis Lavena) Date: Sun, 4 Jan 2009 15:20:14 -0200 Subject: [rspec-devel] [ANN] RSpec-1.1.12 - RC1 In-Reply-To: <57c63afe0901040910x4e5942f8lf52ffc8fb27fb77f@mail.gmail.com> References: <57c63afe0901040841m655f4eb2i835833d5ee581778@mail.gmail.com> <71166b3b0901040850y12f0203cp651b50378aeda487@mail.gmail.com> <57c63afe0901040910x4e5942f8lf52ffc8fb27fb77f@mail.gmail.com> Message-ID: <71166b3b0901040920n34e557b4t3257f0bfaae4c407@mail.gmail.com> On Sun, Jan 4, 2009 at 3:10 PM, David Chelimsky wrote: > On Sun, Jan 4, 2009 at 10:50 AM, Luis Lavena wrote: >> ... > > Thanks for this info. I also see that rubygems is having trouble > uninstalling github-generated gems - at least this one: > > $ gem list dchelimsky > > *** LOCAL GEMS *** > > dchelimsky-rspec (1.1.11.5) > $ sudo gem uninstall dchelimsky-rspec > ERROR: While executing gem ... (Gem::InstallError) > Unknown gem dchelimsky-rspec >= 0 > Uninstall worked without a glitch here: Luis at KEORE (D:\Users\Luis\projects\oss\oci\dsl2) $ gem uninstall dchelimsky-rspec Remove executables: autospec, spec in addition to the gem? [Yn] Removing autospec Removing spec Successfully uninstalled dchelimsky-rspec-1.1.11.5 RubyGems 1.3.1 > AWESOME! > Yeah, there is always a new thing around it ;-) -- Luis Lavena AREA 17 - Perfection in design is achieved not when there is nothing more to add, but rather when there is nothing more to take away. Antoine de Saint-Exup?ry From dchelimsky at gmail.com Sun Jan 4 13:22:42 2009 From: dchelimsky at gmail.com (David Chelimsky) Date: Sun, 4 Jan 2009 12:22:42 -0600 Subject: [rspec-devel] [ANN] RSpec-1.1.12 - RC1 In-Reply-To: <57c63afe0901040841m655f4eb2i835833d5ee581778@mail.gmail.com> References: <57c63afe0901040841m655f4eb2i835833d5ee581778@mail.gmail.com> Message-ID: <57c63afe0901041022m7f1c324fm7049b93bf6f20210@mail.gmail.com> On Sun, Jan 4, 2009 at 10:41 AM, David Chelimsky wrote: > Hey all, > > I'm getting ready to do a 1.1.12 release of rspec and rspec-rails. > Given the history of release-related compatibility problems, I offer > you release candidate gems, which you can acquire thusly: > > [sudo] gem install dchelimsky-rspec -v 1.1.11.5 --source http://gems.github.com > [sudo] gem install dchelimsky-rspec-rails -v 1.1.11.5 --source > http://gems.github.com Fixed gem dependency issue related to github-generated gems (prefixed w/ usernames). Try 1.1.11.6 instead: gem sources -a http://gems.github.com gem install dchelimsky-rspec -v 1.1.11.6 gem install dchelimsky-rspec-rails -v 1.1.11.6 Cheers, David > > Release notes can be seen under Maintenance at: > > http://github.com/dchelimsky/rspec/tree/master/History.txt > http://github.com/dchelimsky/rspec-rails/tree/master/History.txt > > NOTE: This will be the last release of rspec-rails that supports rails < 2.0 > > If you are so inclined, please grab these gems, use them, and let me > know if everything is AOK. > > Cheers, > David > From aslak.hellesoy at gmail.com Sun Jan 4 13:50:11 2009 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Sun, 4 Jan 2009 19:50:11 +0100 Subject: [rspec-devel] [ANN] Cucumber 0.1.14 Message-ID: <8d961d900901041050pd052a6dgd0d4c671d130bc66@mail.gmail.com> Now with Ruby 1.9 support! Full changelog: http://github.com/aslakhellesoy/cucumber/tree/v0.1.14/History.txt The gem will be available in an hour or two. Aslak -------------- next part -------------- An HTML attachment was scrubbed... URL: From dchelimsky at gmail.com Sun Jan 4 13:55:06 2009 From: dchelimsky at gmail.com (David Chelimsky) Date: Sun, 4 Jan 2009 12:55:06 -0600 Subject: [rspec-devel] [ANN] Cucumber 0.1.14 In-Reply-To: <8d961d900901041050pd052a6dgd0d4c671d130bc66@mail.gmail.com> References: <8d961d900901041050pd052a6dgd0d4c671d130bc66@mail.gmail.com> Message-ID: <57c63afe0901041055s4ac8b36fpebe3c299541e3be9@mail.gmail.com> Rock on!!!!! Thanks for this this. It's going to make getting rspec ruby 1.9 compliant much easier (since now I'll be able to run rspec's features!). Cheers, David On Sun, Jan 4, 2009 at 12:50 PM, aslak hellesoy wrote: > Now with Ruby 1.9 support! > > Full changelog: > http://github.com/aslakhellesoy/cucumber/tree/v0.1.14/History.txt > > The gem will be available in an hour or two. > > Aslak > > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From aslak.hellesoy at gmail.com Sun Jan 4 20:55:40 2009 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Mon, 5 Jan 2009 02:55:40 +0100 Subject: [rspec-devel] [ANN] RSpec-1.1.12 - RC1 In-Reply-To: <57c63afe0901041022m7f1c324fm7049b93bf6f20210@mail.gmail.com> References: <57c63afe0901040841m655f4eb2i835833d5ee581778@mail.gmail.com> <57c63afe0901041022m7f1c324fm7049b93bf6f20210@mail.gmail.com> Message-ID: <8d961d900901041755g699aa0bcx71110493511005ef@mail.gmail.com> On Sun, Jan 4, 2009 at 7:22 PM, David Chelimsky wrote: > On Sun, Jan 4, 2009 at 10:41 AM, David Chelimsky > wrote: > > Hey all, > > > > I'm getting ready to do a 1.1.12 release of rspec and rspec-rails. > > Given the history of release-related compatibility problems, I offer > > you release candidate gems, which you can acquire thusly: > > > > [sudo] gem install dchelimsky-rspec -v 1.1.11.5 --source > http://gems.github.com > > [sudo] gem install dchelimsky-rspec-rails -v 1.1.11.5 --source > > http://gems.github.com > > Fixed gem dependency issue related to github-generated gems (prefixed > w/ usernames). Try 1.1.11.6 instead: > > gem sources -a http://gems.github.com > gem install dchelimsky-rspec -v 1.1.11.6 > gem install dchelimsky-rspec-rails -v 1.1.11.6 > Awesome - now get that 1.9 baby rolling! Aslak > > Cheers, > David > > > > > Release notes can be seen under Maintenance at: > > > > http://github.com/dchelimsky/rspec/tree/master/History.txt > > http://github.com/dchelimsky/rspec-rails/tree/master/History.txt > > > > NOTE: This will be the last release of rspec-rails that supports rails < > 2.0 > > > > If you are so inclined, please grab these gems, use them, and let me > > know if everything is AOK. > > > > Cheers, > > David > > > _______________________________________________ > 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 Sun Jan 4 20:58:26 2009 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Mon, 5 Jan 2009 02:58:26 +0100 Subject: [rspec-devel] Voted for Cucumber logo yet? Message-ID: <8d961d900901041758o18fd4a44s10a0e4093d7f851e@mail.gmail.com> If not - please do! http://cukes.info Announcing winner tomorrow. No rallying friends please. Just vote for the best one. Aslak -------------- next part -------------- An HTML attachment was scrubbed... URL: From dchelimsky at gmail.com Wed Jan 7 12:06:41 2009 From: dchelimsky at gmail.com (David Chelimsky) Date: Wed, 7 Jan 2009 11:06:41 -0600 Subject: [rspec-devel] custom runners? Message-ID: <57c63afe0901070906x3e1e41e2sa86522c10b3a951d@mail.gmail.com> Anybody use custom runners? From ben at benmabey.com Wed Jan 7 13:04:59 2009 From: ben at benmabey.com (Ben Mabey) Date: Wed, 07 Jan 2009 11:04:59 -0700 Subject: [rspec-devel] custom runners? In-Reply-To: <57c63afe0901070906x3e1e41e2sa86522c10b3a951d@mail.gmail.com> References: <57c63afe0901070906x3e1e41e2sa86522c10b3a951d@mail.gmail.com> Message-ID: <4964EECB.7000306@benmabey.com> On 1/7/09 10:06 AM, David Chelimsky wrote: > Anybody use custom runners? > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > No. I didn't think doing that was as easy as making a custom formatter. In the past I built in a sort of tagging into my specs and had wanted to make a custom runner to only runner example groups with given tags... I never got that far though. Is there an API for runners, like formatters, that one can easily adhere to accomplish something like that? Of course I could always look at the code more closely myself... From mhennemeyer at gmail.com Wed Jan 7 13:18:59 2009 From: mhennemeyer at gmail.com (mhennemeyer) Date: Wed, 7 Jan 2009 10:18:59 -0800 (PST) Subject: [rspec-devel] Ruby 1.9 and constant lookup rules In-Reply-To: <57c63afe0812311444k65203703tacad8a5c11504dbd@mail.gmail.com> References: <57c63afe0812311444k65203703tacad8a5c11504dbd@mail.gmail.com> Message-ID: <21337216.post@talk.nabble.com> I have created a patch that lets the examples/ruby1.9.compatibility/access_to_constants_spec.rb pass. It uses const_missing and doesn't require any additional xxx_evals: http://rspec.lighthouseapp.com/projects/5645-rspec/tickets/649-look-up-constants-in-enclosing-module-remove-the-include-scope-hack Unfortunatly i had no idea how to write any examples other than the existing compatibility examples mentioned above for this problem. Question: How to write an example (that is not an ugly white-box-test) that fails in ruby 1.8 - for a problem that doesn't exist in ruby 1.8? Matthias -- View this message in context: http://www.nabble.com/Ruby-1.9-and-constant-lookup-rules-tp21237683p21337216.html Sent from the rspec-devel mailing list archive at Nabble.com. From dchelimsky at gmail.com Wed Jan 7 13:33:39 2009 From: dchelimsky at gmail.com (David Chelimsky) Date: Wed, 7 Jan 2009 12:33:39 -0600 Subject: [rspec-devel] Ruby 1.9 and constant lookup rules In-Reply-To: <21337216.post@talk.nabble.com> References: <57c63afe0812311444k65203703tacad8a5c11504dbd@mail.gmail.com> <21337216.post@talk.nabble.com> Message-ID: <57c63afe0901071033y5c049cdq54b345510cf19b9e@mail.gmail.com> On Wed, Jan 7, 2009 at 12:18 PM, mhennemeyer wrote: > > I have created a patch that lets the > examples/ruby1.9.compatibility/access_to_constants_spec.rb pass. > It uses const_missing and doesn't require any additional > xxx_evals: > > http://rspec.lighthouseapp.com/projects/5645-rspec/tickets/649-look-up-constants-in-enclosing-module-remove-the-include-scope-hack Great! I'll review it shortly. > > Unfortunatly i had no idea how to write any examples > other than the existing compatibility examples mentioned above for this > problem. > > Question: How to write an example (that is not an ugly white-box-test) > that fails in ruby 1.8 - for a problem that doesn't exist in ruby 1.8? I actually don't think that's necessary. I think we just need to run against 1.8 and 1.9 as part of an acceptance suite (which is currently mostly automated, but this part is manual). David > > Matthias > -- > View this message in context: http://www.nabble.com/Ruby-1.9-and-constant-lookup-rules-tp21237683p21337216.html > Sent from the rspec-devel mailing list archive at Nabble.com. > > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From dchelimsky at gmail.com Wed Jan 7 13:43:35 2009 From: dchelimsky at gmail.com (David Chelimsky) Date: Wed, 7 Jan 2009 12:43:35 -0600 Subject: [rspec-devel] custom runners? In-Reply-To: <4964EECB.7000306@benmabey.com> References: <57c63afe0901070906x3e1e41e2sa86522c10b3a951d@mail.gmail.com> <4964EECB.7000306@benmabey.com> Message-ID: <57c63afe0901071043i1875d667n5b3972865f6fd8dc@mail.gmail.com> On Wed, Jan 7, 2009 at 12:04 PM, Ben Mabey wrote: > On 1/7/09 10:06 AM, David Chelimsky wrote: >> >> Anybody use custom runners? >> _______________________________________________ >> rspec-devel mailing list >> rspec-devel at rubyforge.org >> http://rubyforge.org/mailman/listinfo/rspec-devel >> > > No. I didn't think doing that was as easy as making a custom formatter. In > the past I built in a sort of tagging into my specs and had wanted to make a > custom runner to only runner example groups with given tags... I never got > that far though. Is there an API for runners, like formatters, that one can > easily adhere to accomplish something like that? Of course I could always > look at the code more closely myself... Actually, there is a reason behind the question: I'm seriously considering running rspec 1.2 (or should it be 2.0?) on either test/unit or mini/unit. This would essentially mean that custom runners (and custom example group classes) would now have to derive from rspec classes (which would derive from t/u or m/u classes). So now that I've opened that door - any thoughts on that? From mhennemeyer at gmail.com Wed Jan 7 14:33:20 2009 From: mhennemeyer at gmail.com (mhennemeyer) Date: Wed, 7 Jan 2009 11:33:20 -0800 (PST) Subject: [rspec-devel] custom runners? In-Reply-To: <57c63afe0901071043i1875d667n5b3972865f6fd8dc@mail.gmail.com> References: <57c63afe0901070906x3e1e41e2sa86522c10b3a951d@mail.gmail.com> <4964EECB.7000306@benmabey.com> <57c63afe0901071043i1875d667n5b3972865f6fd8dc@mail.gmail.com> Message-ID: <21338622.post@talk.nabble.com> David Chelimsky-2 wrote: > > I'm seriously considering running rspec 1.2 (or should it be 2.0?) on > either test/unit or mini/unit. This would essentially mean that custom > runners (and custom example group classes) would now have to derive > from rspec classes (which would derive from t/u or m/u classes). > > So now that I've opened that door - any thoughts on that? > What do you think about going even a step further and introduce an abstract testing framework that lets you build rspec on top but also t/u or m/u or ... ? Something that relates to ruby testing a bit like rack ( http://rack.rubyforge.org/ ) relates to ruby web frameworks. There are underlying similarities in all testing-frameworks and if we would be able to abstract them from the differences, it would be possible that the community acts jointly to build the infrastructure for rspec, t/u and m/u. Just to accompany: An abstract testing framework would have to define well formed interfaces for plugging in: 1. A testing DSL that itself is used to build an abstract testing tree that again is what will be run by the system. 2. A mocking framework. 3. Formatters/Reporters. ... ...still impressed by the merb-rails-merge Matthias -- View this message in context: http://www.nabble.com/custom-runners--tp21336079p21338622.html Sent from the rspec-devel mailing list archive at Nabble.com. From dchelimsky at gmail.com Wed Jan 7 19:25:15 2009 From: dchelimsky at gmail.com (David Chelimsky) Date: Wed, 7 Jan 2009 18:25:15 -0600 Subject: [rspec-devel] custom runners? In-Reply-To: <21338622.post@talk.nabble.com> References: <57c63afe0901070906x3e1e41e2sa86522c10b3a951d@mail.gmail.com> <4964EECB.7000306@benmabey.com> <57c63afe0901071043i1875d667n5b3972865f6fd8dc@mail.gmail.com> <21338622.post@talk.nabble.com> Message-ID: <57c63afe0901071625i5b9d0de0n49a87ff27243512a@mail.gmail.com> On Wed, Jan 7, 2009 at 1:33 PM, mhennemeyer wrote: > > David Chelimsky-2 wrote: >> >> I'm seriously considering running rspec 1.2 (or should it be 2.0?) on >> either test/unit or mini/unit. This would essentially mean that custom >> runners (and custom example group classes) would now have to derive >> from rspec classes (which would derive from t/u or m/u classes). >> >> So now that I've opened that door - any thoughts on that? >> > > What do you think about going even a step further and > introduce an abstract testing framework that lets you build rspec on top but > also t/u or m/u or ... ? > Something that relates to ruby testing a bit like > rack ( http://rack.rubyforge.org/ ) relates to ruby web frameworks. This exact idea has come up in a number of conversations lately, and I'd support it fully if we could get buy-in from Ryan Davis who wrote and maintains miniunit and, I think, is maintaining test/unit as well (but I'm not sure). Let me run the idea by him and see what he says. > > There are underlying similarities in all testing-frameworks and if we would > be able to abstract them from > the differences, it would be possible that the community acts jointly to > build the infrastructure for rspec, t/u and m/u. > > Just to accompany: > > An abstract testing framework would have to define well formed interfaces > for plugging in: > > 1. A testing DSL that itself is used to build an abstract testing tree that > again is what will be run by the system. > > 2. A mocking framework. > > 3. Formatters/Reporters. ... > > > > ...still impressed by the merb-rails-merge > > Matthias > > > > -- > View this message in context: http://www.nabble.com/custom-runners--tp21336079p21338622.html > Sent from the rspec-devel mailing list archive at Nabble.com. > > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From dchelimsky at gmail.com Thu Jan 22 10:15:18 2009 From: dchelimsky at gmail.com (David Chelimsky) Date: Thu, 22 Jan 2009 09:15:18 -0600 Subject: [rspec-devel] test/unit interop Message-ID: <57c63afe0901220715h8fae3b2g6f230a1c9d70ac1@mail.gmail.com> Hey all, As you (hopefully) know, rspec is fully interop'able with test/unit. There are two ways to make it happen right now. The prescribed way is to require 'test/unit' before you require 'spec': require 'test/unit' require 'spec' This way, when rspec loads it checks to see if test/unit is loaded and, if so, loads the interop code. The problem with this strategy is that if you invoke the spec with the spec command, require 'spec' won't cause anything to happen. The alternative, lesser publicized approach, is to explicitly load the interop code after rspec: require 'spec' require 'spec/interop/test' This *always* works, but that require is ugly, IMO. I'm thinking of adding 'spec/test/unit', so if you're using 'test/unit' and you want to migrate to rspec, you just change: require 'test/unit' to require 'spec/test/unit' Another suggestion that came up was a means of explicitly setting the base class to Test::Unit::TestCase. So you'd do something like require 'spec' Spec::ExampleGroup = Test::Unit::TestCase There are some tricky things about this, but it's probably doable. I like this because it's explicit and declarative. I don't like it because it's less simple than just changing the require. Thoughts? I need to make these changes today or tomorrow if their going to make the beta book release. Cheers, David From mhennemeyer at gmail.com Thu Jan 22 10:36:58 2009 From: mhennemeyer at gmail.com (mhennemeyer) Date: Thu, 22 Jan 2009 07:36:58 -0800 (PST) Subject: [rspec-devel] custom runners? In-Reply-To: <57c63afe0901070906x3e1e41e2sa86522c10b3a951d@mail.gmail.com> References: <57c63afe0901070906x3e1e41e2sa86522c10b3a951d@mail.gmail.com> Message-ID: <21606684.post@talk.nabble.com> David, i have played with minitest a little bit and hacked together a (kinda) framework that provides a set of functionality between rspec and minitest/spec. (say : minispec + nested example groups and 'obj.should matcher' syntax) Please try it (self contained script with examples, only dependency is minitest) : http://pastie.org/367764 Of course it is experimental (and involves at least one dirty trick) but it is working, fast, 1.9 compatible and fun. My rating, based on these experiences, is that it would be relatively easy to rebuild rspec on top of minitest. (Needless to say that having a generic framework (as mentioned) would be superior) Matthias -- View this message in context: http://www.nabble.com/custom-runners--tp21336079p21606684.html Sent from the rspec-devel mailing list archive at Nabble.com. From philodespotos at gmail.com Thu Jan 22 10:49:16 2009 From: philodespotos at gmail.com (Kyle Hargraves) Date: Thu, 22 Jan 2009 09:49:16 -0600 Subject: [rspec-devel] test/unit interop In-Reply-To: <57c63afe0901220715h8fae3b2g6f230a1c9d70ac1@mail.gmail.com> References: <57c63afe0901220715h8fae3b2g6f230a1c9d70ac1@mail.gmail.com> Message-ID: <60f3810c0901220749p3ed7e7b8p8c5f73c35d8093d@mail.gmail.com> On Thu, Jan 22, 2009 at 9:15 AM, David Chelimsky wrote: > require 'spec/test/unit' I barely use the interop, but this is intuitive and tells me immediately what it's doing: loading (r)spec with test/unit support. > Another suggestion that came up was a means of explicitly setting the > base class to Test::Unit::TestCase. So you'd do something like > > require 'spec' > Spec::ExampleGroup = Test::Unit::TestCase If I've just decided to make the transition from test/unit to rspec, I probably have no idea what an ExampleGroup is, and it feels pretty weird to start be assigning constants inside some project's namespace. Definitely +1 for spec/test/unit over the above. k From scott at railsnewbie.com Thu Jan 22 11:40:49 2009 From: scott at railsnewbie.com (Scott Taylor) Date: Thu, 22 Jan 2009 11:40:49 -0500 Subject: [rspec-devel] test/unit interop In-Reply-To: <60f3810c0901220749p3ed7e7b8p8c5f73c35d8093d@mail.gmail.com> References: <57c63afe0901220715h8fae3b2g6f230a1c9d70ac1@mail.gmail.com> <60f3810c0901220749p3ed7e7b8p8c5f73c35d8093d@mail.gmail.com> Message-ID: <4978A191.2020408@railsnewbie.com> Kyle Hargraves wrote: > On Thu, Jan 22, 2009 at 9:15 AM, David Chelimsky wrote: > >> require 'spec/test/unit' >> > > I barely use the interop, but this is intuitive and tells me > immediately what it's doing: loading (r)spec with test/unit support. > Yeah, I like this one too, and don't find it ugly at all. It's also a bit easier to hack when something goes wrong (say, rails loads Test::Unit without my knowledge). Scott From jim.weirich at gmail.com Thu Jan 22 15:30:29 2009 From: jim.weirich at gmail.com (Jim Weirich) Date: Thu, 22 Jan 2009 15:30:29 -0500 Subject: [rspec-devel] test/unit interop In-Reply-To: <57c63afe0901220715h8fae3b2g6f230a1c9d70ac1@mail.gmail.com> References: <57c63afe0901220715h8fae3b2g6f230a1c9d70ac1@mail.gmail.com> Message-ID: On Jan 22, 2009, at 10:15 AM, David Chelimsky wrote: > require 'spec' > Spec::ExampleGroup = Test::Unit::TestCase > > There are some tricky things about this, but it's probably doable. I > like this because it's explicit and declarative. I don't like it > because it's less simple than just changing the require. Your gut reaction that it is tricky is correct. To me, it looks neither explicit (what the hell is an ExampleGroup?) nor declarative (assignment statements, the hallmark of an imperative language, are now declarative?). In fact, it looks like you are twiddling with the innards of RSpec. Even if you are not, that's what it looks like. +100 on the require 'rspec/test/unit' technique. [1] -- -- Jim Weirich -- jim.weirich at gmail.com [1] BTW, FlexMock uses the same technique for compatibility. require 'flexmock/test_unit' loads the test unit adapters for flexmock. We don't even try to get tricky and auto-detect. Sometimes explicit is good. From dchelimsky at gmail.com Thu Jan 22 15:43:29 2009 From: dchelimsky at gmail.com (David Chelimsky) Date: Thu, 22 Jan 2009 14:43:29 -0600 Subject: [rspec-devel] test/unit interop In-Reply-To: References: <57c63afe0901220715h8fae3b2g6f230a1c9d70ac1@mail.gmail.com> Message-ID: <57c63afe0901221243u159c5903udc8ce0880552d5ff@mail.gmail.com> On Thu, Jan 22, 2009 at 2:30 PM, Jim Weirich wrote: > > On Jan 22, 2009, at 10:15 AM, David Chelimsky wrote: > >> require 'spec' >> Spec::ExampleGroup = Test::Unit::TestCase >> >> There are some tricky things about this, but it's probably doable. I >> like this because it's explicit and declarative. I don't like it >> because it's less simple than just changing the require. > > Your gut reaction that it is tricky is correct. To me, it looks neither > explicit (what the hell is an ExampleGroup?) nor declarative (assignment > statements, the hallmark of an imperative language, are now declarative?). > > In fact, it looks like you are twiddling with the innards of RSpec. Even if > you are not, that's what it looks like. > > +100 on the require 'rspec/test/unit' technique. [1] Interesting that you wrote 'rspec/test/unit' and not 'spec/test/unit' :) I've been thinking of changing the namespace to from Spec to Rspec (leaving aliases in place, of course, for the foreseeable future). Then you'd require 'rspec' and use an rspec command, etc, etc. But perhaps that's a topic for a separate thread ;) Cheers, David > > -- > -- Jim Weirich > -- jim.weirich at gmail.com > > [1] BTW, FlexMock uses the same technique for compatibility. require > 'flexmock/test_unit' loads the test unit adapters for flexmock. We don't > even try to get tricky and auto-detect. Sometimes explicit is good. > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From chad.humphries at gmail.com Thu Jan 22 19:39:40 2009 From: chad.humphries at gmail.com (Chad Humphries) Date: Thu, 22 Jan 2009 19:39:40 -0500 Subject: [rspec-devel] test/unit interop In-Reply-To: <57c63afe0901221243u159c5903udc8ce0880552d5ff@mail.gmail.com> References: <57c63afe0901220715h8fae3b2g6f230a1c9d70ac1@mail.gmail.com> <57c63afe0901221243u159c5903udc8ce0880552d5ff@mail.gmail.com> Message-ID: <24BC4726-8DAF-4375-AD1D-8330DC5293E1@gmail.com> I agree on on the require vs assignment, and the rspec vs spec. I do agree that it would need to keep compatibility for the near term. Cheers, Chad Humphries On Jan 22, 2009, at 3:43 PM, David Chelimsky wrote: > On Thu, Jan 22, 2009 at 2:30 PM, Jim Weirich > wrote: >> >> On Jan 22, 2009, at 10:15 AM, David Chelimsky wrote: >> >>> require 'spec' >>> Spec::ExampleGroup = Test::Unit::TestCase >>> >>> There are some tricky things about this, but it's probably doable. I >>> like this because it's explicit and declarative. I don't like it >>> because it's less simple than just changing the require. >> >> Your gut reaction that it is tricky is correct. To me, it looks >> neither >> explicit (what the hell is an ExampleGroup?) nor declarative >> (assignment >> statements, the hallmark of an imperative language, are now >> declarative?). >> >> In fact, it looks like you are twiddling with the innards of >> RSpec. Even if >> you are not, that's what it looks like. >> >> +100 on the require 'rspec/test/unit' technique. [1] > > Interesting that you wrote 'rspec/test/unit' and not 'spec/test/ > unit' :) > > I've been thinking of changing the namespace to from Spec to Rspec > (leaving aliases in place, of course, for the foreseeable future). > > Then you'd require 'rspec' and use an rspec command, etc, etc. > > But perhaps that's a topic for a separate thread ;) > > Cheers, > David > >> >> -- >> -- Jim Weirich >> -- jim.weirich at gmail.com >> >> [1] BTW, FlexMock uses the same technique for compatibility. require >> 'flexmock/test_unit' loads the test unit adapters for flexmock. We >> don't >> even try to get tricky and auto-detect. Sometimes explicit is good. >> _______________________________________________ >> 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 aslak.hellesoy at gmail.com Thu Jan 22 20:10:23 2009 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Fri, 23 Jan 2009 02:10:23 +0100 Subject: [rspec-devel] test/unit interop In-Reply-To: <24BC4726-8DAF-4375-AD1D-8330DC5293E1@gmail.com> References: <57c63afe0901220715h8fae3b2g6f230a1c9d70ac1@mail.gmail.com> <57c63afe0901221243u159c5903udc8ce0880552d5ff@mail.gmail.com> <24BC4726-8DAF-4375-AD1D-8330DC5293E1@gmail.com> Message-ID: <8d961d900901221710wc01cd72qb79c2968aa63fc84@mail.gmail.com> On Fri, Jan 23, 2009 at 1:39 AM, Chad Humphries wrote: > I agree on on the require vs assignment, and the rspec vs spec. I do > agree that it would need to keep compatibility for the near term. > > Cheers, > > Chad Humphries > > > On Jan 22, 2009, at 3:43 PM, David Chelimsky wrote: > > On Thu, Jan 22, 2009 at 2:30 PM, Jim Weirich >> wrote: >> >>> >>> On Jan 22, 2009, at 10:15 AM, David Chelimsky wrote: >>> >>> require 'spec' >>>> Spec::ExampleGroup = Test::Unit::TestCase >>>> >>>> There are some tricky things about this, but it's probably doable. I >>>> like this because it's explicit and declarative. I don't like it >>>> because it's less simple than just changing the require. >>>> >>> >>> Your gut reaction that it is tricky is correct. To me, it looks neither >>> explicit (what the hell is an ExampleGroup?) nor declarative (assignment >>> statements, the hallmark of an imperative language, are now >>> declarative?). >>> >>> In fact, it looks like you are twiddling with the innards of RSpec. Even >>> if >>> you are not, that's what it looks like. >>> >>> +100 on the require 'rspec/test/unit' technique. [1] >>> >> >> Interesting that you wrote 'rspec/test/unit' and not 'spec/test/unit' :) >> >> I've been thinking of changing the namespace to from Spec to Rspec >> (leaving aliases in place, of course, for the foreseeable future). >> >> Then you'd require 'rspec' and use an rspec command, etc, etc. >> > Plus, it would be in accordance with good gem/lib naming conventions. > >> But perhaps that's a topic for a separate thread ;) >> >> Cheers, >> David >> >> >>> -- >>> -- Jim Weirich >>> -- jim.weirich at gmail.com >>> >>> [1] BTW, FlexMock uses the same technique for compatibility. require >>> 'flexmock/test_unit' loads the test unit adapters for flexmock. We don't >>> even try to get tricky and auto-detect. Sometimes explicit is good. >>> _______________________________________________ >>> 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 >> > > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > -- Aslak (::) -------------- next part -------------- An HTML attachment was scrubbed... URL: From zach.dennis at gmail.com Fri Jan 23 09:39:49 2009 From: zach.dennis at gmail.com (Zach Dennis) Date: Fri, 23 Jan 2009 09:39:49 -0500 Subject: [rspec-devel] test/unit interop In-Reply-To: <24BC4726-8DAF-4375-AD1D-8330DC5293E1@gmail.com> References: <57c63afe0901220715h8fae3b2g6f230a1c9d70ac1@mail.gmail.com> <57c63afe0901221243u159c5903udc8ce0880552d5ff@mail.gmail.com> <24BC4726-8DAF-4375-AD1D-8330DC5293E1@gmail.com> Message-ID: <85d99afe0901230639n16724500s4875f77981dfa166@mail.gmail.com> On Thu, Jan 22, 2009 at 7:39 PM, Chad Humphries wrote: > I agree on on the require vs assignment, and the rspec vs spec. I do agree > that it would need to keep compatibility for the near term. +1, -- Zach Dennis http://www.continuousthinking.com http://www.mutuallyhuman.com From dchelimsky at gmail.com Fri Jan 23 19:13:44 2009 From: dchelimsky at gmail.com (David Chelimsky) Date: Fri, 23 Jan 2009 18:13:44 -0600 Subject: [rspec-devel] improvements Message-ID: <57c63afe0901231613i208fba4dqaeb6309e87fe41b0@mail.gmail.com> In case anybody is interested, I've been doing some refactoring on rspec over the last couple of weeks. My very unscientific benchmarking (running the suite 5x each) shows the following data: 1.1.11 ran in an avg of 8.99 secs 1.1.12 ran in an avg of 8.59 secs current runs in an avg of 6.47 secs That's a 28% increase since 1.1.11 and a 25% increase since 1.1.12. Still no where near as fast as miniunit, or even test/unit. But progress is progress. Cheers, David From ben at benmabey.com Fri Jan 23 19:54:57 2009 From: ben at benmabey.com (Ben Mabey) Date: Fri, 23 Jan 2009 17:54:57 -0700 Subject: [rspec-devel] improvements In-Reply-To: <57c63afe0901231613i208fba4dqaeb6309e87fe41b0@mail.gmail.com> References: <57c63afe0901231613i208fba4dqaeb6309e87fe41b0@mail.gmail.com> Message-ID: <497A66E1.5070303@benmabey.com> On 1/23/09 5:13 PM, David Chelimsky wrote: > In case anybody is interested, I've been doing some refactoring on > rspec over the last couple of weeks. My very unscientific benchmarking > (running the suite 5x each) shows the following data: > > 1.1.11 ran in an avg of 8.99 secs > 1.1.12 ran in an avg of 8.59 secs > current runs in an avg of 6.47 secs > > That's a 28% increase since 1.1.11 and a 25% increase since 1.1.12. > > Still no where near as fast as miniunit, or even test/unit. But > progress is progress. > > Cheers, > David > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > Very nice! Just curious... Was the goal of the refactoring to improve performance? If so, were there any big gains made by specific changes? Thanks for all the time and work to making the improvements! -Ben From scott at railsnewbie.com Fri Jan 23 20:10:10 2009 From: scott at railsnewbie.com (Scott Taylor) Date: Fri, 23 Jan 2009 20:10:10 -0500 Subject: [rspec-devel] improvements In-Reply-To: <57c63afe0901231613i208fba4dqaeb6309e87fe41b0@mail.gmail.com> References: <57c63afe0901231613i208fba4dqaeb6309e87fe41b0@mail.gmail.com> Message-ID: <497A6A72.7040005@railsnewbie.com> David Chelimsky wrote: > In case anybody is interested, I've been doing some refactoring on > rspec over the last couple of weeks. My very unscientific benchmarking > (running the suite 5x each) shows the following data: > > 1.1.11 ran in an avg of 8.99 secs > 1.1.12 ran in an avg of 8.59 secs > current runs in an avg of 6.47 secs > > That's a 28% increase since 1.1.11 and a 25% increase since 1.1.12. > > Still no where near as fast as miniunit, or even test/unit. But > progress is progress. > But how are you measuring this? My suspicion is that the rspec spec framework may exercise parts of rspec more frequently than other frameworks, which might mean it's gotten faster to run the specs for rspec, but everyone else's specs might have gotten slower. It would be nice to see some benchmarks among the various (ruby) test suites. Scott From scott at railsnewbie.com Fri Jan 23 20:19:27 2009 From: scott at railsnewbie.com (Scott Taylor) Date: Fri, 23 Jan 2009 20:19:27 -0500 Subject: [rspec-devel] improvements In-Reply-To: <497A6A72.7040005@railsnewbie.com> References: <57c63afe0901231613i208fba4dqaeb6309e87fe41b0@mail.gmail.com> <497A6A72.7040005@railsnewbie.com> Message-ID: <497A6C9F.4030004@railsnewbie.com> Scott Taylor wrote: > David Chelimsky wrote: >> In case anybody is interested, I've been doing some refactoring on >> rspec over the last couple of weeks. My very unscientific benchmarking >> (running the suite 5x each) shows the following data: >> >> 1.1.11 ran in an avg of 8.99 secs >> 1.1.12 ran in an avg of 8.59 secs >> current runs in an avg of 6.47 secs >> >> That's a 28% increase since 1.1.11 and a 25% increase since 1.1.12. >> >> Still no where near as fast as miniunit, or even test/unit. But >> progress is progress. >> > > But how are you measuring this? > > My suspicion is that the rspec spec framework may exercise parts of > rspec more frequently than other frameworks, which might mean it's > gotten faster to run the specs for rspec, but everyone else's specs > might have gotten slower. s/frameworks/spec suites/p Scott > > It would be nice to see some benchmarks among the various (ruby) test > suites. > > Scott > > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel From dchelimsky at gmail.com Sat Jan 24 01:52:03 2009 From: dchelimsky at gmail.com (David Chelimsky) Date: Sat, 24 Jan 2009 00:52:03 -0600 Subject: [rspec-devel] improvements In-Reply-To: <497A6A72.7040005@railsnewbie.com> References: <57c63afe0901231613i208fba4dqaeb6309e87fe41b0@mail.gmail.com> <497A6A72.7040005@railsnewbie.com> Message-ID: <57c63afe0901232252k316d5ca5h733a2bb48d487bf5@mail.gmail.com> On Fri, Jan 23, 2009 at 7:10 PM, Scott Taylor wrote: > David Chelimsky wrote: >> >> In case anybody is interested, I've been doing some refactoring on >> rspec over the last couple of weeks. My very unscientific benchmarking >> (running the suite 5x each) shows the following data: >> >> 1.1.11 ran in an avg of 8.99 secs >> 1.1.12 ran in an avg of 8.59 secs >> current runs in an avg of 6.47 secs >> >> That's a 28% increase since 1.1.11 and a 25% increase since 1.1.12. >> >> Still no where near as fast as miniunit, or even test/unit. But >> progress is progress. >> > > But how are you measuring this? > > My suspicion is that the rspec spec framework may exercise parts of rspec > more frequently than other frameworks, which might mean it's gotten faster > to run the specs for rspec, but everyone else's specs might have gotten > slower. > > It would be nice to see some benchmarks among the various (ruby) test > suites. That would be cool to do. RubySpec uses mspec and I think there are some things in there that are unique to mspec, but I'll take a look at that in the coming days. Also, sadly, I neglected to recall an important fact, which is that we yanked the story runner out :) So we're running considerably fewer specs. Still, going back to 1.1.11 and deleting the story specs, it runs at about 7.5 seconds - so there's still a loss of about a second, or 13% - not as sexy as 25%, and certainly still not scientific :) Oh well - onward and upward. > > Scott > > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From dchelimsky at gmail.com Sat Jan 24 01:53:51 2009 From: dchelimsky at gmail.com (David Chelimsky) Date: Sat, 24 Jan 2009 00:53:51 -0600 Subject: [rspec-devel] improvements In-Reply-To: <497A66E1.5070303@benmabey.com> References: <57c63afe0901231613i208fba4dqaeb6309e87fe41b0@mail.gmail.com> <497A66E1.5070303@benmabey.com> Message-ID: <57c63afe0901232253s2cd0a146gc5a1c5f11ad20e2f@mail.gmail.com> On Fri, Jan 23, 2009 at 6:54 PM, Ben Mabey wrote: > On 1/23/09 5:13 PM, David Chelimsky wrote: >> >> In case anybody is interested, I've been doing some refactoring on >> rspec over the last couple of weeks. My very unscientific benchmarking >> (running the suite 5x each) shows the following data: >> >> 1.1.11 ran in an avg of 8.99 secs >> 1.1.12 ran in an avg of 8.59 secs >> current runs in an avg of 6.47 secs >> >> That's a 28% increase since 1.1.11 and a 25% increase since 1.1.12. >> >> Still no where near as fast as miniunit, or even test/unit. But >> progress is progress. >> >> Cheers, >> David >> _______________________________________________ >> rspec-devel mailing list >> rspec-devel at rubyforge.org >> http://rubyforge.org/mailman/listinfo/rspec-devel >> > > Very nice! Just curious... Was the goal of the refactoring to improve > performance? If so, were there any big gains made by specific changes? > Thanks for all the time and work to making the improvements! Two goals - clean up some technical debt and optimize as well. In terms of cleanup, I'm trying to move stuff around so things are more cohesive, eliminate circular dependencies between different components (like example groups and the runner), etc. As for optimization, I'm mostly just keeping my out for waste as I pore through the code. Repeated iterations through examples in a group, etc. I made two changes today that should have some impact on larger suites: 1. Instead of loading up every single example in memory (which means g*e instances of example groups where g = a group and e = the number of examples in each group), the groups are loaded up but the instances are only created as each example is run. Assuming GC is doing its thing, this *should* help, and it does appear to help in the rspec suite. 2. Instead of sending example group instances to the reporter, they get lightweight structs that only hold the string info needed by the formatters. Again, this will mostly impact large suites as examples and groups get deref'd and GC does its thing. David > > -Ben From george.ogata at gmail.com Mon Jan 26 01:18:40 2009 From: george.ogata at gmail.com (George) Date: Mon, 26 Jan 2009 17:18:40 +1100 Subject: [rspec-devel] Ticket #164: Steps with a variable number of block parameters Message-ID: <6580dc180901252218y2b7f0eddxbae6d8e53547c39c@mail.gmail.com> Hi, I filed a ticket about a week ago now about allowing steps with a variable number of block parameters for creating "meta-steps." http://rspec.lighthouseapp.com/projects/16211/tickets/164-steps-with-a-variable-number-of-block-parameters Just wondering if anyone's had any thoughts on this yet. Regards, George. From dchelimsky at gmail.com Thu Jan 29 10:36:03 2009 From: dchelimsky at gmail.com (David Chelimsky) Date: Thu, 29 Jan 2009 09:36:03 -0600 Subject: [rspec-devel] [ANN] The RSpec Book is now in beta Message-ID: <68A01C2A-2808-493D-B212-C16617AFB9A6@gmail.com> I?m pleased to announce the beta release of the Pragmatic Bookshelf?s The RSpec Book: Behaviour Driven Development with RSpec, Cucumber and Friends! It?s been a long time coming, and there?s still a lot of work to do to get to print. The beta release has 9 of the 22 chapters we have planned. Most of what remains is almost done, but not quite ready to release yet. As with all of the Pragmatic beta books, we?ll do regular updates every few weeks as we wrap up the remaining chapters and incorporate your feedback. And please do provide feedback. We want this book to serve you well! There are six authors involved: Dave Astels, Zach Dennis, Aslak Hellesoy, Bryan Helmkamp, Dan North, and me. I'm honored to be in such good company here, with the guys who brought us BDD, to the developers and maintainers of RSpec, Cucumber and Webrat. You can read more (and buy the book!) at http://www.pragprog.com/titles/achbd/the-rspec-book On behalf of all the authors, I'd like to extend a special thank you to all of you who have contributed to the software and the conversation around RSpec, Cucumber, and BDD in general. RSpec would be nothing without the community that has evolved around it, so thank you, thank you, thank you. Again, THANK YOU! David Chelimsky From jake.howerton at gmail.com Fri Jan 30 13:18:34 2009 From: jake.howerton at gmail.com (Jake Howerton) Date: Fri, 30 Jan 2009 13:18:34 -0500 Subject: [rspec-devel] [Cucumber] --guess option to choose between Ambiguous step definitions when appropriate Message-ID: <218a05e40901301018q7bf8ac83y4b5f9d9172e5644b@mail.gmail.com> Hey All, I discussed this option with Aslak in #cucumber and think I convinced him of its value ;) Please chime in with any thoughts. This feature is currently available in my github fork here: http://github.com/jakehow/cucumber/tree/master Please pull and test if this matters to you or you are curious. Way back in Story Runner ;), the order you defined your steps in mattered. This allowed you to put steps in a specific order if you had more specific steps that you wanted to match first. ( Aslak tells me this was a bad idea, b/c different OS's order Dir[] differently). Either way I found it useful, because it allows you to make a more specific step definition instead of contorting your English in order to avoid multiple matches. Every time I sit down with cucumber, I hit this issue, in cucumber you can at least make more specific regex's, but this is also a pain, especially in complex situations. Say we have two step definitions. Then /the form has a field called: (.*)/ and Then /the form has a field called: (.*) with value: (.*)/ By default this will raise a Cucumber::Multiple error because of the ambiguousness of it from the regex standpoint. However, it is not really ambiguous for the user who entered the step: Then the form has a field called: name with value: Jake. My changes will pick the appropriate step, when you have the --guess option turned on. How it works: There is ranking logic that gets invoked when the option is turned on: - The step definition with the most capture groups wins - If there are 2+ definitions with the same amount of capture groups, the one with the shortest overall captured string length wins - If there are still 2+ options the Ambiguous error is raised I am pretty happy with how accurately this ranking works for how I intend to use it, but it is not perfect. Let me know your thoughts about this, method names, and my implementation ( which I think is pretty ugly atm). Particularly, I had to inject the config option into StepMother, and had to change some stubs in other specs in order to accomodate this. Also it is probably slow b/c I test the matches multiple times, should this be cached within the best_matches method body? Is there a better way to select the top matches, etc. Thanks, Jake -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter.fitzgibbons at gmail.com Fri Jan 30 13:39:29 2009 From: peter.fitzgibbons at gmail.com (Peter Fitzgibbons) Date: Fri, 30 Jan 2009 12:39:29 -0600 Subject: [rspec-devel] [Cucumber] --guess option to choose between Ambiguous step definitions when appropriate In-Reply-To: <218a05e40901301018q7bf8ac83y4b5f9d9172e5644b@mail.gmail.com> References: <218a05e40901301018q7bf8ac83y4b5f9d9172e5644b@mail.gmail.com> Message-ID: <670a00380901301039j3941732dq71f27fe94afaf53e@mail.gmail.com> How about forming your regex as follows? You're writing a Grammar Parser (via regex's), so you have to think grammar parsing: Then /the form has a field called: (.*) (with value: (.*))?/ Yes, this gets you a longish list of matchers... the evil of grammar parsing. What do you think? Peter Fitzgibbons (847) 687-7646 Email: peter.fitzgibbons at gmail.com IM GTalk: peter.fitzgibbons IM Yahoo: pjfitzgibbons IM MSN: pjfitzgibbons at hotmail.com IM AOL: peter.fitzgibbons at gmail.com 2009/1/30 Jake Howerton > Hey All, > > I discussed this option with Aslak in #cucumber and think I convinced him > of its value ;) Please chime in with any thoughts. > > This feature is currently available in my github fork here: > http://github.com/jakehow/cucumber/tree/master > Please pull and test if this matters to you or you are curious. > > Way back in Story Runner ;), the order you defined your steps in mattered. > This allowed you to put steps in a specific order if you had more specific > steps that you wanted to match first. ( Aslak tells me this was a bad idea, > b/c different OS's order Dir[] differently). Either way I found it useful, > because it allows you to make a more specific step definition instead of > contorting your English in order to avoid multiple matches. Every time I sit > down with cucumber, I hit this issue, in cucumber you can at least make more > specific regex's, but this is also a pain, especially in complex situations. > > Say we have two step definitions. > > Then /the form has a field called: (.*)/ > and > Then /the form hThen /the form has a field called: (.*) with value: (.*)/as > a field called: (.*) with value: (.*)/ > > By default this will raise a Cucumber::Multiple error because of the > ambiguousness of it from the regex standpoint. However, it is not really > ambiguous for the user who entered the step: Then the form has a field > called: name with value: Jake. My changes will pick the appropriate step, > when you have the --guess option turned on. > > How it works: > There is ranking logic that gets invoked when the option is turned on: > - The step definition with the most capture groups wins > - If there are 2+ definitions with the same amount of capture groups, the > one with the shortest overall captured string length wins > - If there are still 2+ options the Ambiguous error is raised > > I am pretty happy with how accurately this ranking works for how I intend > to use it, but it is not perfect. Let me know your thoughts about this, > method names, and my implementation ( which I think is pretty ugly atm). > Particularly, I had to inject the config option into StepMother, and had to > change some stubs in other specs in order to accomodate this. > > Also it is probably slow b/c I test the matches multiple times, should this > be cached within the best_matches method body? Is there a better way to > select the top matches, etc. > > Thanks, > > Jake > _______________________________________________ > 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 jake.howerton at gmail.com Fri Jan 30 14:04:14 2009 From: jake.howerton at gmail.com (Jake Howerton) Date: Fri, 30 Jan 2009 14:04:14 -0500 Subject: [rspec-devel] [Cucumber] --guess option to choose between Ambiguous step definitions when appropriate In-Reply-To: <670a00380901301039j3941732dq71f27fe94afaf53e@mail.gmail.com> References: <218a05e40901301018q7bf8ac83y4b5f9d9172e5644b@mail.gmail.com> <670a00380901301039j3941732dq71f27fe94afaf53e@mail.gmail.com> Message-ID: <218a05e40901301104m5b47700g131f6b607b1e2dca@mail.gmail.com> Hey Peter, Not sure I follow what you are saying, or how changing the regex solves the problem at hand. Both regex's would still get matched by default with your form. Also, not sure how the nested grouping would effect what gets passed to the block. Am I missing something in your comment? -Jake On Fri, Jan 30, 2009 at 1:39 PM, Peter Fitzgibbons < peter.fitzgibbons at gmail.com> wrote: > How about forming your regex as follows? You're writing a Grammar Parser > (via regex's), so you have to think grammar parsing: > > Then /the form has a field called: (.*) (with value: (.*))?/ > > Yes, this gets you a longish list of matchers... the evil of grammar > parsing. > > What do you think? > > Peter Fitzgibbons > (847) 687-7646 > Email: peter.fitzgibbons at gmail.com > IM GTalk: peter.fitzgibbons > IM Yahoo: pjfitzgibbons > IM MSN: pjfitzgibbons at hotmail.com > IM AOL: peter.fitzgibbons at gmail.com > > > 2009/1/30 Jake Howerton > >> Hey All, >> >> I discussed this option with Aslak in #cucumber and think I convinced him >> of its value ;) Please chime in with any thoughts. >> >> This feature is currently available in my github fork here: >> http://github.com/jakehow/cucumber/tree/master >> Please pull and test if this matters to you or you are curious. >> >> Way back in Story Runner ;), the order you defined your steps in >> mattered. This allowed you to put steps in a specific order if you had more >> specific steps that you wanted to match first. ( Aslak tells me this was a >> bad idea, b/c different OS's order Dir[] differently). Either way I found >> it useful, because it allows you to make a more specific step definition >> instead of contorting your English in order to avoid multiple matches. Every >> time I sit down with cucumber, I hit this issue, in cucumber you can at >> least make more specific regex's, but this is also a pain, especially in >> complex situations. >> >> Say we have two step definitions. >> >> Then /the form has a field called: (.*)/ >> and >> Then /the form hThen /the form has a field called: (.*) with value: >> (.*)/as a field called: (.*) with value: (.*)/ >> >> By default this will raise a Cucumber::Multiple error because of the >> ambiguousness of it from the regex standpoint. However, it is not really >> ambiguous for the user who entered the step: Then the form has a field >> called: name with value: Jake. My changes will pick the appropriate step, >> when you have the --guess option turned on. >> >> How it works: >> There is ranking logic that gets invoked when the option is turned on: >> - The step definition with the most capture groups wins >> - If there are 2+ definitions with the same amount of capture groups, the >> one with the shortest overall captured string length wins >> - If there are still 2+ options the Ambiguous error is raised >> >> I am pretty happy with how accurately this ranking works for how I intend >> to use it, but it is not perfect. Let me know your thoughts about this, >> method names, and my implementation ( which I think is pretty ugly atm). >> Particularly, I had to inject the config option into StepMother, and had to >> change some stubs in other specs in order to accomodate this. >> >> Also it is probably slow b/c I test the matches multiple times, should >> this be cached within the best_matches method body? Is there a better way >> to select the top matches, etc. >> >> Thanks, >> >> Jake >> _______________________________________________ >> 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pergesu at gmail.com Fri Jan 30 14:29:16 2009 From: pergesu at gmail.com (Pat Maddox) Date: Fri, 30 Jan 2009 11:29:16 -0800 Subject: [rspec-devel] [Cucumber] --guess option to choose between Ambiguous step definitions when appropriate In-Reply-To: <218a05e40901301018q7bf8ac83y4b5f9d9172e5644b@mail.gmail.com> References: <218a05e40901301018q7bf8ac83y4b5f9d9172e5644b@mail.gmail.com> Message-ID: <810a540e0901301129l2f4692b9v77fd59e265f49181@mail.gmail.com> On Fri, Jan 30, 2009 at 10:18 AM, Jake Howerton wrote: > Hey All, > > I discussed this option with Aslak in #cucumber and think I convinced him of > its value ;) Please chime in with any thoughts. > > This feature is currently available in my github fork here: > http://github.com/jakehow/cucumber/tree/master > Please pull and test if this matters to you or you are curious. > > Way back in Story Runner ;), the order you defined your steps in mattered. > This allowed you to put steps in a specific order if you had more specific > steps that you wanted to match first. ( Aslak tells me this was a bad idea, > b/c different OS's order Dir[] differently). Either way I found it useful, > because it allows you to make a more specific step definition instead of > contorting your English in order to avoid multiple matches. Every time I sit > down with cucumber, I hit this issue, in cucumber you can at least make more > specific regex's, but this is also a pain, especially in complex situations. > > Say we have two step definitions. > > Then /the form has a field called: (.*)/ > and > Then /the form has a field called: (.*) with value: (.*)/ > > By default this will raise a Cucumber::Multiple error because of the > ambiguousness of it from the regex standpoint. Maybe. I think before introducing a funky ranking algorithm to match steps, it's probably best to make your step definitions more precise. This means using anchors and character classes. Then /^the form has a field called: (\S+)$/ Then /^the form has a field called: (\S+) with value: (.*)$/ Cucumber prints out (.*) in pending regex's because that's a pretty sensible default, and it doesn't have enough context to do otherwise really. A lot of times you can get away with being lazy and just leaving that (I know I do plenty) but when you can't, spend a couple minutes to tidy up your regexes. I do think your idea is cool :) but at this point it sounds like clean regexes are simpler and more effective, no? Pat From jake.howerton at gmail.com Fri Jan 30 15:19:45 2009 From: jake.howerton at gmail.com (Jake Howerton) Date: Fri, 30 Jan 2009 15:19:45 -0500 Subject: [rspec-devel] [Cucumber] --guess option to choose between Ambiguous step definitions when appropriate In-Reply-To: <810a540e0901301129l2f4692b9v77fd59e265f49181@mail.gmail.com> References: <218a05e40901301018q7bf8ac83y4b5f9d9172e5644b@mail.gmail.com> <810a540e0901301129l2f4692b9v77fd59e265f49181@mail.gmail.com> Message-ID: <218a05e40901301219r6c058bb1t17cf95a9550cccb5@mail.gmail.com> Hey Pat, It is quite easy to tighten up your regex's if it is truly a really simple case. As it gets more complicated it gets harder and harder and requires more and more time. The purpose of the change is not to make smarter matches, it is to remove this work from the process of writing steps and stories. What happens if you want to match something with a space in it for instance? Also, putting the $ anchor directly after (.*) is redundant. In the cases where this helps the most, I would have either had to write negative lookahead regex's, or negative lookbehinds ( unsupported in 1.8). - Jake On Fri, Jan 30, 2009 at 2:29 PM, Pat Maddox wrote: > On Fri, Jan 30, 2009 at 10:18 AM, Jake Howerton > wrote: > > Hey All, > > > > I discussed this option with Aslak in #cucumber and think I convinced him > of > > its value ;) Please chime in with any thoughts. > > > > This feature is currently available in my github fork here: > > http://github.com/jakehow/cucumber/tree/master > > Please pull and test if this matters to you or you are curious. > > > > Way back in Story Runner ;), the order you defined your steps in > mattered. > > This allowed you to put steps in a specific order if you had more > specific > > steps that you wanted to match first. ( Aslak tells me this was a bad > idea, > > b/c different OS's order Dir[] differently). Either way I found it > useful, > > because it allows you to make a more specific step definition instead of > > contorting your English in order to avoid multiple matches. Every time I > sit > > down with cucumber, I hit this issue, in cucumber you can at least make > more > > specific regex's, but this is also a pain, especially in complex > situations. > > > > Say we have two step definitions. > > > > Then /the form has a field called: (.*)/ > > and > > Then /the form has a field called: (.*) with value: (.*)/ > > > > By default this will raise a Cucumber::Multiple error because of the > > ambiguousness of it from the regex standpoint. > > Maybe. I think before introducing a funky ranking algorithm to match > steps, it's probably best to make your step definitions more precise. > This means using anchors and character classes. > > Then /^the form has a field called: (\S+)$/ > Then /^the form has a field called: (\S+) with value: (.*)$/ > > Cucumber prints out (.*) in pending regex's because that's a pretty > sensible default, and it doesn't have enough context to do otherwise > really. A lot of times you can get away with being lazy and just > leaving that (I know I do plenty) but when you can't, spend a couple > minutes to tidy up your regexes. > > I do think your idea is cool :) but at this point it sounds like > clean regexes are simpler and more effective, no? > > Pat > _______________________________________________ > 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 Jan 30 19:26:24 2009 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Sat, 31 Jan 2009 01:26:24 +0100 Subject: [rspec-devel] [Cucumber] --guess option to choose between Ambiguous step definitions when appropriate In-Reply-To: <218a05e40901301219r6c058bb1t17cf95a9550cccb5@mail.gmail.com> References: <218a05e40901301018q7bf8ac83y4b5f9d9172e5644b@mail.gmail.com> <810a540e0901301129l2f4692b9v77fd59e265f49181@mail.gmail.com> <218a05e40901301219r6c058bb1t17cf95a9550cccb5@mail.gmail.com> Message-ID: <8d961d900901301626g3efbadb3ya36cbcf4012a25d5@mail.gmail.com> On Fri, Jan 30, 2009 at 9:19 PM, Jake Howerton wrote: > Hey Pat, > > It is quite easy to tighten up your regex's if it is truly a really simple > case. As it gets more complicated it gets harder and harder and requires > more and more time. The purpose of the change is not to make smarter > matches, it is to remove this work from the process of writing steps and > stories. > > What happens if you want to match something with a space in it for instance? > Also, putting the $ anchor directly after (.*) is redundant. In the cases > where this helps the most, I would have either had to write negative > lookahead regex's, or negative lookbehinds ( unsupported in 1.8). > Merged (with small tweaks) and documented under "guess mode": http://wiki.github.com/aslakhellesoy/cucumber/step-definitions Aslak > - Jake > > On Fri, Jan 30, 2009 at 2:29 PM, Pat Maddox wrote: >> >> On Fri, Jan 30, 2009 at 10:18 AM, Jake Howerton >> wrote: >> > Hey All, >> > >> > I discussed this option with Aslak in #cucumber and think I convinced >> > him of >> > its value ;) Please chime in with any thoughts. >> > >> > This feature is currently available in my github fork here: >> > http://github.com/jakehow/cucumber/tree/master >> > Please pull and test if this matters to you or you are curious. >> > >> > Way back in Story Runner ;), the order you defined your steps in >> > mattered. >> > This allowed you to put steps in a specific order if you had more >> > specific >> > steps that you wanted to match first. ( Aslak tells me this was a bad >> > idea, >> > b/c different OS's order Dir[] differently). Either way I found it >> > useful, >> > because it allows you to make a more specific step definition instead of >> > contorting your English in order to avoid multiple matches. Every time I >> > sit >> > down with cucumber, I hit this issue, in cucumber you can at least make >> > more >> > specific regex's, but this is also a pain, especially in complex >> > situations. >> > >> > Say we have two step definitions. >> > >> > Then /the form has a field called: (.*)/ >> > and >> > Then /the form has a field called: (.*) with value: (.*)/ >> > >> > By default this will raise a Cucumber::Multiple error because of the >> > ambiguousness of it from the regex standpoint. >> >> Maybe. I think before introducing a funky ranking algorithm to match >> steps, it's probably best to make your step definitions more precise. >> This means using anchors and character classes. >> >> Then /^the form has a field called: (\S+)$/ >> Then /^the form has a field called: (\S+) with value: (.*)$/ >> >> Cucumber prints out (.*) in pending regex's because that's a pretty >> sensible default, and it doesn't have enough context to do otherwise >> really. A lot of times you can get away with being lazy and just >> leaving that (I know I do plenty) but when you can't, spend a couple >> minutes to tidy up your regexes. >> >> I do think your idea is cool :) but at this point it sounds like >> clean regexes are simpler and more effective, no? >> >> Pat >> _______________________________________________ >> 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 > -- Aslak (::) From jake.howerton at gmail.com Fri Jan 30 20:03:24 2009 From: jake.howerton at gmail.com (Jake Howerton) Date: Fri, 30 Jan 2009 20:03:24 -0500 Subject: [rspec-devel] [Cucumber] --guess option to choose between Ambiguous step definitions when appropriate In-Reply-To: <8d961d900901301626g3efbadb3ya36cbcf4012a25d5@mail.gmail.com> References: <218a05e40901301018q7bf8ac83y4b5f9d9172e5644b@mail.gmail.com> <810a540e0901301129l2f4692b9v77fd59e265f49181@mail.gmail.com> <218a05e40901301219r6c058bb1t17cf95a9550cccb5@mail.gmail.com> <8d961d900901301626g3efbadb3ya36cbcf4012a25d5@mail.gmail.com> Message-ID: <218a05e40901301703m2b2a0780kcfb3d51228cba8c1@mail.gmail.com> Cool.. If anyone starts using this and has issues with it please let me know. -Jake On Fri, Jan 30, 2009 at 7:26 PM, aslak hellesoy wrote: > > > Merged (with small tweaks) and documented under "guess mode": > > http://wiki.github.com/aslakhellesoy/cucumber/step-definitions > > Aslak > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From george.ogata at gmail.com Sat Jan 31 02:57:56 2009 From: george.ogata at gmail.com (George) Date: Sat, 31 Jan 2009 18:57:56 +1100 Subject: [rspec-devel] Ticket #164: Steps with a variable number of block parameters In-Reply-To: <6580dc180901252218y2b7f0eddxbae6d8e53547c39c@mail.gmail.com> References: <6580dc180901252218y2b7f0eddxbae6d8e53547c39c@mail.gmail.com> Message-ID: <6580dc180901302357w6eef4d7dk301ad4c1574c8668@mail.gmail.com> On Mon, Jan 26, 2009 at 5:18 PM, George wrote: > Hi, > > I filed a ticket about a week ago now about allowing steps with a > variable number of block parameters for creating "meta-steps." > > > http://rspec.lighthouseapp.com/projects/16211/tickets/164-steps-with-a-variable-number-of-block-parameters > > Just wondering if anyone's had any thoughts on this yet. > > Regards, > George. Anyone? -------------- next part -------------- An HTML attachment was scrubbed... URL: From aslak.hellesoy at gmail.com Sat Jan 31 05:57:59 2009 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Sat, 31 Jan 2009 11:57:59 +0100 Subject: [rspec-devel] Ticket #164: Steps with a variable number of block parameters In-Reply-To: <6580dc180901302357w6eef4d7dk301ad4c1574c8668@mail.gmail.com> References: <6580dc180901252218y2b7f0eddxbae6d8e53547c39c@mail.gmail.com> <6580dc180901302357w6eef4d7dk301ad4c1574c8668@mail.gmail.com> Message-ID: <8d961d900901310257p4ae86c90jcbf4cbe332a32515@mail.gmail.com> On Sat, Jan 31, 2009 at 8:57 AM, George wrote: > On Mon, Jan 26, 2009 at 5:18 PM, George wrote: >> >> Hi, >> >> I filed a ticket about a week ago now about allowing steps with a >> variable number of block parameters for creating "meta-steps." >> >> >> http://rspec.lighthouseapp.com/projects/16211/tickets/164-steps-with-a-variable-number-of-block-parameters >> >> Just wondering if anyone's had any thoughts on this yet. >> >> Regards, >> George. > > Anyone? > I have added a comment in the ticket now :-) Aslak > > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > -- Aslak (::) From george.ogata at gmail.com Sat Jan 31 06:51:34 2009 From: george.ogata at gmail.com (George) Date: Sat, 31 Jan 2009 22:51:34 +1100 Subject: [rspec-devel] Ticket #164: Steps with a variable number of block parameters In-Reply-To: <8d961d900901310257p4ae86c90jcbf4cbe332a32515@mail.gmail.com> References: <6580dc180901252218y2b7f0eddxbae6d8e53547c39c@mail.gmail.com> <6580dc180901302357w6eef4d7dk301ad4c1574c8668@mail.gmail.com> <8d961d900901310257p4ae86c90jcbf4cbe332a32515@mail.gmail.com> Message-ID: <6580dc180901310351p79b40594l91762f16c1512135@mail.gmail.com> Thanks, Aslak. I'll reply there. George. On Sat, Jan 31, 2009 at 9:57 PM, aslak hellesoy wrote: > On Sat, Jan 31, 2009 at 8:57 AM, George wrote: > > On Mon, Jan 26, 2009 at 5:18 PM, George wrote: > >> > >> Hi, > >> > >> I filed a ticket about a week ago now about allowing steps with a > >> variable number of block parameters for creating "meta-steps." > >> > >> > >> > http://rspec.lighthouseapp.com/projects/16211/tickets/164-steps-with-a-variable-number-of-block-parameters > >> > >> Just wondering if anyone's had any thoughts on this yet. > >> > >> Regards, > >> George. > > > > Anyone? > > > > I have added a comment in the ticket now :-) > > Aslak > > > > > _______________________________________________ > > rspec-devel mailing list > > rspec-devel at rubyforge.org > > http://rubyforge.org/mailman/listinfo/rspec-devel > > > > > > -- > Aslak (::) > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: