From noreply at rubyforge.org Sun Jul 1 20:49:29 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 1 Jul 2007 20:49:29 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-11949 ] "should_yield" or ".should raise_error(MySpecificError)" equivalent for yields Message-ID: <20070702004929.73AF05240B5A@rubyforge.org> Feature Requests item #11949, was opened at 2007-07-01 19:49 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=11949&group_id=797 Category: expectation module Group: None Status: Open Priority: 3 Submitted By: S. Potter (mbbx6spp) Assigned to: Nobody (None) Summary: "should_yield" or ".should raise_error(MySpecificError)" equivalent for yields Initial Comment: The problem is already described here: http://snakesgemscoffee.blogspot.com/2007/07/rspec-shouldyield.html In summary: Just like we can write: lambda { Client.configure(&spec_block(1)) }.should raise_error(MySpecificError) We should also be able to write: lambda { Client.configure(&spec_block(1)) }.should_yield(Config) This should mean, to the "spec_block" that expects one (1) argument of type Config. Other suggestions for syntax are: lambda { Client.configure(&spec_block(1)) }.should yield_instances_of(Config) lambda { Client.configure(&spec_block(1)) }.should yield_objects_of(Config) Or something else similar (these are just things that popped in my head right now. Feedback much appreciated. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=11949&group_id=797 From noreply at rubyforge.org Sun Jul 1 20:56:16 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 1 Jul 2007 20:56:16 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-11949 ] "should_yield" or ".should raise_error(MySpecificError)" equivalent for yields Message-ID: <20070702005617.20671A970002@rubyforge.org> Feature Requests item #11949, was opened at 2007-07-02 00:49 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=11949&group_id=797 Category: expectation module Group: None Status: Open Priority: 3 Submitted By: S. Potter (mbbx6spp) Assigned to: Nobody (None) >Summary: "should_yield" or ".should raise_error(MySpecificError)" equivalent for yields Initial Comment: The problem is already described here: http://snakesgemscoffee.blogspot.com/2007/07/rspec-shouldyield.html In summary: Just like we can write: lambda { Client.configure(&spec_block(1)) }.should raise_error(MySpecificError) We should also be able to write: lambda { Client.configure(&spec_block(1)) }.should_yield(Config) This should mean, to the "spec_block" that expects one (1) argument of type Config. Other suggestions for syntax are: lambda { Client.configure(&spec_block(1)) }.should yield_instances_of(Config) lambda { Client.configure(&spec_block(1)) }.should yield_objects_of(Config) Or something else similar (these are just things that popped in my head right now. Feedback much appreciated. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-07-02 00:56 Message: We don't want to add any more "should_xyz" methods because they have to get added directly to object. So it's got to be a matcher - the trick is coming up w/ good verbiage. How about this? should yield_with(arg1,arg2) should yield_with(no_args) You would always have to supply at least one arg - but that arg could be no_args which would be the same method we use for mocks: should_receive(:message).with(no_args) WDYT? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=11949&group_id=797 From noreply at rubyforge.org Sun Jul 1 21:21:40 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 1 Jul 2007 21:21:40 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-11949 ] " should_yield" or " .should raise_error(MySpecificError)" equivalent for yields Message-ID: <20070702012140.1DB565240B5A@rubyforge.org> Feature Requests item #11949, was opened at 2007-07-01 19:49 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=11949&group_id=797 Category: expectation module Group: None Status: Open Priority: 3 Submitted By: S. Potter (mbbx6spp) Assigned to: Nobody (None) >Summary: "should_yield" or ".should raise_error(MySpecificError)" equivalent for yields Initial Comment: The problem is already described here: http://snakesgemscoffee.blogspot.com/2007/07/rspec-shouldyield.html In summary: Just like we can write: lambda { Client.configure(&spec_block(1)) }.should raise_error(MySpecificError) We should also be able to write: lambda { Client.configure(&spec_block(1)) }.should_yield(Config) This should mean, to the "spec_block" that expects one (1) argument of type Config. Other suggestions for syntax are: lambda { Client.configure(&spec_block(1)) }.should yield_instances_of(Config) lambda { Client.configure(&spec_block(1)) }.should yield_objects_of(Config) Or something else similar (these are just things that popped in my head right now. Feedback much appreciated. ---------------------------------------------------------------------- >Comment By: S. Potter (mbbx6spp) Date: 2007-07-01 20:21 Message: Actually that sounds great. I wasn't convinced of my own suggestions to be honest, just a starting point - wonderful! I can try coming up with a patch after work days this week, to contribute back. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-07-01 19:56 Message: We don't want to add any more "should_xyz" methods because they have to get added directly to object. So it's got to be a matcher - the trick is coming up w/ good verbiage. How about this? should yield_with(arg1,arg2) should yield_with(no_args) You would always have to supply at least one arg - but that arg could be no_args which would be the same method we use for mocks: should_receive(:message).with(no_args) WDYT? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=11949&group_id=797 From noreply at rubyforge.org Sun Jul 1 21:25:30 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 1 Jul 2007 21:25:30 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-11949 ] " should_yield" or " .should raise_error(MySpecificError)" equivalent for yields Message-ID: <20070702012530.7695F5240B92@rubyforge.org> Feature Requests item #11949, was opened at 2007-07-02 00:49 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=11949&group_id=797 Category: expectation module Group: None Status: Open Priority: 3 Submitted By: S. Potter (mbbx6spp) Assigned to: Nobody (None) Summary: "should_yield" or ".should raise_error(MySpecificError)" equivalent for yields Initial Comment: The problem is already described here: http://snakesgemscoffee.blogspot.com/2007/07/rspec-shouldyield.html In summary: Just like we can write: lambda { Client.configure(&spec_block(1)) }.should raise_error(MySpecificError) We should also be able to write: lambda { Client.configure(&spec_block(1)) }.should_yield(Config) This should mean, to the "spec_block" that expects one (1) argument of type Config. Other suggestions for syntax are: lambda { Client.configure(&spec_block(1)) }.should yield_instances_of(Config) lambda { Client.configure(&spec_block(1)) }.should yield_objects_of(Config) Or something else similar (these are just things that popped in my head right now. Feedback much appreciated. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-07-02 01:25 Message: Cool - I'll keep my eyes peeled for your patch. Go ahead and just attach it to this ticket - no need to make a new patch ticket - OK? ---------------------------------------------------------------------- Comment By: S. Potter (mbbx6spp) Date: 2007-07-02 01:21 Message: Actually that sounds great. I wasn't convinced of my own suggestions to be honest, just a starting point - wonderful! I can try coming up with a patch after work days this week, to contribute back. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-07-02 00:56 Message: We don't want to add any more "should_xyz" methods because they have to get added directly to object. So it's got to be a matcher - the trick is coming up w/ good verbiage. How about this? should yield_with(arg1,arg2) should yield_with(no_args) You would always have to supply at least one arg - but that arg could be no_args which would be the same method we use for mocks: should_receive(:message).with(no_args) WDYT? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=11949&group_id=797 From noreply at rubyforge.org Sun Jul 1 21:27:19 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 1 Jul 2007 21:27:19 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-11949 ] & quot; should_yield& quot; or & quot; .should raise_error(MySpecificError)& quot; equivalent for yields Message-ID: <20070702012719.3AE205240B5A@rubyforge.org> Feature Requests item #11949, was opened at 2007-07-01 19:49 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=11949&group_id=797 Category: expectation module Group: None Status: Open Priority: 3 Submitted By: S. Potter (mbbx6spp) Assigned to: Nobody (None) >Summary: &quot;should_yield&quot; or &quot;.should raise_error(MySpecificError)&quot; equivalent for yields Initial Comment: The problem is already described here: http://snakesgemscoffee.blogspot.com/2007/07/rspec-shouldyield.html In summary: Just like we can write: lambda { Client.configure(&spec_block(1)) }.should raise_error(MySpecificError) We should also be able to write: lambda { Client.configure(&spec_block(1)) }.should_yield(Config) This should mean, to the "spec_block" that expects one (1) argument of type Config. Other suggestions for syntax are: lambda { Client.configure(&spec_block(1)) }.should yield_instances_of(Config) lambda { Client.configure(&spec_block(1)) }.should yield_objects_of(Config) Or something else similar (these are just things that popped in my head right now. Feedback much appreciated. ---------------------------------------------------------------------- >Comment By: S. Potter (mbbx6spp) Date: 2007-07-01 20:27 Message: Great thanks, I'll attached to this ticket. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-07-01 20:25 Message: Cool - I'll keep my eyes peeled for your patch. Go ahead and just attach it to this ticket - no need to make a new patch ticket - OK? ---------------------------------------------------------------------- Comment By: S. Potter (mbbx6spp) Date: 2007-07-01 20:21 Message: Actually that sounds great. I wasn't convinced of my own suggestions to be honest, just a starting point - wonderful! I can try coming up with a patch after work days this week, to contribute back. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-07-01 19:56 Message: We don't want to add any more "should_xyz" methods because they have to get added directly to object. So it's got to be a matcher - the trick is coming up w/ good verbiage. How about this? should yield_with(arg1,arg2) should yield_with(no_args) You would always have to supply at least one arg - but that arg could be no_args which would be the same method we use for mocks: should_receive(:message).with(no_args) WDYT? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=11949&group_id=797 From noreply at rubyforge.org Mon Jul 2 05:03:23 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 2 Jul 2007 05:03:23 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-11891 ] script/generate rspec_controller fails to create appropriate views (from templates) on edge rails Message-ID: <20070702090323.429ED5240A90@rubyforge.org> Bugs item #11891, was opened at 2007-06-27 19:45 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=11891&group_id=797 Category: rails plugin Group: None >Status: Closed >Resolution: Accepted Priority: 3 Submitted By: George Anderson (caton) Assigned to: David Chelimsky (dchelimsky) Summary: script/generate rspec_controller fails to create appropriate views (from templates) on edge rails Initial Comment: Mac OSX 10.4.9 edge rails: r7126 rspec (plugin): r2082 rspec_on_rails: r2081 Views couldn't be generated by script/generate rspec_controller ... $ script/generate rspec_controller patient_base index face_sheet patient_messages rx chart_timeline archive chart_note flow_sheet hist ory hospital lab_results radiology x_ray exists app/controllers/ exists app/helpers/ create app/views/patient_base exists spec/controllers/ exists spec/helpers/ create spec/views/patient_base create spec/controllers/patient_base_controller_spec.rb create spec/helpers/patient_base_helper_spec.rb create app/controllers/patient_base_controller.rb create app/helpers/patient_base_helper.rb create spec/views/patient_base/index_view_spec.rb create app/views/patient_base/index.rhtml No such file or directory - /Users/george/work/one_box/vendor/rails/railties/lib/rails_generator/generators/components/controller/templates/view.rhtml railties/lib/rails_generator/generators/components/controller/templates/view.html changed to view.html.erb as of r6690 (roughly 2 months ago). See: http://dev.rubyonrails.org/browser/trunk/railties/lib/rails_generator/generators/components/controller/templates Rails 1.2 STABLE should use view.rhtml (See: http://dev.rubyonrails.org/browser/branches/1-2-stable/railties/lib/rails_generator/generators/components/controller/templates) So perhaps this ticket is premature. Consider, however, the *.html.erb style will eventually be in the STABLE release. At that time, RSpec may have to deal with the *old* and *new* style templates. For those of you reading this far, and not feeling you have suffient RSpec-fu to create a patch for this (myself included among you), consider this workaround: $ script/generate rspec_controller patient_base index this will throw the error herein described, but just lop off the "rspec_" bit and run: $ script/generate controller patient_base index Most of the files will be identical, but the *.html.erb-style templates will generate as expected. For bonus points, clean up the test::unit cruft thusly: $ rm test/functional/patient_base_controller_test.rb Thx. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-07-02 09:03 Message: Fixed in r2152. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-06-28 16:48 Message: No need to justify this - it's missing functionality that we'll add. The rspec_resource generator already does the right thing based on the rails environment and we can get the rspec_controller generator to do the same. ---------------------------------------------------------------------- Comment By: George Anderson (caton) Date: 2007-06-28 16:45 Message: .rhtml won't be fully deprecated until Rails 3.0 See: http://dev.rubyonrails.org/changeset/6178 ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=11891&group_id=797 From noreply at rubyforge.org Mon Jul 2 05:52:17 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 2 Jul 2007 05:52:17 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-11628 ] error mocking partial page variable only after partial has already been rendered Message-ID: <20070702095217.9DBE95240A90@rubyforge.org> Bugs item #11628, was opened at 2007-06-17 10:22 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=11628&group_id=797 Category: rails plugin Group: None >Status: Closed >Resolution: Rejected Priority: 3 Submitted By: David Chelimsky (dchelimsky) >Assigned to: David Chelimsky (dchelimsky) Summary: error mocking partial page variable only after partial has already been rendered Initial Comment: Steps to reproduce: Apply the attached patch (which adds an example file w/ 2 examples) cd example_rails_app rake rspec:install_plugin script/spec spec/views/person/_person.rhtml_spec.rb You should see an error. If, however, you apply --reverse, you should not: script/spec spec/views/person/_person.rhtml_spec.rb --reverse ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-07-02 09:52 Message: The solution to this is to NOT do this. Instead, we've added template.expects_render for view examples and controller.expects_render for controller examples. Docs have been appropriately updated as of r2153. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=11628&group_id=797 From noreply at rubyforge.org Mon Jul 2 16:06:47 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 2 Jul 2007 16:06:47 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-11960 ] spec command line complains about multiple format options when only one Message-ID: <20070702200647.2583FA970002@rubyforge.org> Bugs item #11960, was opened at 2007-07-02 16:06 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=11960&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Fran?ois Beausoleil (fbos) Assigned to: Nobody (None) Summary: spec command line complains about multiple format options when only one Initial Comment: $ spec --version RSpec-1.0.5 (r2081) - BDD for Ruby http://rspec.rubyforge.org/ $ spec --format specdoc spec/import_spec.rb /usr/local/lib/ruby/gems/1.8/gems/rspec-1.0.5/lib/spec/runner/options.rb:109:in `parse_format': When using several --format options only one of them can be without a file (RuntimeError) from /usr/local/lib/ruby/gems/1.8/gems/rspec-1.0.5/lib/spec/runner/option_parser.rb:118:in `parse' from /usr/local/lib/ruby/1.8/optparse.rb:1260:in `call' from /usr/local/lib/ruby/1.8/optparse.rb:1260:in `parse_in_order' from /usr/local/lib/ruby/1.8/optparse.rb:1247:in `catch' from /usr/local/lib/ruby/1.8/optparse.rb:1247:in `parse_in_order' from /usr/local/lib/ruby/1.8/optparse.rb:1241:in `order!' from /usr/local/lib/ruby/1.8/optparse.rb:1332:in `permute!' from /usr/local/lib/ruby/1.8/optparse.rb:1353:in `parse!' ... 14 levels... from /usr/local/lib/ruby/gems/1.8/gems/rspec-1.0.5/lib/spec/runner/command_line.rb:14:in `run' from /usr/local/lib/ruby/gems/1.8/gems/rspec-1.0.5/bin/spec:3 from /usr/local/bin/spec:16:in `load' from /usr/local/bin/spec:16 Anything wrong with my install ? Thanks ! Fran?ois ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=11960&group_id=797 From noreply at rubyforge.org Tue Jul 3 03:13:29 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 3 Jul 2007 03:13:29 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-11960 ] spec command line complains about multiple format options when only one Message-ID: <20070703071329.209D0A970002@rubyforge.org> Bugs item #11960, was opened at 2007-07-02 16:06 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=11960&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Fran?ois Beausoleil (fbos) Assigned to: Nobody (None) Summary: spec command line complains about multiple format options when only one Initial Comment: $ spec --version RSpec-1.0.5 (r2081) - BDD for Ruby http://rspec.rubyforge.org/ $ spec --format specdoc spec/import_spec.rb /usr/local/lib/ruby/gems/1.8/gems/rspec-1.0.5/lib/spec/runner/options.rb:109:in `parse_format': When using several --format options only one of them can be without a file (RuntimeError) from /usr/local/lib/ruby/gems/1.8/gems/rspec-1.0.5/lib/spec/runner/option_parser.rb:118:in `parse' from /usr/local/lib/ruby/1.8/optparse.rb:1260:in `call' from /usr/local/lib/ruby/1.8/optparse.rb:1260:in `parse_in_order' from /usr/local/lib/ruby/1.8/optparse.rb:1247:in `catch' from /usr/local/lib/ruby/1.8/optparse.rb:1247:in `parse_in_order' from /usr/local/lib/ruby/1.8/optparse.rb:1241:in `order!' from /usr/local/lib/ruby/1.8/optparse.rb:1332:in `permute!' from /usr/local/lib/ruby/1.8/optparse.rb:1353:in `parse!' ... 14 levels... from /usr/local/lib/ruby/gems/1.8/gems/rspec-1.0.5/lib/spec/runner/command_line.rb:14:in `run' from /usr/local/lib/ruby/gems/1.8/gems/rspec-1.0.5/bin/spec:3 from /usr/local/bin/spec:16:in `load' from /usr/local/bin/spec:16 Anything wrong with my install ? Thanks ! Fran?ois ---------------------------------------------------------------------- >Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-07-03 03:13 Message: I'm unable to reproduce this. If you look at line 109 and 110 of options.rb (where the error is raised), you'll see that @out_used must be true in order for the error to be raised. @out_used is only set to true on line 110, so it sounds like this is a second pass to parse_format. But I don't see how that could happen. Could you insert some debug statements? Does this happen with RSpec trunk too? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=11960&group_id=797 From noreply at rubyforge.org Thu Jul 5 04:32:30 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 5 Jul 2007 04:32:30 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-12010 ] Nicer failure message formatting Message-ID: <20070705083230.ADC6D52409AA@rubyforge.org> Patches item #12010, was opened at 2007-07-05 08:32 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=12010&group_id=797 Category: expectation module Group: None Status: Open Resolution: None Priority: 3 Submitted By: Wincent Colaiuta (wincent) Assigned to: Nobody (None) Summary: Nicer failure message formatting Initial Comment: Patch that implements more readable failure formatting as discussed in this thread: http://rubyforge.org/pipermail/rspec-users/2007-June/002153.html ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=12010&group_id=797 From noreply at rubyforge.org Thu Jul 5 04:47:27 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 5 Jul 2007 04:47:27 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-12010 ] Nicer failure message formatting Message-ID: <20070705084728.032545240A2E@rubyforge.org> Patches item #12010, was opened at 2007-07-05 08:32 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=12010&group_id=797 Category: expectation module Group: None Status: Open Resolution: None Priority: 3 Submitted By: Wincent Colaiuta (wincent) Assigned to: Nobody (None) Summary: Nicer failure message formatting Initial Comment: Patch that implements more readable failure formatting as discussed in this thread: http://rubyforge.org/pipermail/rspec-users/2007-June/002153.html ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-07-05 08:47 Message: On http://pastie.textmate.org/76180 you describe this: expected: blah got: other But I'm seeing this: expected: blah got : other Of the two, I prefer the former. Also, this is all good for equality, but not as good for comparisons: expected: > 6 got: 5 I'd rather see: expected: > 6 got: 5 I won't have time to get this right immediately, but if you want to take another crack at a patch based on these suggestions, I'd be happy to apply it. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=12010&group_id=797 From noreply at rubyforge.org Thu Jul 5 04:48:23 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 5 Jul 2007 04:48:23 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-12010 ] Nicer failure message formatting Message-ID: <20070705084824.0DCD75240A44@rubyforge.org> Patches item #12010, was opened at 2007-07-05 08:32 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=12010&group_id=797 Category: expectation module Group: None Status: Open Resolution: None Priority: 3 Submitted By: Wincent Colaiuta (wincent) Assigned to: Nobody (None) Summary: Nicer failure message formatting Initial Comment: Patch that implements more readable failure formatting as discussed in this thread: http://rubyforge.org/pipermail/rspec-users/2007-June/002153.html ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-07-05 08:48 Message: ps - make sure you view that last comment in a fixed width font :) ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-07-05 08:47 Message: On http://pastie.textmate.org/76180 you describe this: expected: blah got: other But I'm seeing this: expected: blah got : other Of the two, I prefer the former. Also, this is all good for equality, but not as good for comparisons: expected: > 6 got: 5 I'd rather see: expected: > 6 got: 5 I won't have time to get this right immediately, but if you want to take another crack at a patch based on these suggestions, I'd be happy to apply it. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=12010&group_id=797 From noreply at rubyforge.org Thu Jul 5 05:59:46 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 5 Jul 2007 05:59:46 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-12010 ] Nicer failure message formatting Message-ID: <20070705095946.C23025240945@rubyforge.org> Patches item #12010, was opened at 2007-07-05 08:32 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=12010&group_id=797 Category: expectation module Group: None Status: Open Resolution: None Priority: 3 Submitted By: Wincent Colaiuta (wincent) Assigned to: Nobody (None) Summary: Nicer failure message formatting Initial Comment: Patch that implements more readable failure formatting as discussed in this thread: http://rubyforge.org/pipermail/rspec-users/2007-June/002153.html ---------------------------------------------------------------------- >Comment By: Wincent Colaiuta (wincent) Date: 2007-07-05 09:59 Message: Darn transparent proxy... looks like I got logged out again; it let me attach the patch but silently discarded the comment I'd included... Here it is again: Ok, so I've revised the patch to implement what you suggest. I will also attach a second patch same as the first one but which includes one other change: treating "=~" like "==" and "===". For me the three operators "go" together conceptually, so to me this: expected: /blah/, got: "other" (using ~=) Reads better than this: expected: =~ /blah/, got: "other" Or the way it looked in my first shot at this patch: expected: =~ /blah/, got : "other" Or prior to the patch: expected: =~ /blah/, got "other" So anyway, like I said, will attach that one as a separate patch because I realize it might be more contentious. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-07-05 08:48 Message: ps - make sure you view that last comment in a fixed width font :) ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-07-05 08:47 Message: On http://pastie.textmate.org/76180 you describe this: expected: blah got: other But I'm seeing this: expected: blah got : other Of the two, I prefer the former. Also, this is all good for equality, but not as good for comparisons: expected: > 6 got: 5 I'd rather see: expected: > 6 got: 5 I won't have time to get this right immediately, but if you want to take another crack at a patch based on these suggestions, I'd be happy to apply it. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=12010&group_id=797 From noreply at rubyforge.org Thu Jul 5 06:02:55 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 5 Jul 2007 06:02:55 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-12010 ] Nicer failure message formatting Message-ID: <20070705100255.5B2005240951@rubyforge.org> Patches item #12010, was opened at 2007-07-05 08:32 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=12010&group_id=797 Category: expectation module Group: None Status: Open Resolution: None Priority: 3 Submitted By: Wincent Colaiuta (wincent) Assigned to: Nobody (None) Summary: Nicer failure message formatting Initial Comment: Patch that implements more readable failure formatting as discussed in this thread: http://rubyforge.org/pipermail/rspec-users/2007-June/002153.html ---------------------------------------------------------------------- >Comment By: Wincent Colaiuta (wincent) Date: 2007-07-05 10:02 Message: Will attach alternative patch as commented previously. ---------------------------------------------------------------------- Comment By: Wincent Colaiuta (wincent) Date: 2007-07-05 09:59 Message: Darn transparent proxy... looks like I got logged out again; it let me attach the patch but silently discarded the comment I'd included... Here it is again: Ok, so I've revised the patch to implement what you suggest. I will also attach a second patch same as the first one but which includes one other change: treating "=~" like "==" and "===". For me the three operators "go" together conceptually, so to me this: expected: /blah/, got: "other" (using ~=) Reads better than this: expected: =~ /blah/, got: "other" Or the way it looked in my first shot at this patch: expected: =~ /blah/, got : "other" Or prior to the patch: expected: =~ /blah/, got "other" So anyway, like I said, will attach that one as a separate patch because I realize it might be more contentious. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-07-05 08:48 Message: ps - make sure you view that last comment in a fixed width font :) ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-07-05 08:47 Message: On http://pastie.textmate.org/76180 you describe this: expected: blah got: other But I'm seeing this: expected: blah got : other Of the two, I prefer the former. Also, this is all good for equality, but not as good for comparisons: expected: > 6 got: 5 I'd rather see: expected: > 6 got: 5 I won't have time to get this right immediately, but if you want to take another crack at a patch based on these suggestions, I'd be happy to apply it. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=12010&group_id=797 From noreply at rubyforge.org Fri Jul 6 14:09:16 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 6 Jul 2007 14:09:16 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-12054 ] rake task for spec:recent Message-ID: <20070706180916.ADBD65240A95@rubyforge.org> Patches item #12054, was opened at 2007-07-06 18:09 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=12054&group_id=797 Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: Jerrett Taylor (ennoia) Assigned to: Nobody (None) Summary: rake task for spec:recent Initial Comment: This is pretty simple, but i found it missing once i started to accumulate lots of specs ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=12054&group_id=797 From noreply at rubyforge.org Fri Jul 6 14:09:34 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 6 Jul 2007 14:09:34 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-12054 ] rake task for spec:recent Message-ID: <20070706180934.30D335240B60@rubyforge.org> Patches item #12054, was opened at 2007-07-06 18:09 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=12054&group_id=797 Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: Jerrett Taylor (ennoia) Assigned to: Nobody (None) Summary: rake task for spec:recent Initial Comment: This is pretty simple, but i found it missing once i started to accumulate lots of specs ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=12054&group_id=797 From noreply at rubyforge.org Sat Jul 7 00:21:52 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sat, 7 Jul 2007 00:21:52 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-12066 ] Docfix for mocks/mocks.page Message-ID: <20070707042152.A62565240D53@rubyforge.org> Patches item #12066, was opened at 2007-07-07 04:21 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=12066&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Kyle Hargraves (philodespotos) Assigned to: Nobody (None) Summary: Docfix for mocks/mocks.page Initial Comment: The mocks page was still using the magic underscore syntax in one little place. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=12066&group_id=797 From noreply at rubyforge.org Sat Jul 7 00:25:13 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sat, 7 Jul 2007 00:25:13 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-12066 ] Docfix for mocks/mocks.page Message-ID: <20070707042513.E6A845240D54@rubyforge.org> Patches item #12066, was opened at 2007-07-07 04:21 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=12066&group_id=797 Category: None Group: None >Status: Closed >Resolution: Accepted Priority: 3 Submitted By: Kyle Hargraves (philodespotos) >Assigned to: David Chelimsky (dchelimsky) Summary: Docfix for mocks/mocks.page Initial Comment: The mocks page was still using the magic underscore syntax in one little place. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-07-07 04:25 Message: Applied to r2154. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=12066&group_id=797 From noreply at rubyforge.org Sat Jul 7 14:46:53 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sat, 7 Jul 2007 14:46:53 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-11254 ] RSpec syntax coloring and function pop-up integration in TextMate Message-ID: <20070707184653.DD77CA970016@rubyforge.org> Patches item #11254, was opened at 2007-05-31 14:43 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=11254&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Wincent Colaiuta (wincent) Assigned to: Aslak Helles?y (aslak_hellesoy) Summary: RSpec syntax coloring and function pop-up integration in TextMate Initial Comment: This patch makes two additions to the RSpec TextMate bundle to provide a better user experience: syntax coloring of RSpec keywords (before, after, describe, it), and display of behaviours and examples in the function pop-up menu. This latter feature is very useful for navigation when working with files with large numbers of specs. Examples appear indented. Now, this is my first ever TextMate customization so I am sure someone more experienced could improve on the implementation, but in its basic form it works. Shortcomings of the current implementation: - recognition occurs at the whole-line level, so syntax colouring only kicks in once you have typed the entire line - recognition simplisticly divides the behaviour and example descriptions into three parts, the "describe" (or "it"), the "do", and "everything else" between the two - this in turn means that there is no special syntax colouring of the "everything else" - it also means that examples such as: it "should be valid" do ... end will appear in the function pop-up with the enclosing quotes: "should be valid" - likewise, a behaviour like: describe User, "at creation time" do ... end Will appear in the function pop-up as: User, "at creation time" - and shared behaviours will appear as: "All controllers", :shared => true Hopefully someone with more knowledge about TextMate customization than I can address these issues, but as it stands I think the basic implementation is useful enough that life is better with the aid of these imperfect changes. Will also try to attach a screenshot with the patch to show what the pop-up looks like. ---------------------------------------------------------------------- >Comment By: Wincent Colaiuta (wincent) Date: 2007-07-07 18:46 Message: Very interesting... Noticed in the changelog for the just released TextMate r1401 the following: [CHANGED] File types (extensions) specified in language grammars are now matched against the full path so e.g. ?.git/config? and ?.ssh/config? are both valid extensions -- the match is required to be anchored either at an ?/? or ?.? so e.g. ?tml? will not match ?index.html?. On a tie, the longest suffix-match is chosen. So, not quite what would be necessary to distinguish between ".rb" and "_spec.rb", but a step closer. Think I might file a TextMate feature request to accept "_" as an anchor as well; that would allow spec files to be auto-detected and auto-syntax highlighted. ---------------------------------------------------------------------- Comment By: Wincent Colaiuta (wincent) Date: 2007-06-25 09:21 Message: (1) The patch was made against the trunk back at the end of May (r2060, I think). The changes to the info.plist (shouldn't it be Info.plist, btw?) weren't manually done by me, but were inserted by TextMate when I made the other additions via its Bundle Editor. These settings are pretty opaque to me and omitting them seems to make no difference, so I will attach a patch against the current trunk which does not include the info.plist changes. (2) There aren't any new user-settable "preferences" as such. The two new files in the "Preferences" subdirectory of the bundle are used to add Behaviours and Examples to the TextMate symbols list... this is what allows them to appear in the pop-up. (3) To see the syntax highlighting you must select "RSpec" from the language pop-up at the bottom of the window. This is just like when you have a Rails file and want special Rails-specific highlighting instead of the default Ruby highlighting. It would be nice if TextMate allowed you to specify that all files ending in "_spec.rb" would be auto-detected as RSpec files, but as far as I know, TextMate only allows you to specify the extension part (".rb") and that would override the default Ruby highlighting. So if we want that feature we either need to try again get the RSpec syntax rolled into the Ruby.tmbundle, or try to get Allan to modify Textmate to allow us to specify not just the extension. (4) The pop-up menu is the function pop-up at the bottom of the TextMate window (right hand side). I don't know if there is a keyboard shortcut; I use the mouse for that. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-06-24 13:06 Message: This sounds great, but I'm having some problems. 1) The patch doesn't apply cleanly against trunk r2121 with "patch -p0 < textmate.diff": patching file Preferences/Symbol patching file Preferences/Symbol patching file info.plist Hunk #1 FAILED at 280. 1 out of 1 hunk FAILED -- saving rejects to file info.plist.rej patching file Syntaxes/RSpec.tmLanguage $ cat info.plist.rej *************** *** 280,285 **** 240FDD9D-CD49-4917-9003-80A3E1DADFBA B5906021-8E54-4863-A13B-EA46333DB5F1 67E726E0-63E2-4840-B8BB-37F665CD34B8 uuid 4CEA47CC-2C3A-45FB-80BE-3820828227C2 --- 280,288 ---- 240FDD9D-CD49-4917-9003-80A3E1DADFBA B5906021-8E54-4863-A13B-EA46333DB5F1 67E726E0-63E2-4840-B8BB-37F665CD34B8 + 923F0A10-96B9-4792-99A4-94FEF66E0B8C + 57EF6130-05A6-4117-94CB-C0BD63328334 + 28F89786-04F4-43D7-82A6-34B046C2BC6B uuid 4CEA47CC-2C3A-45FB-80BE-3820828227C2 2) I tried to add the three rejected lines manually, and in the bundle editor I can see the new RSpec syntax, but I don't see the new preferences. Shouldn't they show up too? 3) There is no new syntax highlighting on my Textmate. How does TextMate know to use this highlighting? Do I need to do anything special to make it work? 4) How do I bring up the list over behaviours and examples shown in your screenshot? It must be some keyboard shortcut I'm unaware of. Cheers, Aslak ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=11254&group_id=797 From noreply at rubyforge.org Sat Jul 7 14:51:06 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sat, 7 Jul 2007 14:51:06 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-11254 ] RSpec syntax coloring and function pop-up integration in TextMate Message-ID: <20070707185106.B1A64A970012@rubyforge.org> Patches item #11254, was opened at 2007-05-31 14:43 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=11254&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Wincent Colaiuta (wincent) Assigned to: Aslak Helles?y (aslak_hellesoy) Summary: RSpec syntax coloring and function pop-up integration in TextMate Initial Comment: This patch makes two additions to the RSpec TextMate bundle to provide a better user experience: syntax coloring of RSpec keywords (before, after, describe, it), and display of behaviours and examples in the function pop-up menu. This latter feature is very useful for navigation when working with files with large numbers of specs. Examples appear indented. Now, this is my first ever TextMate customization so I am sure someone more experienced could improve on the implementation, but in its basic form it works. Shortcomings of the current implementation: - recognition occurs at the whole-line level, so syntax colouring only kicks in once you have typed the entire line - recognition simplisticly divides the behaviour and example descriptions into three parts, the "describe" (or "it"), the "do", and "everything else" between the two - this in turn means that there is no special syntax colouring of the "everything else" - it also means that examples such as: it "should be valid" do ... end will appear in the function pop-up with the enclosing quotes: "should be valid" - likewise, a behaviour like: describe User, "at creation time" do ... end Will appear in the function pop-up as: User, "at creation time" - and shared behaviours will appear as: "All controllers", :shared => true Hopefully someone with more knowledge about TextMate customization than I can address these issues, but as it stands I think the basic implementation is useful enough that life is better with the aid of these imperfect changes. Will also try to attach a screenshot with the patch to show what the pop-up looks like. ---------------------------------------------------------------------- >Comment By: Wincent Colaiuta (wincent) Date: 2007-07-07 18:51 Message: Ok, submitted a TextMate feature request here: http://macromates.com/ticket/show?ticket_id=48BF3775 ---------------------------------------------------------------------- Comment By: Wincent Colaiuta (wincent) Date: 2007-07-07 18:46 Message: Very interesting... Noticed in the changelog for the just released TextMate r1401 the following: [CHANGED] File types (extensions) specified in language grammars are now matched against the full path so e.g. ?.git/config? and ?.ssh/config? are both valid extensions -- the match is required to be anchored either at an ?/? or ?.? so e.g. ?tml? will not match ?index.html?. On a tie, the longest suffix-match is chosen. So, not quite what would be necessary to distinguish between ".rb" and "_spec.rb", but a step closer. Think I might file a TextMate feature request to accept "_" as an anchor as well; that would allow spec files to be auto-detected and auto-syntax highlighted. ---------------------------------------------------------------------- Comment By: Wincent Colaiuta (wincent) Date: 2007-06-25 09:21 Message: (1) The patch was made against the trunk back at the end of May (r2060, I think). The changes to the info.plist (shouldn't it be Info.plist, btw?) weren't manually done by me, but were inserted by TextMate when I made the other additions via its Bundle Editor. These settings are pretty opaque to me and omitting them seems to make no difference, so I will attach a patch against the current trunk which does not include the info.plist changes. (2) There aren't any new user-settable "preferences" as such. The two new files in the "Preferences" subdirectory of the bundle are used to add Behaviours and Examples to the TextMate symbols list... this is what allows them to appear in the pop-up. (3) To see the syntax highlighting you must select "RSpec" from the language pop-up at the bottom of the window. This is just like when you have a Rails file and want special Rails-specific highlighting instead of the default Ruby highlighting. It would be nice if TextMate allowed you to specify that all files ending in "_spec.rb" would be auto-detected as RSpec files, but as far as I know, TextMate only allows you to specify the extension part (".rb") and that would override the default Ruby highlighting. So if we want that feature we either need to try again get the RSpec syntax rolled into the Ruby.tmbundle, or try to get Allan to modify Textmate to allow us to specify not just the extension. (4) The pop-up menu is the function pop-up at the bottom of the TextMate window (right hand side). I don't know if there is a keyboard shortcut; I use the mouse for that. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-06-24 13:06 Message: This sounds great, but I'm having some problems. 1) The patch doesn't apply cleanly against trunk r2121 with "patch -p0 < textmate.diff": patching file Preferences/Symbol patching file Preferences/Symbol patching file info.plist Hunk #1 FAILED at 280. 1 out of 1 hunk FAILED -- saving rejects to file info.plist.rej patching file Syntaxes/RSpec.tmLanguage $ cat info.plist.rej *************** *** 280,285 **** 240FDD9D-CD49-4917-9003-80A3E1DADFBA B5906021-8E54-4863-A13B-EA46333DB5F1 67E726E0-63E2-4840-B8BB-37F665CD34B8 uuid 4CEA47CC-2C3A-45FB-80BE-3820828227C2 --- 280,288 ---- 240FDD9D-CD49-4917-9003-80A3E1DADFBA B5906021-8E54-4863-A13B-EA46333DB5F1 67E726E0-63E2-4840-B8BB-37F665CD34B8 + 923F0A10-96B9-4792-99A4-94FEF66E0B8C + 57EF6130-05A6-4117-94CB-C0BD63328334 + 28F89786-04F4-43D7-82A6-34B046C2BC6B uuid 4CEA47CC-2C3A-45FB-80BE-3820828227C2 2) I tried to add the three rejected lines manually, and in the bundle editor I can see the new RSpec syntax, but I don't see the new preferences. Shouldn't they show up too? 3) There is no new syntax highlighting on my Textmate. How does TextMate know to use this highlighting? Do I need to do anything special to make it work? 4) How do I bring up the list over behaviours and examples shown in your screenshot? It must be some keyboard shortcut I'm unaware of. Cheers, Aslak ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=11254&group_id=797 From noreply at rubyforge.org Sat Jul 7 17:26:41 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sat, 7 Jul 2007 17:26:41 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-12079 ] auto-generated example name incomplete: should have 1 error on .... Message-ID: <20070707212641.DFC625240BC2@rubyforge.org> Bugs item #12079, was opened at 2007-07-07 21:26 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=12079&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: David Chelimsky (dchelimsky) Assigned to: Nobody (None) Summary: auto-generated example name incomplete: should have 1 error on .... Initial Comment: Per the "RSpec Basics" peepcode: If you do this in a model: describe SomeModel ... specify do model.should have(1).error_on(:some_attribute) end end The feedback you get says: SomeModel - should have 1 error on But it doesn't tell you on what. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=12079&group_id=797 From noreply at rubyforge.org Sat Jul 7 17:34:35 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sat, 7 Jul 2007 17:34:35 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-12079 ] auto-generated example name incomplete: should have 1 error on .... Message-ID: <20070707213436.029265240AB4@rubyforge.org> Bugs item #12079, was opened at 2007-07-07 21:26 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=12079&group_id=797 Category: None Group: None >Status: Closed >Resolution: Accepted Priority: 3 Submitted By: David Chelimsky (dchelimsky) >Assigned to: David Chelimsky (dchelimsky) Summary: auto-generated example name incomplete: should have 1 error on .... Initial Comment: Per the "RSpec Basics" peepcode: If you do this in a model: describe SomeModel ... specify do model.should have(1).error_on(:some_attribute) end end The feedback you get says: SomeModel - should have 1 error on But it doesn't tell you on what. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-07-07 21:34 Message: Fixed in r2159. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=12079&group_id=797 From noreply at rubyforge.org Sun Jul 8 06:14:13 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 8 Jul 2007 06:14:13 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-11254 ] RSpec syntax coloring and function pop-up integration in TextMate Message-ID: <20070708101413.CB2EB5240A4D@rubyforge.org> Patches item #11254, was opened at 2007-05-31 14:43 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=11254&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Wincent Colaiuta (wincent) Assigned to: Aslak Helles?y (aslak_hellesoy) Summary: RSpec syntax coloring and function pop-up integration in TextMate Initial Comment: This patch makes two additions to the RSpec TextMate bundle to provide a better user experience: syntax coloring of RSpec keywords (before, after, describe, it), and display of behaviours and examples in the function pop-up menu. This latter feature is very useful for navigation when working with files with large numbers of specs. Examples appear indented. Now, this is my first ever TextMate customization so I am sure someone more experienced could improve on the implementation, but in its basic form it works. Shortcomings of the current implementation: - recognition occurs at the whole-line level, so syntax colouring only kicks in once you have typed the entire line - recognition simplisticly divides the behaviour and example descriptions into three parts, the "describe" (or "it"), the "do", and "everything else" between the two - this in turn means that there is no special syntax colouring of the "everything else" - it also means that examples such as: it "should be valid" do ... end will appear in the function pop-up with the enclosing quotes: "should be valid" - likewise, a behaviour like: describe User, "at creation time" do ... end Will appear in the function pop-up as: User, "at creation time" - and shared behaviours will appear as: "All controllers", :shared => true Hopefully someone with more knowledge about TextMate customization than I can address these issues, but as it stands I think the basic implementation is useful enough that life is better with the aid of these imperfect changes. Will also try to attach a screenshot with the patch to show what the pop-up looks like. ---------------------------------------------------------------------- >Comment By: Wincent Colaiuta (wincent) Date: 2007-07-08 10:14 Message: Awesome, looks like the requested change is already implemented in the new r1405: [NEW] Add ?_? to the set of anchor characters for file types (extensions) -- ticket 48BF377 ---------------------------------------------------------------------- Comment By: Wincent Colaiuta (wincent) Date: 2007-07-07 18:51 Message: Ok, submitted a TextMate feature request here: http://macromates.com/ticket/show?ticket_id=48BF3775 ---------------------------------------------------------------------- Comment By: Wincent Colaiuta (wincent) Date: 2007-07-07 18:46 Message: Very interesting... Noticed in the changelog for the just released TextMate r1401 the following: [CHANGED] File types (extensions) specified in language grammars are now matched against the full path so e.g. ?.git/config? and ?.ssh/config? are both valid extensions -- the match is required to be anchored either at an ?/? or ?.? so e.g. ?tml? will not match ?index.html?. On a tie, the longest suffix-match is chosen. So, not quite what would be necessary to distinguish between ".rb" and "_spec.rb", but a step closer. Think I might file a TextMate feature request to accept "_" as an anchor as well; that would allow spec files to be auto-detected and auto-syntax highlighted. ---------------------------------------------------------------------- Comment By: Wincent Colaiuta (wincent) Date: 2007-06-25 09:21 Message: (1) The patch was made against the trunk back at the end of May (r2060, I think). The changes to the info.plist (shouldn't it be Info.plist, btw?) weren't manually done by me, but were inserted by TextMate when I made the other additions via its Bundle Editor. These settings are pretty opaque to me and omitting them seems to make no difference, so I will attach a patch against the current trunk which does not include the info.plist changes. (2) There aren't any new user-settable "preferences" as such. The two new files in the "Preferences" subdirectory of the bundle are used to add Behaviours and Examples to the TextMate symbols list... this is what allows them to appear in the pop-up. (3) To see the syntax highlighting you must select "RSpec" from the language pop-up at the bottom of the window. This is just like when you have a Rails file and want special Rails-specific highlighting instead of the default Ruby highlighting. It would be nice if TextMate allowed you to specify that all files ending in "_spec.rb" would be auto-detected as RSpec files, but as far as I know, TextMate only allows you to specify the extension part (".rb") and that would override the default Ruby highlighting. So if we want that feature we either need to try again get the RSpec syntax rolled into the Ruby.tmbundle, or try to get Allan to modify Textmate to allow us to specify not just the extension. (4) The pop-up menu is the function pop-up at the bottom of the TextMate window (right hand side). I don't know if there is a keyboard shortcut; I use the mouse for that. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-06-24 13:06 Message: This sounds great, but I'm having some problems. 1) The patch doesn't apply cleanly against trunk r2121 with "patch -p0 < textmate.diff": patching file Preferences/Symbol patching file Preferences/Symbol patching file info.plist Hunk #1 FAILED at 280. 1 out of 1 hunk FAILED -- saving rejects to file info.plist.rej patching file Syntaxes/RSpec.tmLanguage $ cat info.plist.rej *************** *** 280,285 **** 240FDD9D-CD49-4917-9003-80A3E1DADFBA B5906021-8E54-4863-A13B-EA46333DB5F1 67E726E0-63E2-4840-B8BB-37F665CD34B8 uuid 4CEA47CC-2C3A-45FB-80BE-3820828227C2 --- 280,288 ---- 240FDD9D-CD49-4917-9003-80A3E1DADFBA B5906021-8E54-4863-A13B-EA46333DB5F1 67E726E0-63E2-4840-B8BB-37F665CD34B8 + 923F0A10-96B9-4792-99A4-94FEF66E0B8C + 57EF6130-05A6-4117-94CB-C0BD63328334 + 28F89786-04F4-43D7-82A6-34B046C2BC6B uuid 4CEA47CC-2C3A-45FB-80BE-3820828227C2 2) I tried to add the three rejected lines manually, and in the bundle editor I can see the new RSpec syntax, but I don't see the new preferences. Shouldn't they show up too? 3) There is no new syntax highlighting on my Textmate. How does TextMate know to use this highlighting? Do I need to do anything special to make it work? 4) How do I bring up the list over behaviours and examples shown in your screenshot? It must be some keyboard shortcut I'm unaware of. Cheers, Aslak ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=11254&group_id=797 From noreply at rubyforge.org Sun Jul 8 06:27:52 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 8 Jul 2007 06:27:52 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-11254 ] RSpec syntax coloring and function pop-up integration in TextMate Message-ID: <20070708102752.E21D65240A4D@rubyforge.org> Patches item #11254, was opened at 2007-05-31 14:43 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=11254&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Wincent Colaiuta (wincent) Assigned to: Aslak Helles?y (aslak_hellesoy) Summary: RSpec syntax coloring and function pop-up integration in TextMate Initial Comment: This patch makes two additions to the RSpec TextMate bundle to provide a better user experience: syntax coloring of RSpec keywords (before, after, describe, it), and display of behaviours and examples in the function pop-up menu. This latter feature is very useful for navigation when working with files with large numbers of specs. Examples appear indented. Now, this is my first ever TextMate customization so I am sure someone more experienced could improve on the implementation, but in its basic form it works. Shortcomings of the current implementation: - recognition occurs at the whole-line level, so syntax colouring only kicks in once you have typed the entire line - recognition simplisticly divides the behaviour and example descriptions into three parts, the "describe" (or "it"), the "do", and "everything else" between the two - this in turn means that there is no special syntax colouring of the "everything else" - it also means that examples such as: it "should be valid" do ... end will appear in the function pop-up with the enclosing quotes: "should be valid" - likewise, a behaviour like: describe User, "at creation time" do ... end Will appear in the function pop-up as: User, "at creation time" - and shared behaviours will appear as: "All controllers", :shared => true Hopefully someone with more knowledge about TextMate customization than I can address these issues, but as it stands I think the basic implementation is useful enough that life is better with the aid of these imperfect changes. Will also try to attach a screenshot with the patch to show what the pop-up looks like. ---------------------------------------------------------------------- >Comment By: Wincent Colaiuta (wincent) Date: 2007-07-08 10:27 Message: Just attached an updated patch with "_spec.rb" denoted as file extension. ---------------------------------------------------------------------- Comment By: Wincent Colaiuta (wincent) Date: 2007-07-08 10:14 Message: Awesome, looks like the requested change is already implemented in the new r1405: [NEW] Add ?_? to the set of anchor characters for file types (extensions) -- ticket 48BF377 ---------------------------------------------------------------------- Comment By: Wincent Colaiuta (wincent) Date: 2007-07-07 18:51 Message: Ok, submitted a TextMate feature request here: http://macromates.com/ticket/show?ticket_id=48BF3775 ---------------------------------------------------------------------- Comment By: Wincent Colaiuta (wincent) Date: 2007-07-07 18:46 Message: Very interesting... Noticed in the changelog for the just released TextMate r1401 the following: [CHANGED] File types (extensions) specified in language grammars are now matched against the full path so e.g. ?.git/config? and ?.ssh/config? are both valid extensions -- the match is required to be anchored either at an ?/? or ?.? so e.g. ?tml? will not match ?index.html?. On a tie, the longest suffix-match is chosen. So, not quite what would be necessary to distinguish between ".rb" and "_spec.rb", but a step closer. Think I might file a TextMate feature request to accept "_" as an anchor as well; that would allow spec files to be auto-detected and auto-syntax highlighted. ---------------------------------------------------------------------- Comment By: Wincent Colaiuta (wincent) Date: 2007-06-25 09:21 Message: (1) The patch was made against the trunk back at the end of May (r2060, I think). The changes to the info.plist (shouldn't it be Info.plist, btw?) weren't manually done by me, but were inserted by TextMate when I made the other additions via its Bundle Editor. These settings are pretty opaque to me and omitting them seems to make no difference, so I will attach a patch against the current trunk which does not include the info.plist changes. (2) There aren't any new user-settable "preferences" as such. The two new files in the "Preferences" subdirectory of the bundle are used to add Behaviours and Examples to the TextMate symbols list... this is what allows them to appear in the pop-up. (3) To see the syntax highlighting you must select "RSpec" from the language pop-up at the bottom of the window. This is just like when you have a Rails file and want special Rails-specific highlighting instead of the default Ruby highlighting. It would be nice if TextMate allowed you to specify that all files ending in "_spec.rb" would be auto-detected as RSpec files, but as far as I know, TextMate only allows you to specify the extension part (".rb") and that would override the default Ruby highlighting. So if we want that feature we either need to try again get the RSpec syntax rolled into the Ruby.tmbundle, or try to get Allan to modify Textmate to allow us to specify not just the extension. (4) The pop-up menu is the function pop-up at the bottom of the TextMate window (right hand side). I don't know if there is a keyboard shortcut; I use the mouse for that. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-06-24 13:06 Message: This sounds great, but I'm having some problems. 1) The patch doesn't apply cleanly against trunk r2121 with "patch -p0 < textmate.diff": patching file Preferences/Symbol patching file Preferences/Symbol patching file info.plist Hunk #1 FAILED at 280. 1 out of 1 hunk FAILED -- saving rejects to file info.plist.rej patching file Syntaxes/RSpec.tmLanguage $ cat info.plist.rej *************** *** 280,285 **** 240FDD9D-CD49-4917-9003-80A3E1DADFBA B5906021-8E54-4863-A13B-EA46333DB5F1 67E726E0-63E2-4840-B8BB-37F665CD34B8 uuid 4CEA47CC-2C3A-45FB-80BE-3820828227C2 --- 280,288 ---- 240FDD9D-CD49-4917-9003-80A3E1DADFBA B5906021-8E54-4863-A13B-EA46333DB5F1 67E726E0-63E2-4840-B8BB-37F665CD34B8 + 923F0A10-96B9-4792-99A4-94FEF66E0B8C + 57EF6130-05A6-4117-94CB-C0BD63328334 + 28F89786-04F4-43D7-82A6-34B046C2BC6B uuid 4CEA47CC-2C3A-45FB-80BE-3820828227C2 2) I tried to add the three rejected lines manually, and in the bundle editor I can see the new RSpec syntax, but I don't see the new preferences. Shouldn't they show up too? 3) There is no new syntax highlighting on my Textmate. How does TextMate know to use this highlighting? Do I need to do anything special to make it work? 4) How do I bring up the list over behaviours and examples shown in your screenshot? It must be some keyboard shortcut I'm unaware of. Cheers, Aslak ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=11254&group_id=797 From noreply at rubyforge.org Sun Jul 8 06:48:13 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 8 Jul 2007 06:48:13 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-11254 ] RSpec syntax coloring and function pop-up integration in TextMate Message-ID: <20070708104813.77ACF5240A4D@rubyforge.org> Patches item #11254, was opened at 2007-05-31 14:43 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=11254&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Wincent Colaiuta (wincent) Assigned to: Aslak Helles?y (aslak_hellesoy) Summary: RSpec syntax coloring and function pop-up integration in TextMate Initial Comment: This patch makes two additions to the RSpec TextMate bundle to provide a better user experience: syntax coloring of RSpec keywords (before, after, describe, it), and display of behaviours and examples in the function pop-up menu. This latter feature is very useful for navigation when working with files with large numbers of specs. Examples appear indented. Now, this is my first ever TextMate customization so I am sure someone more experienced could improve on the implementation, but in its basic form it works. Shortcomings of the current implementation: - recognition occurs at the whole-line level, so syntax colouring only kicks in once you have typed the entire line - recognition simplisticly divides the behaviour and example descriptions into three parts, the "describe" (or "it"), the "do", and "everything else" between the two - this in turn means that there is no special syntax colouring of the "everything else" - it also means that examples such as: it "should be valid" do ... end will appear in the function pop-up with the enclosing quotes: "should be valid" - likewise, a behaviour like: describe User, "at creation time" do ... end Will appear in the function pop-up as: User, "at creation time" - and shared behaviours will appear as: "All controllers", :shared => true Hopefully someone with more knowledge about TextMate customization than I can address these issues, but as it stands I think the basic implementation is useful enough that life is better with the aid of these imperfect changes. Will also try to attach a screenshot with the patch to show what the pop-up looks like. ---------------------------------------------------------------------- >Comment By: Wincent Colaiuta (wincent) Date: 2007-07-08 10:48 Message: Posted a follow-up TextMate ticket here: http://macromates.com/ticket/show?ticket_id=0F597093 ---------------------------------------------------------------------- Comment By: Wincent Colaiuta (wincent) Date: 2007-07-08 10:27 Message: Just attached an updated patch with "_spec.rb" denoted as file extension. ---------------------------------------------------------------------- Comment By: Wincent Colaiuta (wincent) Date: 2007-07-08 10:14 Message: Awesome, looks like the requested change is already implemented in the new r1405: [NEW] Add ?_? to the set of anchor characters for file types (extensions) -- ticket 48BF377 ---------------------------------------------------------------------- Comment By: Wincent Colaiuta (wincent) Date: 2007-07-07 18:51 Message: Ok, submitted a TextMate feature request here: http://macromates.com/ticket/show?ticket_id=48BF3775 ---------------------------------------------------------------------- Comment By: Wincent Colaiuta (wincent) Date: 2007-07-07 18:46 Message: Very interesting... Noticed in the changelog for the just released TextMate r1401 the following: [CHANGED] File types (extensions) specified in language grammars are now matched against the full path so e.g. ?.git/config? and ?.ssh/config? are both valid extensions -- the match is required to be anchored either at an ?/? or ?.? so e.g. ?tml? will not match ?index.html?. On a tie, the longest suffix-match is chosen. So, not quite what would be necessary to distinguish between ".rb" and "_spec.rb", but a step closer. Think I might file a TextMate feature request to accept "_" as an anchor as well; that would allow spec files to be auto-detected and auto-syntax highlighted. ---------------------------------------------------------------------- Comment By: Wincent Colaiuta (wincent) Date: 2007-06-25 09:21 Message: (1) The patch was made against the trunk back at the end of May (r2060, I think). The changes to the info.plist (shouldn't it be Info.plist, btw?) weren't manually done by me, but were inserted by TextMate when I made the other additions via its Bundle Editor. These settings are pretty opaque to me and omitting them seems to make no difference, so I will attach a patch against the current trunk which does not include the info.plist changes. (2) There aren't any new user-settable "preferences" as such. The two new files in the "Preferences" subdirectory of the bundle are used to add Behaviours and Examples to the TextMate symbols list... this is what allows them to appear in the pop-up. (3) To see the syntax highlighting you must select "RSpec" from the language pop-up at the bottom of the window. This is just like when you have a Rails file and want special Rails-specific highlighting instead of the default Ruby highlighting. It would be nice if TextMate allowed you to specify that all files ending in "_spec.rb" would be auto-detected as RSpec files, but as far as I know, TextMate only allows you to specify the extension part (".rb") and that would override the default Ruby highlighting. So if we want that feature we either need to try again get the RSpec syntax rolled into the Ruby.tmbundle, or try to get Allan to modify Textmate to allow us to specify not just the extension. (4) The pop-up menu is the function pop-up at the bottom of the TextMate window (right hand side). I don't know if there is a keyboard shortcut; I use the mouse for that. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-06-24 13:06 Message: This sounds great, but I'm having some problems. 1) The patch doesn't apply cleanly against trunk r2121 with "patch -p0 < textmate.diff": patching file Preferences/Symbol patching file Preferences/Symbol patching file info.plist Hunk #1 FAILED at 280. 1 out of 1 hunk FAILED -- saving rejects to file info.plist.rej patching file Syntaxes/RSpec.tmLanguage $ cat info.plist.rej *************** *** 280,285 **** 240FDD9D-CD49-4917-9003-80A3E1DADFBA B5906021-8E54-4863-A13B-EA46333DB5F1 67E726E0-63E2-4840-B8BB-37F665CD34B8 uuid 4CEA47CC-2C3A-45FB-80BE-3820828227C2 --- 280,288 ---- 240FDD9D-CD49-4917-9003-80A3E1DADFBA B5906021-8E54-4863-A13B-EA46333DB5F1 67E726E0-63E2-4840-B8BB-37F665CD34B8 + 923F0A10-96B9-4792-99A4-94FEF66E0B8C + 57EF6130-05A6-4117-94CB-C0BD63328334 + 28F89786-04F4-43D7-82A6-34B046C2BC6B uuid 4CEA47CC-2C3A-45FB-80BE-3820828227C2 2) I tried to add the three rejected lines manually, and in the bundle editor I can see the new RSpec syntax, but I don't see the new preferences. Shouldn't they show up too? 3) There is no new syntax highlighting on my Textmate. How does TextMate know to use this highlighting? Do I need to do anything special to make it work? 4) How do I bring up the list over behaviours and examples shown in your screenshot? It must be some keyboard shortcut I'm unaware of. Cheers, Aslak ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=11254&group_id=797 From noreply at rubyforge.org Mon Jul 9 02:46:10 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 9 Jul 2007 02:46:10 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-12121 ] uninitialized constant Spec::Mocks during a Controller exception when using a different mock framework Message-ID: <20070709064610.835995240D67@rubyforge.org> Bugs item #12121, was opened at 2007-07-08 23:46 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=12121&group_id=797 Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: Brian Takita (btakita) Assigned to: Nobody (None) Summary: uninitialized constant Spec::Mocks during a Controller exception when using a different mock framework Initial Comment: rspec_on_rails/lib/spec/rails/extensions/action_controller/rescue.rb:6 ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=12121&group_id=797 From noreply at rubyforge.org Mon Jul 9 04:11:11 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 9 Jul 2007 04:11:11 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-12121 ] uninitialized constant Spec::Mocks during a Controller exception when using a different mock framework Message-ID: <20070709081111.742ABA970002@rubyforge.org> Bugs item #12121, was opened at 2007-07-08 23:46 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=12121&group_id=797 Category: rails plugin Group: None >Status: Closed Resolution: None Priority: 3 Submitted By: Brian Takita (btakita) Assigned to: Nobody (None) Summary: uninitialized constant Spec::Mocks during a Controller exception when using a different mock framework Initial Comment: rspec_on_rails/lib/spec/rails/extensions/action_controller/rescue.rb:6 ---------------------------------------------------------------------- >Comment By: Brian Takita (btakita) Date: 2007-07-09 01:11 Message: Fixed in Head ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=12121&group_id=797 From noreply at rubyforge.org Mon Jul 9 18:10:44 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 9 Jul 2007 18:10:44 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-12132 ] succeed matcher Message-ID: <20070709221044.939EF5240B0A@rubyforge.org> Feature Requests item #12132, was opened at 2007-07-09 15:10 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=12132&group_id=797 Category: expectation module Group: None Status: Open Priority: 3 Submitted By: Brian Takita (btakita) Assigned to: Nobody (None) Summary: succeed matcher Initial Comment: Sometime I want to have a method that has a compound matcher. The succeed matcher executes the block and returns true if there is no exception. e.g. "Foobar".should succeed do |obj| obj.to_s.should == "Foobar" end # success "Foobar".should succeed do |obj| obj.to_s.should == "Baz" end # Failure ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=12132&group_id=797 From noreply at rubyforge.org Mon Jul 9 18:18:18 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 9 Jul 2007 18:18:18 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-11949 ] & quot; should_yield& quot; or & quot; .should raise_error(MySpecificError)& quot; equivalent for yields Message-ID: <20070709221818.BC8145240B0A@rubyforge.org> Feature Requests item #11949, was opened at 2007-07-01 20:49 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=11949&group_id=797 Category: expectation module Group: None Status: Open Priority: 3 Submitted By: S. Potter (mbbx6spp) Assigned to: Nobody (None) Summary: &quot;should_yield&quot; or &quot;.should raise_error(MySpecificError)&quot; equivalent for yields Initial Comment: The problem is already described here: http://snakesgemscoffee.blogspot.com/2007/07/rspec-shouldyield.html In summary: Just like we can write: lambda { Client.configure(&spec_block(1)) }.should raise_error(MySpecificError) We should also be able to write: lambda { Client.configure(&spec_block(1)) }.should_yield(Config) This should mean, to the "spec_block" that expects one (1) argument of type Config. Other suggestions for syntax are: lambda { Client.configure(&spec_block(1)) }.should yield_instances_of(Config) lambda { Client.configure(&spec_block(1)) }.should yield_objects_of(Config) Or something else similar (these are just things that popped in my head right now. Feedback much appreciated. ---------------------------------------------------------------------- >Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-07-09 18:18 Message: In your example (both here and in your blog entry) - what does &spec_block(1) refer to? Is this some sort of block that would be implicitly available when yield_with (or similar) is used? Could you use something more straightforward like this? class Funky def self.bacon(&proc) yield '_how' if proc.arity == 1 end end describe Funky do it "should yield when arity is 1" do lambda do Funky.bacon do |s| s.should == '_how' throw :done end end.should throw_symbol(:done) # proves the bacon yielded end it "should not yield when arity is 2" do lambda do Funky.bacon do throw :done end end.should_not throw_symbol(:done) end end ---------------------------------------------------------------------- Comment By: S. Potter (mbbx6spp) Date: 2007-07-01 21:27 Message: Great thanks, I'll attached to this ticket. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-07-01 21:25 Message: Cool - I'll keep my eyes peeled for your patch. Go ahead and just attach it to this ticket - no need to make a new patch ticket - OK? ---------------------------------------------------------------------- Comment By: S. Potter (mbbx6spp) Date: 2007-07-01 21:21 Message: Actually that sounds great. I wasn't convinced of my own suggestions to be honest, just a starting point - wonderful! I can try coming up with a patch after work days this week, to contribute back. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-07-01 20:56 Message: We don't want to add any more "should_xyz" methods because they have to get added directly to object. So it's got to be a matcher - the trick is coming up w/ good verbiage. How about this? should yield_with(arg1,arg2) should yield_with(no_args) You would always have to supply at least one arg - but that arg could be no_args which would be the same method we use for mocks: should_receive(:message).with(no_args) WDYT? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=11949&group_id=797 From noreply at rubyforge.org Mon Jul 9 18:26:17 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 9 Jul 2007 18:26:17 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-12132 ] succeed matcher Message-ID: <20070709222617.3609A5240B0A@rubyforge.org> Feature Requests item #12132, was opened at 2007-07-09 22:10 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=12132&group_id=797 Category: expectation module Group: None Status: Open Priority: 3 Submitted By: Brian Takita (btakita) Assigned to: Nobody (None) Summary: succeed matcher Initial Comment: Sometime I want to have a method that has a compound matcher. The succeed matcher executes the block and returns true if there is no exception. e.g. "Foobar".should succeed do |obj| obj.to_s.should == "Foobar" end # success "Foobar".should succeed do |obj| obj.to_s.should == "Baz" end # Failure ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-07-09 22:26 Message: Have you tried should satisfy? It's basically what you're asking for: http://rspec.rubyforge.org/rdoc/classes/Spec/Matchers.html#M000248 ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=12132&group_id=797 From noreply at rubyforge.org Mon Jul 9 18:29:08 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 9 Jul 2007 18:29:08 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-12132 ] succeed matcher Message-ID: <20070709222908.8AAC75240B0A@rubyforge.org> Feature Requests item #12132, was opened at 2007-07-09 18:10 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=12132&group_id=797 Category: expectation module Group: None Status: Open Priority: 3 Submitted By: Brian Takita (btakita) Assigned to: Nobody (None) Summary: succeed matcher Initial Comment: Sometime I want to have a method that has a compound matcher. The succeed matcher executes the block and returns true if there is no exception. e.g. "Foobar".should succeed do |obj| obj.to_s.should == "Foobar" end # success "Foobar".should succeed do |obj| obj.to_s.should == "Baz" end # Failure ---------------------------------------------------------------------- >Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-07-09 18:29 Message: What kind of method are you talking about? Why does it matter what the succeed matcher _returns_? Can you provide a more illustrative/complete example? I can rewrite your code as (I must be missing something): "Foobar".to_s.should == "Foobar" "Foobar".to_s.should == "Baz" ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-07-09 18:26 Message: Have you tried should satisfy? It's basically what you're asking for: http://rspec.rubyforge.org/rdoc/classes/Spec/Matchers.html#M000248 ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=12132&group_id=797 From noreply at rubyforge.org Mon Jul 9 18:59:14 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 9 Jul 2007 18:59:14 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-11949 ] & amp; quot; should_yield& amp; quot; or & amp; quot; .should raise_error(MySpecificError)& amp; quot; equivalent for yields Message-ID: <20070709225914.329905240B5F@rubyforge.org> Feature Requests item #11949, was opened at 2007-07-01 19:49 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=11949&group_id=797 Category: expectation module Group: None Status: Open Priority: 3 Submitted By: S. Potter (mbbx6spp) Assigned to: Nobody (None) >Summary: &amp;quot;should_yield&amp;quot; or &amp;quot;.should raise_error(MySpecificError)&amp;quot; equivalent for yields Initial Comment: The problem is already described here: http://snakesgemscoffee.blogspot.com/2007/07/rspec-shouldyield.html In summary: Just like we can write: lambda { Client.configure(&spec_block(1)) }.should raise_error(MySpecificError) We should also be able to write: lambda { Client.configure(&spec_block(1)) }.should_yield(Config) This should mean, to the "spec_block" that expects one (1) argument of type Config. Other suggestions for syntax are: lambda { Client.configure(&spec_block(1)) }.should yield_instances_of(Config) lambda { Client.configure(&spec_block(1)) }.should yield_objects_of(Config) Or something else similar (these are just things that popped in my head right now. Feedback much appreciated. ---------------------------------------------------------------------- >Comment By: S. Potter (mbbx6spp) Date: 2007-07-09 17:59 Message: Aslak, that is very similar (with less validation) to what I already do (as explained in the blog entry above), but doesn't add too much value if we are following a DSL approach in my opinion. My thoughts on what spec_block would do is generate a block with whatever arity is given for it. For example, if I call spec_block(3) that block will produce a block that has 3 arguments that cannot be ignored. I am open to suggestions on the naming of this helper method, but I would prefer that the specs I write for my application don't require so much setup to specify such a simple thing. Those are just my thoughts and will leave this open until there is a bit more clarity to what the RSpec developer consensus is. I will work on a patch based on the vision after that point. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-07-09 17:18 Message: In your example (both here and in your blog entry) - what does &spec_block(1) refer to? Is this some sort of block that would be implicitly available when yield_with (or similar) is used? Could you use something more straightforward like this? class Funky def self.bacon(&proc) yield '_how' if proc.arity == 1 end end describe Funky do it "should yield when arity is 1" do lambda do Funky.bacon do |s| s.should == '_how' throw :done end end.should throw_symbol(:done) # proves the bacon yielded end it "should not yield when arity is 2" do lambda do Funky.bacon do throw :done end end.should_not throw_symbol(:done) end end ---------------------------------------------------------------------- Comment By: S. Potter (mbbx6spp) Date: 2007-07-01 20:27 Message: Great thanks, I'll attached to this ticket. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-07-01 20:25 Message: Cool - I'll keep my eyes peeled for your patch. Go ahead and just attach it to this ticket - no need to make a new patch ticket - OK? ---------------------------------------------------------------------- Comment By: S. Potter (mbbx6spp) Date: 2007-07-01 20:21 Message: Actually that sounds great. I wasn't convinced of my own suggestions to be honest, just a starting point - wonderful! I can try coming up with a patch after work days this week, to contribute back. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-07-01 19:56 Message: We don't want to add any more "should_xyz" methods because they have to get added directly to object. So it's got to be a matcher - the trick is coming up w/ good verbiage. How about this? should yield_with(arg1,arg2) should yield_with(no_args) You would always have to supply at least one arg - but that arg could be no_args which would be the same method we use for mocks: should_receive(:message).with(no_args) WDYT? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=11949&group_id=797 From noreply at rubyforge.org Tue Jul 10 08:15:05 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 10 Jul 2007 08:15:05 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-12153 ] got undifined method 'fixtures' for spec Message-ID: <20070710121505.48C205240A31@rubyforge.org> Bugs item #12153, was opened at 2007-07-10 12:15 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=12153&group_id=797 Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: Akhil Bansal (bansalakhil) Assigned to: Nobody (None) Summary: got undifined method 'fixtures' for spec Initial Comment: I am using rails 1.2.3 and rspec 1.0.5. When I tried to run spec with "ruby script\spec spec\models\users.rb -b", I stuck with following error C:\Akhil\ror\kewl with rspec>ruby script\spec spec\models\users.rb -b C:/Akhil/ror/kewl with rspec/vendor/plugins/rspec/lib/spec/dsl/behaviour_eval.rb:137:in `method_missing': undefined method `fixtures' for # (NoMethodError) from ./spec\models\users.rb:4 from C:/Akhil/ror/kewl with rspec/vendor/plugins/rspec/lib/spec/dsl/behaviour.rb:54:in `class_eval' from C:/Akhil/ror/kewl with rspec/vendor/plugins/rspec/lib/spec/dsl/behaviour.rb:54:in `eval_behaviour' from C:/Akhil/ror/kewl with rspec/vendor/plugins/rspec/lib/spec/dsl/behaviour.rb:31:in `initialize' from C:/Akhil/ror/kewl with rspec/vendor/plugins/rspec/lib/spec/dsl/behaviour_factory.rb:36:in `new' from C:/Akhil/ror/kewl with rspec/vendor/plugins/rspec/lib/spec/dsl/behaviour_factory.rb:36:in `create' from C:/Akhil/ror/kewl with rspec/vendor/plugins/rspec/lib/spec/runner/extensions/kernel.rb:24:in `describe' from ./spec\models\users.rb:3 from C:/Akhil/ror/kewl with rspec/vendor/plugins/rspec/lib/spec/runner/behaviour_runner.rb:85:in `load' from C:/Akhil/ror/kewl with rspec/vendor/plugins/rspec/lib/spec/runner/behaviour_runner.rb:85:in `load_specs' from C:/Akhil/ror/kewl with rspec/vendor/plugins/rspec/lib/spec/runner/behaviour_runner.rb:84:in `each' from C:/Akhil/ror/kewl with rspec/vendor/plugins/rspec/lib/spec/runner/behaviour_runner.rb:84:in `load_specs' from C:/Akhil/ror/kewl with rspec/vendor/plugins/rspec/lib/spec/runner/behaviour_runner.rb:22:in `run' from C:/Akhil/ror/kewl with rspec/vendor/plugins/rspec/lib/spec/runner/command_line.rb:17:in `run' from script/spec:4 any idea? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=12153&group_id=797 From noreply at rubyforge.org Tue Jul 10 08:19:37 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 10 Jul 2007 08:19:37 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-12153 ] got undifined method 'fixtures' for spec Message-ID: <20070710121937.A38405240A41@rubyforge.org> Bugs item #12153, was opened at 2007-07-10 12:15 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=12153&group_id=797 Category: rails plugin Group: None >Status: Closed >Resolution: Rejected Priority: 3 Submitted By: Akhil Bansal (bansalakhil) >Assigned to: David Chelimsky (dchelimsky) Summary: got undifined method 'fixtures' for spec Initial Comment: I am using rails 1.2.3 and rspec 1.0.5. When I tried to run spec with "ruby script\spec spec\models\users.rb -b", I stuck with following error C:\Akhil\ror\kewl with rspec>ruby script\spec spec\models\users.rb -b C:/Akhil/ror/kewl with rspec/vendor/plugins/rspec/lib/spec/dsl/behaviour_eval.rb:137:in `method_missing': undefined method `fixtures' for # (NoMethodError) from ./spec\models\users.rb:4 from C:/Akhil/ror/kewl with rspec/vendor/plugins/rspec/lib/spec/dsl/behaviour.rb:54:in `class_eval' from C:/Akhil/ror/kewl with rspec/vendor/plugins/rspec/lib/spec/dsl/behaviour.rb:54:in `eval_behaviour' from C:/Akhil/ror/kewl with rspec/vendor/plugins/rspec/lib/spec/dsl/behaviour.rb:31:in `initialize' from C:/Akhil/ror/kewl with rspec/vendor/plugins/rspec/lib/spec/dsl/behaviour_factory.rb:36:in `new' from C:/Akhil/ror/kewl with rspec/vendor/plugins/rspec/lib/spec/dsl/behaviour_factory.rb:36:in `create' from C:/Akhil/ror/kewl with rspec/vendor/plugins/rspec/lib/spec/runner/extensions/kernel.rb:24:in `describe' from ./spec\models\users.rb:3 from C:/Akhil/ror/kewl with rspec/vendor/plugins/rspec/lib/spec/runner/behaviour_runner.rb:85:in `load' from C:/Akhil/ror/kewl with rspec/vendor/plugins/rspec/lib/spec/runner/behaviour_runner.rb:85:in `load_specs' from C:/Akhil/ror/kewl with rspec/vendor/plugins/rspec/lib/spec/runner/behaviour_runner.rb:84:in `each' from C:/Akhil/ror/kewl with rspec/vendor/plugins/rspec/lib/spec/runner/behaviour_runner.rb:84:in `load_specs' from C:/Akhil/ror/kewl with rspec/vendor/plugins/rspec/lib/spec/runner/behaviour_runner.rb:22:in `run' from C:/Akhil/ror/kewl with rspec/vendor/plugins/rspec/lib/spec/runner/command_line.rb:17:in `run' from script/spec:4 any idea? ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-07-10 12:19 Message: RSpec wants the file to be called user_spec.rb. If you don't want to call it that, you can do this: describe User, :behaviour_type => :model do ... end ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=12153&group_id=797 From noreply at rubyforge.org Tue Jul 10 08:25:40 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 10 Jul 2007 08:25:40 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-12153 ] got undifined method 'fixtures' for spec Message-ID: <20070710122540.142D15240A41@rubyforge.org> Bugs item #12153, was opened at 2007-07-10 08:15 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=12153&group_id=797 Category: rails plugin Group: None Status: Closed Resolution: Rejected Priority: 3 Submitted By: Akhil Bansal (bansalakhil) Assigned to: David Chelimsky (dchelimsky) Summary: got undifined method 'fixtures' for spec Initial Comment: I am using rails 1.2.3 and rspec 1.0.5. When I tried to run spec with "ruby script\spec spec\models\users.rb -b", I stuck with following error C:\Akhil\ror\kewl with rspec>ruby script\spec spec\models\users.rb -b C:/Akhil/ror/kewl with rspec/vendor/plugins/rspec/lib/spec/dsl/behaviour_eval.rb:137:in `method_missing': undefined method `fixtures' for # (NoMethodError) from ./spec\models\users.rb:4 from C:/Akhil/ror/kewl with rspec/vendor/plugins/rspec/lib/spec/dsl/behaviour.rb:54:in `class_eval' from C:/Akhil/ror/kewl with rspec/vendor/plugins/rspec/lib/spec/dsl/behaviour.rb:54:in `eval_behaviour' from C:/Akhil/ror/kewl with rspec/vendor/plugins/rspec/lib/spec/dsl/behaviour.rb:31:in `initialize' from C:/Akhil/ror/kewl with rspec/vendor/plugins/rspec/lib/spec/dsl/behaviour_factory.rb:36:in `new' from C:/Akhil/ror/kewl with rspec/vendor/plugins/rspec/lib/spec/dsl/behaviour_factory.rb:36:in `create' from C:/Akhil/ror/kewl with rspec/vendor/plugins/rspec/lib/spec/runner/extensions/kernel.rb:24:in `describe' from ./spec\models\users.rb:3 from C:/Akhil/ror/kewl with rspec/vendor/plugins/rspec/lib/spec/runner/behaviour_runner.rb:85:in `load' from C:/Akhil/ror/kewl with rspec/vendor/plugins/rspec/lib/spec/runner/behaviour_runner.rb:85:in `load_specs' from C:/Akhil/ror/kewl with rspec/vendor/plugins/rspec/lib/spec/runner/behaviour_runner.rb:84:in `each' from C:/Akhil/ror/kewl with rspec/vendor/plugins/rspec/lib/spec/runner/behaviour_runner.rb:84:in `load_specs' from C:/Akhil/ror/kewl with rspec/vendor/plugins/rspec/lib/spec/runner/behaviour_runner.rb:22:in `run' from C:/Akhil/ror/kewl with rspec/vendor/plugins/rspec/lib/spec/runner/command_line.rb:17:in `run' from script/spec:4 any idea? ---------------------------------------------------------------------- >Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-07-10 08:25 Message: You may also have been bitten by this bug: http://rubyforge.org/tracker/index.php?func=detail&aid=10534&group_id=797&atid=3149 The bug exists in RSpec 1.0.5 and should be gone with the next release. It's fixed on trunk, so you may want to try with that to see if your problem goes away. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-07-10 08:19 Message: RSpec wants the file to be called user_spec.rb. If you don't want to call it that, you can do this: describe User, :behaviour_type => :model do ... end ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=12153&group_id=797 From noreply at rubyforge.org Tue Jul 10 08:29:42 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 10 Jul 2007 08:29:42 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-10577 ] Rails with Oracle breaks 0.9.2 Message-ID: <20070710122942.5EB505240A42@rubyforge.org> Bugs item #10577, was opened at 2007-05-04 11:57 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10577&group_id=797 Category: rails plugin Group: None Status: Open Resolution: Accepted Priority: 3 Submitted By: John Andrews (jandrews) >Assigned to: Aslak Helles?y (aslak_hellesoy) Summary: Rails with Oracle breaks 0.9.2 Initial Comment: Upgrading to rspec 0.9.2 from 0.8.2 using Oracle database with ActiveRecord breaks due to the following: oracle_adapter.rb:316 (owner, table_name) = @connection.describe(table_name) @connection is an instance of OCI8AutoRecover which itself delegates the describe method to OCI8. class OCI8AutoRecover < DelegateClass(OCI8) #... # no def describe method end DelegateClass internally uses method_missing to call the delegate class' describe class OCI8 #:nodoc: def describe(name) #... end #... end The problem is that rspec defines Kernel#describe, so method_missing never catches the call to delegate and it fails from rspec because there is obviously no block given. My work-around modifies 2 files. I will just include the methods I changed because I don't have diffs from trunk. from file: rspec_on_rails/lib/spec/rails/extensions/kernel.rb def describe(*args, &block) # assuming that if a block is not given that it is not a call # for rspec if block_given? args << {} unless Hash === args.last args.last[:spec_path] = caller(0)[1] end original_describe(*args, &block) end from file: rspec-0.9.2/lib/spec/runner/extensions/kernel.rb def describe(*args, &block) if block_given? raise ArgumentError if args.empty? register_behaviour(Spec::DSL::BehaviourFactory.create(*args, &block)) else # not the describe that we are looking for # it's probably a call from the oracle adapter super *args end end I don't know if this is the best way to fix the issue, but it works for me and all my specs pass again. if you need more info or someone to test a fix for Oracle I am able to help. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-06-28 14:54 Message: Method visibility is as follows: Object method > Kernel method > method_missing (RSpec describe) ORA driver (DelegateClass) What we need to do here is to make sure the OCI8AutoRecover object intercepts the method before it falls back to Kernel. That's easily done by monkey patching it: class OCI8AutoRecover def describe(name) @connection.describe(name) end end All this does is to define the describe method directly and delegate explicitly. It should work just like before, but I don't have an ORA here to verify it. If someone can confirm that this works I'll roll this into Spec::Rails and enable it automagically so you don't have anything special to do. Aaait? ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-06-28 14:06 Message: I'm looking into a fix for this... ---------------------------------------------------------------------- Comment By: sinclair bain (sinclair) Date: 2007-06-28 12:12 Message: We have a patch for this: Save the following to your /lib directory in a file called e.g. oracle_adapter.rb --------------- # Rspec's dsl uses #describe as a method name at the core of its functionality # The oracle_adapter also uses #describe and the two clash. # Because rspec mixes-in the #describe method via the Kernel module all # Object instances (i.e. all objects) have a #describe method. # The oracle adpater uses a delegation model for some functionality via the # #method_missing mechanism. The #describe method is one of the methods which # _was_ missing when rspec was not around. However the mixin via Kernel changes # that thus _things_ do not function as intended (on the oracle side). # This patch hacks in the #describe method to where it was missing and then # delegates to the implementation. # #see # http://rubyforge.org/tracker/index.php?func=detail&aid=10577&group_id=797&atid=3149 module OracleAdapterPatch # rspec method name collision patch def describe(obj) # puts "OCI8AutoRecover#describe( #{obj} ) forwarded to #{@connection}" @connection.describe(obj) end end OCI8AutoRecover.send(:include, OracleAdapterPatch) ---------------------------- Edit as required. In your environment.rb for example add the following require 'oracle_adapter' which can be made conditional (or could this be a rspec rake task?) Cheers! sinclair rspec now functions ---------------------------------------------------------------------- Comment By: Venkatasubramaniyan K (venkat) Date: 2007-06-28 11:57 Message: Dear rspec team: I am also running into the same problem. I figured out the issue after a long debug session. I don't have any good solution for it. But I would appreciate a solution for this soon (even if it is a temp patch to begin with), so that we don't waste time debugging this. Yes, there could be other software affected by this but the specific Oracle issue at least needs to be resolved. Thanks, Venkat. ---------------------------------------------------------------------- Comment By: sinclair bain (sinclair) Date: 2007-06-01 14:25 Message: Hi, I just ran into this problem in rspec_for_rails 1.0.0. The solution I think we will settle for in the short term is a monkey patch to the OCI8AutoRecover class. The patch implements the #describe method in the OCI8AutoRecover class (via a module include). The patch file is in our rails_app/lib directory and is #required in the environment.rb. This is the implementation: module OracleAdapterPatch # rspec method name collision patch def describe(obj) puts "OCI8AutoRecover#describe( #{obj} ) forwarded to #{@connection}" @connection.describe(obj) end end OCI8AutoRecover.send(:include, OracleAdapterPatch) As is stated below this is (still) a band-aid approach. Cheers! sinclair ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-05-05 19:56 Message: I'm uncomfortable with this solution. It's a band-aid for this particular example, but someone else might come along and do something similar - using method_missing to delegate to another object WITH a block expected in that object's #describe method. Does anyone have any other suggestions? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10577&group_id=797 From noreply at rubyforge.org Tue Jul 10 09:36:17 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 10 Jul 2007 09:36:17 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-12156 ] smooth open mate patch Message-ID: <20070710133617.DB2945240A20@rubyforge.org> Patches item #12156, was opened at 2007-07-10 13:36 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=12156&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Ienaga Eiji (ienaga) Assigned to: Nobody (None) Summary: smooth open mate patch Initial Comment: Category of This patch is RSpec.tmbundle This patch is (1) To run command mate, not set path ~/.MacOSX/environment.plist (2) To open pair file even if file name include "spase" for exapmle #{other} is [~/Library/Application Support/TextMate/**/spec_mate.rb] ^^^^^^^^^^^^^^^^^^^^ ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=12156&group_id=797 From noreply at rubyforge.org Tue Jul 10 09:46:16 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 10 Jul 2007 09:46:16 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-12156 ] smooth open mate patch Message-ID: <20070710134616.282565240A41@rubyforge.org> Patches item #12156, was opened at 2007-07-10 09:36 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=12156&group_id=797 Category: None Group: None Status: Open >Resolution: Accepted Priority: 3 Submitted By: Ienaga Eiji (ienaga) >Assigned to: Aslak Helles?y (aslak_hellesoy) Summary: smooth open mate patch Initial Comment: Category of This patch is RSpec.tmbundle This patch is (1) To run command mate, not set path ~/.MacOSX/environment.plist (2) To open pair file even if file name include "spase" for exapmle #{other} is [~/Library/Application Support/TextMate/**/spec_mate.rb] ^^^^^^^^^^^^^^^^^^^^ ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=12156&group_id=797 From noreply at rubyforge.org Tue Jul 10 11:11:11 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 10 Jul 2007 11:11:11 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-10577 ] Rails with Oracle breaks 0.9.2 Message-ID: <20070710151113.5CA225240A9F@rubyforge.org> Bugs item #10577, was opened at 2007-05-04 11:57 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10577&group_id=797 Category: rails plugin Group: None >Status: Closed Resolution: Accepted Priority: 3 Submitted By: John Andrews (jandrews) Assigned to: Aslak Helles?y (aslak_hellesoy) Summary: Rails with Oracle breaks 0.9.2 Initial Comment: Upgrading to rspec 0.9.2 from 0.8.2 using Oracle database with ActiveRecord breaks due to the following: oracle_adapter.rb:316 (owner, table_name) = @connection.describe(table_name) @connection is an instance of OCI8AutoRecover which itself delegates the describe method to OCI8. class OCI8AutoRecover < DelegateClass(OCI8) #... # no def describe method end DelegateClass internally uses method_missing to call the delegate class' describe class OCI8 #:nodoc: def describe(name) #... end #... end The problem is that rspec defines Kernel#describe, so method_missing never catches the call to delegate and it fails from rspec because there is obviously no block given. My work-around modifies 2 files. I will just include the methods I changed because I don't have diffs from trunk. from file: rspec_on_rails/lib/spec/rails/extensions/kernel.rb def describe(*args, &block) # assuming that if a block is not given that it is not a call # for rspec if block_given? args << {} unless Hash === args.last args.last[:spec_path] = caller(0)[1] end original_describe(*args, &block) end from file: rspec-0.9.2/lib/spec/runner/extensions/kernel.rb def describe(*args, &block) if block_given? raise ArgumentError if args.empty? register_behaviour(Spec::DSL::BehaviourFactory.create(*args, &block)) else # not the describe that we are looking for # it's probably a call from the oracle adapter super *args end end I don't know if this is the best way to fix the issue, but it works for me and all my specs pass again. if you need more info or someone to test a fix for Oracle I am able to help. ---------------------------------------------------------------------- >Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-07-10 11:11 Message: Fixed in r2162. In my previous comment I completely overlooked that my suggestion was in essence what Sinclair had suggested below :-) ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-06-28 14:54 Message: Method visibility is as follows: Object method > Kernel method > method_missing (RSpec describe) ORA driver (DelegateClass) What we need to do here is to make sure the OCI8AutoRecover object intercepts the method before it falls back to Kernel. That's easily done by monkey patching it: class OCI8AutoRecover def describe(name) @connection.describe(name) end end All this does is to define the describe method directly and delegate explicitly. It should work just like before, but I don't have an ORA here to verify it. If someone can confirm that this works I'll roll this into Spec::Rails and enable it automagically so you don't have anything special to do. Aaait? ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-06-28 14:06 Message: I'm looking into a fix for this... ---------------------------------------------------------------------- Comment By: sinclair bain (sinclair) Date: 2007-06-28 12:12 Message: We have a patch for this: Save the following to your /lib directory in a file called e.g. oracle_adapter.rb --------------- # Rspec's dsl uses #describe as a method name at the core of its functionality # The oracle_adapter also uses #describe and the two clash. # Because rspec mixes-in the #describe method via the Kernel module all # Object instances (i.e. all objects) have a #describe method. # The oracle adpater uses a delegation model for some functionality via the # #method_missing mechanism. The #describe method is one of the methods which # _was_ missing when rspec was not around. However the mixin via Kernel changes # that thus _things_ do not function as intended (on the oracle side). # This patch hacks in the #describe method to where it was missing and then # delegates to the implementation. # #see # http://rubyforge.org/tracker/index.php?func=detail&aid=10577&group_id=797&atid=3149 module OracleAdapterPatch # rspec method name collision patch def describe(obj) # puts "OCI8AutoRecover#describe( #{obj} ) forwarded to #{@connection}" @connection.describe(obj) end end OCI8AutoRecover.send(:include, OracleAdapterPatch) ---------------------------- Edit as required. In your environment.rb for example add the following require 'oracle_adapter' which can be made conditional (or could this be a rspec rake task?) Cheers! sinclair rspec now functions ---------------------------------------------------------------------- Comment By: Venkatasubramaniyan K (venkat) Date: 2007-06-28 11:57 Message: Dear rspec team: I am also running into the same problem. I figured out the issue after a long debug session. I don't have any good solution for it. But I would appreciate a solution for this soon (even if it is a temp patch to begin with), so that we don't waste time debugging this. Yes, there could be other software affected by this but the specific Oracle issue at least needs to be resolved. Thanks, Venkat. ---------------------------------------------------------------------- Comment By: sinclair bain (sinclair) Date: 2007-06-01 14:25 Message: Hi, I just ran into this problem in rspec_for_rails 1.0.0. The solution I think we will settle for in the short term is a monkey patch to the OCI8AutoRecover class. The patch implements the #describe method in the OCI8AutoRecover class (via a module include). The patch file is in our rails_app/lib directory and is #required in the environment.rb. This is the implementation: module OracleAdapterPatch # rspec method name collision patch def describe(obj) puts "OCI8AutoRecover#describe( #{obj} ) forwarded to #{@connection}" @connection.describe(obj) end end OCI8AutoRecover.send(:include, OracleAdapterPatch) As is stated below this is (still) a band-aid approach. Cheers! sinclair ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-05-05 19:56 Message: I'm uncomfortable with this solution. It's a band-aid for this particular example, but someone else might come along and do something similar - using method_missing to delegate to another object WITH a block expected in that object's #describe method. Does anyone have any other suggestions? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10577&group_id=797 From noreply at rubyforge.org Tue Jul 10 11:23:23 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 10 Jul 2007 11:23:23 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-12156 ] smooth open mate patch Message-ID: <20070710152323.AC0815240A67@rubyforge.org> Patches item #12156, was opened at 2007-07-10 09:36 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=12156&group_id=797 Category: None Group: None >Status: Closed Resolution: Accepted Priority: 3 Submitted By: Ienaga Eiji (ienaga) Assigned to: Aslak Helles?y (aslak_hellesoy) Summary: smooth open mate patch Initial Comment: Category of This patch is RSpec.tmbundle This patch is (1) To run command mate, not set path ~/.MacOSX/environment.plist (2) To open pair file even if file name include "spase" for exapmle #{other} is [~/Library/Application Support/TextMate/**/spec_mate.rb] ^^^^^^^^^^^^^^^^^^^^ ---------------------------------------------------------------------- >Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-07-10 11:23 Message: Thanks. Applied in r2163. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=12156&group_id=797 From noreply at rubyforge.org Tue Jul 10 11:34:18 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 10 Jul 2007 11:34:18 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-12010 ] Nicer failure message formatting Message-ID: <20070710153418.6060C5240A31@rubyforge.org> Patches item #12010, was opened at 2007-07-05 04:32 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=12010&group_id=797 Category: expectation module Group: None >Status: Closed >Resolution: Accepted Priority: 3 Submitted By: Wincent Colaiuta (wincent) >Assigned to: Aslak Helles?y (aslak_hellesoy) Summary: Nicer failure message formatting Initial Comment: Patch that implements more readable failure formatting as discussed in this thread: http://rubyforge.org/pipermail/rspec-users/2007-June/002153.html ---------------------------------------------------------------------- >Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-07-10 11:34 Message: Great patch! Applied in r2164. ---------------------------------------------------------------------- Comment By: Wincent Colaiuta (wincent) Date: 2007-07-05 06:02 Message: Will attach alternative patch as commented previously. ---------------------------------------------------------------------- Comment By: Wincent Colaiuta (wincent) Date: 2007-07-05 05:59 Message: Darn transparent proxy... looks like I got logged out again; it let me attach the patch but silently discarded the comment I'd included... Here it is again: Ok, so I've revised the patch to implement what you suggest. I will also attach a second patch same as the first one but which includes one other change: treating "=~" like "==" and "===". For me the three operators "go" together conceptually, so to me this: expected: /blah/, got: "other" (using ~=) Reads better than this: expected: =~ /blah/, got: "other" Or the way it looked in my first shot at this patch: expected: =~ /blah/, got : "other" Or prior to the patch: expected: =~ /blah/, got "other" So anyway, like I said, will attach that one as a separate patch because I realize it might be more contentious. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-07-05 04:48 Message: ps - make sure you view that last comment in a fixed width font :) ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-07-05 04:47 Message: On http://pastie.textmate.org/76180 you describe this: expected: blah got: other But I'm seeing this: expected: blah got : other Of the two, I prefer the former. Also, this is all good for equality, but not as good for comparisons: expected: > 6 got: 5 I'd rather see: expected: > 6 got: 5 I won't have time to get this right immediately, but if you want to take another crack at a patch based on these suggestions, I'd be happy to apply it. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=12010&group_id=797 From noreply at rubyforge.org Tue Jul 10 11:42:44 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 10 Jul 2007 11:42:44 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-11888 ] rspec_on_rails spews out warnings when assert_select is used with an XML response Message-ID: <20070710154245.ABC125240A89@rubyforge.org> Patches item #11888, was opened at 2007-06-27 13:13 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=11888&group_id=797 Category: rails plugin Group: None >Status: Closed >Resolution: Accepted Priority: 3 Submitted By: Ian Leitch (idl) >Assigned to: Aslak Helles?y (aslak_hellesoy) Summary: rspec_on_rails spews out warnings when assert_select is used with an XML response Initial Comment: The warning: ignoring attempt to close channel with link opened at byte 61, line 3 closed at byte 141, line 5 attributes at open: {} text around open: "ss version=\2.0\>\n \n \n Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-07-10 11:42 Message: Thanks! Applied in r2165 ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=11888&group_id=797 From noreply at rubyforge.org Tue Jul 10 11:54:15 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 10 Jul 2007 11:54:15 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-12162 ] --drb in spec.opts causes`raise_controller_errors' not to be found and raises subsequent errors Message-ID: <20070710155415.AFB065240AF5@rubyforge.org> Bugs item #12162, was opened at 2007-07-10 11:54 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=12162&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Edward Ocampo-Gooding (edwardog) Assigned to: Nobody (None) Summary: --drb in spec.opts causes`raise_controller_errors' not to be found and raises subsequent errors Initial Comment: Having --drb in spec.opts causes false-failures while running spec tasks against a running spec_server. Such failures resemble the following: NameError in 'PurchaseController should use PurchaseController' undefined local variable or method `raise_controller_errors' for [RSpec example]:# ./spec/models/../spec_helper.rb:12: ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=12162&group_id=797 From noreply at rubyforge.org Tue Jul 10 11:55:54 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 10 Jul 2007 11:55:54 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-12054 ] rake task for spec:recent Message-ID: <20070710155554.8A7885240AE6@rubyforge.org> Patches item #12054, was opened at 2007-07-06 14:09 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=12054&group_id=797 Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: Jerrett Taylor (ennoia) >Assigned to: Aslak Helles?y (aslak_hellesoy) Summary: rake task for spec:recent Initial Comment: This is pretty simple, but i found it missing once i started to accumulate lots of specs ---------------------------------------------------------------------- >Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-07-10 11:55 Message: Great idea. The logic you have to detect twins between lib and spec files is also implemented in RSpec's autotest plugin and in RSpec.tmbundle. I'd like to consolidate this to one place before I apply this, and just rely on one such mechanism from anywhere. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=12054&group_id=797 From noreply at rubyforge.org Tue Jul 10 12:17:11 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 10 Jul 2007 12:17:11 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-11917 ] Cleaner Spec::Ui error for failed Selenium connection Message-ID: <20070710161711.718FE5240BAF@rubyforge.org> Patches item #11917, was opened at 2007-06-29 02:46 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=11917&group_id=797 Category: None Group: None >Status: Closed >Resolution: Accepted Priority: 3 Submitted By: Ian Dees (undees) >Assigned to: Aslak Helles?y (aslak_hellesoy) Summary: Cleaner Spec::Ui error for failed Selenium connection Initial Comment: If Spec::Ui fails for some reason to connect to the Selenium remote (e.g., if it's not running, or the port settings are wrong), the result is a rather lengthy backtrace leading off with a "You must call Spec::Ui::ScreenshotFormatter.screenshot..." message---even if the requisite call to screenshot() is in the right place. Spec::Ui::ScreenshotFormatter::extra_error_content() seems to expect @relative_png_path to be set, which is reasonable for spec failures, but in the case of a "before" clause raising an error, this attribute won't have been set yet. The simplest solution is to skip the call to img_div()---which calls relative_png_path()---if failure.expectation_not_met() is false. This would seem to have the side effect of skipping the screen capture for a "describe" clause that raises any error other than ExpectationNotMet. From a test writer's perspective, I can say the lack of a screenshot in that (rare?) case wouldn't bug me. ---------------------------------------------------------------------- >Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-07-10 12:17 Message: Nice. Applied in r2166 ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=11917&group_id=797 From noreply at rubyforge.org Tue Jul 10 12:48:22 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 10 Jul 2007 12:48:22 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-12163 ] spec:ui:selenium:start and spec:ui:selenium:stop Message-ID: <20070710164822.5CEE95240A4A@rubyforge.org> Feature Requests item #12163, was opened at 2007-07-10 16:48 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=12163&group_id=797 Category: None Group: None Status: Open Priority: 3 Submitted By: David Chelimsky (dchelimsky) Assigned to: Aslak Helles?y (aslak_hellesoy) Summary: spec:ui:selenium:start and spec:ui:selenium:stop Initial Comment: It would be nice to have these rake tasks to stop and start selenium-server just as we start and top spec_server. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=12163&group_id=797 From noreply at rubyforge.org Tue Jul 10 14:44:04 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 10 Jul 2007 14:44:04 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-10823 ] separate errors and failures in output Message-ID: <20070710184404.3680B5240BA4@rubyforge.org> Feature Requests item #10823, was opened at 2007-05-14 09:07 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10823&group_id=797 Category: None Group: None Status: Open Priority: 3 Submitted By: David Chelimsky (dchelimsky) Assigned to: Nobody (None) Summary: separate errors and failures in output Initial Comment: Observe the following output: ========================= $ spec user_spec.rb --format specdoc User - should be in any roles assigned to it (ERROR - 1) - should NOT be in any roles not assigned to it (FAILED - 2) 1) NameError in 'User should be in any roles assigned to it' undefined local variable or method `user' for #<#:0x14ec6a8> ./user_spec.rb:6: 2) 'User should NOT be in any roles not assigned to it' FAILED expected in_role?("unassigned role") to return false, got true ./user_spec.rb:12: Finished in 0.017713 seconds 2 examples, 2 failures ========================= The specdoc output makes a distinction between errors that are raised (ERROR - 1) and logical failures (FAILED - 2), but the last line of the output does not (2 examples, 2 failures). The last line should make the distinction the same way the detailed output does: 2 examples, 1 failure, 1 error ---------------------------------------------------------------------- >Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-07-10 14:44 Message: Currently we only output the pending count when there are 1 or more pending. Failure count is always outputted, even when there are 0 (which is inconsistent with pending). How should we print out errors? I think we should choose between one of the following: a) Always print examples, only print errors/failures/pending inf > 0. b) Always print all of them. This will probably make it a little easier for tools that wish to parse the output (like autotest) ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10823&group_id=797 From noreply at rubyforge.org Tue Jul 10 14:47:25 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 10 Jul 2007 14:47:25 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-8315 ] File "Go to..." functionality Message-ID: <20070710184725.A63125240A9D@rubyforge.org> Feature Requests item #8315, was opened at 2007-01-30 11:20 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=8315&group_id=797 Category: RSpec.tmbundle Group: None >Status: Closed Priority: 3 Submitted By: Brian Yamabe (byamabe) Assigned to: Aslak Helles?y (aslak_hellesoy) >Summary: File "Go to..." functionality Initial Comment: Functionality, similar to the Rails.tmbundle, giving the ability to jump to the related spec from the controller/helper/model/view and vice versa. ---------------------------------------------------------------------- >Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-07-10 14:47 Message: Fixed a while ago. Will be in release 1.0.6. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=8315&group_id=797 From noreply at rubyforge.org Tue Jul 10 19:20:46 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 10 Jul 2007 19:20:46 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-12174 ] mishandling of paths with spaces in spec_mate switch_command Message-ID: <20070710232047.589975240A8D@rubyforge.org> Patches item #12174, was opened at 2007-07-10 23:20 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=12174&group_id=797 Category: RSpec.tmbundle Group: None Status: Open Resolution: None Priority: 3 Submitted By: Carl Porth (badcarl) Assigned to: Aslak Helles?y (aslak_hellesoy) Summary: mishandling of paths with spaces in spec_mate switch_command Initial Comment: In the write_and_open method of SwitchCommand, the paths are not quoted so they blow up when there are spaces in some parent directory. Here is a little patch to fix it. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=12174&group_id=797 From noreply at rubyforge.org Tue Jul 10 20:31:49 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 10 Jul 2007 20:31:49 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-11259 ] windows?: autotest suppresses output Message-ID: <20070711003150.36041A970003@rubyforge.org> Bugs item #11259, was opened at 2007-05-31 12:15 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=11259&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Erik Ostrom (eostrom) Assigned to: Nobody (None) Summary: windows?: autotest suppresses output Initial Comment: When I run rspec under autotest (with the change I noted in 11258), it seems to run okay; it detects specs that should be run anew; it runs them (as evidenced by test.log); but it never, ever shows me any output from the spec runner. Even a test known to fail shows me nothing. If I use rspec without autotest, everything works fine. If I use Test::Unit instead of rspec, autotest shows me the full test runner output. So it must be a problem with the way rspec and autotest interact. (I don't know if this is actually a Windows problem, but it seems plausible.) ---------------------------------------------------------------------- Comment By: Adam Grant (krypticus) Date: 2007-07-10 17:31 Message: Yeah. Same here. I don't get any output from the autotest, except to tell me what it's running. Once I remove --colour from the spec.opts line, I get it working just fine. Windows XP Pro w/SP2 Rspec 1.0.5 (r2081) Rails 1.2.3 Ruby 1.8.6 ZenTest 3.6.0 ---------------------------------------------------------------------- Comment By: Erik Ostrom (eostrom) Date: 2007-05-31 21:44 Message: Another useful piece of information I could have given you, it turns out, is the contents of my spec.opts file, which starts with '--colour'. With that removed, the bug goes away. That's probably good enough for me. In case it'll help track down this problem now or in the future, this is as far as I got: * In run_tests() in autotest.rb, the loop that's supposed to loop over characters in the test command's output gets EOF immediately, i.e., there's apparently no output from the spec script. * In colour() in base_text_formatter.rb, @colour and output_to_tty? are both true, so presumably the colour-formatted string is returned. I don't know what happens to it after it's returned and before it gets output. ---------------------------------------------------------------------- Comment By: Erik Ostrom (eostrom) Date: 2007-05-31 20:46 Message: Sorry, I forgot. I think I've got the latest everything: * Windows XP SP2 * Ruby 1.8.6 * Rails 1.2.3 * RSpec and Spec::Rails r2064 * ZenTest 3.6.0 ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-05-31 12:27 Message: Before investigating this we need to know the versions of all relevant software you are using, for example: * OS X 10.4.9 * Ruby 1.8.6 * RSpec 1.8.2 or RSpec trunk r1643 * Spec::Rails 1.8.2 or Spec::Rails tag r1234... * Rails 1.2.3 or Rails edge r5645 * Whatever other relevant software. Without this information it's like solving 1 equation (your question) with 5 unknown variables (the versions). We strongly recommend that you use the latest released version of RSpec, alternatively the subversion trunk (if you're the bleeding edge kind of person). ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=11259&group_id=797 From noreply at rubyforge.org Wed Jul 11 13:00:36 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 11 Jul 2007 13:00:36 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-11960 ] spec command line complains about multiple format options when only one Message-ID: <20070711170036.82B735240C4B@rubyforge.org> Bugs item #11960, was opened at 2007-07-02 20:06 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=11960&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Fran?ois Beausoleil (fbos) Assigned to: Nobody (None) Summary: spec command line complains about multiple format options when only one Initial Comment: $ spec --version RSpec-1.0.5 (r2081) - BDD for Ruby http://rspec.rubyforge.org/ $ spec --format specdoc spec/import_spec.rb /usr/local/lib/ruby/gems/1.8/gems/rspec-1.0.5/lib/spec/runner/options.rb:109:in `parse_format': When using several --format options only one of them can be without a file (RuntimeError) from /usr/local/lib/ruby/gems/1.8/gems/rspec-1.0.5/lib/spec/runner/option_parser.rb:118:in `parse' from /usr/local/lib/ruby/1.8/optparse.rb:1260:in `call' from /usr/local/lib/ruby/1.8/optparse.rb:1260:in `parse_in_order' from /usr/local/lib/ruby/1.8/optparse.rb:1247:in `catch' from /usr/local/lib/ruby/1.8/optparse.rb:1247:in `parse_in_order' from /usr/local/lib/ruby/1.8/optparse.rb:1241:in `order!' from /usr/local/lib/ruby/1.8/optparse.rb:1332:in `permute!' from /usr/local/lib/ruby/1.8/optparse.rb:1353:in `parse!' ... 14 levels... from /usr/local/lib/ruby/gems/1.8/gems/rspec-1.0.5/lib/spec/runner/command_line.rb:14:in `run' from /usr/local/lib/ruby/gems/1.8/gems/rspec-1.0.5/bin/spec:3 from /usr/local/bin/spec:16:in `load' from /usr/local/bin/spec:16 Anything wrong with my install ? Thanks ! Fran?ois ---------------------------------------------------------------------- Comment By: Michael Klishin (michaelklishin) Date: 2007-07-11 17:00 Message: Seems that regexp in options.rb is missing / symbol. Will back with a patch shortly if so. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-07-03 07:13 Message: I'm unable to reproduce this. If you look at line 109 and 110 of options.rb (where the error is raised), you'll see that @out_used must be true in order for the error to be raised. @out_used is only set to true on line 110, so it sounds like this is a second pass to parse_format. But I don't see how that could happen. Could you insert some debug statements? Does this happen with RSpec trunk too? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=11960&group_id=797 From noreply at rubyforge.org Wed Jul 11 13:03:44 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 11 Jul 2007 13:03:44 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-11960 ] spec command line complains about multiple format options when only one Message-ID: <20070711170344.EC99C5240C4C@rubyforge.org> Bugs item #11960, was opened at 2007-07-02 20:06 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=11960&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Fran?ois Beausoleil (fbos) Assigned to: Nobody (None) Summary: spec command line complains about multiple format options when only one Initial Comment: $ spec --version RSpec-1.0.5 (r2081) - BDD for Ruby http://rspec.rubyforge.org/ $ spec --format specdoc spec/import_spec.rb /usr/local/lib/ruby/gems/1.8/gems/rspec-1.0.5/lib/spec/runner/options.rb:109:in `parse_format': When using several --format options only one of them can be without a file (RuntimeError) from /usr/local/lib/ruby/gems/1.8/gems/rspec-1.0.5/lib/spec/runner/option_parser.rb:118:in `parse' from /usr/local/lib/ruby/1.8/optparse.rb:1260:in `call' from /usr/local/lib/ruby/1.8/optparse.rb:1260:in `parse_in_order' from /usr/local/lib/ruby/1.8/optparse.rb:1247:in `catch' from /usr/local/lib/ruby/1.8/optparse.rb:1247:in `parse_in_order' from /usr/local/lib/ruby/1.8/optparse.rb:1241:in `order!' from /usr/local/lib/ruby/1.8/optparse.rb:1332:in `permute!' from /usr/local/lib/ruby/1.8/optparse.rb:1353:in `parse!' ... 14 levels... from /usr/local/lib/ruby/gems/1.8/gems/rspec-1.0.5/lib/spec/runner/command_line.rb:14:in `run' from /usr/local/lib/ruby/gems/1.8/gems/rspec-1.0.5/bin/spec:3 from /usr/local/bin/spec:16:in `load' from /usr/local/bin/spec:16 Anything wrong with my install ? Thanks ! Fran?ois ---------------------------------------------------------------------- Comment By: Michael Klishin (michaelklishin) Date: 2007-07-11 17:03 Message: Nope, Aslak seems to be right ---------------------------------------------------------------------- Comment By: Michael Klishin (michaelklishin) Date: 2007-07-11 17:00 Message: Seems that regexp in options.rb is missing / symbol. Will back with a patch shortly if so. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-07-03 07:13 Message: I'm unable to reproduce this. If you look at line 109 and 110 of options.rb (where the error is raised), you'll see that @out_used must be true in order for the error to be raised. @out_used is only set to true on line 110, so it sounds like this is a second pass to parse_format. But I don't see how that could happen. Could you insert some debug statements? Does this happen with RSpec trunk too? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=11960&group_id=797 From noreply at rubyforge.org Wed Jul 11 13:52:46 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 11 Jul 2007 13:52:46 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-11960 ] spec command line complains about multiple format options when only one Message-ID: <20070711175247.18BAE5240C4D@rubyforge.org> Bugs item #11960, was opened at 2007-07-02 16:06 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=11960&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Fran?ois Beausoleil (fbos) Assigned to: Nobody (None) Summary: spec command line complains about multiple format options when only one Initial Comment: $ spec --version RSpec-1.0.5 (r2081) - BDD for Ruby http://rspec.rubyforge.org/ $ spec --format specdoc spec/import_spec.rb /usr/local/lib/ruby/gems/1.8/gems/rspec-1.0.5/lib/spec/runner/options.rb:109:in `parse_format': When using several --format options only one of them can be without a file (RuntimeError) from /usr/local/lib/ruby/gems/1.8/gems/rspec-1.0.5/lib/spec/runner/option_parser.rb:118:in `parse' from /usr/local/lib/ruby/1.8/optparse.rb:1260:in `call' from /usr/local/lib/ruby/1.8/optparse.rb:1260:in `parse_in_order' from /usr/local/lib/ruby/1.8/optparse.rb:1247:in `catch' from /usr/local/lib/ruby/1.8/optparse.rb:1247:in `parse_in_order' from /usr/local/lib/ruby/1.8/optparse.rb:1241:in `order!' from /usr/local/lib/ruby/1.8/optparse.rb:1332:in `permute!' from /usr/local/lib/ruby/1.8/optparse.rb:1353:in `parse!' ... 14 levels... from /usr/local/lib/ruby/gems/1.8/gems/rspec-1.0.5/lib/spec/runner/command_line.rb:14:in `run' from /usr/local/lib/ruby/gems/1.8/gems/rspec-1.0.5/bin/spec:3 from /usr/local/bin/spec:16:in `load' from /usr/local/bin/spec:16 Anything wrong with my install ? Thanks ! Fran?ois ---------------------------------------------------------------------- >Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-07-11 13:52 Message: Fran?ois, are you still seeing this behaviour on the trunk? ---------------------------------------------------------------------- Comment By: Michael Klishin (michaelklishin) Date: 2007-07-11 13:03 Message: Nope, Aslak seems to be right ---------------------------------------------------------------------- Comment By: Michael Klishin (michaelklishin) Date: 2007-07-11 13:00 Message: Seems that regexp in options.rb is missing / symbol. Will back with a patch shortly if so. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-07-03 03:13 Message: I'm unable to reproduce this. If you look at line 109 and 110 of options.rb (where the error is raised), you'll see that @out_used must be true in order for the error to be raised. @out_used is only set to true on line 110, so it sounds like this is a second pass to parse_format. But I don't see how that could happen. Could you insert some debug statements? Does this happen with RSpec trunk too? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=11960&group_id=797 From noreply at rubyforge.org Wed Jul 11 14:36:58 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 11 Jul 2007 14:36:58 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-12174 ] mishandling of paths with spaces in spec_mate switch_command Message-ID: <20070711183658.A03E05240C52@rubyforge.org> Patches item #12174, was opened at 2007-07-10 19:20 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=12174&group_id=797 Category: RSpec.tmbundle Group: None >Status: Closed >Resolution: Accepted Priority: 3 Submitted By: Carl Porth (badcarl) Assigned to: Aslak Helles?y (aslak_hellesoy) Summary: mishandling of paths with spaces in spec_mate switch_command Initial Comment: In the write_and_open method of SwitchCommand, the paths are not quoted so they blow up when there are spaces in some parent directory. Here is a little patch to fix it. ---------------------------------------------------------------------- >Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-07-11 14:36 Message: Thanks! Applied in r12174 ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=12174&group_id=797 From noreply at rubyforge.org Thu Jul 12 01:39:54 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 12 Jul 2007 01:39:54 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-12215 ] Misleading error message when passing string as first argument to raise_error Message-ID: <20070712053954.730C5A970004@rubyforge.org> Bugs item #12215, was opened at 2007-07-11 22:39 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=12215&group_id=797 Category: expectation module Group: None Status: Open Resolution: None Priority: 3 Submitted By: Brian Takita (btakita) Assigned to: Nobody (None) Summary: Misleading error message when passing string as first argument to raise_error Initial Comment: describe "An example with raise_error" do it "should provide a nice error message when passed a string as a first argument" do proc do proc do raise "foobar" end.should raise_error("Called 4 times. Expected at most 3 times.") end.should raise_error(ArgumentError, "raise_error expects an Exception Class as its first argument") end end ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=12215&group_id=797 From noreply at rubyforge.org Thu Jul 12 01:44:16 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 12 Jul 2007 01:44:16 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-12215 ] Misleading error message when passing string as first argument to raise_error Message-ID: <20070712054416.D798F5240D9E@rubyforge.org> Bugs item #12215, was opened at 2007-07-12 05:39 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=12215&group_id=797 Category: expectation module Group: None Status: Open Resolution: None Priority: 3 Submitted By: Brian Takita (btakita) Assigned to: Nobody (None) Summary: Misleading error message when passing string as first argument to raise_error Initial Comment: describe "An example with raise_error" do it "should provide a nice error message when passed a string as a first argument" do proc do proc do raise "foobar" end.should raise_error("Called 4 times. Expected at most 3 times.") end.should raise_error(ArgumentError, "raise_error expects an Exception Class as its first argument") end end ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-07-12 05:44 Message: How about allowing the first argument to be a String? That way, especially nice for RuntimeErrors, you can just specify the message and be done with it, unless you want to be more specific. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=12215&group_id=797 From noreply at rubyforge.org Thu Jul 12 15:52:12 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 12 Jul 2007 15:52:12 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-12237 ] (tiny) added full path to mate in switch_command Message-ID: <20070712195213.06F325240A3B@rubyforge.org> Patches item #12237, was opened at 2007-07-12 19:52 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=12237&group_id=797 Category: RSpec.tmbundle Group: None Status: Open Resolution: None Priority: 3 Submitted By: Carl Porth (badcarl) Assigned to: Aslak Helles?y (aslak_hellesoy) Summary: (tiny) added full path to mate in switch_command Initial Comment: My shell config must be hacked to hell because sometimes I get a command not found to "mate". (It might depend on where I am launching TextMate from.) So instead of "mate" we should use "$TM_SUPPORT_PATH/bin/mate". The other shell commands are in /bin and /usr/bin so I don't think they should cause any problems. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=12237&group_id=797 From noreply at rubyforge.org Thu Jul 12 17:26:14 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 12 Jul 2007 17:26:14 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-12237 ] (tiny) added full path to mate in switch_command Message-ID: <20070712212614.4EC805240BE7@rubyforge.org> Patches item #12237, was opened at 2007-07-12 15:52 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=12237&group_id=797 Category: RSpec.tmbundle Group: None >Status: Closed >Resolution: Accepted Priority: 3 Submitted By: Carl Porth (badcarl) Assigned to: Aslak Helles?y (aslak_hellesoy) Summary: (tiny) added full path to mate in switch_command Initial Comment: My shell config must be hacked to hell because sometimes I get a command not found to "mate". (It might depend on where I am launching TextMate from.) So instead of "mate" we should use "$TM_SUPPORT_PATH/bin/mate". The other shell commands are in /bin and /usr/bin so I don't think they should cause any problems. ---------------------------------------------------------------------- >Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-07-12 17:26 Message: Thanks! Applied in r2172 ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=12237&group_id=797 From noreply at rubyforge.org Thu Jul 12 22:19:52 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 12 Jul 2007 22:19:52 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-12246 ] Support Matrix functional testing Message-ID: <20070713021952.65DC85240C95@rubyforge.org> Feature Requests item #12246, was opened at 2007-07-13 02:19 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=12246&group_id=797 Category: runner module Group: None Status: Open Priority: 3 Submitted By: Bin Dong (dongbin) Assigned to: Nobody (None) Summary: Support Matrix functional testing Initial Comment: http://drnicwilliams.com/2007/05/22/functional-testing-using-a-matrix-to-cover-all-edge-cases-video/ There is matrix test support in Zentest. But it can not be used by rspec. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=12246&group_id=797 From noreply at rubyforge.org Sat Jul 14 16:11:28 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sat, 14 Jul 2007 16:11:28 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-12132 ] succeed matcher Message-ID: <20070714201128.5F51B5240E06@rubyforge.org> Feature Requests item #12132, was opened at 2007-07-09 15:10 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=12132&group_id=797 Category: expectation module Group: None Status: Open Priority: 3 Submitted By: Brian Takita (btakita) Assigned to: Nobody (None) Summary: succeed matcher Initial Comment: Sometime I want to have a method that has a compound matcher. The succeed matcher executes the block and returns true if there is no exception. e.g. "Foobar".should succeed do |obj| obj.to_s.should == "Foobar" end # success "Foobar".should succeed do |obj| obj.to_s.should == "Baz" end # Failure ---------------------------------------------------------------------- >Comment By: Brian Takita (btakita) Date: 2007-07-14 13:11 Message: David, satisfy depends on the return value of the block. It has to be true. The intention of succeed is that there is no exception in the block. I suppose that unless the last line of the block is false or nil, it will work, but that seems kind of side-effecty. I'm worried that would lead to unexpected failures. Of course, succeed is very similar to satisfy so it may not justify adding another matcher. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-07-09 15:29 Message: What kind of method are you talking about? Why does it matter what the succeed matcher _returns_? Can you provide a more illustrative/complete example? I can rewrite your code as (I must be missing something): "Foobar".to_s.should == "Foobar" "Foobar".to_s.should == "Baz" ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-07-09 15:26 Message: Have you tried should satisfy? It's basically what you're asking for: http://rspec.rubyforge.org/rdoc/classes/Spec/Matchers.html#M000248 ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=12132&group_id=797 From noreply at rubyforge.org Sat Jul 14 16:18:07 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sat, 14 Jul 2007 16:18:07 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-12132 ] succeed matcher Message-ID: <20070714201808.0F5D35240E06@rubyforge.org> Feature Requests item #12132, was opened at 2007-07-09 15:10 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=12132&group_id=797 Category: expectation module Group: None Status: Open Priority: 3 Submitted By: Brian Takita (btakita) Assigned to: Nobody (None) Summary: succeed matcher Initial Comment: Sometime I want to have a method that has a compound matcher. The succeed matcher executes the block and returns true if there is no exception. e.g. "Foobar".should succeed do |obj| obj.to_s.should == "Foobar" end # success "Foobar".should succeed do |obj| obj.to_s.should == "Baz" end # Failure ---------------------------------------------------------------------- >Comment By: Brian Takita (btakita) Date: 2007-07-14 13:18 Message: Aslak, it equivalent to Test::Unit users making assertion methods. It allows a "test dsl" to be set up. Here is a less arbitrary example. Having matcher methods in the Behaviour makes the intention of the Example clearer. describe User, "#save" do it "works in state 1" do ... @user.should save_related_projects end it "works in state 2" do ... @user.should save_related_projects end it "works in state 3" do ... @user.should save_related_projects end def save_related_projects user.should succeed do |user| user.projects.each do |project| project.should be_saved_by_user end end end end ---------------------------------------------------------------------- Comment By: Brian Takita (btakita) Date: 2007-07-14 13:11 Message: David, satisfy depends on the return value of the block. It has to be true. The intention of succeed is that there is no exception in the block. I suppose that unless the last line of the block is false or nil, it will work, but that seems kind of side-effecty. I'm worried that would lead to unexpected failures. Of course, succeed is very similar to satisfy so it may not justify adding another matcher. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-07-09 15:29 Message: What kind of method are you talking about? Why does it matter what the succeed matcher _returns_? Can you provide a more illustrative/complete example? I can rewrite your code as (I must be missing something): "Foobar".to_s.should == "Foobar" "Foobar".to_s.should == "Baz" ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-07-09 15:26 Message: Have you tried should satisfy? It's basically what you're asking for: http://rspec.rubyforge.org/rdoc/classes/Spec/Matchers.html#M000248 ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=12132&group_id=797 From noreply at rubyforge.org Sat Jul 14 16:28:05 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sat, 14 Jul 2007 16:28:05 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-12132 ] succeed matcher Message-ID: <20070714202805.EB6FF5240AA5@rubyforge.org> Feature Requests item #12132, was opened at 2007-07-09 15:10 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=12132&group_id=797 Category: expectation module Group: None Status: Open Priority: 3 Submitted By: Brian Takita (btakita) Assigned to: Nobody (None) Summary: succeed matcher Initial Comment: Sometime I want to have a method that has a compound matcher. The succeed matcher executes the block and returns true if there is no exception. e.g. "Foobar".should succeed do |obj| obj.to_s.should == "Foobar" end # success "Foobar".should succeed do |obj| obj.to_s.should == "Baz" end # Failure ---------------------------------------------------------------------- >Comment By: Brian Takita (btakita) Date: 2007-07-14 13:28 Message: Also with satisfy, if there is an ExpectationNotMetError, the stack trace does not go into the block. The stack trace ends where .should is called. As a user, I would want to see which line triggers the ExpectationNotMetError occurs. ---------------------------------------------------------------------- Comment By: Brian Takita (btakita) Date: 2007-07-14 13:18 Message: Aslak, it equivalent to Test::Unit users making assertion methods. It allows a "test dsl" to be set up. Here is a less arbitrary example. Having matcher methods in the Behaviour makes the intention of the Example clearer. describe User, "#save" do it "works in state 1" do ... @user.should save_related_projects end it "works in state 2" do ... @user.should save_related_projects end it "works in state 3" do ... @user.should save_related_projects end def save_related_projects user.should succeed do |user| user.projects.each do |project| project.should be_saved_by_user end end end end ---------------------------------------------------------------------- Comment By: Brian Takita (btakita) Date: 2007-07-14 13:11 Message: David, satisfy depends on the return value of the block. It has to be true. The intention of succeed is that there is no exception in the block. I suppose that unless the last line of the block is false or nil, it will work, but that seems kind of side-effecty. I'm worried that would lead to unexpected failures. Of course, succeed is very similar to satisfy so it may not justify adding another matcher. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-07-09 15:29 Message: What kind of method are you talking about? Why does it matter what the succeed matcher _returns_? Can you provide a more illustrative/complete example? I can rewrite your code as (I must be missing something): "Foobar".to_s.should == "Foobar" "Foobar".to_s.should == "Baz" ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-07-09 15:26 Message: Have you tried should satisfy? It's basically what you're asking for: http://rspec.rubyforge.org/rdoc/classes/Spec/Matchers.html#M000248 ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=12132&group_id=797 From noreply at rubyforge.org Sat Jul 14 17:17:29 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sat, 14 Jul 2007 17:17:29 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-12284 ] mock_with :rr Message-ID: <20070714211729.79F605240E0E@rubyforge.org> Feature Requests item #12284, was opened at 2007-07-14 14:17 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=12284&group_id=797 Category: mock module Group: None Status: Open Priority: 3 Submitted By: Brian Takita (btakita) Assigned to: Nobody (None) Summary: mock_with :rr Initial Comment: mock_with the RR (Double R) framework ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=12284&group_id=797 From noreply at rubyforge.org Sat Jul 14 17:20:00 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sat, 14 Jul 2007 17:20:00 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-12132 ] succeed matcher Message-ID: <20070714212000.599235240DFE@rubyforge.org> Feature Requests item #12132, was opened at 2007-07-09 22:10 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=12132&group_id=797 Category: expectation module Group: None Status: Open Priority: 3 Submitted By: Brian Takita (btakita) Assigned to: Nobody (None) Summary: succeed matcher Initial Comment: Sometime I want to have a method that has a compound matcher. The succeed matcher executes the block and returns true if there is no exception. e.g. "Foobar".should succeed do |obj| obj.to_s.should == "Foobar" end # success "Foobar".should succeed do |obj| obj.to_s.should == "Baz" end # Failure ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-07-14 21:20 Message: I can see the usefulness, but "succeed" doesn't speak to me. In fact, it seems to me that "satisfy" is a better word for what you're describing, but we're already using that :( Here's a few other ideas. They probably mostly suck: support pass fulfill meet comply Any other ideas for the right word here? ---------------------------------------------------------------------- Comment By: Brian Takita (btakita) Date: 2007-07-14 20:28 Message: Also with satisfy, if there is an ExpectationNotMetError, the stack trace does not go into the block. The stack trace ends where .should is called. As a user, I would want to see which line triggers the ExpectationNotMetError occurs. ---------------------------------------------------------------------- Comment By: Brian Takita (btakita) Date: 2007-07-14 20:18 Message: Aslak, it equivalent to Test::Unit users making assertion methods. It allows a "test dsl" to be set up. Here is a less arbitrary example. Having matcher methods in the Behaviour makes the intention of the Example clearer. describe User, "#save" do it "works in state 1" do ... @user.should save_related_projects end it "works in state 2" do ... @user.should save_related_projects end it "works in state 3" do ... @user.should save_related_projects end def save_related_projects user.should succeed do |user| user.projects.each do |project| project.should be_saved_by_user end end end end ---------------------------------------------------------------------- Comment By: Brian Takita (btakita) Date: 2007-07-14 20:11 Message: David, satisfy depends on the return value of the block. It has to be true. The intention of succeed is that there is no exception in the block. I suppose that unless the last line of the block is false or nil, it will work, but that seems kind of side-effecty. I'm worried that would lead to unexpected failures. Of course, succeed is very similar to satisfy so it may not justify adding another matcher. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-07-09 22:29 Message: What kind of method are you talking about? Why does it matter what the succeed matcher _returns_? Can you provide a more illustrative/complete example? I can rewrite your code as (I must be missing something): "Foobar".to_s.should == "Foobar" "Foobar".to_s.should == "Baz" ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-07-09 22:26 Message: Have you tried should satisfy? It's basically what you're asking for: http://rspec.rubyforge.org/rdoc/classes/Spec/Matchers.html#M000248 ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=12132&group_id=797 From noreply at rubyforge.org Sat Jul 14 17:23:04 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sat, 14 Jul 2007 17:23:04 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-12284 ] mock_with :rr Message-ID: <20070714212304.58D025240E0E@rubyforge.org> Feature Requests item #12284, was opened at 2007-07-14 21:17 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=12284&group_id=797 Category: mock module Group: None Status: Open Priority: 3 Submitted By: Brian Takita (btakita) Assigned to: Nobody (None) Summary: mock_with :rr Initial Comment: mock_with the RR (Double R) framework ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-07-14 21:23 Message: Hey Brian - can you be a bit more verbose with your requests? I know what you mean because we've discussed this, but probably nobody else on the list does. Something like: Support mocking using the new Double R framework (http://rubyforge.org/projects/pivotalrb/) using "mock_with :rr". Thanks. And please go ahead and feel free to add this. Cheers, David ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=12284&group_id=797 From noreply at rubyforge.org Sat Jul 14 17:26:04 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sat, 14 Jul 2007 17:26:04 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-12284 ] mock_with :rr Message-ID: <20070714212605.040265240E0E@rubyforge.org> Feature Requests item #12284, was opened at 2007-07-14 14:17 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=12284&group_id=797 Category: mock module Group: None >Status: Closed Priority: 3 Submitted By: Brian Takita (btakita) Assigned to: Nobody (None) Summary: mock_with :rr Initial Comment: mock_with the RR (Double R) framework ---------------------------------------------------------------------- >Comment By: Brian Takita (btakita) Date: 2007-07-14 14:26 Message: Checked in Rev 2175 ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-07-14 14:23 Message: Hey Brian - can you be a bit more verbose with your requests? I know what you mean because we've discussed this, but probably nobody else on the list does. Something like: Support mocking using the new Double R framework (http://rubyforge.org/projects/pivotalrb/) using "mock_with :rr". Thanks. And please go ahead and feel free to add this. Cheers, David ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=12284&group_id=797 From noreply at rubyforge.org Sat Jul 14 19:14:31 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sat, 14 Jul 2007 19:14:31 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-12132 ] succeed matcher Message-ID: <20070714231431.A5C4B5240E24@rubyforge.org> Feature Requests item #12132, was opened at 2007-07-09 22:10 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=12132&group_id=797 Category: expectation module Group: None Status: Open Priority: 3 Submitted By: Brian Takita (btakita) Assigned to: Nobody (None) Summary: succeed matcher Initial Comment: Sometime I want to have a method that has a compound matcher. The succeed matcher executes the block and returns true if there is no exception. e.g. "Foobar".should succeed do |obj| obj.to_s.should == "Foobar" end # success "Foobar".should succeed do |obj| obj.to_s.should == "Baz" end # Failure ---------------------------------------------------------------------- Comment By: Michael Klishin (michaelklishin) Date: 2007-07-14 23:14 Message: Brian, I may not get something here but how about lambda ... should_not raise_error? David Ch., I think pass or just expect(-ed) are okay. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-07-14 21:20 Message: I can see the usefulness, but "succeed" doesn't speak to me. In fact, it seems to me that "satisfy" is a better word for what you're describing, but we're already using that :( Here's a few other ideas. They probably mostly suck: support pass fulfill meet comply Any other ideas for the right word here? ---------------------------------------------------------------------- Comment By: Brian Takita (btakita) Date: 2007-07-14 20:28 Message: Also with satisfy, if there is an ExpectationNotMetError, the stack trace does not go into the block. The stack trace ends where .should is called. As a user, I would want to see which line triggers the ExpectationNotMetError occurs. ---------------------------------------------------------------------- Comment By: Brian Takita (btakita) Date: 2007-07-14 20:18 Message: Aslak, it equivalent to Test::Unit users making assertion methods. It allows a "test dsl" to be set up. Here is a less arbitrary example. Having matcher methods in the Behaviour makes the intention of the Example clearer. describe User, "#save" do it "works in state 1" do ... @user.should save_related_projects end it "works in state 2" do ... @user.should save_related_projects end it "works in state 3" do ... @user.should save_related_projects end def save_related_projects user.should succeed do |user| user.projects.each do |project| project.should be_saved_by_user end end end end ---------------------------------------------------------------------- Comment By: Brian Takita (btakita) Date: 2007-07-14 20:11 Message: David, satisfy depends on the return value of the block. It has to be true. The intention of succeed is that there is no exception in the block. I suppose that unless the last line of the block is false or nil, it will work, but that seems kind of side-effecty. I'm worried that would lead to unexpected failures. Of course, succeed is very similar to satisfy so it may not justify adding another matcher. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-07-09 22:29 Message: What kind of method are you talking about? Why does it matter what the succeed matcher _returns_? Can you provide a more illustrative/complete example? I can rewrite your code as (I must be missing something): "Foobar".to_s.should == "Foobar" "Foobar".to_s.should == "Baz" ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-07-09 22:26 Message: Have you tried should satisfy? It's basically what you're asking for: http://rspec.rubyforge.org/rdoc/classes/Spec/Matchers.html#M000248 ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=12132&group_id=797 From noreply at rubyforge.org Sat Jul 14 23:10:19 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sat, 14 Jul 2007 23:10:19 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-12132 ] succeed matcher Message-ID: <20070715031019.5B5995240DF1@rubyforge.org> Feature Requests item #12132, was opened at 2007-07-09 22:10 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=12132&group_id=797 Category: expectation module Group: None Status: Open Priority: 3 Submitted By: Brian Takita (btakita) Assigned to: Nobody (None) Summary: succeed matcher Initial Comment: Sometime I want to have a method that has a compound matcher. The succeed matcher executes the block and returns true if there is no exception. e.g. "Foobar".should succeed do |obj| obj.to_s.should == "Foobar" end # success "Foobar".should succeed do |obj| obj.to_s.should == "Baz" end # Failure ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-07-15 03:10 Message: Michael - the problem w/ using should_not raise_error is that the errors themselves would not propagate up - only should_not raise_error would fail - that would be confusing. However, Brian - consider this: def save_related_projects user.projects.each do |project| project.should be_saved_by_user end end Why do we need to wrap the method body in anything here? Wouldn't that get you what you need? That should give you the functionality you're looking for ---------------------------------------------------------------------- Comment By: Michael Klishin (michaelklishin) Date: 2007-07-14 23:14 Message: Brian, I may not get something here but how about lambda ... should_not raise_error? David Ch., I think pass or just expect(-ed) are okay. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-07-14 21:20 Message: I can see the usefulness, but "succeed" doesn't speak to me. In fact, it seems to me that "satisfy" is a better word for what you're describing, but we're already using that :( Here's a few other ideas. They probably mostly suck: support pass fulfill meet comply Any other ideas for the right word here? ---------------------------------------------------------------------- Comment By: Brian Takita (btakita) Date: 2007-07-14 20:28 Message: Also with satisfy, if there is an ExpectationNotMetError, the stack trace does not go into the block. The stack trace ends where .should is called. As a user, I would want to see which line triggers the ExpectationNotMetError occurs. ---------------------------------------------------------------------- Comment By: Brian Takita (btakita) Date: 2007-07-14 20:18 Message: Aslak, it equivalent to Test::Unit users making assertion methods. It allows a "test dsl" to be set up. Here is a less arbitrary example. Having matcher methods in the Behaviour makes the intention of the Example clearer. describe User, "#save" do it "works in state 1" do ... @user.should save_related_projects end it "works in state 2" do ... @user.should save_related_projects end it "works in state 3" do ... @user.should save_related_projects end def save_related_projects user.should succeed do |user| user.projects.each do |project| project.should be_saved_by_user end end end end ---------------------------------------------------------------------- Comment By: Brian Takita (btakita) Date: 2007-07-14 20:11 Message: David, satisfy depends on the return value of the block. It has to be true. The intention of succeed is that there is no exception in the block. I suppose that unless the last line of the block is false or nil, it will work, but that seems kind of side-effecty. I'm worried that would lead to unexpected failures. Of course, succeed is very similar to satisfy so it may not justify adding another matcher. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-07-09 22:29 Message: What kind of method are you talking about? Why does it matter what the succeed matcher _returns_? Can you provide a more illustrative/complete example? I can rewrite your code as (I must be missing something): "Foobar".to_s.should == "Foobar" "Foobar".to_s.should == "Baz" ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-07-09 22:26 Message: Have you tried should satisfy? It's basically what you're asking for: http://rspec.rubyforge.org/rdoc/classes/Spec/Matchers.html#M000248 ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=12132&group_id=797 From noreply at rubyforge.org Sun Jul 15 11:34:03 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 15 Jul 2007 11:34:03 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-12300 ] rr integration Message-ID: <20070715153403.E515F5240AF6@rubyforge.org> Patches item #12300, was opened at 2007-07-15 15:34 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=12300&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Kyle Hargraves (philodespotos) Assigned to: Nobody (None) Summary: rr integration Initial Comment: Quick fix patch up the integration with RR. The failing example now seems to do what it should. RR is pretty fantabulous. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=12300&group_id=797 From noreply at rubyforge.org Sun Jul 15 14:10:54 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 15 Jul 2007 14:10:54 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-12300 ] rr integration Message-ID: <20070715181054.8F7235240AD2@rubyforge.org> Patches item #12300, was opened at 2007-07-15 15:34 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=12300&group_id=797 Category: None Group: None >Status: Closed >Resolution: Accepted Priority: 3 Submitted By: Kyle Hargraves (philodespotos) >Assigned to: David Chelimsky (dchelimsky) Summary: rr integration Initial Comment: Quick fix patch up the integration with RR. The failing example now seems to do what it should. RR is pretty fantabulous. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-07-15 18:10 Message: Applied to r2176. I also added website docs that explain how to hook in different mock frameworks. These will be published when we do the next release. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=12300&group_id=797 From noreply at rubyforge.org Sun Jul 15 16:53:08 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 15 Jul 2007 16:53:08 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-11231 ] fixtures don't load with before(:all) Message-ID: <20070715205308.B82395240B24@rubyforge.org> Bugs item #11231, was opened at 2007-05-30 14:52 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=11231&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Jeremy Stephens (viking415) Assigned to: Nobody (None) Summary: fixtures don't load with before(:all) Initial Comment: Fixtures only load when using before(:each). If I use before(:all), they don't get loaded at all. To reproduce this, run these commands in a shell: rails -d sqlite3 jungle cd jungle ruby script/plugin install svn://rubyforge.org/var/svn/rspec/tags/CURRENT/rspec ruby script/plugin install svn://rubyforge.org/var/svn/rspec/tags/CURRENT/rspec_on_rails script/generate rspec script/generate rspec_model monkey name:string rake db:migrate Then edit spec/models/monkey_spec.rb to include the following: ############# require File.dirname(__FILE__) + '/../spec_helper' describe "monkey with a before(:each)" do fixtures :monkeys before(:each) do @monkey = Monkey.find_by_id(1) end it "should not be nil" do @monkey.should_not be_nil end end describe "monkey with a before(:all)" do fixtures :monkeys before(:all) do @monkey = Monkey.find_by_id(1) end it "should not be nil" do @monkey.should_not be_nil end end ############# Run rake spec:models, and watch the first pass and the second fail. I'm running Kubuntu (Feisty) with Rails 1.2.3 and RSpec SVN r2060 (1.0.4). ---------------------------------------------------------------------- Comment By: Michael Klishin (michaelklishin) Date: 2007-07-15 20:53 Message: This ticket looks stale. Should we close it? ---------------------------------------------------------------------- Comment By: Jeremy Stephens (viking415) Date: 2007-05-30 18:19 Message: My original reason for wanting to use fixtures in before(:all) was to test a userstamp plugin for Rails/ActiveRecord which automatically sets a 'created_by' or 'updated_by' field when a record is saved. In my tests, I wanted to login an existing user before each example, and it seemed wasteful to me at the time for that login to happen every time. It really isn't a big deal to use before(:each) instead; I guess it just struck me as odd that fixtures weren't available for before(:all). After reading your argument, though, I see your point. I think if you choose to outlaw using fixtures during a before(:all), an error message would definitely be helpful. Thanks! ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-05-30 16:51 Message: This was brought up a while back (using the old syntax): http://rubyforge.org/tracker/index.php?func=detail&aid=8145&group_id=797&atid=3149 The basic problem is that fixtures get rolled back between each example if you're using transactional fixtures (which seems to be the way to go). So if we support fixtures in before(:all) and you create @monkey, when the fixtures roll back the @monkey will remain the same - keeping its state through each example. This goes against conventional wisdom, which suggests that state should not be shared between examples. So my instinct is to implement fixtures in before(:all) such that it raises an error saying you can't do it and should use before(:each). But I'm open to other thoughts on the matter, so please feel free to make a case. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=11231&group_id=797 From noreply at rubyforge.org Sun Jul 15 16:53:57 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 15 Jul 2007 16:53:57 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-11067 ] spec runner with -c removes all 'a'-characters for output Message-ID: <20070715205357.95D895240B24@rubyforge.org> Bugs item #11067, was opened at 2007-05-23 12:54 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=11067&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Jon Egil Strand (jonegil) Assigned to: Nobody (None) Summary: spec runner with -c removes all 'a'-characters for output Initial Comment: ruby 1.8.5 (2006-08-25) [i386-mswin32] rspec 1.0 >From the windows command-line I run spec my_specifications.rb -f s -c Compose SQL - should clen \n nd whitespce Note that all 'a'-characters are missing. If i run _without_ -c, its all good. spec my_specifications.rb -f s Compose SQL - should clean \n and whitespace The colours are really helpful, but so are 'a's. ---------------------------------------------------------------------- Comment By: Michael Klishin (michaelklishin) Date: 2007-07-15 20:53 Message: This ticket looks stale. Should we close it? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-05-24 10:54 Message: I m not running on windows, so I'll let slk tke look t it, but I bsolutely love this bug! ---------------------------------------------------------------------- Comment By: Jon Egil Strand (jonegil) Date: 2007-05-23 18:52 Message: A short version of the spec-file is attached. Note that the 'a' is missing in all specs, both failing and successful. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-05-23 13:48 Message: I'm unable to reproduce this. I am on: ruby 1.8.6 (2007-03-13 patchlevel 0) [i386-mswin32] rspec 1.0.0 win32console (1.0.8) Could you please attach your spec? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=11067&group_id=797 From noreply at rubyforge.org Sun Jul 15 19:45:52 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 15 Jul 2007 19:45:52 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-11231 ] fixtures don't load with before(:all) Message-ID: <20070715234552.E3E285240B93@rubyforge.org> Bugs item #11231, was opened at 2007-05-30 14:52 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=11231&group_id=797 Category: None Group: None >Status: Closed >Resolution: Rejected Priority: 3 Submitted By: Jeremy Stephens (viking415) >Assigned to: David Chelimsky (dchelimsky) Summary: fixtures don't load with before(:all) Initial Comment: Fixtures only load when using before(:each). If I use before(:all), they don't get loaded at all. To reproduce this, run these commands in a shell: rails -d sqlite3 jungle cd jungle ruby script/plugin install svn://rubyforge.org/var/svn/rspec/tags/CURRENT/rspec ruby script/plugin install svn://rubyforge.org/var/svn/rspec/tags/CURRENT/rspec_on_rails script/generate rspec script/generate rspec_model monkey name:string rake db:migrate Then edit spec/models/monkey_spec.rb to include the following: ############# require File.dirname(__FILE__) + '/../spec_helper' describe "monkey with a before(:each)" do fixtures :monkeys before(:each) do @monkey = Monkey.find_by_id(1) end it "should not be nil" do @monkey.should_not be_nil end end describe "monkey with a before(:all)" do fixtures :monkeys before(:all) do @monkey = Monkey.find_by_id(1) end it "should not be nil" do @monkey.should_not be_nil end end ############# Run rake spec:models, and watch the first pass and the second fail. I'm running Kubuntu (Feisty) with Rails 1.2.3 and RSpec SVN r2060 (1.0.4). ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-07-15 23:45 Message: Yes. Closing this now. FYI - We can't create an error message very easily if trying to access fixtures in before(:all) because it has no way of knowing what that a missing method is trying to access fixtures. ---------------------------------------------------------------------- Comment By: Michael Klishin (michaelklishin) Date: 2007-07-15 20:53 Message: This ticket looks stale. Should we close it? ---------------------------------------------------------------------- Comment By: Jeremy Stephens (viking415) Date: 2007-05-30 18:19 Message: My original reason for wanting to use fixtures in before(:all) was to test a userstamp plugin for Rails/ActiveRecord which automatically sets a 'created_by' or 'updated_by' field when a record is saved. In my tests, I wanted to login an existing user before each example, and it seemed wasteful to me at the time for that login to happen every time. It really isn't a big deal to use before(:each) instead; I guess it just struck me as odd that fixtures weren't available for before(:all). After reading your argument, though, I see your point. I think if you choose to outlaw using fixtures during a before(:all), an error message would definitely be helpful. Thanks! ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-05-30 16:51 Message: This was brought up a while back (using the old syntax): http://rubyforge.org/tracker/index.php?func=detail&aid=8145&group_id=797&atid=3149 The basic problem is that fixtures get rolled back between each example if you're using transactional fixtures (which seems to be the way to go). So if we support fixtures in before(:all) and you create @monkey, when the fixtures roll back the @monkey will remain the same - keeping its state through each example. This goes against conventional wisdom, which suggests that state should not be shared between examples. So my instinct is to implement fixtures in before(:all) such that it raises an error saying you can't do it and should use before(:each). But I'm open to other thoughts on the matter, so please feel free to make a case. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=11231&group_id=797 From noreply at rubyforge.org Sun Jul 15 19:48:56 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 15 Jul 2007 19:48:56 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-11067 ] spec runner with -c removes all 'a'-characters for output Message-ID: <20070715234856.DF6875240B93@rubyforge.org> Bugs item #11067, was opened at 2007-05-23 12:54 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=11067&group_id=797 Category: None Group: None >Status: Closed >Resolution: Rejected Priority: 3 Submitted By: Jon Egil Strand (jonegil) >Assigned to: David Chelimsky (dchelimsky) Summary: spec runner with -c removes all 'a'-characters for output Initial Comment: ruby 1.8.5 (2006-08-25) [i386-mswin32] rspec 1.0 >From the windows command-line I run spec my_specifications.rb -f s -c Compose SQL - should clen \n nd whitespce Note that all 'a'-characters are missing. If i run _without_ -c, its all good. spec my_specifications.rb -f s Compose SQL - should clean \n and whitespace The colours are really helpful, but so are 'a's. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-07-15 23:48 Message: Sure. Closing this now. Jon - if you're still experiencing this, please re-open. Thanks, David ---------------------------------------------------------------------- Comment By: Michael Klishin (michaelklishin) Date: 2007-07-15 20:53 Message: This ticket looks stale. Should we close it? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-05-24 10:54 Message: I m not running on windows, so I'll let slk tke look t it, but I bsolutely love this bug! ---------------------------------------------------------------------- Comment By: Jon Egil Strand (jonegil) Date: 2007-05-23 18:52 Message: A short version of the spec-file is attached. Note that the 'a' is missing in all specs, both failing and successful. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-05-23 13:48 Message: I'm unable to reproduce this. I am on: ruby 1.8.6 (2007-03-13 patchlevel 0) [i386-mswin32] rspec 1.0.0 win32console (1.0.8) Could you please attach your spec? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=11067&group_id=797 From noreply at rubyforge.org Sun Jul 15 22:03:45 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 15 Jul 2007 22:03:45 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-12132 ] succeed matcher Message-ID: <20070716020345.147965240BD4@rubyforge.org> Feature Requests item #12132, was opened at 2007-07-09 15:10 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=12132&group_id=797 Category: expectation module Group: None >Status: Closed Priority: 3 Submitted By: Brian Takita (btakita) Assigned to: Nobody (None) Summary: succeed matcher Initial Comment: Sometime I want to have a method that has a compound matcher. The succeed matcher executes the block and returns true if there is no exception. e.g. "Foobar".should succeed do |obj| obj.to_s.should == "Foobar" end # success "Foobar".should succeed do |obj| obj.to_s.should == "Baz" end # Failure ---------------------------------------------------------------------- >Comment By: Brian Takita (btakita) Date: 2007-07-15 19:03 Message: I don't think I tried that. That is the best case scenario too. I'll give it a shot and create a bug if that doesn't work. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-07-14 20:10 Message: Michael - the problem w/ using should_not raise_error is that the errors themselves would not propagate up - only should_not raise_error would fail - that would be confusing. However, Brian - consider this: def save_related_projects user.projects.each do |project| project.should be_saved_by_user end end Why do we need to wrap the method body in anything here? Wouldn't that get you what you need? That should give you the functionality you're looking for ---------------------------------------------------------------------- Comment By: Michael Klishin (michaelklishin) Date: 2007-07-14 16:14 Message: Brian, I may not get something here but how about lambda ... should_not raise_error? David Ch., I think pass or just expect(-ed) are okay. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-07-14 14:20 Message: I can see the usefulness, but "succeed" doesn't speak to me. In fact, it seems to me that "satisfy" is a better word for what you're describing, but we're already using that :( Here's a few other ideas. They probably mostly suck: support pass fulfill meet comply Any other ideas for the right word here? ---------------------------------------------------------------------- Comment By: Brian Takita (btakita) Date: 2007-07-14 13:28 Message: Also with satisfy, if there is an ExpectationNotMetError, the stack trace does not go into the block. The stack trace ends where .should is called. As a user, I would want to see which line triggers the ExpectationNotMetError occurs. ---------------------------------------------------------------------- Comment By: Brian Takita (btakita) Date: 2007-07-14 13:18 Message: Aslak, it equivalent to Test::Unit users making assertion methods. It allows a "test dsl" to be set up. Here is a less arbitrary example. Having matcher methods in the Behaviour makes the intention of the Example clearer. describe User, "#save" do it "works in state 1" do ... @user.should save_related_projects end it "works in state 2" do ... @user.should save_related_projects end it "works in state 3" do ... @user.should save_related_projects end def save_related_projects user.should succeed do |user| user.projects.each do |project| project.should be_saved_by_user end end end end ---------------------------------------------------------------------- Comment By: Brian Takita (btakita) Date: 2007-07-14 13:11 Message: David, satisfy depends on the return value of the block. It has to be true. The intention of succeed is that there is no exception in the block. I suppose that unless the last line of the block is false or nil, it will work, but that seems kind of side-effecty. I'm worried that would lead to unexpected failures. Of course, succeed is very similar to satisfy so it may not justify adding another matcher. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-07-09 15:29 Message: What kind of method are you talking about? Why does it matter what the succeed matcher _returns_? Can you provide a more illustrative/complete example? I can rewrite your code as (I must be missing something): "Foobar".to_s.should == "Foobar" "Foobar".to_s.should == "Baz" ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-07-09 15:26 Message: Have you tried should satisfy? It's basically what you're asking for: http://rspec.rubyforge.org/rdoc/classes/Spec/Matchers.html#M000248 ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=12132&group_id=797 From noreply at rubyforge.org Mon Jul 16 07:06:21 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 16 Jul 2007 07:06:21 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-11254 ] RSpec syntax coloring and function pop-up integration in TextMate Message-ID: <20070716110622.1CF855240A46@rubyforge.org> Patches item #11254, was opened at 2007-05-31 14:43 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=11254&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Wincent Colaiuta (wincent) Assigned to: Aslak Helles?y (aslak_hellesoy) Summary: RSpec syntax coloring and function pop-up integration in TextMate Initial Comment: This patch makes two additions to the RSpec TextMate bundle to provide a better user experience: syntax coloring of RSpec keywords (before, after, describe, it), and display of behaviours and examples in the function pop-up menu. This latter feature is very useful for navigation when working with files with large numbers of specs. Examples appear indented. Now, this is my first ever TextMate customization so I am sure someone more experienced could improve on the implementation, but in its basic form it works. Shortcomings of the current implementation: - recognition occurs at the whole-line level, so syntax colouring only kicks in once you have typed the entire line - recognition simplisticly divides the behaviour and example descriptions into three parts, the "describe" (or "it"), the "do", and "everything else" between the two - this in turn means that there is no special syntax colouring of the "everything else" - it also means that examples such as: it "should be valid" do ... end will appear in the function pop-up with the enclosing quotes: "should be valid" - likewise, a behaviour like: describe User, "at creation time" do ... end Will appear in the function pop-up as: User, "at creation time" - and shared behaviours will appear as: "All controllers", :shared => true Hopefully someone with more knowledge about TextMate customization than I can address these issues, but as it stands I think the basic implementation is useful enough that life is better with the aid of these imperfect changes. Will also try to attach a screenshot with the patch to show what the pop-up looks like. ---------------------------------------------------------------------- >Comment By: Wincent Colaiuta (wincent) Date: 2007-07-16 11:06 Message: Tried to include this comment when I attached the patch, but RubyForge logged me out (accepting the upload but rejecting the comment! darn transparent proxy...); so here it is again: Ok, Allan responded to the ticket. I'm going to attach an updated patch which uses "spec.rb" as the file extension instead of "_spec.rb". Also, Allan notes that if you have previously (implicitly) told TextMate to open ".rb" files as Ruby, you'll need to undo that in one of these ways: 1. Open a test.rb file and then switch away from Ruby and back again ? then TM notices that you?re selecting the default language, and will remove the explicit binding for ?.rb? files (ensure though that only the Ruby bundle has ?rb? declared as an extension). 2. defaults delete com.macromates.textmate OakLanguageFileBindings ? this deletes all stored bindings. ---------------------------------------------------------------------- Comment By: Wincent Colaiuta (wincent) Date: 2007-07-08 10:48 Message: Posted a follow-up TextMate ticket here: http://macromates.com/ticket/show?ticket_id=0F597093 ---------------------------------------------------------------------- Comment By: Wincent Colaiuta (wincent) Date: 2007-07-08 10:27 Message: Just attached an updated patch with "_spec.rb" denoted as file extension. ---------------------------------------------------------------------- Comment By: Wincent Colaiuta (wincent) Date: 2007-07-08 10:14 Message: Awesome, looks like the requested change is already implemented in the new r1405: [NEW] Add ?_? to the set of anchor characters for file types (extensions) -- ticket 48BF377 ---------------------------------------------------------------------- Comment By: Wincent Colaiuta (wincent) Date: 2007-07-07 18:51 Message: Ok, submitted a TextMate feature request here: http://macromates.com/ticket/show?ticket_id=48BF3775 ---------------------------------------------------------------------- Comment By: Wincent Colaiuta (wincent) Date: 2007-07-07 18:46 Message: Very interesting... Noticed in the changelog for the just released TextMate r1401 the following: [CHANGED] File types (extensions) specified in language grammars are now matched against the full path so e.g. ?.git/config? and ?.ssh/config? are both valid extensions -- the match is required to be anchored either at an ?/? or ?.? so e.g. ?tml? will not match ?index.html?. On a tie, the longest suffix-match is chosen. So, not quite what would be necessary to distinguish between ".rb" and "_spec.rb", but a step closer. Think I might file a TextMate feature request to accept "_" as an anchor as well; that would allow spec files to be auto-detected and auto-syntax highlighted. ---------------------------------------------------------------------- Comment By: Wincent Colaiuta (wincent) Date: 2007-06-25 09:21 Message: (1) The patch was made against the trunk back at the end of May (r2060, I think). The changes to the info.plist (shouldn't it be Info.plist, btw?) weren't manually done by me, but were inserted by TextMate when I made the other additions via its Bundle Editor. These settings are pretty opaque to me and omitting them seems to make no difference, so I will attach a patch against the current trunk which does not include the info.plist changes. (2) There aren't any new user-settable "preferences" as such. The two new files in the "Preferences" subdirectory of the bundle are used to add Behaviours and Examples to the TextMate symbols list... this is what allows them to appear in the pop-up. (3) To see the syntax highlighting you must select "RSpec" from the language pop-up at the bottom of the window. This is just like when you have a Rails file and want special Rails-specific highlighting instead of the default Ruby highlighting. It would be nice if TextMate allowed you to specify that all files ending in "_spec.rb" would be auto-detected as RSpec files, but as far as I know, TextMate only allows you to specify the extension part (".rb") and that would override the default Ruby highlighting. So if we want that feature we either need to try again get the RSpec syntax rolled into the Ruby.tmbundle, or try to get Allan to modify Textmate to allow us to specify not just the extension. (4) The pop-up menu is the function pop-up at the bottom of the TextMate window (right hand side). I don't know if there is a keyboard shortcut; I use the mouse for that. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-06-24 13:06 Message: This sounds great, but I'm having some problems. 1) The patch doesn't apply cleanly against trunk r2121 with "patch -p0 < textmate.diff": patching file Preferences/Symbol patching file Preferences/Symbol patching file info.plist Hunk #1 FAILED at 280. 1 out of 1 hunk FAILED -- saving rejects to file info.plist.rej patching file Syntaxes/RSpec.tmLanguage $ cat info.plist.rej *************** *** 280,285 **** 240FDD9D-CD49-4917-9003-80A3E1DADFBA B5906021-8E54-4863-A13B-EA46333DB5F1 67E726E0-63E2-4840-B8BB-37F665CD34B8 uuid 4CEA47CC-2C3A-45FB-80BE-3820828227C2 --- 280,288 ---- 240FDD9D-CD49-4917-9003-80A3E1DADFBA B5906021-8E54-4863-A13B-EA46333DB5F1 67E726E0-63E2-4840-B8BB-37F665CD34B8 + 923F0A10-96B9-4792-99A4-94FEF66E0B8C + 57EF6130-05A6-4117-94CB-C0BD63328334 + 28F89786-04F4-43D7-82A6-34B046C2BC6B uuid 4CEA47CC-2C3A-45FB-80BE-3820828227C2 2) I tried to add the three rejected lines manually, and in the bundle editor I can see the new RSpec syntax, but I don't see the new preferences. Shouldn't they show up too? 3) There is no new syntax highlighting on my Textmate. How does TextMate know to use this highlighting? Do I need to do anything special to make it work? 4) How do I bring up the list over behaviours and examples shown in your screenshot? It must be some keyboard shortcut I'm unaware of. Cheers, Aslak ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=11254&group_id=797 From bob.cotton at rallydev.com Tue Jul 17 21:41:50 2007 From: bob.cotton at rallydev.com (Bob Cotton) Date: Tue, 17 Jul 2007 19:41:50 -0600 Subject: [rspec-devel] Reporter Thread Safety Message-ID: I'm implementing a custom formatter that needs to track the relationship between Examples and their Behaviors. One way to do this is to keep an instance variable on the Reporter for the last Behaviour that was passed to #add_behaviour. Then I can make the association in #example_started. When working with multiple threads, I would need to change that instance variable to a thread local to ensure that the behaviour is the "last" behavior seen. Seems icky. Example#run does not, that I can tell, have access to its Behaviour so it could be passed to the reporter. Thoughts on how to fix this? Pass the Behaviour to the Example, then into the reporter? I can provide a patch. - Bob From noreply at rubyforge.org Wed Jul 18 18:49:01 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 18 Jul 2007 18:49:01 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-6791 ] stub return values for all instances of a class Message-ID: <20070718224901.CD1215240EFC@rubyforge.org> Feature Requests item #6791, was opened at 2006-11-20 16:50 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6791&group_id=797 Category: mock module Group: None Status: Open Priority: 3 Submitted By: David Chelimsky (dchelimsky) Assigned to: Nobody (None) Summary: stub return values for all instances of a class Initial Comment: I'd like to be able to do this: SomeClass.stub_instance_method!(:method_name).and_return(specified_value) (syntax just a suggestion) This should set up a world in which all instances of SomeClass return specified_value for any calls to :method_name. This differs from SomeClass.stub! in that it applies to instance methods rather than class methods. ---------------------------------------------------------------------- Comment By: Carl Porth (badcarl) Date: 2007-07-18 22:49 Message: I'd also like to be able to do this: SomeClass.new_instances do |instance| instance.stub!(:method_name_1).and_return(:value_1) instance.stub!(:method_name_2).and_return(:value_2) end ---------------------------------------------------------------------- Comment By: Chris Anderson (jchris) Date: 2007-01-18 01:29 Message: Found a solution to my specific problem: def login_stub(user) controller.stub!(:current_user).and_return(user) end Just in case someone happens by from a google search etc. ---------------------------------------------------------------------- Comment By: Chris Anderson (jchris) Date: 2007-01-17 23:24 Message: I agree. I'm trying to stub a login_as method for controller specs that won't rely on the database. I'd like to have any instance of ApplicationController stub :current_user and return my mock user. But this doesn't seem possible with the current library. Mocha has the feature, so I may lean on it for the time being. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6791&group_id=797 From dchelimsky at gmail.com Wed Jul 18 23:35:45 2007 From: dchelimsky at gmail.com (David Chelimsky) Date: Wed, 18 Jul 2007 23:35:45 -0400 Subject: [rspec-devel] need help getting a word right Message-ID: <57c63afe0707182035t6b4e49f8u83b99e8da0b5e479@mail.gmail.com> Hey all, I see examples showing up that look like this: describe Thing do before(:each) do @thing = Thing.new end it do @thing.should be_something end end This will produce output like this: Thing - should be something But "it do" is driving me mad :( We need a better word. Of course, 'specify' has not been completely removed, so you can still do this: describe Thing do before(:each) { @thing = Thing.new } specify { @thing.should be_something } end Consise? Yes. But I'm not psyched about 'specify' either. There IS a perfect word for this situation. What is it? Suggestions? Thanks, David From bob.cotton at rallydev.com Thu Jul 19 00:08:29 2007 From: bob.cotton at rallydev.com (Bob Cotton) Date: Wed, 18 Jul 2007 22:08:29 -0600 Subject: [rspec-devel] Using Behaviours inside Examples Message-ID: I'm specing this custom formatter that relies on the entire life-cycle of the formatter class, and will perform the interesting work during dump_summary. In my spec I didn't want to replicate all the calls that the formatter receives, but instead cook up a Behaviour, then run that with my formatter. My question is: should I be able to do this? The following spec says not, but i'm not sure why. class CustomFormatter < Spec::Runner::Formatter::BaseFormatter attr_reader :last_method def add_behaviour(name) @last_method = "add_behaviour" end def dump_summary(duration, example_count, failure_count, pending_count) @last_method = "dump_summary" end end describe "Mixed Behaviours" do before(:each) do @formatter = CustomFormatter.new(nil) @reporter = Spec::Runner::Reporter.new([@formatter], mock("backtrace_tweaker", :null_object => true)) end it "should allow use of Behaviours in examples" do behaviour = Spec::DSL::Behaviour.new("My Behaviour") {} behaviour.it("should") {true.should == true} behaviour.run(@reporter) @formatter.last_method.should == "dump_summary" end end > spec reporter_spec.rb F 1) 'Mixed Behaviours should allow use of Behaviours in examples' FAILED expected: "dump_summary", got: "add_behaviour" (using ==) ./reporter_spec.rb:25: Finished in 0.134144 seconds 1 example, 1 failure From dchelimsky at gmail.com Thu Jul 19 00:29:05 2007 From: dchelimsky at gmail.com (David Chelimsky) Date: Thu, 19 Jul 2007 00:29:05 -0400 Subject: [rspec-devel] Using Behaviours inside Examples In-Reply-To: References: Message-ID: <57c63afe0707182129odf69addvd5958f1f6a1861ff@mail.gmail.com> On 7/19/07, Bob Cotton wrote: > > I'm specing this custom formatter that relies on the entire life-cycle > of the formatter class, and will perform the interesting work during > dump_summary. > > In my spec I didn't want to replicate all the calls that the formatter > receives, but instead cook up a Behaviour, then run that with my > formatter. > > My question is: should I be able to do this? The following spec says > not, but i'm not sure why. > > class CustomFormatter < Spec::Runner::Formatter::BaseFormatter > attr_reader :last_method > def add_behaviour(name) > @last_method = "add_behaviour" > end > > def dump_summary(duration, example_count, failure_count, pending_count) > @last_method = "dump_summary" > end > end > > describe "Mixed Behaviours" do > before(:each) do > @formatter = CustomFormatter.new(nil) > @reporter = Spec::Runner::Reporter.new([@formatter], mock("backtrace_tweaker", :null_object => true)) > end > > it "should allow use of Behaviours in examples" do > behaviour = Spec::DSL::Behaviour.new("My Behaviour") {} > behaviour.it("should") {true.should == true} > > behaviour.run(@reporter) > @formatter.last_method.should == "dump_summary" > end > end > > > spec reporter_spec.rb > F > > 1) > 'Mixed Behaviours should allow use of Behaviours in examples' FAILED > expected: "dump_summary", > got: "add_behaviour" (using ==) > ./reporter_spec.rb:25: dump_summary is never getting called when you run a single behaviour (i.e. tell that behaviour to run). dump_summary is called from the BehaviourRunner. What you can do is call @reporter.dump and that would do it. > > Finished in 0.134144 seconds > > 1 example, 1 failure > > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From barjunk at attglobal.net Thu Jul 19 01:08:21 2007 From: barjunk at attglobal.net (barsalou) Date: Wed, 18 Jul 2007 21:08:21 -0800 Subject: [rspec-devel] [rspec-users] need help getting a word right In-Reply-To: <57c63afe0707182035t6b4e49f8u83b99e8da0b5e479@mail.gmail.com> References: <57c63afe0707182035t6b4e49f8u83b99e8da0b5e479@mail.gmail.com> Message-ID: <20070718210821.l1a8no138oo0swc0@lcgalaska.com> Well in that specific case, please seems like a good choice please do @thing.should be_somthing end But If you had text in between then it wouldn't seem the same: please "whatever text" do @thing.should be_something end Quoting David Chelimsky : > Hey all, > > I see examples showing up that look like this: > > describe Thing do > before(:each) do > @thing = Thing.new > end > > it do > @thing.should be_something > end > end > > This will produce output like this: > > Thing > - should be something > > But "it do" is driving me mad :( > > We need a better word. Of course, 'specify' has not been completely > removed, so you can still do this: > > describe Thing do > before(:each) { @thing = Thing.new } > specify { @thing.should be_something } > end > > Consise? Yes. But I'm not psyched about 'specify' either. There IS a > perfect word for this situation. What is it? Suggestions? > > Thanks, > David > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users > ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. From noreply at rubyforge.org Thu Jul 19 03:03:19 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 19 Jul 2007 03:03:19 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-12404 ] Edge Rails breaks RSpec with newer link_to syntax Message-ID: <20070719070319.20BE45240A8C@rubyforge.org> Bugs item #12404, was opened at 2007-07-19 17:03 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=12404&group_id=797 Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: Marcus Crafter (crafterm) Assigned to: Nobody (None) Summary: Edge Rails breaks RSpec with newer link_to syntax Initial Comment: Hi All, Hope all is going well. In Edge Rails you can specify link to using: link_to('path, @model) as opposed to: link_to('path', model_path(@model)) in 1.2 and earlier. The newer syntax breaks rspec though if you have any helpers or view specs that test code that uses it with mock models. The error it prints is: undefined method `polymorphic_path' for [Dynamically generated class for RSpec example]:# Example to reproduce: describe ApplicationHelper do it "should demo edge link_to problem" do mock = mock_model(User, :name => test) link_to(mock.name, mock).should == 'test' end end I've been able to fix this with the following monkey patch: module Spec module Rails module DSL class EvalContext < Spec::Rails::TestCase def polymorphic_path(uri) "/#{uri.class.to_s.underscore.pluralize}/#{uri.id}" end end end end end However there may be a more appropriate solution? Would be great to get this fixed, please let me know if there's anything else I can do. Cheers, Marcus ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=12404&group_id=797 From undees at gmail.com Thu Jul 19 03:55:24 2007 From: undees at gmail.com (Ian Dees) Date: Thu, 19 Jul 2007 00:55:24 -0700 Subject: [rspec-devel] need help getting a word right Message-ID: Hi, all. Quoth Dave: > it do > @thing.should be_something > end > end ... > But "it do" is driving me mad :( You and me both: http://rubyforge.org/pipermail/rspec-devel/2007-April/002415.html > We need a better word. Of course, 'specify' has not been completely > removed, so you can still do this: I know you're not totally sold on using "specify" here, but I think it looks okay. If you really want to move away from "specify," then would there be a way to keep "it" but add a do-nothing "return self" method to the example object? Something like "must?" it.must do @thing.should be_something end --Ian From dchelimsky at gmail.com Thu Jul 19 08:55:57 2007 From: dchelimsky at gmail.com (David Chelimsky) Date: Thu, 19 Jul 2007 08:55:57 -0400 Subject: [rspec-devel] need help getting a word right In-Reply-To: References: Message-ID: <57c63afe0707190555m747ed034g23c813dbfa47f1e5@mail.gmail.com> On 7/19/07, Ian Dees wrote: > Hi, all. > > Quoth Dave: This makes me feel like the subject of poetry, Edgar. > > > it do > > @thing.should be_something > > end > > end > ... > > But "it do" is driving me mad :( > > You and me both: > http://rubyforge.org/pipermail/rspec-devel/2007-April/002415.html _____ minds think alike (fill in the blank - and "great" is not allowed). > > We need a better word. Of course, 'specify' has not been completely > > removed, so you can still do this: > > I know you're not totally sold on using "specify" here, but I think it > looks okay. It does look okay. I just really want a different word. I may not get what I want. > If you really want to move away from "specify," then would there be a > way to keep "it" but add a do-nothing "return self" method to the > example object? Something like "must?" > > it.must do > @thing.should be_something > end If we were to do something like that we would probably use should: it.should do @thing.should be_something end But that doesn't really work for me either. Structurally, I love this: specify {@thing.should be_something} I just really want a different word. We're saying "describe Thing", and this word should indicate that the block represents a subset of that description. One great word would be "facet": describe Thing do ... facet {@thing.should be_something} end I don't want to use that word though because we may be using it for something else. But that's the idea I'm pushing towards. Following through an on-line thesaurus, starting from "facet", here are some interesting options: property {@thing.should be_something} aspect {@thing.should be_something} feature {@thing.should be_something} dimension {@thing.should be_something} characteristic {@thing.should be_something} responsibility {@thing.should be_something} quality {@thing.should be_something} trait {@thing.should be_something} perspective {@thing.should be_something} Here are some amusing options: peculiarity {@thing.should be_something} idiosyncrasy {@thing.should be_something} And, my personal favorite (from the amusement standpoint): virtue {@thing.should be_something} Any of these strike anybody as useful? Of course, those are all nouns. We could use a verb ('specify', for example). Again, using the thesaurus: define {@thing.should be_something} appoint {@thing.should be_something} determine {@thing.should be_something} prescribe {@thing.should be_something} stipulate {@thing.should be_something} allege {@thing.should be_something} assign {@thing.should be_something} refine {@thing.should be_something} itemize {@thing.should be_something} identify {@thing.should be_something} appoint {@thing.should be_something} establish {@thing.should be_something} intend {@thing.should be_something} submit {@thing.should be_something} suggest {@thing.should be_something} establish {@thing.should be_something} impose {@thing.should be_something} instruct {@thing.should be_something} stipulate {@thing.should be_something} say {@thing.should be_something} Admittedly, some of those are just silly. But perhaps something strikes you as useful. Or perhaps these lead to other ideas. Keep 'em coming. Thanks, David > > --Ian > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From deanwampler at gmail.com Thu Jul 19 09:48:52 2007 From: deanwampler at gmail.com (Dean Wampler) Date: Thu, 19 Jul 2007 08:48:52 -0500 Subject: [rspec-devel] need help getting a word right In-Reply-To: <57c63afe0707190555m747ed034g23c813dbfa47f1e5@mail.gmail.com> References: <57c63afe0707190555m747ed034g23c813dbfa47f1e5@mail.gmail.com> Message-ID: <6cf2a94f0707190648t498b7bf2p1d630310d71bab66@mail.gmail.com> "it_should" works, but I see your objection. I'm intrigued by all 4 of these options: feature {@thing.should be_something} characteristic {@thing.should be_something} responsibility {@thing.should be_something} trait {@thing.should be_something} All the words except for "characteristic" have been used in other contexts, e.g., Traits - Composable Units of Behavior ( http://www.iam.unibe.ch/~scg/Research/Traits/#implementations), but they still convey the right idea. Some of these words are a bit long, but code completion and hot keys are your friends... allege {@thing.should be_indicted} could prove useful ;) dean On 7/19/07, David Chelimsky wrote: > > On 7/19/07, Ian Dees wrote: > > Hi, all. > > > > Quoth Dave: > > This makes me feel like the subject of poetry, Edgar. > > > > > > it do > > > @thing.should be_something > > > end > > > end > > ... > > > But "it do" is driving me mad :( > > > > You and me both: > > http://rubyforge.org/pipermail/rspec-devel/2007-April/002415.html > > _____ minds think alike (fill in the blank - and "great" is not allowed). > > > > We need a better word. Of course, 'specify' has not been completely > > > removed, so you can still do this: > > > > I know you're not totally sold on using "specify" here, but I think it > > looks okay. > > It does look okay. I just really want a different word. I may not get > what I want. > > > If you really want to move away from "specify," then would there be a > > way to keep "it" but add a do-nothing "return self" method to the > > example object? Something like "must?" > > > > it.must do > > @thing.should be_something > > end > > If we were to do something like that we would probably use should: > > it.should do > @thing.should be_something > end > > But that doesn't really work for me either. Structurally, I love this: > > specify {@thing.should be_something} > > I just really want a different word. We're saying "describe Thing", > and this word should indicate that the block represents a subset of > that description. One great word would be "facet": > > describe Thing do > ... > facet {@thing.should be_something} > end > > I don't want to use that word though because we may be using it for > something else. But that's the idea I'm pushing towards. Following > through an on-line thesaurus, starting from "facet", here are some > interesting options: > > property {@thing.should be_something} > aspect {@thing.should be_something} > feature {@thing.should be_something} > dimension {@thing.should be_something} > characteristic {@thing.should be_something} > responsibility {@thing.should be_something} > quality {@thing.should be_something} > trait {@thing.should be_something} > perspective {@thing.should be_something} > > Here are some amusing options: > > peculiarity {@thing.should be_something} > idiosyncrasy {@thing.should be_something} > > And, my personal favorite (from the amusement standpoint): > > virtue {@thing.should be_something} > > Any of these strike anybody as useful? > > Of course, those are all nouns. We could use a verb ('specify', for > example). Again, using the thesaurus: > > define {@thing.should be_something} > appoint {@thing.should be_something} > determine {@thing.should be_something} > prescribe {@thing.should be_something} > stipulate {@thing.should be_something} > allege {@thing.should be_something} > assign {@thing.should be_something} > refine {@thing.should be_something} > itemize {@thing.should be_something} > identify {@thing.should be_something} > appoint {@thing.should be_something} > establish {@thing.should be_something} > intend {@thing.should be_something} > submit {@thing.should be_something} > suggest {@thing.should be_something} > establish {@thing.should be_something} > impose {@thing.should be_something} > instruct {@thing.should be_something} > stipulate {@thing.should be_something} > say {@thing.should be_something} > > Admittedly, some of those are just silly. But perhaps something > strikes you as useful. Or perhaps these lead to other ideas. Keep 'em > coming. > > Thanks, > David > > > > > > --Ian > > _______________________________________________ > > 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 > -- Dean Wampler http://www.objectmentor.com http://www.aspectprogramming.com http://www.contract4j.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20070719/2b92801e/attachment.html From noreply at rubyforge.org Thu Jul 19 10:42:57 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 19 Jul 2007 10:42:57 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-12418 ] An option to spec runner to stop after first failure Message-ID: <20070719144257.28A175240B90@rubyforge.org> Feature Requests item #12418, was opened at 2007-07-19 14:42 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=12418&group_id=797 Category: runner / command line Group: None Status: Open Priority: 3 Submitted By: Esad Hajdarevic (esad) Assigned to: Nobody (None) Summary: An option to spec runner to stop after first failure Initial Comment: I have a relatively big number of specs in the current project which take 5-10 minutes to execute. What I'd like to propose is an option to runner that would stop after the first spec has failed, because otherwise even after a small change I need to wait the few minutes to see what went wrong. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=12418&group_id=797 From bob.cotton at rallydev.com Thu Jul 19 11:43:03 2007 From: bob.cotton at rallydev.com (Bob Cotton) Date: Thu, 19 Jul 2007 09:43:03 -0600 Subject: [rspec-devel] Using Behaviours inside Examples In-Reply-To: <57c63afe0707182129odf69addvd5958f1f6a1861ff@mail.gmail.com> (David Chelimsky's message of "Thu, 19 Jul 2007 00:29:05 -0400") References: <57c63afe0707182129odf69addvd5958f1f6a1861ff@mail.gmail.com> Message-ID: "David Chelimsky" writes: > dump_summary is never getting called when you run a single behaviour > (i.e. tell that behaviour to run). dump_summary is called from the > BehaviourRunner. > > What you can do is call @reporter.dump and that would do it. Cool, thanks. One more question, if I'm using mocks in the "outer" Example, will calling Behaviour#run reset them? I'm seeing it in my spec, but have not been able to create an isolated spec. -Bob From dchelimsky at gmail.com Thu Jul 19 12:03:28 2007 From: dchelimsky at gmail.com (David Chelimsky) Date: Thu, 19 Jul 2007 12:03:28 -0400 Subject: [rspec-devel] Using Behaviours inside Examples In-Reply-To: References: <57c63afe0707182129odf69addvd5958f1f6a1861ff@mail.gmail.com> Message-ID: <57c63afe0707190903k3937b2f4h26d39fb02d9caf1a@mail.gmail.com> On 7/19/07, Bob Cotton wrote: > "David Chelimsky" writes: > > > dump_summary is never getting called when you run a single behaviour > > (i.e. tell that behaviour to run). dump_summary is called from the > > BehaviourRunner. > > > > What you can do is call @reporter.dump and that would do it. > > Cool, thanks. > > One more question, if I'm using mocks in the "outer" Example, will > calling Behaviour#run reset them? I don't understand your question. What is the "outer" example? > > I'm seeing it in my spec, but have not been able to create an isolated > spec. > > -Bob > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From undees at gmail.com Thu Jul 19 13:58:39 2007 From: undees at gmail.com (Ian Dees) Date: Thu, 19 Jul 2007 10:58:39 -0700 Subject: [rspec-devel] need help getting a word right Message-ID: > _____ minds think alike (fill in the blank - and "great" is not allowed). If I have to fill in the blank, can I use the word "blank?" > > it.must do > > @thing.should be_something > > end > > If we were to do something like that we would probably use should: I considered that, too, but didn't know how to say it in my original message without sounding like Who's On First ("we could use should, but not like should inside the should block, but should outside a should block"). Would the "double should" sound okay? it.should {@thing.should be_something} Of the ones I've seen, I've liked these the most: > virtue {@thing.should be_something} > say {@thing.should be_something} > allege {@thing.should be_indicted} "say" is used by Hackety Hack -- don't know whether or not that matters. Will you forgive a brain dump here, so I can get a handle on my thoughts? It seems like the submissions have followed three main patterns: 1) Noun: facet, virtue, and so on. The advantage is that, a noun next to "do" is a common enough idiom in Ruby that these look equally good with braces or with "do." 2) Active verb: say, allege, specify. These look fantastic with braces, but can be a bit jarring if the word "do" follows without an intervening parameter. 3) Pronoun with verb, probably a modal verb: it.should, it.must, it.will, or the lolcat version ("i.can.has_rspec?"). What about 3), with a carefully chosen couple of optional verbs? That way, we can have: it {@thing.should be_something} or: it.does {@thing.should be_something} or: it.will do @thing.should be_something end I lean toward having _all_ the examples start with "it" as the unifying factor, but injecting a verb would allow us to avoid the "it do" jawbreaker. But I could also enjoy using "example:" describe 'A thing' do example {@thing.should be_something} end --Ian From bob.cotton at rallydev.com Thu Jul 19 14:45:03 2007 From: bob.cotton at rallydev.com (Bob Cotton) Date: Thu, 19 Jul 2007 12:45:03 -0600 Subject: [rspec-devel] Using Behaviours inside Examples In-Reply-To: <57c63afe0707190903k3937b2f4h26d39fb02d9caf1a@mail.gmail.com> (David Chelimsky's message of "Thu, 19 Jul 2007 12:03:28 -0400") References: <57c63afe0707182129odf69addvd5958f1f6a1861ff@mail.gmail.com> <57c63afe0707190903k3937b2f4h26d39fb02d9caf1a@mail.gmail.com> Message-ID: "David Chelimsky" writes: > On 7/19/07, Bob Cotton wrote: >> "David Chelimsky" writes: >> >> > dump_summary is never getting called when you run a single behaviour >> > (i.e. tell that behaviour to run). dump_summary is called from the >> > BehaviourRunner. >> > >> > What you can do is call @reporter.dump and that would do it. >> >> Cool, thanks. >> >> One more question, if I'm using mocks in the "outer" Example, will >> calling Behaviour#run reset them? > > I don't understand your question. What is the "outer" example? Sorry about being so cryptic. >> I'm seeing it in my spec, but have not been able to create an isolated >> spec. I was able to isolate it. It seems that Reporter#dump is clearing the mock. class CustomFormatter < Spec::Runner::Formatter::BaseFormatter def initialize(where, m) # <- the mock is new from the last example super(where) @mock = m end attr_reader :last_method def add_behaviour(name) @last_method = "add_behaviour" end def dump_summary(duration, example_count, failure_count, pending_count) @last_method = "dump_summary" @mock.call_method("hello") end end describe "Mixed Behaviours" do before(:each) do @m = mock("mock") @m.should_receive(:call_method).with("hello") @formatter = CustomFormatter.new(nil, @m) @reporter = Spec::Runner::Reporter.new([@formatter], mock("backtrace_tweaker", :null_object => true)) end it "should allow use of Behaviours in examples" do behaviour = Spec::DSL::Behaviour.new("My Behaviour") do it("should") {true.should == true} end behaviour.run(@reporter) @reporter.dump @formatter.last_method.should == "dump_summary" end end > spec reporter_spec.rb F 1) Spec::Mocks::MockExpectationError in 'Mixed Behaviours should allow use of Behaviours in examples' Mock 'mock' received unexpected message :call_method with ("hello") ./reporter_spec.rb:15:in `dump_summary' ./reporter_spec.rb:34: Finished in 0.056315 seconds 1 example, 1 failure From dan at tastapod.com Thu Jul 19 16:03:57 2007 From: dan at tastapod.com (Dan North) Date: Thu, 19 Jul 2007 21:03:57 +0100 Subject: [rspec-devel] need help getting a word right In-Reply-To: <57c63afe0707182035t6b4e49f8u83b99e8da0b5e479@mail.gmail.com> References: <57c63afe0707182035t6b4e49f8u83b99e8da0b5e479@mail.gmail.com> Message-ID: <469FC3AD.8000100@tastapod.com> How about "should" and "example", depending on whether you like braces or not: describe Sheep do before :each do @sheep = Sheep.new end example { @sheep.should say('baa') } should do @sheep.should say('baa') end end Thinking about the use case for this, the no-description examples will most likely be one-liners. Anything more and you would use a description to say what the intent of the example is, so using example {...} seems most congruent to me. Having said that, I find I always provide a description even if the example is trivial - like having a method name for a one-line method - so I'm out on a limb here :) Cheers, Dan David Chelimsky wrote: > Hey all, > > I see examples showing up that look like this: > > describe Thing do > before(:each) do > @thing = Thing.new > end > > it do > @thing.should be_something > end > end > > This will produce output like this: > > Thing > - should be something > > But "it do" is driving me mad :( > > We need a better word. Of course, 'specify' has not been completely > removed, so you can still do this: > > describe Thing do > before(:each) { @thing = Thing.new } > specify { @thing.should be_something } > end > > Consise? Yes. But I'm not psyched about 'specify' either. There IS a > perfect word for this situation. What is it? Suggestions? > > Thanks, > David > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From noreply at rubyforge.org Thu Jul 19 19:26:31 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 19 Jul 2007 19:26:31 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-12427 ] ViewExampleController does not extend ApplicationController Message-ID: <20070719232631.311A35240AC0@rubyforge.org> Bugs item #12427, was opened at 2007-07-19 16:26 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=12427&group_id=797 Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: Brian Takita (btakita) Assigned to: Nobody (None) Summary: ViewExampleController does not extend ApplicationController Initial Comment: This causes breakages when TheController.helper_method is used. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=12427&group_id=797 From noreply at rubyforge.org Thu Jul 19 23:36:00 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 19 Jul 2007 23:36:00 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-12427 ] ViewExampleController does not extend ApplicationController Message-ID: <20070720033601.04D265240F11@rubyforge.org> Bugs item #12427, was opened at 2007-07-19 23:26 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=12427&group_id=797 Category: rails plugin Group: None >Status: Closed >Resolution: Rejected Priority: 3 Submitted By: Brian Takita (btakita) >Assigned to: David Chelimsky (dchelimsky) Summary: ViewExampleController does not extend ApplicationController Initial Comment: This causes breakages when TheController.helper_method is used. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-07-20 03:36 Message: As designed: I very deliberately chose not to derive from ApplicationController because I didn't want any coupling between the views and any other application code, including helper methods that might break. If you want SomeController.helper_method in view examples, you have to mock or stub it. If you want to couple the views to the controllers (so you don't have to mock these methods), you can do that by writing controller examples with integrated views. If you have another suggestion as to how to approach this, feel free, but I'm closing this now as "as designed." ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=12427&group_id=797 From noreply at rubyforge.org Fri Jul 20 09:51:55 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 20 Jul 2007 09:51:55 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-12448 ] The spec:plugins rake task from rspec_on_rails should ignore specs from the rspec_on_rails plugin Message-ID: <20070720135155.9A1AE5240FB4@rubyforge.org> Bugs item #12448, was opened at 2007-07-20 13:51 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=12448&group_id=797 Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: James Adam (lazyatom) Assigned to: Nobody (None) Summary: The spec:plugins rake task from rspec_on_rails should ignore specs from the rspec_on_rails plugin Initial Comment: It's a simple fix - change: t.spec_files = FileList['vendor/plugins/**/spec/**/*_spec.rb'].exclude('vendor/plugins/rspec/*') to t.spec_files = FileList['vendor/plugins/**/spec/**/*_spec.rb'].exclude('vendor/plugins/rspec/*').exclude('vendor/plugins/rspec_on_rails/*') in rspec_on_rails/tasks/rspec.rake ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=12448&group_id=797 From noreply at rubyforge.org Fri Jul 20 09:57:40 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 20 Jul 2007 09:57:40 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-12448 ] The spec:plugins rake task from rspec_on_rails should ignore specs from the rspec_on_rails plugin Message-ID: <20070720135740.C8F725240FC3@rubyforge.org> Bugs item #12448, was opened at 2007-07-20 13:51 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=12448&group_id=797 Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: James Adam (lazyatom) Assigned to: Nobody (None) Summary: The spec:plugins rake task from rspec_on_rails should ignore specs from the rspec_on_rails plugin Initial Comment: It's a simple fix - change: t.spec_files = FileList['vendor/plugins/**/spec/**/*_spec.rb'].exclude('vendor/plugins/rspec/*') to t.spec_files = FileList['vendor/plugins/**/spec/**/*_spec.rb'].exclude('vendor/plugins/rspec/*').exclude('vendor/plugins/rspec_on_rails/*') in rspec_on_rails/tasks/rspec.rake ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-07-20 13:57 Message: Not quite so simple. We need to make sure they run when we're making changes to the plugin. So we need a strategy for ensuring that it runs when we want it to, and not when we don't. Not a big problem to solve. It's just been very low on our list of priorities. If you have an idea of how to solve it and wish to submit a patch, we would welcome it. Otherwise this one might be a while off. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=12448&group_id=797 From noreply at rubyforge.org Fri Jul 20 10:05:29 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 20 Jul 2007 10:05:29 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-12448 ] The spec:plugins rake task from rspec_on_rails should ignore specs from the rspec_on_rails plugin Message-ID: <20070720140529.D6B835240FA9@rubyforge.org> Bugs item #12448, was opened at 2007-07-20 13:51 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=12448&group_id=797 Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: James Adam (lazyatom) Assigned to: Nobody (None) Summary: The spec:plugins rake task from rspec_on_rails should ignore specs from the rspec_on_rails plugin Initial Comment: It's a simple fix - change: t.spec_files = FileList['vendor/plugins/**/spec/**/*_spec.rb'].exclude('vendor/plugins/rspec/*') to t.spec_files = FileList['vendor/plugins/**/spec/**/*_spec.rb'].exclude('vendor/plugins/rspec/*').exclude('vendor/plugins/rspec_on_rails/*') in rspec_on_rails/tasks/rspec.rake ---------------------------------------------------------------------- >Comment By: James Adam (lazyatom) Date: 2007-07-20 14:05 Message: How about this: desc "Run the specs under vendor/plugins (except RSpec's own)" Spec::Rake::SpecTask.new(:plugins => spec_prereq) do |t| t.spec_opts = ['--options', "\#{RAILS_ROOT}/spec/spec.opts\"] t.spec_files = FileList['vendor/plugins/**/spec/**/*_spec.rb'].exclude('vendor/plugins/rspec/*').exclude("vendor/plugins/rspec_on_rails/*") end namespace :plugins do desc "Run the specs under vendor/plugins (including RSpec's own)" Spec::Rake::SpecTask.new(:all => spec_prereq) do |t| t.spec_opts = ['--options', "\#{RAILS_ROOT}/spec/spec.opts\"] t.spec_files = FileList['vendor/plugins/**/spec/**/*_spec.rb'] end end I'm not sure of your exact workflow when developing and testing these plugins, but those are the two edge cases covered - rake spec:plugins -- when you are developing using rspec; rake spec:plugins:all -- when you are developing rspec itself. Another approach would be to add a flag, but this seemed simpler in the short term. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-07-20 13:57 Message: Not quite so simple. We need to make sure they run when we're making changes to the plugin. So we need a strategy for ensuring that it runs when we want it to, and not when we don't. Not a big problem to solve. It's just been very low on our list of priorities. If you have an idea of how to solve it and wish to submit a patch, we would welcome it. Otherwise this one might be a while off. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=12448&group_id=797 From noreply at rubyforge.org Sun Jul 22 10:26:22 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 22 Jul 2007 10:26:22 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-12484 ] Allow a Behaviour's Description to flow through to the Formatter Message-ID: <20070722142622.83A025240AB4@rubyforge.org> Patches item #12484, was opened at 2007-07-22 08:26 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=12484&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Bob Cotton (bcotton) Assigned to: Nobody (None) Summary: Allow a Behaviour's Description to flow through to the Formatter Initial Comment: With the ability to pass options to Behaviours, having those options available to custom Formatters allows for interesting integrations, for example, with test tracking systems. Attached is a patch that passes the Behaviour's Description to the reporter, which will flow it to all the Formatters. No Formatter specs failed, but I tried to ensure that all calls (in specs) to Formatter#add_behavior and Reporter#add_behaviour are passed an instance of Description. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=12484&group_id=797 From evgeny.zislis at gmail.com Sun Jul 22 13:34:31 2007 From: evgeny.zislis at gmail.com (Evgeny) Date: Sun, 22 Jul 2007 20:34:31 +0300 Subject: [rspec-devel] Regarding DSL::Configure Message-ID: Greetings rSpec developers! According to rSpec documentation, in Spec::Runner.configuration I am able to include various helpers to my behaviors. Like so: config.include ActionView::Helpers, :behaviour_type => :helpers So I wanted to do something like : config.with_options :behaviour_type => :helpers do |config| config.include Haml::Helpers config.include ActionView::Helpers config.prepend_before :all do @haml_is_haml = true @haml_stack = [Haml::Buffer.new] end end Which is supported in Rails (Object#with_options), since this seems to be quite DRY and logical. But it didn't work, because config.include doesn't accept hashes (thats the error anyway). Using rSpec 1.05. Anyone else thinks this is a good idea, and should work? Anyone knows whats the problem and why its broken? From dchelimsky at gmail.com Sun Jul 22 15:09:34 2007 From: dchelimsky at gmail.com (David Chelimsky) Date: Sun, 22 Jul 2007 14:09:34 -0500 Subject: [rspec-devel] Regarding DSL::Configure In-Reply-To: References: Message-ID: <57c63afe0707221209t25198476ga42633ec509c0b9a@mail.gmail.com> On 7/22/07, Evgeny wrote: > Greetings rSpec developers! > > According to rSpec documentation, in Spec::Runner.configuration I am > able to include various helpers to my behaviors. Like so: > config.include ActionView::Helpers, :behaviour_type => :helpers > > So I wanted to do something like : > > config.with_options :behaviour_type => :helpers do |config| > config.include Haml::Helpers > config.include ActionView::Helpers > config.prepend_before :all do > @haml_is_haml = true > @haml_stack = [Haml::Buffer.new] > end > end > > Which is supported in Rails (Object#with_options), since this seems to > be quite DRY and logical. But it didn't work, because config.include > doesn't accept hashes (thats the error anyway). > > Using rSpec 1.05. > > Anyone else thinks this is a good idea, and should work? > > Anyone knows whats the problem and why its broken? I *think* that I've fixed this in trunk. Can you grab the latest and see if you still have this problem? (I can't be sure because I can't produce the same error you're reporting - but I did get a different error that led me to some refactoring). Thanks, David > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From noreply at rubyforge.org Sun Jul 22 15:52:36 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 22 Jul 2007 15:52:36 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-12448 ] The spec:plugins rake task from rspec_on_rails should ignore specs from the rspec_on_rails plugin Message-ID: <20070722195236.C19825240AF3@rubyforge.org> Bugs item #12448, was opened at 2007-07-20 13:51 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=12448&group_id=797 Category: rails plugin Group: None >Status: Closed >Resolution: Accepted Priority: 3 Submitted By: James Adam (lazyatom) >Assigned to: David Chelimsky (dchelimsky) Summary: The spec:plugins rake task from rspec_on_rails should ignore specs from the rspec_on_rails plugin Initial Comment: It's a simple fix - change: t.spec_files = FileList['vendor/plugins/**/spec/**/*_spec.rb'].exclude('vendor/plugins/rspec/*') to t.spec_files = FileList['vendor/plugins/**/spec/**/*_spec.rb'].exclude('vendor/plugins/rspec/*').exclude('vendor/plugins/rspec_on_rails/*') in rspec_on_rails/tasks/rspec.rake ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-07-22 19:52 Message: Thanks. For some reason, spec:plugins:all wouldn't work (specifically :all), but spec:plugins:rspec_on_rails did. So the tasks are: # Run the specs under vendor/plugins (except RSpec's own) rake spec:plugins # Runs the examples for rspec_on_railsrake spec:plugins:rspec_on_rails Fixed in r2181. ---------------------------------------------------------------------- Comment By: James Adam (lazyatom) Date: 2007-07-20 14:05 Message: How about this: desc "Run the specs under vendor/plugins (except RSpec's own)" Spec::Rake::SpecTask.new(:plugins => spec_prereq) do |t| t.spec_opts = ['--options', "\#{RAILS_ROOT}/spec/spec.opts\"] t.spec_files = FileList['vendor/plugins/**/spec/**/*_spec.rb'].exclude('vendor/plugins/rspec/*').exclude("vendor/plugins/rspec_on_rails/*") end namespace :plugins do desc "Run the specs under vendor/plugins (including RSpec's own)" Spec::Rake::SpecTask.new(:all => spec_prereq) do |t| t.spec_opts = ['--options', "\#{RAILS_ROOT}/spec/spec.opts\"] t.spec_files = FileList['vendor/plugins/**/spec/**/*_spec.rb'] end end I'm not sure of your exact workflow when developing and testing these plugins, but those are the two edge cases covered - rake spec:plugins -- when you are developing using rspec; rake spec:plugins:all -- when you are developing rspec itself. Another approach would be to add a flag, but this seemed simpler in the short term. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-07-20 13:57 Message: Not quite so simple. We need to make sure they run when we're making changes to the plugin. So we need a strategy for ensuring that it runs when we want it to, and not when we don't. Not a big problem to solve. It's just been very low on our list of priorities. If you have an idea of how to solve it and wish to submit a patch, we would welcome it. Otherwise this one might be a while off. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=12448&group_id=797 From noreply at rubyforge.org Sun Jul 22 16:03:34 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 22 Jul 2007 16:03:34 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-12404 ] Edge Rails breaks RSpec with newer link_to syntax Message-ID: <20070722200334.42DAF5240AE3@rubyforge.org> Bugs item #12404, was opened at 2007-07-19 07:03 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=12404&group_id=797 Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: Marcus Crafter (crafterm) Assigned to: Nobody (None) Summary: Edge Rails breaks RSpec with newer link_to syntax Initial Comment: Hi All, Hope all is going well. In Edge Rails you can specify link to using: link_to('path, @model) as opposed to: link_to('path', model_path(@model)) in 1.2 and earlier. The newer syntax breaks rspec though if you have any helpers or view specs that test code that uses it with mock models. The error it prints is: undefined method `polymorphic_path' for [Dynamically generated class for RSpec example]:# Example to reproduce: describe ApplicationHelper do it "should demo edge link_to problem" do mock = mock_model(User, :name => test) link_to(mock.name, mock).should == 'test' end end I've been able to fix this with the following monkey patch: module Spec module Rails module DSL class EvalContext < Spec::Rails::TestCase def polymorphic_path(uri) "/#{uri.class.to_s.underscore.pluralize}/#{uri.id}" end end end end end However there may be a more appropriate solution? Would be great to get this fixed, please let me know if there's anything else I can do. Cheers, Marcus ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-07-22 20:03 Message: I'm not able to reproduce this error using the example you've provided. Please submit an example that we can get to fail running rspec's own examples. See http://rspec.rubyforge.org/community/contribute.html for more information. Thanks ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=12404&group_id=797 From noreply at rubyforge.org Sun Jul 22 19:53:16 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 22 Jul 2007 19:53:16 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-12404 ] Edge Rails breaks RSpec with newer link_to syntax Message-ID: <20070722235316.D5E10A970003@rubyforge.org> Bugs item #12404, was opened at 2007-07-19 17:03 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=12404&group_id=797 Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: Marcus Crafter (crafterm) Assigned to: Nobody (None) Summary: Edge Rails breaks RSpec with newer link_to syntax Initial Comment: Hi All, Hope all is going well. In Edge Rails you can specify link to using: link_to('path, @model) as opposed to: link_to('path', model_path(@model)) in 1.2 and earlier. The newer syntax breaks rspec though if you have any helpers or view specs that test code that uses it with mock models. The error it prints is: undefined method `polymorphic_path' for [Dynamically generated class for RSpec example]:# Example to reproduce: describe ApplicationHelper do it "should demo edge link_to problem" do mock = mock_model(User, :name => test) link_to(mock.name, mock).should == 'test' end end I've been able to fix this with the following monkey patch: module Spec module Rails module DSL class EvalContext < Spec::Rails::TestCase def polymorphic_path(uri) "/#{uri.class.to_s.underscore.pluralize}/#{uri.id}" end end end end end However there may be a more appropriate solution? Would be great to get this fixed, please let me know if there's anything else I can do. Cheers, Marcus ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-07-23 06:03 Message: I'm not able to reproduce this error using the example you've provided. Please submit an example that we can get to fail running rspec's own examples. See http://rspec.rubyforge.org/community/contribute.html for more information. Thanks ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=12404&group_id=797 From noreply at rubyforge.org Sun Jul 22 19:57:44 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 22 Jul 2007 19:57:44 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-12404 ] Edge Rails breaks RSpec with newer link_to syntax Message-ID: <20070722235744.7FC1EA970003@rubyforge.org> Bugs item #12404, was opened at 2007-07-19 17:03 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=12404&group_id=797 Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: Marcus Crafter (crafterm) Assigned to: Nobody (None) Summary: Edge Rails breaks RSpec with newer link_to syntax Initial Comment: Hi All, Hope all is going well. In Edge Rails you can specify link to using: link_to('path, @model) as opposed to: link_to('path', model_path(@model)) in 1.2 and earlier. The newer syntax breaks rspec though if you have any helpers or view specs that test code that uses it with mock models. The error it prints is: undefined method `polymorphic_path' for [Dynamically generated class for RSpec example]:# Example to reproduce: describe ApplicationHelper do it "should demo edge link_to problem" do mock = mock_model(User, :name => test) link_to(mock.name, mock).should == 'test' end end I've been able to fix this with the following monkey patch: module Spec module Rails module DSL class EvalContext < Spec::Rails::TestCase def polymorphic_path(uri) "/#{uri.class.to_s.underscore.pluralize}/#{uri.id}" end end end end end However there may be a more appropriate solution? Would be great to get this fixed, please let me know if there's anything else I can do. Cheers, Marcus ---------------------------------------------------------------------- >Comment By: Marcus Crafter (crafterm) Date: 2007-07-23 09:57 Message: Hi David, My apologies, I've attached a tar.bz2 archive that includes a working example of the issue. Please extract the polymorphic-path-example.tar.bz2, and run the notes_helper_spec.rb spec, or simply run rake spec after creating the test database, and you'll see the error. I haven't included rails, or rspec with this example, in the vendor directory, I've symlinked rails to the latest trunk (rev 7209), and in the plugins directory rspec/rpec_on_rails (rev 2181). The notes_helper_spec.rb includes the fix I wrote but I'm unsure if this is the correct solution. I'm happy to write a patch for this for rspec itself if you're happy with it. Cheers, Marcus ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-07-23 06:03 Message: I'm not able to reproduce this error using the example you've provided. Please submit an example that we can get to fail running rspec's own examples. See http://rspec.rubyforge.org/community/contribute.html for more information. Thanks ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=12404&group_id=797 From noreply at rubyforge.org Sun Jul 22 22:43:41 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 22 Jul 2007 22:43:41 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-12494 ] RSpec gemspec contains illegal value for authors Message-ID: <20070723024341.D47DD5240B62@rubyforge.org> Bugs item #12494, was opened at 2007-07-22 19:43 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=12494&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Eric Hodel (drbrain) Assigned to: Nobody (None) Summary: RSpec gemspec contains illegal value for authors Initial Comment: $ gem spec rspec | grep -A2 authors authors: - - RSpec Development Team files: authors should be an Array of Strings, not an Array of Arrays of Strings $ gem spec ZenTest | grep -A3 authors authors: - Ryan Davis - Eric Hodel files: ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=12494&group_id=797 From noreply at rubyforge.org Sun Jul 22 22:52:55 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 22 Jul 2007 22:52:55 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-12494 ] RSpec gemspec contains illegal value for authors Message-ID: <20070723025255.A5E5A5240B62@rubyforge.org> Bugs item #12494, was opened at 2007-07-22 19:43 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=12494&group_id=797 Category: None Group: None >Status: Closed >Resolution: Accepted Priority: 3 Submitted By: Eric Hodel (drbrain) >Assigned to: Steven Baker (srbaker) Summary: RSpec gemspec contains illegal value for authors Initial Comment: $ gem spec rspec | grep -A2 authors authors: - - RSpec Development Team files: authors should be an Array of Strings, not an Array of Arrays of Strings $ gem spec ZenTest | grep -A3 authors authors: - Ryan Davis - Eric Hodel files: ---------------------------------------------------------------------- >Comment By: Steven Baker (srbaker) Date: 2007-07-22 19:52 Message: fixed in r2182 ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=12494&group_id=797 From noreply at rubyforge.org Mon Jul 23 08:18:02 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 23 Jul 2007 08:18:02 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-11259 ] windows?: autotest suppresses output Message-ID: <20070723121802.C6ECB5240C1C@rubyforge.org> Bugs item #11259, was opened at 2007-05-31 19:15 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=11259&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Erik Ostrom (eostrom) Assigned to: Nobody (None) Summary: windows?: autotest suppresses output Initial Comment: When I run rspec under autotest (with the change I noted in 11258), it seems to run okay; it detects specs that should be run anew; it runs them (as evidenced by test.log); but it never, ever shows me any output from the spec runner. Even a test known to fail shows me nothing. If I use rspec without autotest, everything works fine. If I use Test::Unit instead of rspec, autotest shows me the full test runner output. So it must be a problem with the way rspec and autotest interact. (I don't know if this is actually a Windows problem, but it seems plausible.) ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-07-23 12:18 Message: The --colour option on windows requires the win32console gem. Do you have that installed? If not, it would help if you would install it and report the behaviour with and without the --colour option. Thanks, David ---------------------------------------------------------------------- Comment By: Adam Grant (krypticus) Date: 2007-07-11 00:31 Message: Yeah. Same here. I don't get any output from the autotest, except to tell me what it's running. Once I remove --colour from the spec.opts line, I get it working just fine. Windows XP Pro w/SP2 Rspec 1.0.5 (r2081) Rails 1.2.3 Ruby 1.8.6 ZenTest 3.6.0 ---------------------------------------------------------------------- Comment By: Erik Ostrom (eostrom) Date: 2007-06-01 04:44 Message: Another useful piece of information I could have given you, it turns out, is the contents of my spec.opts file, which starts with '--colour'. With that removed, the bug goes away. That's probably good enough for me. In case it'll help track down this problem now or in the future, this is as far as I got: * In run_tests() in autotest.rb, the loop that's supposed to loop over characters in the test command's output gets EOF immediately, i.e., there's apparently no output from the spec script. * In colour() in base_text_formatter.rb, @colour and output_to_tty? are both true, so presumably the colour-formatted string is returned. I don't know what happens to it after it's returned and before it gets output. ---------------------------------------------------------------------- Comment By: Erik Ostrom (eostrom) Date: 2007-06-01 03:46 Message: Sorry, I forgot. I think I've got the latest everything: * Windows XP SP2 * Ruby 1.8.6 * Rails 1.2.3 * RSpec and Spec::Rails r2064 * ZenTest 3.6.0 ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-05-31 19:27 Message: Before investigating this we need to know the versions of all relevant software you are using, for example: * OS X 10.4.9 * Ruby 1.8.6 * RSpec 1.8.2 or RSpec trunk r1643 * Spec::Rails 1.8.2 or Spec::Rails tag r1234... * Rails 1.2.3 or Rails edge r5645 * Whatever other relevant software. Without this information it's like solving 1 equation (your question) with 5 unknown variables (the versions). We strongly recommend that you use the latest released version of RSpec, alternatively the subversion trunk (if you're the bleeding edge kind of person). ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=11259&group_id=797 From noreply at rubyforge.org Mon Jul 23 08:21:16 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 23 Jul 2007 08:21:16 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-12162 ] --drb in spec.opts causes`raise_controller_errors' not to be found and raises subsequent errors Message-ID: <20070723122116.ADA5E5240B68@rubyforge.org> Bugs item #12162, was opened at 2007-07-10 15:54 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=12162&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Edward Ocampo-Gooding (edwardog) Assigned to: Nobody (None) Summary: --drb in spec.opts causes`raise_controller_errors' not to be found and raises subsequent errors Initial Comment: Having --drb in spec.opts causes false-failures while running spec tasks against a running spec_server. Such failures resemble the following: NameError in 'PurchaseController should use PurchaseController' undefined local variable or method `raise_controller_errors' for [RSpec example]:# ./spec/models/../spec_helper.rb:12: ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-07-23 12:21 Message: Before investigating this we need to know the versions of all relevant software you are using, for example: * OS X 10.4.9 * Ruby 1.8.6 * RSpec 1.8.2 or RSpec trunk r1643 * Spec::Rails 1.8.2 or Spec::Rails tag r1234... * Rails 1.2.3 or Rails edge r5645 * Whatever other relevant software. Without this information it's like solving 1 equation (your question) with 5 unknown variables (the versions). We strongly recommend that you use the latest released version of RSpec, alternatively the subversion trunk (if you're the bleeding edge kind of person). ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=12162&group_id=797 From noreply at rubyforge.org Mon Jul 23 08:22:13 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 23 Jul 2007 08:22:13 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-12215 ] Misleading error message when passing string as first argument to raise_error Message-ID: <20070723122213.3C323A970005@rubyforge.org> Bugs item #12215, was opened at 2007-07-12 05:39 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=12215&group_id=797 Category: expectation module Group: None Status: Open Resolution: None Priority: 3 Submitted By: Brian Takita (btakita) Assigned to: Nobody (None) Summary: Misleading error message when passing string as first argument to raise_error Initial Comment: describe "An example with raise_error" do it "should provide a nice error message when passed a string as a first argument" do proc do proc do raise "foobar" end.should raise_error("Called 4 times. Expected at most 3 times.") end.should raise_error(ArgumentError, "raise_error expects an Exception Class as its first argument") end end ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-07-23 12:22 Message: Bueller? Bueller? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-07-12 05:44 Message: How about allowing the first argument to be a String? That way, especially nice for RuntimeErrors, you can just specify the message and be done with it, unless you want to be more specific. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=12215&group_id=797 From noreply at rubyforge.org Mon Jul 23 08:36:36 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 23 Jul 2007 08:36:36 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-11608 ] Exclude rspec_on_rails from plugin spec runs Message-ID: <20070723123636.E417EA970012@rubyforge.org> Patches item #11608, was opened at 2007-06-16 04:32 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=11608&group_id=797 Category: rails plugin Group: None >Status: Closed Resolution: Accepted Priority: 3 Submitted By: Kyle Hargraves (philodespotos) Assigned to: Aslak Helles?y (aslak_hellesoy) Summary: Exclude rspec_on_rails from plugin spec runs Initial Comment: Simple patch to exclude rspec_on_rails' plugin specs from the spec:plugins and :plugin_doc tasks. rspec_on_rails' specs largely fail for me, anyhow, so this seems like the best way to go. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-07-23 12:36 Message: Fixed with http://rubyforge.org/tracker/?func=detail&atid=3149&aid=12448&group_id=797 . ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-06-27 01:30 Message: Making contributions isn't harassing. If you contribute a patch that is tested and doesn't stop our own examples from running, I'll be glad to apply it. FYI - you should look into http://piston.rubyforge.org/ - it's a good general solution for this sort of problem. ---------------------------------------------------------------------- Comment By: Kyle Hargraves (philodespotos) Date: 2007-06-26 18:01 Message: How about just depending on the environment? This patch probably isn't exactly what you'd want, but it seems to work -- though I haven't tested my pre_commit edit. Sorry to harrass, but developing a plugin on 'fresh' installs is a pain, since I have to patch rspec_on_rails every time I check it out, or pull my own copy around with me. =) ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-06-24 16:20 Message: I'm un-applying this and re-opening it as it stops our own examples from running when we run rake. Need a version that we can control whether or not to run them easily. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-06-24 13:20 Message: Applied in r2122 ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=11608&group_id=797 From noreply at rubyforge.org Mon Jul 23 08:41:00 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 23 Jul 2007 08:41:00 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-12484 ] Allow a Behaviour's Description to flow through to the Formatter Message-ID: <20070723124100.845FCA970005@rubyforge.org> Patches item #12484, was opened at 2007-07-22 14:26 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=12484&group_id=797 >Category: runner module Group: None >Status: Closed >Resolution: Accepted Priority: 3 Submitted By: Bob Cotton (bcotton) >Assigned to: David Chelimsky (dchelimsky) Summary: Allow a Behaviour's Description to flow through to the Formatter Initial Comment: With the ability to pass options to Behaviours, having those options available to custom Formatters allows for interesting integrations, for example, with test tracking systems. Attached is a patch that passes the Behaviour's Description to the reporter, which will flow it to all the Formatters. No Formatter specs failed, but I tried to ensure that all calls (in specs) to Formatter#add_behavior and Reporter#add_behaviour are passed an instance of Description. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-07-23 12:41 Message: Applied to r2183. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=12484&group_id=797 From noreply at rubyforge.org Mon Jul 23 10:12:48 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 23 Jul 2007 10:12:48 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-12162 ] --drb in spec.opts causes`raise_controller_errors' not to be found and raises subsequent errors Message-ID: <20070723141248.DC2585240ABB@rubyforge.org> Bugs item #12162, was opened at 2007-07-10 11:54 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=12162&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Edward Ocampo-Gooding (edwardog) Assigned to: Nobody (None) Summary: --drb in spec.opts causes`raise_controller_errors' not to be found and raises subsequent errors Initial Comment: Having --drb in spec.opts causes false-failures while running spec tasks against a running spec_server. Such failures resemble the following: NameError in 'PurchaseController should use PurchaseController' undefined local variable or method `raise_controller_errors' for [RSpec example]:# ./spec/models/../spec_helper.rb:12: ---------------------------------------------------------------------- >Comment By: Edward Ocampo-Gooding (edwardog) Date: 2007-07-23 10:12 Message: Relevent peripheral software: * OS X 10.4.9 * Ruby 1.8.6 * RSpec-1.0.5 (r2081) * Spec::Rails 1.0.5 * Rails 1.2.3 ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-07-23 08:21 Message: Before investigating this we need to know the versions of all relevant software you are using, for example: * OS X 10.4.9 * Ruby 1.8.6 * RSpec 1.8.2 or RSpec trunk r1643 * Spec::Rails 1.8.2 or Spec::Rails tag r1234... * Rails 1.2.3 or Rails edge r5645 * Whatever other relevant software. Without this information it's like solving 1 equation (your question) with 5 unknown variables (the versions). We strongly recommend that you use the latest released version of RSpec, alternatively the subversion trunk (if you're the bleeding edge kind of person). ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=12162&group_id=797 From noreply at rubyforge.org Mon Jul 23 21:55:45 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 23 Jul 2007 21:55:45 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-12162 ] --drb in spec.opts causes`raise_controller_errors' not to be found and raises subsequent errors Message-ID: <20070724015545.D6FA75240CEA@rubyforge.org> Bugs item #12162, was opened at 2007-07-10 15:54 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=12162&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Edward Ocampo-Gooding (edwardog) Assigned to: Nobody (None) Summary: --drb in spec.opts causes`raise_controller_errors' not to be found and raises subsequent errors Initial Comment: Having --drb in spec.opts causes false-failures while running spec tasks against a running spec_server. Such failures resemble the following: NameError in 'PurchaseController should use PurchaseController' undefined local variable or method `raise_controller_errors' for [RSpec example]:# ./spec/models/../spec_helper.rb:12: ---------------------------------------------------------------------- Comment By: Scott Taylor (smtlaissezfaire) Date: 2007-07-24 01:55 Message: Could you attach the relevant code sample? Could you also try reloading the spec server, and running the specs again? I've encountered errors like this before when I've created a new Rails Model, but haven't yet reloaded the spec server. ---------------------------------------------------------------------- Comment By: Edward Ocampo-Gooding (edwardog) Date: 2007-07-23 14:12 Message: Relevent peripheral software: * OS X 10.4.9 * Ruby 1.8.6 * RSpec-1.0.5 (r2081) * Spec::Rails 1.0.5 * Rails 1.2.3 ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-07-23 12:21 Message: Before investigating this we need to know the versions of all relevant software you are using, for example: * OS X 10.4.9 * Ruby 1.8.6 * RSpec 1.8.2 or RSpec trunk r1643 * Spec::Rails 1.8.2 or Spec::Rails tag r1234... * Rails 1.2.3 or Rails edge r5645 * Whatever other relevant software. Without this information it's like solving 1 equation (your question) with 5 unknown variables (the versions). We strongly recommend that you use the latest released version of RSpec, alternatively the subversion trunk (if you're the bleeding edge kind of person). ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=12162&group_id=797 From noreply at rubyforge.org Tue Jul 24 11:17:42 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 24 Jul 2007 11:17:42 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-12547 ] validates_each issue in rails with mocking and stubbing Message-ID: <20070724151742.9D80E5240979@rubyforge.org> Bugs item #12547, was opened at 2007-07-25 01:17 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=12547&group_id=797 Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: Daniel Neighman (hassox) Assigned to: Nobody (None) Summary: validates_each issue in rails with mocking and stubbing Initial Comment: I've been trying some code that checks for a validates_each call in an AR model. The spec: http://pastie.caboo.se/81744 This produces the following error: does not detect that two responses are equal Mock 'Book_1027' expected :store_with_privacy? with (#) but received it with (#) and stub overwrites mock Mock 'Book_1026' expected :store_with_privacy? with (#) once, but received it 0 times The Model is: http://pastie.caboo.se/81745 ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=12547&group_id=797 From noreply at rubyforge.org Tue Jul 24 11:23:34 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 24 Jul 2007 11:23:34 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-12547 ] validates_each issue in rails with mocking and stubbing Message-ID: <20070724152334.CE52F5240979@rubyforge.org> Bugs item #12547, was opened at 2007-07-25 01:17 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=12547&group_id=797 Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: Daniel Neighman (hassox) Assigned to: Nobody (None) Summary: validates_each issue in rails with mocking and stubbing Initial Comment: I've been trying some code that checks for a validates_each call in an AR model. The spec: http://pastie.caboo.se/81744 This produces the following error: does not detect that two responses are equal Mock 'Book_1027' expected :store_with_privacy? with (#) but received it with (#) and stub overwrites mock Mock 'Book_1026' expected :store_with_privacy? with (#) once, but received it 0 times The Model is: http://pastie.caboo.se/81745 ---------------------------------------------------------------------- >Comment By: Daniel Neighman (hassox) Date: 2007-07-25 01:23 Message: A bit more information I have rspec installed as plugins in rails rspec 2174 rspec_on_rails 2174 ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=12547&group_id=797 From noreply at rubyforge.org Tue Jul 24 11:29:31 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 24 Jul 2007 11:29:31 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-12547 ] validates_each issue in rails with mocking and stubbing Message-ID: <20070724152931.1CE975240A3F@rubyforge.org> Bugs item #12547, was opened at 2007-07-24 15:17 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=12547&group_id=797 Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: Daniel Neighman (hassox) Assigned to: Nobody (None) Summary: validates_each issue in rails with mocking and stubbing Initial Comment: I've been trying some code that checks for a validates_each call in an AR model. The spec: http://pastie.caboo.se/81744 This produces the following error: does not detect that two responses are equal Mock 'Book_1027' expected :store_with_privacy? with (#) but received it with (#) and stub overwrites mock Mock 'Book_1026' expected :store_with_privacy? with (#) once, but received it 0 times The Model is: http://pastie.caboo.se/81745 ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-07-24 15:29 Message: Would you mind posting the relevant migrations as well? Then I can build a subset of your app and see the error happen. ---------------------------------------------------------------------- Comment By: Daniel Neighman (hassox) Date: 2007-07-24 15:23 Message: A bit more information I have rspec installed as plugins in rails rspec 2174 rspec_on_rails 2174 ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=12547&group_id=797 From noreply at rubyforge.org Tue Jul 24 11:38:47 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 24 Jul 2007 11:38:47 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-12547 ] validates_each issue in rails with mocking and stubbing Message-ID: <20070724153847.B30FA5240A52@rubyforge.org> Bugs item #12547, was opened at 2007-07-25 01:17 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=12547&group_id=797 Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: Daniel Neighman (hassox) Assigned to: Nobody (None) Summary: validates_each issue in rails with mocking and stubbing Initial Comment: I've been trying some code that checks for a validates_each call in an AR model. The spec: http://pastie.caboo.se/81744 This produces the following error: does not detect that two responses are equal Mock 'Book_1027' expected :store_with_privacy? with (#) but received it with (#) and stub overwrites mock Mock 'Book_1026' expected :store_with_privacy? with (#) once, but received it 0 times The Model is: http://pastie.caboo.se/81745 ---------------------------------------------------------------------- >Comment By: Daniel Neighman (hassox) Date: 2007-07-25 01:38 Message: The migrations are here http://pastie.caboo.se/81756 ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-07-25 01:29 Message: Would you mind posting the relevant migrations as well? Then I can build a subset of your app and see the error happen. ---------------------------------------------------------------------- Comment By: Daniel Neighman (hassox) Date: 2007-07-25 01:23 Message: A bit more information I have rspec installed as plugins in rails rspec 2174 rspec_on_rails 2174 ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=12547&group_id=797 From obiefernandez at gmail.com Tue Jul 24 14:43:31 2007 From: obiefernandez at gmail.com (Obie Fernandez) Date: Tue, 24 Jul 2007 14:43:31 -0400 Subject: [rspec-devel] integration testing/rspec/rbehave In-Reply-To: <46828137.7030304@tastapod.com> References: <57c63afe0706231350y211ddb14r5c6710f5012d31cd@mail.gmail.com> <46828137.7030304@tastapod.com> Message-ID: <8bf510930707241143i4bdfcb81y6e89075a47a77dc7@mail.gmail.com> Has there been any further progress on this front? Hi Dan! Are you back from holiday? Cheers, Obie On 6/27/07, Dan North wrote: > Thanks for the mention David. > > I'm very excited about the idea of rspec+rbehave becoming a killer stack > for integration/acceptance testing and full "outside-in" BDD. > > Having said that, I don't know nearly enough about rails or the > rails/rspec integration points. I've lurked on this list for some time > now, and I have noticed that a lot of the issues in the tracker are > about rails integration. I would really appreciate any help from the > people on this list to help bring that richness of integration into rbehave. > > To reiterate what David said, please feel free to contact me directly or > join the rbehave-devel list if you are interested in helping out. I'm > away until mid-July, but I'll be in touch then. In the meantime please > feel free to gem install rbehave and take it for a spin. > > Thanks, > Dan > > > David Chelimsky wrote: > > Hi all, > > > > Dan North has released rbehave: > > http://dannorth.net/2007/06/introducing-rbehave, > > http://rubyforge.org/projects/rbehave/. He used rspec to describe it, > > and it actually uses rspec's expectation library to express the > > details. The idea is that while rspec excels at expressing object > > behaviour, rbehave is targeted at story level behaviour. By using > > rspec expectations for both there's very little context shifting for > > developers who use both tools on the same project. The only real > > difference is in how object-specific examples are structured in rspec > > vs stories and scenarios in rbehave. > > > > With that context, there is one big thing missing from our BDD/Rails > > toolset, and that is pure ruby rails integration testing. I'd like to > > propose that we focus on getting that support into rbehave. If any of > > you are interested in contributing to this effort, please join the > > rbehave-devel list (http://rubyforge.org/mail/?group_id=1475) and let > > Dan know. > > > > Thanks, > > David > > _______________________________________________ > > 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 > -- Obie Fernandez http://jroller.com/obie/ Pre-order my book The Rails Way today! http://www.amazon.com/dp/0321445619 From brian.takita at gmail.com Wed Jul 25 16:33:07 2007 From: brian.takita at gmail.com (Brian Takita) Date: Wed, 25 Jul 2007 13:33:07 -0700 Subject: [rspec-devel] Simplifying Behaviour in Rspec Message-ID: <1d7ddd110707251333p1ea14707l53a01d4fe33065ff@mail.gmail.com> I remember that much of Behaviour's complexity put in place to reuse Rails fixtures. That includes the inherit method and the dynamic class builder. BehaviourEval.derive_execution_context_class_from_behaviour_superclass Since we now call Test::Unit's setup and teardown in before and after blocks, we can compose in a Test::Unit::TestCase instance to call setup and teardown on. This would make the dynamic class inherit from Test::Unit unnecessary. In fact, I don't think there is any other reason to use BehaviorEval to create a Dynamic class. Since that is the case, we can probably use class and instance methods for Behaviour and remove BehaviourEval from the loop. This would simplify things. What do you all think about this? Are there extensions out there that this would break? This would be a major change to Rspec's internals, so please speak up. Thank you, Brian From dchelimsky at gmail.com Wed Jul 25 16:59:58 2007 From: dchelimsky at gmail.com (David Chelimsky) Date: Wed, 25 Jul 2007 16:59:58 -0400 Subject: [rspec-devel] Simplifying Behaviour in Rspec In-Reply-To: <1d7ddd110707251333p1ea14707l53a01d4fe33065ff@mail.gmail.com> References: <1d7ddd110707251333p1ea14707l53a01d4fe33065ff@mail.gmail.com> Message-ID: <57c63afe0707251359q56fcdd18g77c3be5cc6975aeb@mail.gmail.com> On 7/25/07, Brian Takita wrote: > I remember that much of Behaviour's complexity put in place to reuse > Rails fixtures. > That includes the inherit method and the dynamic class builder. > BehaviourEval.derive_execution_context_class_from_behaviour_superclass > > Since we now call Test::Unit's setup and teardown in before and after > blocks, we can compose in a Test::Unit::TestCase instance to call > setup and teardown on. > This would make the dynamic class inherit from Test::Unit unnecessary. > > In fact, I don't think there is any other reason to use BehaviorEval > to create a Dynamic class. > Since that is the case, we can probably use class and instance methods > for Behaviour and remove BehaviourEval from the loop. > This would simplify things. > > What do you all think about this? > Are there extensions out there that this would break? > > This would be a major change to Rspec's internals, so please speak up. FYI - Brian and I have discussed this a bit. The only users this might affect are those who've written extensions that extend or talk directly to Behaviour or BehaviourEval and anyone who is using the "inherit" method in examples. My sense is that this should be a VERY limited group, if any at all. If you are in this group, we need to hear from you. The benefits of this change would be enormous, because it would greatly simplify RSpec's internals, making it much easier to modify/maintain. +1 (at least) David > > Thank you, > Brian > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From dan at tastapod.com Wed Jul 25 18:15:00 2007 From: dan at tastapod.com (Dan North) Date: Wed, 25 Jul 2007 23:15:00 +0100 Subject: [rspec-devel] Simplifying Behaviour in Rspec In-Reply-To: <57c63afe0707251359q56fcdd18g77c3be5cc6975aeb@mail.gmail.com> References: <1d7ddd110707251333p1ea14707l53a01d4fe33065ff@mail.gmail.com> <57c63afe0707251359q56fcdd18g77c3be5cc6975aeb@mail.gmail.com> Message-ID: <46A7CB64.3070802@tastapod.com> +1 from someone who's about to dive into rspec's internals and see how much he can reuse in rbehave :) Simple is good. David Chelimsky wrote: > On 7/25/07, Brian Takita wrote: > >> I remember that much of Behaviour's complexity put in place to reuse >> Rails fixtures. >> That includes the inherit method and the dynamic class builder. >> BehaviourEval.derive_execution_context_class_from_behaviour_superclass >> >> Since we now call Test::Unit's setup and teardown in before and after >> blocks, we can compose in a Test::Unit::TestCase instance to call >> setup and teardown on. >> This would make the dynamic class inherit from Test::Unit unnecessary. >> >> In fact, I don't think there is any other reason to use BehaviorEval >> to create a Dynamic class. >> Since that is the case, we can probably use class and instance methods >> for Behaviour and remove BehaviourEval from the loop. >> This would simplify things. >> >> What do you all think about this? >> Are there extensions out there that this would break? >> >> This would be a major change to Rspec's internals, so please speak up. >> > > FYI - Brian and I have discussed this a bit. The only users this might > affect are those who've written extensions that extend or talk > directly to Behaviour or BehaviourEval and anyone who is using the > "inherit" method in examples. My sense is that this should be a VERY > limited group, if any at all. If you are in this group, we need to > hear from you. > > The benefits of this change would be enormous, because it would > greatly simplify RSpec's internals, making it much easier to > modify/maintain. > > +1 (at least) > > David > > > >> Thank you, >> Brian >> _______________________________________________ >> 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: http://rubyforge.org/pipermail/rspec-devel/attachments/20070725/f8eb2869/attachment.html From noreply at rubyforge.org Thu Jul 26 11:45:48 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 26 Jul 2007 11:45:48 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-7612 ] Add ENV['RAILS_ENV'] = 'test' at the top of spec_helper.rb Message-ID: <20070726154548.CAD4BA970007@rubyforge.org> Feature Requests item #7612, was opened at 2007-01-06 02:21 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=7612&group_id=797 Category: rails plugin Group: None Status: Closed Priority: 3 Submitted By: Brian Takita (btakita) Assigned to: David Chelimsky (dchelimsky) Summary: Add ENV['RAILS_ENV'] = 'test' at the top of spec_helper.rb Initial Comment: Otherwise, specs are run in development mode. Very confusing. ---------------------------------------------------------------------- Comment By: Peter Marklund (peter_marklund) Date: 2007-07-26 17:45 Message: I still have this problem, and I'm on the current stable release (I think it is 1.0.5). In spec_helper.rb we have: ENV["RAILS_ENV"] ||= "test" which means that the environment for specs defaults to test if RAILS_ENV isn't set and otherwise runs in whatever environment RAILS_ENV is set to. This meant for me that specs tried to run in development mode, which failed for some obscure reason. I run specs on my production server as well and I definetely don't want to run them in the production environment there... I think that just like in test_helper.rb the line should instead read: ENV["RAILS_ENV"] = "test" so that specs are always run in the test environment. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-01-06 03:20 Message: This was fixed in the trunk some time ago (but after 0.7.5). Will be part of next release. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=7612&group_id=797 From noreply at rubyforge.org Thu Jul 26 13:56:09 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 26 Jul 2007 13:56:09 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-12603 ] Methods in controllers defined with helper_method are not available in helper tests Message-ID: <20070726175609.BF43E5240BF4@rubyforge.org> Bugs item #12603, was opened at 2007-07-26 17:56 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=12603&group_id=797 Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: Michael Schreifels (technel) Assigned to: Nobody (None) Summary: Methods in controllers defined with helper_method are not available in helper tests Initial Comment: When you define a method in a controller and use helper_method to make it available in views and helpers, it is not made available to Rspec helper tests. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=12603&group_id=797 From noreply at rubyforge.org Thu Jul 26 14:33:44 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 26 Jul 2007 14:33:44 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-7612 ] Add ENV['RAILS_ENV'] = 'test' at the top of spec_helper.rb Message-ID: <20070726183345.0A6295240C54@rubyforge.org> Feature Requests item #7612, was opened at 2007-01-06 01:21 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=7612&group_id=797 Category: rails plugin Group: None Status: Closed Priority: 3 Submitted By: Brian Takita (btakita) Assigned to: David Chelimsky (dchelimsky) Summary: Add ENV['RAILS_ENV'] = 'test' at the top of spec_helper.rb Initial Comment: Otherwise, specs are run in development mode. Very confusing. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-07-26 18:33 Message: This is already fixed in trunk and will be released with 1.0.6. ---------------------------------------------------------------------- Comment By: Peter Marklund (peter_marklund) Date: 2007-07-26 15:45 Message: I still have this problem, and I'm on the current stable release (I think it is 1.0.5). In spec_helper.rb we have: ENV["RAILS_ENV"] ||= "test" which means that the environment for specs defaults to test if RAILS_ENV isn't set and otherwise runs in whatever environment RAILS_ENV is set to. This meant for me that specs tried to run in development mode, which failed for some obscure reason. I run specs on my production server as well and I definetely don't want to run them in the production environment there... I think that just like in test_helper.rb the line should instead read: ENV["RAILS_ENV"] = "test" so that specs are always run in the test environment. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-01-06 02:20 Message: This was fixed in the trunk some time ago (but after 0.7.5). Will be part of next release. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=7612&group_id=797 From noreply at rubyforge.org Thu Jul 26 14:39:59 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 26 Jul 2007 14:39:59 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-12603 ] Methods in controllers defined with helper_method are not available in helper tests Message-ID: <20070726183959.87E325240C4F@rubyforge.org> Bugs item #12603, was opened at 2007-07-26 17:56 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=12603&group_id=797 Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: Michael Schreifels (technel) Assigned to: Nobody (None) Summary: Methods in controllers defined with helper_method are not available in helper tests Initial Comment: When you define a method in a controller and use helper_method to make it available in views and helpers, it is not made available to Rspec helper tests. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-07-26 18:39 Message: Here's my instinctive reaction to this: Helper examples are where you describe methods in your helper modules, not helper methods defined anywhere else (like in a controller). If you're defining this method in your controller, then you should be describing it in a controller example. Based on that, I'm inclined to reject this. But I'll leave it open for the moment and await your comments on this thinking. Thanks, David ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=12603&group_id=797 From noreply at rubyforge.org Thu Jul 26 15:13:35 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 26 Jul 2007 15:13:35 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-12054 ] rake task for spec:recent Message-ID: <20070726191335.D72665240C4D@rubyforge.org> Patches item #12054, was opened at 2007-07-06 18:09 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=12054&group_id=797 Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: Jerrett Taylor (ennoia) Assigned to: Aslak Helles?y (aslak_hellesoy) Summary: rake task for spec:recent Initial Comment: This is pretty simple, but i found it missing once i started to accumulate lots of specs ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-07-10 15:55 Message: Great idea. The logic you have to detect twins between lib and spec files is also implemented in RSpec's autotest plugin and in RSpec.tmbundle. I'd like to consolidate this to one place before I apply this, and just rely on one such mechanism from anywhere. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=12054&group_id=797 From noreply at rubyforge.org Thu Jul 26 15:13:40 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 26 Jul 2007 15:13:40 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-12054 ] rake task for spec:recent Message-ID: <20070726191340.5034E5240C5C@rubyforge.org> Patches item #12054, was opened at 2007-07-06 18:09 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=12054&group_id=797 Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: Jerrett Taylor (ennoia) Assigned to: Aslak Helles?y (aslak_hellesoy) Summary: rake task for spec:recent Initial Comment: This is pretty simple, but i found it missing once i started to accumulate lots of specs ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-07-10 15:55 Message: Great idea. The logic you have to detect twins between lib and spec files is also implemented in RSpec's autotest plugin and in RSpec.tmbundle. I'd like to consolidate this to one place before I apply this, and just rely on one such mechanism from anywhere. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=12054&group_id=797 From noreply at rubyforge.org Thu Jul 26 15:32:41 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 26 Jul 2007 15:32:41 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-12603 ] Methods in controllers defined with helper_method are not available in helper tests Message-ID: <20070726193241.B714C5240C4D@rubyforge.org> Bugs item #12603, was opened at 2007-07-26 17:56 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=12603&group_id=797 Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: Michael Schreifels (technel) Assigned to: Nobody (None) Summary: Methods in controllers defined with helper_method are not available in helper tests Initial Comment: When you define a method in a controller and use helper_method to make it available in views and helpers, it is not made available to Rspec helper tests. ---------------------------------------------------------------------- >Comment By: Michael Schreifels (technel) Date: 2007-07-26 19:32 Message: Hi David, I didn't actually clarify exactly what I was trying to do, but the solution would remain the same (that is, to include helpers defined using helper_method in controllers). This issue came up when I had a method in helpers/application_helper.rb that would check the value of the logged_in? method and return a URL to the index page based on that (e.g. user dashboard vs index page for non-registered users). I decided to test this (regular) helper method with a spec. The problem was that I kept getting NoMethodError for logged_in? because it was a helper method defined in the controller and thus was not included. I ended up just stubbing out logged_in? and it wasn't a problem, but I just wanted to bring it to your attention. Mike ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-07-26 18:39 Message: Here's my instinctive reaction to this: Helper examples are where you describe methods in your helper modules, not helper methods defined anywhere else (like in a controller). If you're defining this method in your controller, then you should be describing it in a controller example. Based on that, I'm inclined to reject this. But I'll leave it open for the moment and await your comments on this thinking. Thanks, David ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=12603&group_id=797 From noreply at rubyforge.org Thu Jul 26 21:44:19 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 26 Jul 2007 21:44:19 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-12611 ] should_not redirect_to implementation Message-ID: <20070727014419.835C85240C5D@rubyforge.org> Patches item #12611, was opened at 2007-07-27 04:44 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=12611&group_id=797 Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: Yurii Rashkovskii (yrashk) Assigned to: Nobody (None) Summary: should_not redirect_to implementation Initial Comment: Here is an extract from my source code it "should allow authenticated user to access '#{action}'" do @user = mock_user_authentication(:id => 1, :identity_url => "http://openid.server/yrashk", :queues => []) get action, params assigns[:current_user].should == @user flash[:error].should be_nil response.should_not redirect_to(login_url) end Depending on action, it is either successful response or response that redirects somewhere (but not to login, since user is "proven" to be authenticated). In this example, I really don't want to care, whether it was successful response or redirection to somewhere, until it is not a redirection to login URL. -- Was discussed with David on maillist, he proposed to prepare a patch. Here it is. It is seems to be working, though can't be sure for 100% ? almost 5AM. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=12611&group_id=797 From mattaimonetti at gmail.com Fri Jul 27 04:10:23 2007 From: mattaimonetti at gmail.com (Matt Aimonetti) Date: Fri, 27 Jul 2007 01:10:23 -0700 Subject: [rspec-devel] integration testing/rspec/rbehave In-Reply-To: <8bf510930707241143i4bdfcb81y6e89075a47a77dc7@mail.gmail.com> References: <57c63afe0706231350y211ddb14r5c6710f5012d31cd@mail.gmail.com> <46828137.7030304@tastapod.com> <8bf510930707241143i4bdfcb81y6e89075a47a77dc7@mail.gmail.com> Message-ID: Any news? Anyone knows if Dan is back? -Matt On 7/24/07, Obie Fernandez wrote: > > Has there been any further progress on this front? Hi Dan! Are you > back from holiday? > > Cheers, > Obie > > On 6/27/07, Dan North wrote: > > Thanks for the mention David. > > > > I'm very excited about the idea of rspec+rbehave becoming a killer stack > > for integration/acceptance testing and full "outside-in" BDD. > > > > Having said that, I don't know nearly enough about rails or the > > rails/rspec integration points. I've lurked on this list for some time > > now, and I have noticed that a lot of the issues in the tracker are > > about rails integration. I would really appreciate any help from the > > people on this list to help bring that richness of integration into > rbehave. > > > > To reiterate what David said, please feel free to contact me directly or > > join the rbehave-devel list if you are interested in helping out. I'm > > away until mid-July, but I'll be in touch then. In the meantime please > > feel free to gem install rbehave and take it for a spin. > > > > Thanks, > > Dan > > > > > > David Chelimsky wrote: > > > Hi all, > > > > > > Dan North has released rbehave: > > > http://dannorth.net/2007/06/introducing-rbehave, > > > http://rubyforge.org/projects/rbehave/. He used rspec to describe it, > > > and it actually uses rspec's expectation library to express the > > > details. The idea is that while rspec excels at expressing object > > > behaviour, rbehave is targeted at story level behaviour. By using > > > rspec expectations for both there's very little context shifting for > > > developers who use both tools on the same project. The only real > > > difference is in how object-specific examples are structured in rspec > > > vs stories and scenarios in rbehave. > > > > > > With that context, there is one big thing missing from our BDD/Rails > > > toolset, and that is pure ruby rails integration testing. I'd like to > > > propose that we focus on getting that support into rbehave. If any of > > > you are interested in contributing to this effort, please join the > > > rbehave-devel list (http://rubyforge.org/mail/?group_id=1475) and let > > > Dan know. > > > > > > Thanks, > > > David > > > _______________________________________________ > > > 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 > > > > > -- > Obie Fernandez > http://jroller.com/obie/ > > Pre-order my book The Rails Way today! > http://www.amazon.com/dp/0321445619 > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20070727/1ce8ed8f/attachment-0001.html From dan at tastapod.com Fri Jul 27 06:58:53 2007 From: dan at tastapod.com (Dan North) Date: Fri, 27 Jul 2007 11:58:53 +0100 Subject: [rspec-devel] merging rbehave into rspec Message-ID: <46A9CFED.1020709@tastapod.com> Hi folks. I've been talking with David Chelimsky and Aslak* about bringing rbehave and rspec together into a "full stack" BDD framework. The thinking is roughly this: - rspec is about describing and verifying objects and interactions, at the code level - rbehave is about describing and verifying stories and scenarios, at the application level (from here on I'm calling rspec /the object description framework/, and rbehave /the story description framework/) So here's the plan: - the object and story frameworks keep their own runners - they are functionally different although they share some common design concepts (listeners, renderers, etc.) - the story framework adopts the object framework's domain vocabulary (so if rspec calls something a Renderer and rbehave calls the same concept a Describer, it gets renamed in rbehave to a Renderer) - the story framework will reuse any identical concepts from the object framework (so rbehave will use rspec's PendingException, for example) - the story runner becomes part of rspec's core, in a suitable module namespace - all the story runner behaviours are migrated across - the rbehave rubyforge project is gutted to simply delegate to the rspec story framework (this is an interim move to retain compatibility) The near-term objectives are: 1) integrate story description behaviour natively into rspec 2) support description of Rails behaviour at a story/scenario level So: - what do you think? - does anyone want to help me? - please say yes because I have no idea how to do 2) Thanks, Dan * Aslak only has one name - like Cher or Madonna. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20070727/ed4feb96/attachment.html From yrashk at gmail.com Fri Jul 27 07:10:47 2007 From: yrashk at gmail.com (Yurii Rashkovskii) Date: Fri, 27 Jul 2007 14:10:47 +0300 Subject: [rspec-devel] merging rbehave into rspec In-Reply-To: <46A9CFED.1020709@tastapod.com> References: <46A9CFED.1020709@tastapod.com> Message-ID: On Jul 27, 2007, at 1:58 PM, Dan North wrote: > > - does anyone want to help me? > - please say yes because I have no idea how to do 2) I'd be interested to. Yurii. From noreply at rubyforge.org Fri Jul 27 08:33:49 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 27 Jul 2007 08:33:49 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-12628 ] Integrate rbehave into rspec Message-ID: <20070727123349.F21635240A9C@rubyforge.org> Feature Requests item #12628, was opened at 2007-07-27 13:33 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=12628&group_id=797 Category: None Group: None Status: Open Priority: 3 Submitted By: Dan North (tastapod) Assigned to: Nobody (None) Summary: Integrate rbehave into rspec Initial Comment: rbehave is a story/scenario description framework that describes behaviour for an application in the same way that rspec describes behaviour for objects. It would make sense for rspec to contain rbehave in a "story" module (spec/story) so that rspec becomes a "full stack" BDD framework. This initial feature request is simply to bring rbehave into the rspec project. Further work (ie. further feature requests) would create closer integration between the two, and providing a way to describe Rails behaviour at a story/scenario level. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=12628&group_id=797 From noreply at rubyforge.org Fri Jul 27 18:26:40 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 27 Jul 2007 18:26:40 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-12648 ] rspec_on_rails without a database Message-ID: <20070727222640.693C8A970007@rubyforge.org> Bugs item #12648, was opened at 2007-07-27 22:26 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=12648&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: David Chelimsky (dchelimsky) Assigned to: Nobody (None) Summary: rspec_on_rails without a database Initial Comment: With this setup: RSpec (1.0.5 or trunk r2183) Edge Rails (r7245) And following these instructions from http://rubyforge.org/tracker/?func=detail&group_id=797&aid=6523&atid=3152: Remove config/database.yml. Tell Rails not to use AR in config/environment.rb. This no longer works. With a new rails app configured that way, I get the following error: undefined method `connected?' for ActiveRecord::Base:Class /Users/david/projects/ruby/nodb/vendor/rails/activerecord/lib/active_record/base.rb:1261:in `method_missing' /Users/david/projects/ruby/nodb/vendor/rails/actionpack/lib/action_controller/benchmarking.rb:48:in `render' /Users/david/projects/ruby/nodb/vendor/plugins/rspec_on_rails/lib/spec/rails/dsl/behaviour/controller.rb:70:in `render' /Users/david/projects/ruby/nodb/app/controllers/things_controller.rb:3:in `index' /Users/david/projects/ruby/nodb/vendor/rails/actionpack/lib/action_controller/base.rb:1136:in `send' /Users/david/projects/ruby/nodb/vendor/rails/actionpack/lib/action_controller/base.rb:1136:in `perform_action_without_filters' /Users/david/projects/ruby/nodb/vendor/rails/actionpack/lib/action_controller/filters.rb:695:in `call_filters' /Users/david/projects/ruby/nodb/vendor/rails/actionpack/lib/action_controller/filters.rb:687:in `perform_action_without_benchmark' /Users/david/projects/ruby/nodb/vendor/rails/actionpack/lib/action_controller/benchmarking.rb:68:in `perform_action_without_rescue' /opt/local/lib/ruby/1.8/benchmark.rb:293:in `measure' /Users/david/projects/ruby/nodb/vendor/rails/actionpack/lib/action_controller/benchmarking.rb:68:in `perform_action_without_rescue' /Users/david/projects/ruby/nodb/vendor/rails/actionpack/lib/action_controller/rescue.rb:133:in `perform_action' /Users/david/projects/ruby/nodb/vendor/rails/actionpack/lib/action_controller/base.rb:494:in `send' /Users/david/projects/ruby/nodb/vendor/rails/actionpack/lib/action_controller/base.rb:494:in `process_without_filters' /Users/david/projects/ruby/nodb/vendor/rails/actionpack/lib/action_controller/filters.rb:683:in `process_without_session_management_support' /Users/david/projects/ruby/nodb/vendor/rails/actionpack/lib/action_controller/session_management.rb:122:in `process_without_test' /Users/david/projects/ruby/nodb/vendor/rails/actionpack/lib/action_controller/test_process.rb:15:in `process' /Users/david/projects/ruby/nodb/vendor/rails/actionpack/lib/action_controller/test_process.rb:394:in `process' /Users/david/projects/ruby/nodb/vendor/rails/actionpack/lib/action_controller/test_process.rb:365:in `get' ./spec/controllers/things_controller_spec.rb:5: /Users/david/projects/ruby/nodb/vendor/plugins/rspec/lib/spec/dsl/example.rb:81:in `instance_eval' /Users/david/projects/ruby/nodb/vendor/plugins/rspec/lib/spec/dsl/example.rb:81:in `run_example' /Users/david/projects/ruby/nodb/vendor/plugins/rspec/lib/spec/dsl/example.rb:26:in `run' /opt/local/lib/ruby/1.8/timeout.rb:48:in `timeout' /Users/david/projects/ruby/nodb/vendor/plugins/rspec/lib/spec/dsl/example.rb:24:in `run' /Users/david/projects/ruby/nodb/vendor/plugins/rspec/lib/spec/dsl/behaviour.rb:81:in `run' /Users/david/projects/ruby/nodb/vendor/plugins/rspec/lib/spec/dsl/behaviour.rb:75:in `each' /Users/david/projects/ruby/nodb/vendor/plugins/rspec/lib/spec/dsl/behaviour.rb:75:in `run' /Users/david/projects/ruby/nodb/vendor/plugins/rspec/lib/spec/runner/behaviour_runner.rb:58:in `run_behaviours' /Users/david/projects/ruby/nodb/vendor/plugins/rspec/lib/spec/runner/behaviour_runner.rb:57:in `each' /Users/david/projects/ruby/nodb/vendor/plugins/rspec/lib/spec/runner/behaviour_runner.rb:57:in `run_behaviours' /Users/david/projects/ruby/nodb/vendor/plugins/rspec/lib/spec/runner/behaviour_runner.rb:21:in `run' /Users/david/projects/ruby/nodb/vendor/plugins/rspec/lib/spec/runner/command_line.rb:17:in `run' script/spec:4: ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=12648&group_id=797 From noreply at rubyforge.org Fri Jul 27 18:29:29 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 27 Jul 2007 18:29:29 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-12603 ] Methods in controllers defined with helper_method are not available in helper tests Message-ID: <20070727222929.511F2A970007@rubyforge.org> Bugs item #12603, was opened at 2007-07-26 17:56 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=12603&group_id=797 Category: rails plugin Group: None >Status: Closed >Resolution: Rejected Priority: 3 Submitted By: Michael Schreifels (technel) Assigned to: Nobody (None) Summary: Methods in controllers defined with helper_method are not available in helper tests Initial Comment: When you define a method in a controller and use helper_method to make it available in views and helpers, it is not made available to Rspec helper tests. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-07-27 22:29 Message: To me, that is actually the right way to deal with a situation like this. If you want to isolate things for testing, then you have to isolate them. Otherwise, use controller examples with integrate_views and you get everything integrated. Can't really have it both ways. ---------------------------------------------------------------------- Comment By: Michael Schreifels (technel) Date: 2007-07-26 19:32 Message: Hi David, I didn't actually clarify exactly what I was trying to do, but the solution would remain the same (that is, to include helpers defined using helper_method in controllers). This issue came up when I had a method in helpers/application_helper.rb that would check the value of the logged_in? method and return a URL to the index page based on that (e.g. user dashboard vs index page for non-registered users). I decided to test this (regular) helper method with a spec. The problem was that I kept getting NoMethodError for logged_in? because it was a helper method defined in the controller and thus was not included. I ended up just stubbing out logged_in? and it wasn't a problem, but I just wanted to bring it to your attention. Mike ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-07-26 18:39 Message: Here's my instinctive reaction to this: Helper examples are where you describe methods in your helper modules, not helper methods defined anywhere else (like in a controller). If you're defining this method in your controller, then you should be describing it in a controller example. Based on that, I'm inclined to reject this. But I'll leave it open for the moment and await your comments on this thinking. Thanks, David ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=12603&group_id=797 From noreply at rubyforge.org Fri Jul 27 19:16:24 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 27 Jul 2007 19:16:24 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-12404 ] Edge Rails breaks RSpec with newer link_to syntax Message-ID: <20070727231624.42D72A970008@rubyforge.org> Bugs item #12404, was opened at 2007-07-19 07:03 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=12404&group_id=797 Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: Marcus Crafter (crafterm) Assigned to: Nobody (None) Summary: Edge Rails breaks RSpec with newer link_to syntax Initial Comment: Hi All, Hope all is going well. In Edge Rails you can specify link to using: link_to('path, @model) as opposed to: link_to('path', model_path(@model)) in 1.2 and earlier. The newer syntax breaks rspec though if you have any helpers or view specs that test code that uses it with mock models. The error it prints is: undefined method `polymorphic_path' for [Dynamically generated class for RSpec example]:# Example to reproduce: describe ApplicationHelper do it "should demo edge link_to problem" do mock = mock_model(User, :name => test) link_to(mock.name, mock).should == 'test' end end I've been able to fix this with the following monkey patch: module Spec module Rails module DSL class EvalContext < Spec::Rails::TestCase def polymorphic_path(uri) "/#{uri.class.to_s.underscore.pluralize}/#{uri.id}" end end end end end However there may be a more appropriate solution? Would be great to get this fixed, please let me know if there's anything else I can do. Cheers, Marcus ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-07-27 23:16 Message: I took a look at this. The method as you've defined it would always return what is essentially the "show" path. The whole magic of polymorphic_path is that it renders a different url based on the state of the object. I think this would lead to people getting frustrated using rspec to describe helper methods like the one you are trying to deal with, with objects that are in varying states, and getting unexpected results. With that in mind, a more robust solution *would* be to include ActionController::PolymorphicRoutes in the helper examples (that's where polymorphic_path gets defined) - but this creates a new problem, which is that polymorphic_path ends up using named routes that don't exist in scope either. Anybody have any suggestions here? David ---------------------------------------------------------------------- Comment By: Marcus Crafter (crafterm) Date: 2007-07-22 23:57 Message: Hi David, My apologies, I've attached a tar.bz2 archive that includes a working example of the issue. Please extract the polymorphic-path-example.tar.bz2, and run the notes_helper_spec.rb spec, or simply run rake spec after creating the test database, and you'll see the error. I haven't included rails, or rspec with this example, in the vendor directory, I've symlinked rails to the latest trunk (rev 7209), and in the plugins directory rspec/rpec_on_rails (rev 2181). The notes_helper_spec.rb includes the fix I wrote but I'm unsure if this is the correct solution. I'm happy to write a patch for this for rspec itself if you're happy with it. Cheers, Marcus ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-07-22 20:03 Message: I'm not able to reproduce this error using the example you've provided. Please submit an example that we can get to fail running rspec's own examples. See http://rspec.rubyforge.org/community/contribute.html for more information. Thanks ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=12404&group_id=797 From noreply at rubyforge.org Sat Jul 28 06:59:12 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sat, 28 Jul 2007 06:59:12 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-12628 ] Integrate rbehave into rspec Message-ID: <20070728105912.8A2FE5240ADA@rubyforge.org> Feature Requests item #12628, was opened at 2007-07-27 15:33 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=12628&group_id=797 Category: None Group: None Status: Open Priority: 3 Submitted By: Dan North (tastapod) Assigned to: Nobody (None) Summary: Integrate rbehave into rspec Initial Comment: rbehave is a story/scenario description framework that describes behaviour for an application in the same way that rspec describes behaviour for objects. It would make sense for rspec to contain rbehave in a "story" module (spec/story) so that rspec becomes a "full stack" BDD framework. This initial feature request is simply to bring rbehave into the rspec project. Further work (ie. further feature requests) would create closer integration between the two, and providing a way to describe Rails behaviour at a story/scenario level. ---------------------------------------------------------------------- Comment By: Yurii Rashkovskii (yrashk) Date: 2007-07-28 13:59 Message: First of all, thank you for your nice DSL Then, here is a draft version of code that isolates scenarios into ActiveRecord transactions (extract from my project) class ActiveRecordSafetyListener include Singleton def scenario_started(*args) unless Rails::VERSION::STRING == "1.1.6" ActiveRecord::Base.send :increment_open_transactions end ActiveRecord::Base.connection.begin_db_transaction end def scenario_succeeded(*args) ActiveRecord::Base.connection.rollback_db_transaction unless Rails::VERSION::STRING == "1.1.6" ActiveRecord::Base.send :decrement_open_transactions end end alias :scenario_pending :scenario_succeeded alias :scenario_failed :scenario_succeeded end class RBehave::Runner::ScenarioRunner def initialize @listeners = [ActiveRecordSafetyListener.instance] end end ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=12628&group_id=797 From noreply at rubyforge.org Sat Jul 28 07:14:14 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sat, 28 Jul 2007 07:14:14 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-12628 ] Integrate rbehave into rspec Message-ID: <20070728111414.4630C5240B41@rubyforge.org> Feature Requests item #12628, was opened at 2007-07-27 12:33 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=12628&group_id=797 Category: None Group: None Status: Open Priority: 3 Submitted By: Dan North (tastapod) Assigned to: Nobody (None) Summary: Integrate rbehave into rspec Initial Comment: rbehave is a story/scenario description framework that describes behaviour for an application in the same way that rspec describes behaviour for objects. It would make sense for rspec to contain rbehave in a "story" module (spec/story) so that rspec becomes a "full stack" BDD framework. This initial feature request is simply to bring rbehave into the rspec project. Further work (ie. further feature requests) would create closer integration between the two, and providing a way to describe Rails behaviour at a story/scenario level. ---------------------------------------------------------------------- Comment By: Michael Klishin (michaelklishin) Date: 2007-07-28 11:14 Message: RBehave is great, plus one for it. The only problem is that it is poorly documented. And yes, I'd like to submit a patch when I get deep enough in the source. ---------------------------------------------------------------------- Comment By: Yurii Rashkovskii (yrashk) Date: 2007-07-28 10:59 Message: First of all, thank you for your nice DSL Then, here is a draft version of code that isolates scenarios into ActiveRecord transactions (extract from my project) class ActiveRecordSafetyListener include Singleton def scenario_started(*args) unless Rails::VERSION::STRING == "1.1.6" ActiveRecord::Base.send :increment_open_transactions end ActiveRecord::Base.connection.begin_db_transaction end def scenario_succeeded(*args) ActiveRecord::Base.connection.rollback_db_transaction unless Rails::VERSION::STRING == "1.1.6" ActiveRecord::Base.send :decrement_open_transactions end end alias :scenario_pending :scenario_succeeded alias :scenario_failed :scenario_succeeded end class RBehave::Runner::ScenarioRunner def initialize @listeners = [ActiveRecordSafetyListener.instance] end end ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=12628&group_id=797 From noreply at rubyforge.org Sat Jul 28 11:48:40 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sat, 28 Jul 2007 11:48:40 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-12628 ] Integrate rbehave into rspec Message-ID: <20070728154840.93F045240DB5@rubyforge.org> Feature Requests item #12628, was opened at 2007-07-27 05:33 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=12628&group_id=797 Category: None Group: None Status: Open Priority: 3 Submitted By: Dan North (tastapod) Assigned to: Nobody (None) Summary: Integrate rbehave into rspec Initial Comment: rbehave is a story/scenario description framework that describes behaviour for an application in the same way that rspec describes behaviour for objects. It would make sense for rspec to contain rbehave in a "story" module (spec/story) so that rspec becomes a "full stack" BDD framework. This initial feature request is simply to bring rbehave into the rspec project. Further work (ie. further feature requests) would create closer integration between the two, and providing a way to describe Rails behaviour at a story/scenario level. ---------------------------------------------------------------------- Comment By: Ian Dees (undees) Date: 2007-07-28 08:48 Message: I like the idea. As long as it doesn't invalidate all those GUI tests I've written in RSpec.... ;-) ---------------------------------------------------------------------- Comment By: Michael Klishin (michaelklishin) Date: 2007-07-28 04:14 Message: RBehave is great, plus one for it. The only problem is that it is poorly documented. And yes, I'd like to submit a patch when I get deep enough in the source. ---------------------------------------------------------------------- Comment By: Yurii Rashkovskii (yrashk) Date: 2007-07-28 03:59 Message: First of all, thank you for your nice DSL Then, here is a draft version of code that isolates scenarios into ActiveRecord transactions (extract from my project) class ActiveRecordSafetyListener include Singleton def scenario_started(*args) unless Rails::VERSION::STRING == "1.1.6" ActiveRecord::Base.send :increment_open_transactions end ActiveRecord::Base.connection.begin_db_transaction end def scenario_succeeded(*args) ActiveRecord::Base.connection.rollback_db_transaction unless Rails::VERSION::STRING == "1.1.6" ActiveRecord::Base.send :decrement_open_transactions end end alias :scenario_pending :scenario_succeeded alias :scenario_failed :scenario_succeeded end class RBehave::Runner::ScenarioRunner def initialize @listeners = [ActiveRecordSafetyListener.instance] end end ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=12628&group_id=797 From marcus at ahnve.com Sun Jul 29 07:38:19 2007 From: marcus at ahnve.com (Marcus Ahnve) Date: Sun, 29 Jul 2007 13:38:19 +0200 Subject: [rspec-devel] merging rbehave into rspec In-Reply-To: <46A9CFED.1020709@tastapod.com> References: <46A9CFED.1020709@tastapod.com> Message-ID: <4d4e79cc0707290438h6c86b4eei11beeeac287501b9@mail.gmail.com> On 7/27/07, Dan North wrote: > [...] > - what do you think? I find rbehave intriguing - it seems to fill in what I always missed in Fit/Fitness > - does anyone want to help me? My knowledge of the inner workings of RSpec is probably too limited, but I will definitely try my best to help out. Cheers /Marcus -- http://marcus.ahnve.net From brian.takita at gmail.com Sun Jul 29 23:20:16 2007 From: brian.takita at gmail.com (Brian Takita) Date: Sun, 29 Jul 2007 20:20:16 -0700 Subject: [rspec-devel] merging rbehave into rspec In-Reply-To: <46A9CFED.1020709@tastapod.com> References: <46A9CFED.1020709@tastapod.com> Message-ID: <1d7ddd110707292020w5ec08657tb4ced0dbb8459021@mail.gmail.com> Fyi, I was planning starting the Behaviour refactoring next week. I don't know how this affects the Rbehave integration at this time. It doesn' On 7/27/07, Dan North wrote: > > Hi folks. > > I've been talking with David Chelimsky and Aslak* about bringing rbehave > and rspec together into a "full stack" BDD framework. The thinking is > roughly this: > > - rspec is about describing and verifying objects and interactions, at the > code level> - rbehave is about describing and verifying stories and scenarios, at the > application level > (from here on I'm calling rspec the object description framework, and > rbehave the story description framework) > > So here's the plan: > > - the object and story frameworks keep their own runners - they are > functionally different although they share some common design concepts > (listeners, renderers, etc.) > - the story framework adopts the object framework's domain vocabulary (so > if rspec calls something a Renderer and rbehave calls the same concept a > Describer, it gets renamed in rbehave to a Renderer) > - the story framework will reuse any identical concepts from the object > framework (so rbehave will use rspec's PendingException, for example) > - the story runner becomes part of rspec's core, in a suitable module > namespace > - all the story runner behaviours are migrated across > - the rbehave rubyforge project is gutted to simply delegate to the rspec > story framework (this is an interim move to retain compatibility) > > The near-term objectives are: > > 1) integrate story description behaviour natively into rspec > 2) support description of Rails behaviour at a story/scenario level > > So: > > - what do you think? > - does anyone want to help me? > - please say yes because I have no idea how to do 2) > > Thanks, > Dan > > * Aslak only has one name - like Cher or Madonna. > > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From brian.takita at gmail.com Sun Jul 29 23:21:21 2007 From: brian.takita at gmail.com (Brian Takita) Date: Sun, 29 Jul 2007 20:21:21 -0700 Subject: [rspec-devel] merging rbehave into rspec In-Reply-To: <1d7ddd110707292020w5ec08657tb4ced0dbb8459021@mail.gmail.com> References: <46A9CFED.1020709@tastapod.com> <1d7ddd110707292020w5ec08657tb4ced0dbb8459021@mail.gmail.com> Message-ID: <1d7ddd110707292021v7370dc23s33de85d4f3fa770b@mail.gmail.com> Sorry, I sent the email too early: It doesn't look like we will collide too much, though. On 7/29/07, Brian Takita wrote: > Fyi, I was planning starting the Behaviour refactoring next week. I > don't know how this affects the Rbehave integration at this time. > > It doesn' > > On 7/27/07, Dan North wrote: > > > > Hi folks. > > > > I've been talking with David Chelimsky and Aslak* about bringing rbehave > > and rspec together into a "full stack" BDD framework. The thinking is > > roughly this: > > > > - rspec is about describing and verifying objects and interactions, at the > > code level> - rbehave is about describing and verifying stories and scenarios, at the > > application level > > (from here on I'm calling rspec the object description framework, and > > rbehave the story description framework) > > > > So here's the plan: > > > > - the object and story frameworks keep their own runners - they are > > functionally different although they share some common design concepts > > (listeners, renderers, etc.) > > - the story framework adopts the object framework's domain vocabulary (so > > if rspec calls something a Renderer and rbehave calls the same concept a > > Describer, it gets renamed in rbehave to a Renderer) > > - the story framework will reuse any identical concepts from the object > > framework (so rbehave will use rspec's PendingException, for example) > > - the story runner becomes part of rspec's core, in a suitable module > > namespace > > - all the story runner behaviours are migrated across > > - the rbehave rubyforge project is gutted to simply delegate to the rspec > > story framework (this is an interim move to retain compatibility) > > > > The near-term objectives are: > > > > 1) integrate story description behaviour natively into rspec > > 2) support description of Rails behaviour at a story/scenario level > > > > So: > > > > - what do you think? > > - does anyone want to help me? > > - please say yes because I have no idea how to do 2) > > > > Thanks, > > Dan > > > > * Aslak only has one name - like Cher or Madonna. > > > > _______________________________________________ > > rspec-devel mailing list > > rspec-devel at rubyforge.org > > http://rubyforge.org/mailman/listinfo/rspec-devel > > > From noreply at rubyforge.org Mon Jul 30 07:53:42 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 30 Jul 2007 07:53:42 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-12682 ] Not correctly aliasing original 'stub!' and 'should_receive' methods for ApplicationController Message-ID: <20070730115342.B9C465240A1B@rubyforge.org> Patches item #12682, was opened at 2007-07-30 13:53 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=12682&group_id=797 Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: Matthijs Langenberg (mlangenberg) Assigned to: Nobody (None) Summary: Not correctly aliasing original 'stub!' and 'should_receive' methods for ApplicationController Initial Comment: Revision 2184 disables controller.should_receive(:render) and controller.stub!(:render), and points to the use of expect_render or stub_render instead. To do this, the original controller's #should_receive and #stub! methods are being aliased, but the aliasing doesn't work like it should. I've attached a fix for the alias and a spec to check if the methods are being defined. However, there might be a need for a more 'real life' spec using the sample rails application, but that just depends on how long the deprecation message will be visible. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=12682&group_id=797 From noreply at rubyforge.org Mon Jul 30 08:17:26 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 30 Jul 2007 08:17:26 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-12682 ] Not correctly aliasing original 'stub!' and 'should_receive' methods for ApplicationController Message-ID: <20070730121726.961725240A1B@rubyforge.org> Patches item #12682, was opened at 2007-07-30 11:53 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=12682&group_id=797 Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: Matthijs Langenberg (mlangenberg) Assigned to: Nobody (None) Summary: Not correctly aliasing original 'stub!' and 'should_receive' methods for ApplicationController Initial Comment: Revision 2184 disables controller.should_receive(:render) and controller.stub!(:render), and points to the use of expect_render or stub_render instead. To do this, the original controller's #should_receive and #stub! methods are being aliased, but the aliasing doesn't work like it should. I've attached a fix for the alias and a spec to check if the methods are being defined. However, there might be a need for a more 'real life' spec using the sample rails application, but that just depends on how long the deprecation message will be visible. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-07-30 12:17 Message: Is something broken? What is incorrect about the existing implementation? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=12682&group_id=797 From noreply at rubyforge.org Mon Jul 30 08:26:52 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 30 Jul 2007 08:26:52 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-12682 ] Not correctly aliasing original 'stub!' and 'should_receive' methods for ApplicationController Message-ID: <20070730122652.7BF465240A2F@rubyforge.org> Patches item #12682, was opened at 2007-07-30 13:53 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=12682&group_id=797 Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: Matthijs Langenberg (mlangenberg) Assigned to: Nobody (None) Summary: Not correctly aliasing original 'stub!' and 'should_receive' methods for ApplicationController Initial Comment: Revision 2184 disables controller.should_receive(:render) and controller.stub!(:render), and points to the use of expect_render or stub_render instead. To do this, the original controller's #should_receive and #stub! methods are being aliased, but the aliasing doesn't work like it should. I've attached a fix for the alias and a spec to check if the methods are being defined. However, there might be a need for a more 'real life' spec using the sample rails application, but that just depends on how long the deprecation message will be visible. ---------------------------------------------------------------------- >Comment By: Matthijs Langenberg (mlangenberg) Date: 2007-07-30 14:26 Message: David, I believe the existing implementation defines the methods on the wrong class. After I updated to r2184 (from 2183) I wasn't able to call controller.should_receive or controller.stub! anymore. See the following pastie: http://p.caboo.se/83407 Also a chat at #rspec revealed that someone else had the very same problem, fixed by using the attached patch. If you need more information, please ask. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-07-30 14:17 Message: Is something broken? What is incorrect about the existing implementation? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=12682&group_id=797 From noreply at rubyforge.org Mon Jul 30 08:31:58 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 30 Jul 2007 08:31:58 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-12682 ] Not correctly aliasing original 'stub!' and 'should_receive' methods for ApplicationController Message-ID: <20070730123158.6B05E5240A41@rubyforge.org> Patches item #12682, was opened at 2007-07-30 11:53 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=12682&group_id=797 Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: Matthijs Langenberg (mlangenberg) Assigned to: Nobody (None) Summary: Not correctly aliasing original 'stub!' and 'should_receive' methods for ApplicationController Initial Comment: Revision 2184 disables controller.should_receive(:render) and controller.stub!(:render), and points to the use of expect_render or stub_render instead. To do this, the original controller's #should_receive and #stub! methods are being aliased, but the aliasing doesn't work like it should. I've attached a fix for the alias and a spec to check if the methods are being defined. However, there might be a need for a more 'real life' spec using the sample rails application, but that just depends on how long the deprecation message will be visible. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-07-30 12:31 Message: That's hilarious - I didn't even know there was an #rspec channel. I'll see you there some time. :) I'll take a closer look.... ---------------------------------------------------------------------- Comment By: Matthijs Langenberg (mlangenberg) Date: 2007-07-30 12:26 Message: David, I believe the existing implementation defines the methods on the wrong class. After I updated to r2184 (from 2183) I wasn't able to call controller.should_receive or controller.stub! anymore. See the following pastie: http://p.caboo.se/83407 Also a chat at #rspec revealed that someone else had the very same problem, fixed by using the attached patch. If you need more information, please ask. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-07-30 12:17 Message: Is something broken? What is incorrect about the existing implementation? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=12682&group_id=797 From noreply at rubyforge.org Mon Jul 30 08:50:53 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 30 Jul 2007 08:50:53 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-12682 ] Not correctly aliasing original 'stub!' and 'should_receive' methods for ApplicationController Message-ID: <20070730125053.DDEA25240A1C@rubyforge.org> Patches item #12682, was opened at 2007-07-30 11:53 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=12682&group_id=797 Category: rails plugin Group: None >Status: Closed >Resolution: Accepted Priority: 3 Submitted By: Matthijs Langenberg (mlangenberg) >Assigned to: David Chelimsky (dchelimsky) Summary: Not correctly aliasing original 'stub!' and 'should_receive' methods for ApplicationController Initial Comment: Revision 2184 disables controller.should_receive(:render) and controller.stub!(:render), and points to the use of expect_render or stub_render instead. To do this, the original controller's #should_receive and #stub! methods are being aliased, but the aliasing doesn't work like it should. I've attached a fix for the alias and a spec to check if the methods are being defined. However, there might be a need for a more 'real life' spec using the sample rails application, but that just depends on how long the deprecation message will be visible. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-07-30 12:50 Message: I applied your fix, but with different examples to drive it - see controller_spec_spec.rb. Applied to r2185. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-07-30 12:31 Message: That's hilarious - I didn't even know there was an #rspec channel. I'll see you there some time. :) I'll take a closer look.... ---------------------------------------------------------------------- Comment By: Matthijs Langenberg (mlangenberg) Date: 2007-07-30 12:26 Message: David, I believe the existing implementation defines the methods on the wrong class. After I updated to r2184 (from 2183) I wasn't able to call controller.should_receive or controller.stub! anymore. See the following pastie: http://p.caboo.se/83407 Also a chat at #rspec revealed that someone else had the very same problem, fixed by using the attached patch. If you need more information, please ask. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-07-30 12:17 Message: Is something broken? What is incorrect about the existing implementation? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=12682&group_id=797 From noreply at rubyforge.org Mon Jul 30 08:58:02 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 30 Jul 2007 08:58:02 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-12611 ] should_not redirect_to implementation Message-ID: <20070730125803.249E05240A1C@rubyforge.org> Patches item #12611, was opened at 2007-07-27 01:44 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=12611&group_id=797 Category: rails plugin Group: None >Status: Closed >Resolution: Accepted Priority: 3 Submitted By: Yurii Rashkovskii (yrashk) >Assigned to: David Chelimsky (dchelimsky) Summary: should_not redirect_to implementation Initial Comment: Here is an extract from my source code it "should allow authenticated user to access '#{action}'" do @user = mock_user_authentication(:id => 1, :identity_url => "http://openid.server/yrashk", :queues => []) get action, params assigns[:current_user].should == @user flash[:error].should be_nil response.should_not redirect_to(login_url) end Depending on action, it is either successful response or response that redirects somewhere (but not to login, since user is "proven" to be authenticated). In this example, I really don't want to care, whether it was successful response or redirection to somewhere, until it is not a redirection to login URL. -- Was discussed with David on maillist, he proposed to prepare a patch. Here it is. It is seems to be working, though can't be sure for 100% ? almost 5AM. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-07-30 12:58 Message: Applied to r2186. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=12611&group_id=797 From noreply at rubyforge.org Mon Jul 30 13:03:25 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 30 Jul 2007 13:03:25 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-12694 ] DrbCommandLine is very slow to start the DRb service Message-ID: <20070730170326.38B7F5240B13@rubyforge.org> Bugs item #12694, was opened at 2007-07-30 10:03 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=12694&group_id=797 Category: Autotest Group: None Status: Open Resolution: None Priority: 3 Submitted By: Brian Takita (btakita) Assigned to: Nobody (None) Summary: DrbCommandLine is very slow to start the DRb service Initial Comment: If we explicitly put in the port when calling start_service, it becomes MUCH faster. e.g. DRb.start_service "druby://localhost:8990" ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=12694&group_id=797 From noreply at rubyforge.org Mon Jul 30 13:04:50 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 30 Jul 2007 13:04:50 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-12694 ] DrbCommandLine is very slow to start the DRb service Message-ID: <20070730170450.C10195240B15@rubyforge.org> Bugs item #12694, was opened at 2007-07-30 10:03 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=12694&group_id=797 Category: Autotest Group: None Status: Open Resolution: None Priority: 3 Submitted By: Brian Takita (btakita) Assigned to: Nobody (None) Summary: DrbCommandLine is very slow to start the DRb service Initial Comment: If we explicitly put in the port when calling start_service, it becomes MUCH faster. e.g. DRb.start_service "druby://localhost:8990" ---------------------------------------------------------------------- >Comment By: Brian Takita (btakita) Date: 2007-07-30 10:04 Message: I'm using Ruby 1.8.6 on Ubunutu 7.0.4 ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=12694&group_id=797 From noreply at rubyforge.org Mon Jul 30 16:03:20 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 30 Jul 2007 16:03:20 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-12694 ] DrbCommandLine is very slow to start the DRb service Message-ID: <20070730200320.F1C075240DC4@rubyforge.org> Bugs item #12694, was opened at 2007-07-30 10:03 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=12694&group_id=797 Category: Autotest Group: None Status: Open Resolution: None Priority: 3 Submitted By: Brian Takita (btakita) Assigned to: Nobody (None) Summary: DrbCommandLine is very slow to start the DRb service Initial Comment: If we explicitly put in the port when calling start_service, it becomes MUCH faster. e.g. DRb.start_service "druby://localhost:8990" ---------------------------------------------------------------------- >Comment By: Brian Takita (btakita) Date: 2007-07-30 13:03 Message: It seems like it is an issue with creating a socket. I have this issue with both of my Ubuntu machines, so I believe that this has to do with the default Ubuntu configuration. I've seen some problems relating to /etc/hosts, but I have not figured it out yet. ---------------------------------------------------------------------- Comment By: Brian Takita (btakita) Date: 2007-07-30 10:04 Message: I'm using Ruby 1.8.6 on Ubunutu 7.0.4 ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=12694&group_id=797 From noreply at rubyforge.org Mon Jul 30 16:04:41 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 30 Jul 2007 16:04:41 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-12698 ] ::Dispatcher.reset_application! causes exception Message-ID: <20070730200441.BAF355240DC2@rubyforge.org> Bugs item #12698, was opened at 2007-07-30 13:04 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=12698&group_id=797 Category: Autotest Group: None Status: Open Resolution: None Priority: 3 Submitted By: Brian Takita (btakita) Assigned to: Nobody (None) Summary: ::Dispatcher.reset_application! causes exception Initial Comment: Here is the backtrace. This happens in spec_server.rb (druby://localhost:8989) /usr/local/lib/ruby/gems/1.8/gems/activerecord-1.15.3/lib/active_record/connection_adapters/abstract/connection_specification.rb:93:in `clear_reloadable_connections!': undefined method `requires_reloading?' for {}:Hash (NoMethodError) from (druby://localhost:8989) /usr/local/lib/ruby/gems/1.8/gems/activerecord-1.15.3/lib/active_record/connection_adapters/abstract/connection_specification.rb:92:in `each' from (druby://localhost:8989) /usr/local/lib/ruby/gems/1.8/gems/activerecord-1.15.3/lib/active_record/connection_adapters/abstract/connection_specification.rb:92:in `clear_reloadable_connections!' from (druby://localhost:8989) /usr/local/lib/ruby/gems/1.8/gems/rails-1.2.3/lib/dispatcher.rb:65:in `reset_application!' from (druby://localhost:8989) ./script/spec_server:21:in `run' from /usr/local/lib/ruby/gems/1.8/gems/rspec-1.0.5/lib/spec/runner/drb_command_line.rb:13:in `run' from /usr/local/lib/ruby/gems/1.8/gems/rspec-1.0.5/lib/spec/runner/option_parser.rb:188:in `parse_drb' from /usr/local/lib/ruby/gems/1.8/gems/rspec-1.0.5/lib/spec/runner/option_parser.rb:147:in `parse' from /usr/local/lib/ruby/1.8/optparse.rb:1260:in `call' ... 8 levels... from /usr/local/lib/ruby/gems/1.8/gems/rspec-1.0.5/lib/spec/runner/command_line.rb:14:in `run' from /usr/local/lib/ruby/gems/1.8/gems/rspec-1.0.5/bin/spec:3 from /usr/local/bin/spec:16:in `load' from /usr/local/bin/spec:16 ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=12698&group_id=797 From noreply at rubyforge.org Mon Jul 30 16:05:08 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 30 Jul 2007 16:05:08 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-12698 ] ::Dispatcher.reset_application! causes exception Message-ID: <20070730200508.D36C65240DC2@rubyforge.org> Bugs item #12698, was opened at 2007-07-30 13:04 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=12698&group_id=797 Category: Autotest Group: None Status: Open Resolution: None Priority: 3 Submitted By: Brian Takita (btakita) Assigned to: Nobody (None) Summary: ::Dispatcher.reset_application! causes exception Initial Comment: Here is the backtrace. This happens in spec_server.rb (druby://localhost:8989) /usr/local/lib/ruby/gems/1.8/gems/activerecord-1.15.3/lib/active_record/connection_adapters/abstract/connection_specification.rb:93:in `clear_reloadable_connections!': undefined method `requires_reloading?' for {}:Hash (NoMethodError) from (druby://localhost:8989) /usr/local/lib/ruby/gems/1.8/gems/activerecord-1.15.3/lib/active_record/connection_adapters/abstract/connection_specification.rb:92:in `each' from (druby://localhost:8989) /usr/local/lib/ruby/gems/1.8/gems/activerecord-1.15.3/lib/active_record/connection_adapters/abstract/connection_specification.rb:92:in `clear_reloadable_connections!' from (druby://localhost:8989) /usr/local/lib/ruby/gems/1.8/gems/rails-1.2.3/lib/dispatcher.rb:65:in `reset_application!' from (druby://localhost:8989) ./script/spec_server:21:in `run' from /usr/local/lib/ruby/gems/1.8/gems/rspec-1.0.5/lib/spec/runner/drb_command_line.rb:13:in `run' from /usr/local/lib/ruby/gems/1.8/gems/rspec-1.0.5/lib/spec/runner/option_parser.rb:188:in `parse_drb' from /usr/local/lib/ruby/gems/1.8/gems/rspec-1.0.5/lib/spec/runner/option_parser.rb:147:in `parse' from /usr/local/lib/ruby/1.8/optparse.rb:1260:in `call' ... 8 levels... from /usr/local/lib/ruby/gems/1.8/gems/rspec-1.0.5/lib/spec/runner/command_line.rb:14:in `run' from /usr/local/lib/ruby/gems/1.8/gems/rspec-1.0.5/bin/spec:3 from /usr/local/bin/spec:16:in `load' from /usr/local/bin/spec:16 ---------------------------------------------------------------------- >Comment By: Brian Takita (btakita) Date: 2007-07-30 13:05 Message: Here is my redefined run method that fixes this issue: module Spec module Runner class RailsSpecServer def run(args, stderr, stdout) $stdout = stdout $stderr = stderr Dependencies.mechanism = :load Dependencies.clear ::Spec::Runner::CommandLine.run(args, stderr, stdout, false, true) end end end end ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=12698&group_id=797 From noreply at rubyforge.org Mon Jul 30 16:09:31 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 30 Jul 2007 16:09:31 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-12699 ] Shared Specs are not reloaded when using DRb Message-ID: <20070730200931.E208A5240DC1@rubyforge.org> Bugs item #12699, was opened at 2007-07-30 13:09 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=12699&group_id=797 Category: Autotest Group: None Status: Open Resolution: None Priority: 3 Submitted By: Brian Takita (btakita) Assigned to: Nobody (None) Summary: Shared Specs are not reloaded when using DRb Initial Comment: If I change the spec, it does not reload on the spec_server. To reproduce, make a spec, create a spec and run it using the spec_server. describe "DRb", :shared => true do it "should reload shared specs" do true.should == false end end describe "DRb reloading" do it_should_behave_like "DRb" end Now edit the shared spec: describe "DRb", :shared => true do it "should reload shared specs" do true.should == true end end There will still be a failure. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=12699&group_id=797 From noreply at rubyforge.org Mon Jul 30 16:12:05 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 30 Jul 2007 16:12:05 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-12699 ] Shared Specs are not reloaded when using DRb Message-ID: <20070730201205.3AB515240DC8@rubyforge.org> Bugs item #12699, was opened at 2007-07-30 13:09 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=12699&group_id=797 Category: Autotest Group: None Status: Open Resolution: None Priority: 3 Submitted By: Brian Takita (btakita) Assigned to: Nobody (None) Summary: Shared Specs are not reloaded when using DRb Initial Comment: If I change the spec, it does not reload on the spec_server. To reproduce, make a spec, create a spec and run it using the spec_server. describe "DRb", :shared => true do it "should reload shared specs" do true.should == false end end describe "DRb reloading" do it_should_behave_like "DRb" end Now edit the shared spec: describe "DRb", :shared => true do it "should reload shared specs" do true.should == true end end There will still be a failure. ---------------------------------------------------------------------- >Comment By: Brian Takita (btakita) Date: 2007-07-30 13:12 Message: To fix this for my project I edited spec_server: module Spec module Runner class RailsSpecServer def run(args, stderr, stdout) $stdout = stdout $stderr = stderr Spec::DSL::Behaviour.shared_behaviours.clear Dependencies.mechanism = :load Dependencies.clear ::Spec::Runner::CommandLine.run(args, stderr, stdout, false, true) end end end end ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=12699&group_id=797 From noreply at rubyforge.org Mon Jul 30 17:15:46 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 30 Jul 2007 17:15:46 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-12701 ] Allow checking of content captured with content_for in view specs Message-ID: <20070730211546.9EBD75240DCB@rubyforge.org> Patches item #12701, was opened at 2007-07-30 23:15 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=12701&group_id=797 Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: Jens Kr?mer (jkraemer) Assigned to: Nobody (None) Summary: Allow checking of content captured with content_for in view specs Initial Comment: This patch extends ActionController::TestResponse with an accessor to get any content rendered inside a content_for block so it can easily be checked like the template's main content: <% content_for :sidebar do %>

The sidebar

<% end %> it "should render the sidebar" do response[:sidebar].should have_tag('h2', 'The sidebar') end ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=12701&group_id=797 From dan at tastapod.com Mon Jul 30 17:18:13 2007 From: dan at tastapod.com (Dan North) Date: Mon, 30 Jul 2007 22:18:13 +0100 Subject: [rspec-devel] merging rbehave into rspec In-Reply-To: <1d7ddd110707292021v7370dc23s33de85d4f3fa770b@mail.gmail.com> References: <46A9CFED.1020709@tastapod.com> <1d7ddd110707292020w5ec08657tb4ced0dbb8459021@mail.gmail.com> <1d7ddd110707292021v7370dc23s33de85d4f3fa770b@mail.gmail.com> Message-ID: <46AE5595.6090407@tastapod.com> Hi Brian. Thanks for the heads-up. If you're talking about taking the eval magic out of Behaviour, then I think we should be ok. Again, although rbehave uses a similar model, it needs its own instance_eval magic because of the way it processes multiple scenarios within a story. You're welcome to steal the design - and even factor out common code if there is any. It works like this: Story 'a story', ... do # shared code from here -> def shared_method # ... end @some_shared_var = 'hello' include SomeSharedModule # -> to here Scenario 'scenario 1' do # ... end Scenario 'scenario 2' do # ... end end For each scenario, it takes an instance of an object (either an Object or your own custom class, say a Rails IntegrationTestCase) and instance_evals the Story block, but with the Scenario method redefined to do nothing. This has the effect of making sure any shared code such as support methods are defined or modules included etc. Then it instance_evals the Scenario block for that scenario in the same instance, which now has access to the support methods, instance vars and included modules. I'm pretty sure the same thing would work for the examples (it-blocks) within each describe block, but I haven't looked too closely. The rbehave stuff will hopefully be in the rspec codebase by the end of the week in a new rspec/story module. I should have some time on Friday to do this. (The parameterised steps - the Given, When and Then blocks - are more devious :) David is about to push out a new rspec build, so I will hold off committing anything until after that, but it should tie in quite nicely in terms of timing. Cheers, Dan Brian Takita wrote: > Sorry, I sent the email too early: > > It doesn't look like we will collide too much, though. > > On 7/29/07, Brian Takita wrote: > >> Fyi, I was planning starting the Behaviour refactoring next week. I >> don't know how this affects the Rbehave integration at this time. >> >> It doesn' >> >> On 7/27/07, Dan North wrote: >> >>> Hi folks. >>> >>> I've been talking with David Chelimsky and Aslak* about bringing rbehave >>> and rspec together into a "full stack" BDD framework. The thinking is >>> roughly this: >>> >>> - rspec is about describing and verifying objects and interactions, at the >>> code level> - rbehave is about describing and verifying stories and scenarios, at the >>> application level >>> (from here on I'm calling rspec the object description framework, and >>> rbehave the story description framework) >>> >>> So here's the plan: >>> >>> - the object and story frameworks keep their own runners - they are >>> functionally different although they share some common design concepts >>> (listeners, renderers, etc.) >>> - the story framework adopts the object framework's domain vocabulary (so >>> if rspec calls something a Renderer and rbehave calls the same concept a >>> Describer, it gets renamed in rbehave to a Renderer) >>> - the story framework will reuse any identical concepts from the object >>> framework (so rbehave will use rspec's PendingException, for example) >>> - the story runner becomes part of rspec's core, in a suitable module >>> namespace >>> - all the story runner behaviours are migrated across >>> - the rbehave rubyforge project is gutted to simply delegate to the rspec >>> story framework (this is an interim move to retain compatibility) >>> >>> The near-term objectives are: >>> >>> 1) integrate story description behaviour natively into rspec >>> 2) support description of Rails behaviour at a story/scenario level >>> >>> So: >>> >>> - what do you think? >>> - does anyone want to help me? >>> - please say yes because I have no idea how to do 2) >>> >>> Thanks, >>> Dan >>> >>> * Aslak only has one name - like Cher or Madonna. >>> >>> _______________________________________________ >>> 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: http://rubyforge.org/pipermail/rspec-devel/attachments/20070730/0432597f/attachment-0001.html From noreply at rubyforge.org Mon Jul 30 17:22:36 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 30 Jul 2007 17:22:36 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-12703 ] pre_commit task only picks up files after they have been svn added Message-ID: <20070730212236.E39C0A970005@rubyforge.org> Bugs item #12703, was opened at 2007-07-30 23:22 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=12703&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Jens Kr?mer (jkraemer) Assigned to: Nobody (None) Summary: pre_commit task only picks up files after they have been svn added Initial Comment: Since pre_commit uses svn export to install rspec and rspec_on_rails into the rails project before running tests, one is required to 'svn add' any new files so they actually are included in the test run. This should at least be mentioned at http://rspec.rubyforge.org/community/contribute.html to save potential contributors some time :-) ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=12703&group_id=797 From noreply at rubyforge.org Mon Jul 30 22:32:52 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 30 Jul 2007 22:32:52 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-12710 ] Error messages on multiple lines Message-ID: <20070731023252.4C59FA970017@rubyforge.org> Feature Requests item #12710, was opened at 2007-07-30 19:32 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=12710&group_id=797 Category: expectation module Group: None Status: Open Priority: 3 Submitted By: Brian Takita (btakita) Assigned to: Nobody (None) Summary: Error messages on multiple lines Initial Comment: Currently its: expected got This makes it very difficult to see the differences once the textual length of the objects are longer than the length of the console. It would be MUCH easier to read if the output were formatted on multiple lines: expected got ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=12710&group_id=797 From noreply at rubyforge.org Mon Jul 30 23:10:04 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 30 Jul 2007 23:10:04 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-12710 ] Error messages on multiple lines Message-ID: <20070731031005.2D4ECA970018@rubyforge.org> Feature Requests item #12710, was opened at 2007-07-31 02:32 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=12710&group_id=797 Category: expectation module Group: None Status: Open Priority: 3 Submitted By: Brian Takita (btakita) Assigned to: Nobody (None) Summary: Error messages on multiple lines Initial Comment: Currently its: expected got This makes it very difficult to see the differences once the textual length of the objects are longer than the length of the console. It would be MUCH easier to read if the output were formatted on multiple lines: expected got ---------------------------------------------------------------------- Comment By: Kyle Hargraves (philodespotos) Date: 2007-07-31 03:10 Message: This is actually already in trunk: 'Foo should == #' expected: # got: # In a -users thread (maybe last month?), someone mentioned it'd also be nice to have semi-intelligent use of pretty printing if the inspect string for the object were obscenely long. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=12710&group_id=797 From noreply at rubyforge.org Tue Jul 31 06:17:23 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 31 Jul 2007 06:17:23 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-12714 ] helper spec not finding rails core helpers Message-ID: <20070731101723.70E665240964@rubyforge.org> Bugs item #12714, was opened at 2007-07-31 10:17 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=12714&group_id=797 Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: David Chelimsky (dchelimsky) Assigned to: David Chelimsky (dchelimsky) Summary: helper spec not finding rails core helpers Initial Comment: See http://rubyforge.org/pipermail/rspec-users/2007-July/002511.html. Not all of the helper modules are included in helper examples. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=12714&group_id=797 From noreply at rubyforge.org Tue Jul 31 06:18:49 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 31 Jul 2007 06:18:49 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-12714 ] helper spec not finding rails core helpers Message-ID: <20070731101849.21CD25240964@rubyforge.org> Bugs item #12714, was opened at 2007-07-31 10:17 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=12714&group_id=797 Category: rails plugin Group: None >Status: Closed >Resolution: Accepted Priority: 3 Submitted By: David Chelimsky (dchelimsky) Assigned to: David Chelimsky (dchelimsky) Summary: helper spec not finding rails core helpers Initial Comment: See http://rubyforge.org/pipermail/rspec-users/2007-July/002511.html. Not all of the helper modules are included in helper examples. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-07-31 10:18 Message: Fixed in trunk r2187 ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=12714&group_id=797 From michael.s.klishin at gmail.com Tue Jul 31 11:05:19 2007 From: michael.s.klishin at gmail.com (Michael Klishin) Date: Tue, 31 Jul 2007 19:05:19 +0400 Subject: [rspec-devel] merging rbehave into rspec In-Reply-To: <46A9CFED.1020709@tastapod.com> References: <46A9CFED.1020709@tastapod.com> Message-ID: <709de1d10707310805g732e3ac0k52731f7ffa936ac6@mail.gmail.com> My level of knowledge of RSpec internals is averange but I'd like to help at least with documentation. Fair enough? On 27/07/07, Dan North wrote: > - does anyone want to help me? > - please say yes because I have no idea how to do 2) -- MK From noreply at rubyforge.org Tue Jul 31 12:05:42 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 31 Jul 2007 12:05:42 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-12719 ] rspec_on_rails should not include pagination helper Message-ID: <20070731160542.B8F7A5240ABA@rubyforge.org> Patches item #12719, was opened at 2007-07-31 18:05 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=12719&group_id=797 Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: Matthijs Langenberg (mlangenberg) Assigned to: Nobody (None) Summary: rspec_on_rails should not include pagination helper Initial Comment: Pagination is being removed from Rails and is no longer being maintained. Therefor rspec_on_rails shouldn't try to include it. Currently it raises a "NameError: uninitialized constant ActionView::Helpers::PaginationHelper". ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=12719&group_id=797 From noreply at rubyforge.org Tue Jul 31 12:08:46 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 31 Jul 2007 12:08:46 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-12719 ] rspec_on_rails should not include pagination helper Message-ID: <20070731160847.1AF6A5240ADB@rubyforge.org> Patches item #12719, was opened at 2007-07-31 16:05 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=12719&group_id=797 Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: Matthijs Langenberg (mlangenberg) Assigned to: Nobody (None) Summary: rspec_on_rails should not include pagination helper Initial Comment: Pagination is being removed from Rails and is no longer being maintained. Therefor rspec_on_rails shouldn't try to include it. Currently it raises a "NameError: uninitialized constant ActionView::Helpers::PaginationHelper". ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-07-31 16:08 Message: We'll need it to remain included for Rails 1.2.1-1.2.3. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=12719&group_id=797 From noreply at rubyforge.org Tue Jul 31 14:05:49 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 31 Jul 2007 14:05:49 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-12719 ] rspec_on_rails should not include pagination helper Message-ID: <20070731180550.102C9A970015@rubyforge.org> Patches item #12719, was opened at 2007-07-31 18:05 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=12719&group_id=797 Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: Matthijs Langenberg (mlangenberg) Assigned to: Nobody (None) Summary: rspec_on_rails should not include pagination helper Initial Comment: Pagination is being removed from Rails and is no longer being maintained. Therefor rspec_on_rails shouldn't try to include it. Currently it raises a "NameError: uninitialized constant ActionView::Helpers::PaginationHelper". ---------------------------------------------------------------------- >Comment By: Matthijs Langenberg (mlangenberg) Date: 2007-07-31 20:05 Message: Oops, just overlooked the fact that the RSpec trunk is going to be used with rails versions other than the current edge. If you want I'll try to search for a solution, because I need it to work with edge rails anyway. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-07-31 18:08 Message: We'll need it to remain included for Rails 1.2.1-1.2.3. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=12719&group_id=797 From noreply at rubyforge.org Tue Jul 31 14:08:27 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 31 Jul 2007 14:08:27 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-12719 ] rspec_on_rails should not include pagination helper Message-ID: <20070731180827.EED64A970015@rubyforge.org> Patches item #12719, was opened at 2007-07-31 16:05 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=12719&group_id=797 Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: Matthijs Langenberg (mlangenberg) Assigned to: Nobody (None) Summary: rspec_on_rails should not include pagination helper Initial Comment: Pagination is being removed from Rails and is no longer being maintained. Therefor rspec_on_rails shouldn't try to include it. Currently it raises a "NameError: uninitialized constant ActionView::Helpers::PaginationHelper". ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-07-31 18:08 Message: Please. Thanks. ---------------------------------------------------------------------- Comment By: Matthijs Langenberg (mlangenberg) Date: 2007-07-31 18:05 Message: Oops, just overlooked the fact that the RSpec trunk is going to be used with rails versions other than the current edge. If you want I'll try to search for a solution, because I need it to work with edge rails anyway. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-07-31 16:08 Message: We'll need it to remain included for Rails 1.2.1-1.2.3. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=12719&group_id=797 From dan at tastapod.com Tue Jul 31 14:13:09 2007 From: dan at tastapod.com (Dan North) Date: Tue, 31 Jul 2007 19:13:09 +0100 Subject: [rspec-devel] merging rbehave into rspec In-Reply-To: <709de1d10707310805g732e3ac0k52731f7ffa936ac6@mail.gmail.com> References: <46A9CFED.1020709@tastapod.com> <709de1d10707310805g732e3ac0k52731f7ffa936ac6@mail.gmail.com> Message-ID: <46AF7BB5.90404@tastapod.com> I'm not going to reject any offers of help :) Seriously though, the story stuff is subtly different from the object description framework, so any help with documentation will be very gratefully received. Cheers, Dan Michael Klishin wrote: > My level of knowledge of RSpec internals is averange but I'd like to > help at least with documentation. Fair enough? > > On 27/07/07, Dan North wrote: > > >> - does anyone want to help me? >> - please say yes because I have no idea how to do 2) >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20070731/9f494d0d/attachment.html From noreply at rubyforge.org Tue Jul 31 15:56:24 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 31 Jul 2007 15:56:24 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-12719 ] rspec_on_rails should not include pagination helper Message-ID: <20070731195624.0DC5E5240C69@rubyforge.org> Patches item #12719, was opened at 2007-07-31 16:05 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=12719&group_id=797 Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: Matthijs Langenberg (mlangenberg) Assigned to: Nobody (None) Summary: rspec_on_rails should not include pagination helper Initial Comment: Pagination is being removed from Rails and is no longer being maintained. Therefor rspec_on_rails shouldn't try to include it. Currently it raises a "NameError: uninitialized constant ActionView::Helpers::PaginationHelper". ---------------------------------------------------------------------- Comment By: Carl Porth (badcarl) Date: 2007-07-31 19:56 Message: Why not use the same kind of functionality that ActionView::Base uses to load the helpers? In rails/actionpack/lib/action_view/base.rb there is the method: def self.load_helpers #:nodoc: Dir.entries("#{File.dirname(__FILE__)}/helpers").sort.each do |file| next unless file =~ /^([a-z][a-z_]*_helper).rb$/ require "action_view/helpers/#{$1}" helper_module_name = $1.camelize if Helpers.const_defined?(helper_module_name) include Helpers.const_get(helper_module_name) end end end ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-07-31 18:08 Message: Please. Thanks. ---------------------------------------------------------------------- Comment By: Matthijs Langenberg (mlangenberg) Date: 2007-07-31 18:05 Message: Oops, just overlooked the fact that the RSpec trunk is going to be used with rails versions other than the current edge. If you want I'll try to search for a solution, because I need it to work with edge rails anyway. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-07-31 16:08 Message: We'll need it to remain included for Rails 1.2.1-1.2.3. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=12719&group_id=797 From aslak.hellesoy at gmail.com Tue Jul 31 16:15:31 2007 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Tue, 31 Jul 2007 22:15:31 +0200 Subject: [rspec-devel] Simplifying Behaviour in Rspec In-Reply-To: <46A7CB64.3070802@tastapod.com> References: <1d7ddd110707251333p1ea14707l53a01d4fe33065ff@mail.gmail.com> <57c63afe0707251359q56fcdd18g77c3be5cc6975aeb@mail.gmail.com> <46A7CB64.3070802@tastapod.com> Message-ID: <8d961d900707311315p6b72e6b2la25855a1d0d5a16b@mail.gmail.com> On 7/26/07, Dan North wrote: > > +1 from someone who's about to dive into rspec's internals and see how much > he can reuse in rbehave :) > > Simple is good. > +1 Good isn't simple ;-) > > > David Chelimsky wrote: > On 7/25/07, Brian Takita wrote: > > > I remember that much of Behaviour's complexity put in place to reuse > Rails fixtures. > That includes the inherit method and the dynamic class builder. > BehaviourEval.derive_execution_context_class_from_behaviour_superclass > > Since we now call Test::Unit's setup and teardown in before and after > blocks, we can compose in a Test::Unit::TestCase instance to call > setup and teardown on. > This would make the dynamic class inherit from Test::Unit unnecessary. > > In fact, I don't think there is any other reason to use BehaviorEval > to create a Dynamic class. > Since that is the case, we can probably use class and instance methods > for Behaviour and remove BehaviourEval from the loop. > This would simplify things. > > What do you all think about this? > Are there extensions out there that this would break? > > This would be a major change to Rspec's internals, so please speak up. > > FYI - Brian and I have discussed this a bit. The only users this might > affect are those who've written extensions that extend or talk > directly to Behaviour or BehaviourEval and anyone who is using the > "inherit" method in examples. My sense is that this should be a VERY > limited group, if any at all. If you are in this group, we need to > hear from you. > > The benefits of this change would be enormous, because it would > greatly simplify RSpec's internals, making it much easier to > modify/maintain. > > +1 (at least) > > David > > > > > Thank you, > Brian > _______________________________________________ > 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 > From noreply at rubyforge.org Tue Jul 31 16:39:14 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 31 Jul 2007 16:39:14 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-12722 ] the alternate file command does not work in rails views due to scope Message-ID: <20070731203914.4FEF45240C07@rubyforge.org> Patches item #12722, was opened at 2007-07-31 20:39 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=12722&group_id=797 Category: RSpec.tmbundle Group: None Status: Open Resolution: None Priority: 3 Submitted By: Carl Porth (badcarl) Assigned to: Aslak Helles?y (aslak_hellesoy) Summary: the alternate file command does not work in rails views due to scope Initial Comment: Here is a tiny patch to add the text.html.ruby scope to the Alternate File comand so it works in rails views. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=12722&group_id=797 From noreply at rubyforge.org Tue Jul 31 16:41:02 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 31 Jul 2007 16:41:02 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-12722 ] the alternate file command does not work in rails views due to scope Message-ID: <20070731204102.35CC85240BBC@rubyforge.org> Patches item #12722, was opened at 2007-07-31 20:39 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=12722&group_id=797 Category: RSpec.tmbundle Group: None Status: Open Resolution: None Priority: 3 Submitted By: Carl Porth (badcarl) >Assigned to: David Chelimsky (dchelimsky) Summary: the alternate file command does not work in rails views due to scope Initial Comment: Here is a tiny patch to add the text.html.ruby scope to the Alternate File comand so it works in rails views. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=12722&group_id=797 From noreply at rubyforge.org Tue Jul 31 16:42:45 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 31 Jul 2007 16:42:45 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-12723 ] Add a second reporter (HTML) to rake tasks Message-ID: <20070731204245.E5B985240CA1@rubyforge.org> Feature Requests item #12723, was opened at 2007-07-31 16:42 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=12723&group_id=797 Category: rails plugin Group: None Status: Open Priority: 4 Submitted By: Aslak Helles?y (aslak_hellesoy) Assigned to: Aslak Helles?y (aslak_hellesoy) Summary: Add a second reporter (HTML) to rake tasks Initial Comment: Easy to do - just do it ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=12723&group_id=797 From noreply at rubyforge.org Tue Jul 31 16:44:35 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 31 Jul 2007 16:44:35 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-12722 ] the alternate file command does not work in rails views due to scope Message-ID: <20070731204435.12E5E5240C07@rubyforge.org> Patches item #12722, was opened at 2007-07-31 20:39 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=12722&group_id=797 Category: RSpec.tmbundle Group: None Status: Open Resolution: None Priority: 3 Submitted By: Carl Porth (badcarl) >Assigned to: Aslak Helles?y (aslak_hellesoy) Summary: the alternate file command does not work in rails views due to scope Initial Comment: Here is a tiny patch to add the text.html.ruby scope to the Alternate File comand so it works in rails views. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=12722&group_id=797 From jake.howerton at gmail.com Tue Jul 31 17:17:56 2007 From: jake.howerton at gmail.com (Jake Howerton) Date: Tue, 31 Jul 2007 17:17:56 -0400 Subject: [rspec-devel] spec_ui wont run multiple files Message-ID: <218a05e40707311417k11263603ta7687910e504685e@mail.gmail.com> Hey Guys, I have been playing w/ spec_ui over the past couple of days and ran into an issue where if I have multiple files that get collected by the rake task, it will just hang after the first one is processed. Everything works fine if I only have one file in the directory or I run them individually. Does before(:all) and after(:all) get called at each describe block? Seems like it might be related to the browser getting killed at the end of the file. I am attempting this with safariwatir. Any help appreciated. Thanks, Jake Howerton From dchelimsky at gmail.com Tue Jul 31 17:21:41 2007 From: dchelimsky at gmail.com (David Chelimsky) Date: Tue, 31 Jul 2007 16:21:41 -0500 Subject: [rspec-devel] spec_ui wont run multiple files In-Reply-To: <218a05e40707311417k11263603ta7687910e504685e@mail.gmail.com> References: <218a05e40707311417k11263603ta7687910e504685e@mail.gmail.com> Message-ID: <57c63afe0707311421o1697b9bw3c60b1edd5f22174@mail.gmail.com> On 7/31/07, Jake Howerton wrote: > Hey Guys, > > I have been playing w/ spec_ui over the past couple of days and ran > into an issue where if I have multiple files that get collected by the > rake task, it will just hang after the first one is processed. > > Everything works fine if I only have one file in the directory or I > run them individually. > > Does before(:all) and after(:all) get called at each describe block? Yes. > Seems like it might be related to the browser getting killed at the > end of the file. I am attempting this with safariwatir. Definitely. I moved killing the browser to at_exit in one project and that worked well. Aslak? How do you deal w/ this issue? > > Any help appreciated. > > Thanks, > > Jake Howerton > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From aslak.hellesoy at gmail.com Tue Jul 31 17:38:27 2007 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Tue, 31 Jul 2007 23:38:27 +0200 Subject: [rspec-devel] spec_ui wont run multiple files In-Reply-To: <57c63afe0707311421o1697b9bw3c60b1edd5f22174@mail.gmail.com> References: <218a05e40707311417k11263603ta7687910e504685e@mail.gmail.com> <57c63afe0707311421o1697b9bw3c60b1edd5f22174@mail.gmail.com> Message-ID: <8d961d900707311438y143da310i9dcc5dbf0eb3884b@mail.gmail.com> On 7/31/07, David Chelimsky wrote: > On 7/31/07, Jake Howerton wrote: > > Hey Guys, > > > > I have been playing w/ spec_ui over the past couple of days and ran > > into an issue where if I have multiple files that get collected by the > > rake task, it will just hang after the first one is processed. > > > > Everything works fine if I only have one file in the directory or I > > run them individually. > > > > Does before(:all) and after(:all) get called at each describe block? > > Yes. > > > Seems like it might be related to the browser getting killed at the > > end of the file. I am attempting this with safariwatir. > Not sure what you mean by "the end of the file". Can you post some relevant code? after and before blocks and any Browser.new and @browser.kill! related code please. > Definitely. I moved killing the browser to at_exit in one project and > that worked well. > That's one solution > Aslak? How do you deal w/ this issue? > IIRC I had an issue that sounds like yours when I kill! ed the @browser in after(:each). This destroys the "connection" to the "browser window", but the @browser ruby object is still there, and now if you try to use it, it's b0rked. This might be why it's hanging. The trick is to never kill! a @browser object that you're planning to use again. HTH, Aslak > > > > Any help appreciated. > > > > Thanks, > > > > Jake Howerton > > _______________________________________________ > > 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 dchelimsky at gmail.com Tue Jul 31 17:41:39 2007 From: dchelimsky at gmail.com (David Chelimsky) Date: Tue, 31 Jul 2007 16:41:39 -0500 Subject: [rspec-devel] spec_ui wont run multiple files In-Reply-To: <8d961d900707311438y143da310i9dcc5dbf0eb3884b@mail.gmail.com> References: <218a05e40707311417k11263603ta7687910e504685e@mail.gmail.com> <57c63afe0707311421o1697b9bw3c60b1edd5f22174@mail.gmail.com> <8d961d900707311438y143da310i9dcc5dbf0eb3884b@mail.gmail.com> Message-ID: <57c63afe0707311441n122a01cex10072d398383663c@mail.gmail.com> On 7/31/07, aslak hellesoy wrote: > The trick is to never kill! a @browser object that you're planning to use again. That sounds like very good advice in general. Unless, of course, by "use" you mean "eat". From mailing_lists at railsnewbie.com Tue Jul 31 17:20:28 2007 From: mailing_lists at railsnewbie.com (Scott Taylor) Date: Tue, 31 Jul 2007 17:20:28 -0400 Subject: [rspec-devel] merging rbehave into rspec In-Reply-To: <46AF7BB5.90404@tastapod.com> References: <46A9CFED.1020709@tastapod.com> <709de1d10707310805g732e3ac0k52731f7ffa936ac6@mail.gmail.com> <46AF7BB5.90404@tastapod.com> Message-ID: I'd be willing to help, whether it is writing code or documenting. Do you have a public svn repos which could be checked out? Scott On Jul 31, 2007, at 2:13 PM, Dan North wrote: On Jul 31, 2007, at 2:13 PM, Dan North wrote: > I'm not going to reject any offers of help :) > > Seriously though, the story stuff is subtly different from the > object description framework, so any help with documentation will > be very gratefully received. > > Cheers, > Dan > > > Michael Klishin wrote: >> My level of knowledge of RSpec internals is averange but I'd like >> to help at least with documentation. Fair enough? On 27/07/07, Dan >> North wrote: >>> - does anyone want to help me? - please say yes because I have no >>> idea how to do 2) > > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel From aslak.hellesoy at gmail.com Tue Jul 31 18:14:58 2007 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Wed, 1 Aug 2007 00:14:58 +0200 Subject: [rspec-devel] merging rbehave into rspec In-Reply-To: <46AF7BB5.90404@tastapod.com> References: <46A9CFED.1020709@tastapod.com> <709de1d10707310805g732e3ac0k52731f7ffa936ac6@mail.gmail.com> <46AF7BB5.90404@tastapod.com> Message-ID: <8d961d900707311514g38082017wf45b24efe63c1e01@mail.gmail.com> I just want to say that it's great to see so many people interested in this. Now we have cornered the market of tools with dubious figureheads: http://www.reelwavs.com/movies/austin_powers/behave.wav (Austin powers: "RBehave baby") http://www.reevoo.com/blogs/bengriffiths/2006/12/12/rspec-video/ (Fido doing some RSpecing) http://www.internetstart.se/download/ljud/respect.wav (Ali G: "RSpec") Anyone else? Aslak On 7/31/07, Dan North wrote: > > I'm not going to reject any offers of help :) > > Seriously though, the story stuff is subtly different from the object > description framework, so any help with documentation will be very > gratefully received. > > Cheers, > Dan > > > Michael Klishin wrote: > My level of knowledge of RSpec internals is averange but I'd like to > help at least with documentation. Fair enough? > > On 27/07/07, Dan North wrote: > > > > - does anyone want to help me? > - please say yes because I have no idea how to do 2) > > > > > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From aslak.hellesoy at gmail.com Tue Jul 31 18:16:49 2007 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Wed, 1 Aug 2007 00:16:49 +0200 Subject: [rspec-devel] merging rbehave into rspec In-Reply-To: <46AF7BB5.90404@tastapod.com> References: <46A9CFED.1020709@tastapod.com> <709de1d10707310805g732e3ac0k52731f7ffa936ac6@mail.gmail.com> <46AF7BB5.90404@tastapod.com> Message-ID: <8d961d900707311516n525f93e9u79a67887171310e@mail.gmail.com> I just want to say that it's great to see so many people interested in this. Now we have cornered the market of tools with dubious figureheads: http://www.reelwavs.com/movies/austin_powers/behave.wav (Austin powers: "RBehave baby") http://www.reevoo.com/blogs/bengriffiths/2006/12/12/rspec-video/ (Fido doing some RSpecing) http://www.internetstart.se/download/ljud/respect.wav (Ali G: "RSpec") Anyone else? Aslak On 7/31/07, Dan North wrote: > > I'm not going to reject any offers of help :) > > Seriously though, the story stuff is subtly different from the object > description framework, so any help with documentation will be very > gratefully received. > > Cheers, > Dan > > > Michael Klishin wrote: > My level of knowledge of RSpec internals is averange but I'd like to > help at least with documentation. Fair enough? > > On 27/07/07, Dan North wrote: > > > > - does anyone want to help me? > - please say yes because I have no idea how to do 2) > > > > > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel >