From aslak.hellesoy at gmail.com Mon Jan 1 22:38:32 2007 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Tue, 2 Jan 2007 04:38:32 +0100 Subject: [rspec-devel] DB changes Message-ID: <8d961d900701011938h2fac7a95gefa4752d067be5f9@mail.gmail.com> I'v done some changes to the 001 migration, so a manual rake migrate VERSION=0 is required for everyone who's building rspec. Aslak From nicksieger at gmail.com Tue Jan 2 00:42:12 2007 From: nicksieger at gmail.com (Nick Sieger) Date: Mon, 1 Jan 2007 23:42:12 -0600 Subject: [rspec-devel] Feedback on article Message-ID: Hi, I wrote an article [1] outlining some tricks I've developed adding custom extensions into RSpec. But they all hinge upon Spec::Runner::Context#before_context_eval and the @context_eval_module ivar. So I was wondering whether this mechanism can be relied on in the future, or whether this is even the best way to wire in such extensions. If you have a recommended way I'd love to hear about it so I can incorporate it into my article and make sure I don't highlight the wrong way of doing things. Thanks and happy new year! /Nick [1]: http://blog.nicksieger.com/articles/2007/01/02/customizing-rspec -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20070101/52db9e96/attachment.html From aslak.hellesoy at gmail.com Tue Jan 2 00:47:14 2007 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Tue, 2 Jan 2007 06:47:14 +0100 Subject: [rspec-devel] New Gem: spec/ui In-Reply-To: <8d961d900612262035t64bdf551kfb9cfe5ebb8faf09@mail.gmail.com> References: <8d961d900612262035t64bdf551kfb9cfe5ebb8faf09@mail.gmail.com> Message-ID: <8d961d900701012147o3bfcf293wcf5169c3077bfaea@mail.gmail.com> On 12/27/06, aslak hellesoy wrote: > Hi all, > > A few weeks ago I blogged about how to get pretty RSpec/Watir HTML > reports with screenshots > (http://blog.aslakhellesoy.com/articles/2006/12/02/getting-screenshots-from-watir). > > I have taken the code and wrapped it up as a gem (still unreleased). > If you check out the trunk you'll find it under spec_ui. > > There isn't a lot of documentation, but there are two examples in > there, one for Watir/Safariwatir and one for Selenium-RC. > > I'd appreciate some feedback on this - I'd like to make this gem part > of the next release. > I have added a new Rake task to spec/rails: spec:watir This task will run specs under spec/watir and generate HTML reports with screenshots in doc/spec/watir. (If you're on Windows you need RMagick and win32screenshot installed). Specs in the spec/watir directory will have to follow a certain style, and there is an example checked in under spec/watir/person_spec.rb. I'm planning to add generator support for this such that the (new) rspec_resource generator will also generate a skeleton watir spec. A couple of things need more work: 1) Make this work with fixtures. This will require some work in spec/ui's webapp_helper.rb - it uses inherit, which conflicts with spec/rails, which also uses inherit. We can't inherit from both Test::Unit::TestCase and Spec::Ui::WebappHelper. 2) Create spec:selenium and spec:selenium_server tasks in a selenium.rake file Aslak > Aslak > From noreply at rubyforge.org Tue Jan 2 02:34:04 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 2 Jan 2007 02:34:04 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-7524 ] Incorrect Documentation for 'pattern' in Rake task Message-ID: <20070102073404.536815241C8D@rubyforge.org> Bugs item #7524, was opened at 2007-01-02 07:34 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=7524&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Stephen Duncan (jrduncans) Assigned to: Nobody (None) Summary: Incorrect Documentation for 'pattern' in Rake task Initial Comment: The documentation for the rake task states that the default pattern is 'spec/spec*.rb' but is, in fact, 'spec/**/*_spec.rb'. Patch is attached. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=7524&group_id=797 From noreply at rubyforge.org Tue Jan 2 07:38:42 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 2 Jan 2007 07:38:42 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-7409 ] default fixtures do not appear to run. Message-ID: <20070102123842.B1DE95241158@rubyforge.org> Bugs item #7409, was opened at 2006-12-21 07:23 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=7409&group_id=797 >Category: rails plugin Group: None >Status: Closed >Resolution: Accepted Priority: 3 Submitted By: Dallas Pool (codeninja) >Assigned to: David Chelimsky (dchelimsky) Summary: default fixtures do not appear to run. Initial Comment: when I insert my default fixtures into the spec helper... "Nothing Happens" and all tests fail. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-01-02 12:38 Message: Fixed in trunk (rev 1358). I added a slightly different mechanism for global fixtures. In spec_helper.rb, you have to add a line to Spec::Rails::EvalContext self.global_fixtures = :table_a, :table_b, :etc ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-12-28 21:21 Message: We can reproduce it in the spec/rails demo app as follows: 1) comment out "fixtures :people, :animals" in person_spec.rb 2) put "fxtures :people, :animals" in spec_helper.rb 3) ruby -I../rspec/lib spec/models/person_spec.rb See the specs fail ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-12-28 20:29 Message: Can we see the full text of your spec_helper please? ---------------------------------------------------------------------- Comment By: Dallas Pool (codeninja) Date: 2006-12-21 17:43 Message: This line (ENV["RAILS_ENV"] = "test") is currently in the top of my spec_helper.rb and I snagged the plugin directly from trunk 2 days ago. The problem persists. Please advise. Thanks. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-12-21 12:50 Message: Please add the following to the top of spec_helper and tell us if you still experience the problem: ENV["RAILS_ENV"] = "test" This was errantly removed from spec_helper. It has now been replaced (in trunk), so if that solves your problem we can close this ticket. Thanks ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=7409&group_id=797 From noreply at rubyforge.org Tue Jan 2 07:46:21 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 2 Jan 2007 07:46:21 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-7524 ] Incorrect Documentation for 'pattern' in Rake task Message-ID: <20070102124621.F2ECC524113E@rubyforge.org> Bugs item #7524, was opened at 2007-01-02 02:34 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=7524&group_id=797 >Category: expectation module Group: None >Status: Closed >Resolution: Accepted Priority: 3 Submitted By: Stephen Duncan (jrduncans) >Assigned to: David Chelimsky (dchelimsky) Summary: Incorrect Documentation for 'pattern' in Rake task Initial Comment: The documentation for the rake task states that the default pattern is 'spec/spec*.rb' but is, in fact, 'spec/**/*_spec.rb'. Patch is attached. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-01-02 07:46 Message: Applied in trunk (rev 1359). In the future, please use .patch or .diff as the file extension. Makes it easier to download as a file (some browsers tend to want to show you .txt files rather than download them). Thanks ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=7524&group_id=797 From aslak.hellesoy at gmail.com Tue Jan 2 11:29:45 2007 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Tue, 2 Jan 2007 17:29:45 +0100 Subject: [rspec-devel] Feedback on article In-Reply-To: References: Message-ID: <8d961d900701020829l380f4cccr4d4da158c1eeb197@mail.gmail.com> On 1/2/07, Nick Sieger wrote: > Hi, I wrote an article [1] outlining some tricks I've developed adding > custom extensions into RSpec. But they all hinge upon > Spec::Runner::Context#before_context_eval and the > @context_eval_module ivar. So I was wondering whether this mechanism can be > relied on in the future, or whether this is even the best way to wire in > such extensions. If you have a recommended way I'd love to hear about it so > I can incorporate it into my article and make sure I don't highlight the > wrong way of doing things. > That's a great explenation of some of the hardest-to-understand corners of RSpec. Thanks a lot for writing it! It's very pedagogic. Regarding the stability of the API - I'm a little worried about having extensions use private variables. I think it would be better to pass the module to the method: before_context_eval(context_eval_module) A second point is monkey patching. I'm not convinced it's the best way to do things - it makes things tricky when you want to tweak things more than once (see my mail from yesterday - I want to mix the screenshot stuff with fixtures). I haven't thought of an alternative way yet, but I think we need to be able to register "extension" blocks somehow. Aslak > Thanks and happy new year! > > /Nick > > [1]: > http://blog.nicksieger.com/articles/2007/01/02/customizing-rspec > > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > > From nicksieger at gmail.com Tue Jan 2 11:34:37 2007 From: nicksieger at gmail.com (Nick Sieger) Date: Tue, 2 Jan 2007 10:34:37 -0600 Subject: [rspec-devel] Feedback on article In-Reply-To: <8d961d900701020829l380f4cccr4d4da158c1eeb197@mail.gmail.com> References: <8d961d900701020829l380f4cccr4d4da158c1eeb197@mail.gmail.com> Message-ID: On 1/2/07, aslak hellesoy wrote: > > On 1/2/07, Nick Sieger wrote: > > Hi, I wrote an article [1] outlining some tricks I've developed adding > > custom extensions into RSpec. But they all hinge upon > > Spec::Runner::Context#before_context_eval and the > > @context_eval_module ivar. So I was wondering whether this mechanism > can be > > relied on in the future, or whether this is even the best way to wire in > > such extensions. If you have a recommended way I'd love to hear about > it so > > I can incorporate it into my article and make sure I don't highlight the > > wrong way of doing things. > > > > Regarding the stability of the API - I'm a little worried about having > extensions use private variables. Agreed. I was still motivated to post, but I suspected you would think that about the monkeypatching and the direct use of the ivar. I think I'll put a small disclaimer at the top of the post, and keep it up to date to follow whatever you guys think would be appropriate for an extension point API. /Nick -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20070102/8326a6af/attachment.html From aslak.hellesoy at gmail.com Tue Jan 2 12:15:49 2007 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Tue, 2 Jan 2007 18:15:49 +0100 Subject: [rspec-devel] Feedback on article In-Reply-To: References: <8d961d900701020829l380f4cccr4d4da158c1eeb197@mail.gmail.com> Message-ID: <8d961d900701020915u18f430dfv21ae731f65dee7a0@mail.gmail.com> On 1/2/07, Nick Sieger wrote: > On 1/2/07, aslak hellesoy wrote: > > On 1/2/07, Nick Sieger wrote: > > > Hi, I wrote an article [1] outlining some tricks I've developed adding > > > custom extensions into RSpec. But they all hinge upon > > > Spec::Runner::Context#before_context_eval and the > > > @context_eval_module ivar. So I was wondering whether this mechanism > can be > > > relied on in the future, or whether this is even the best way to wire in > > > such extensions. If you have a recommended way I'd love to hear about > it so > > > I can incorporate it into my article and make sure I don't highlight the > > > wrong way of doing things. > > > > > > > Regarding the stability of the API - I'm a little worried about having > > extensions use private variables. > > Agreed. I was still motivated to post, but I suspected you would think that > about the monkeypatching and the direct use of the ivar. I think I'll put a > small disclaimer at the top of the post, and keep it up to date to follow > whatever you guys think would be appropriate for an extension point API. > That sounds good. We're likely to debate what this API looks like for a while, because we only get one shot at it ;-) Here is my initial suggestion/example: Spec::Runner::Context.extend do |context_eval_module| context_eval_module.include StackMethods end class Spec::Runner::Context def self.extend(&block) @@extension_blocks << block end def initialize(name, &context_block) @name = name @context_eval_module = Module.new @context_eval_module.extend ContextEval::ModuleMethods @context_eval_module.include ContextEval::InstanceMethods @@extension_blocks.each{|b| b.call(@context_eval_module)} @context_eval_module.class_eval(&context_block) end end WDYT? > /Nick > > > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > > From nicksieger at gmail.com Tue Jan 2 12:36:38 2007 From: nicksieger at gmail.com (Nick Sieger) Date: Tue, 2 Jan 2007 11:36:38 -0600 Subject: [rspec-devel] Feedback on article In-Reply-To: <8d961d900701020915u18f430dfv21ae731f65dee7a0@mail.gmail.com> References: <8d961d900701020829l380f4cccr4d4da158c1eeb197@mail.gmail.com> <8d961d900701020915u18f430dfv21ae731f65dee7a0@mail.gmail.com> Message-ID: On 1/2/07, aslak hellesoy wrote: > > That sounds good. We're likely to debate what this API looks like for > a while, because we only get one shot at it ;-) Here is my initial > suggestion/example: > > Spec::Runner::Context.extend do |context_eval_module| > context_eval_module.include StackMethods > end > > class Spec::Runner::Context > def self.extend(&block) > @@extension_blocks << block > end > > def initialize(name, &context_block) > @name = name > > @context_eval_module = Module.new > @context_eval_module.extend ContextEval::ModuleMethods > @context_eval_module.include ContextEval::InstanceMethods > @@extension_blocks.each{|b| b.call(@context_eval_module)} > @context_eval_module.class_eval(&context_block) > end > end > > WDYT? That looks great. I can't imagine it needing to get much more complicated than that. I personally wouldn't change a thing. /Nick -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20070102/6d1f930a/attachment-0001.html From noreply at rubyforge.org Tue Jan 2 15:40:39 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 2 Jan 2007 15:40:39 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-7533 ] Spec suite fails and the process exits with a code 0 Message-ID: <20070102204039.14BA252416C9@rubyforge.org> Bugs item #7533, was opened at 2007-01-02 12:40 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=7533&group_id=797 Category: runner module Group: None Status: Open Resolution: None Priority: 3 Submitted By: Brian Takita (btakita) Assigned to: Nobody (None) Summary: Spec suite fails and the process exits with a code 0 Initial Comment: The process should exit with an error code (e.g. 1) ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=7533&group_id=797 From noreply at rubyforge.org Tue Jan 2 15:55:56 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 2 Jan 2007 15:55:56 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-7533 ] Spec suite fails and the process exits with a code 0 Message-ID: <20070102205556.F158652416C9@rubyforge.org> Bugs item #7533, was opened at 2007-01-02 12:40 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=7533&group_id=797 Category: runner module Group: None Status: Open Resolution: None Priority: 3 Submitted By: Brian Takita (btakita) Assigned to: Nobody (None) Summary: Spec suite fails and the process exits with a code 0 Initial Comment: The process should exit with an error code (e.g. 1) ---------------------------------------------------------------------- >Comment By: Brian Takita (btakita) Date: 2007-01-02 12:55 Message: It happens because I called the `ruby spec_suite.rb` instead of `spec spec_suite.rb`. Should we default CommandLine#run exit argument to true? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=7533&group_id=797 From noreply at rubyforge.org Tue Jan 2 18:26:37 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 2 Jan 2007 18:26:37 -0500 (EST) Subject: [rspec-devel] [ rspec-Feature Requests-7536 ] Mock expectations can be called more than once and ordered Message-ID: <20070102232637.9FF555241CA6@rubyforge.org> Feature Requests item #7536, was opened at 2007-01-02 15:26 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=7536&group_id=797 Category: None Group: None Status: Open Priority: 3 Submitted By: Brian Takita (btakita) Assigned to: Nobody (None) Summary: Mock expectations can be called more than once and ordered Initial Comment: the_mock = mock("the_mock") the_mock.should_receive(:foo).ordered the_mock.should_receive(:bar).ordered the_mock.should_receive(:foo).ordered the_mock.should_receive(:baz).ordered ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=7536&group_id=797 From noreply at rubyforge.org Tue Jan 2 19:17:27 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 2 Jan 2007 19:17:27 -0500 (EST) Subject: [rspec-devel] [ rspec-Feature Requests-7536 ] Mock expectations can be called more than once and ordered Message-ID: <20070103001727.98AB15241CC6@rubyforge.org> Feature Requests item #7536, was opened at 2007-01-02 18:26 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=7536&group_id=797 Category: None Group: None Status: Open Priority: 3 Submitted By: Brian Takita (btakita) Assigned to: Nobody (None) Summary: Mock expectations can be called more than once and ordered Initial Comment: the_mock = mock("the_mock") the_mock.should_receive(:foo).ordered the_mock.should_receive(:bar).ordered the_mock.should_receive(:foo).ordered the_mock.should_receive(:baz).ordered ---------------------------------------------------------------------- >Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-01-02 19:17 Message: Do you have a failing spec? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=7536&group_id=797 From noreply at rubyforge.org Thu Jan 4 13:14:59 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 4 Jan 2007 13:14:59 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-7565 ] Subsequent stub! calls for method fail to override the first call to method Message-ID: <20070104181500.1AA745241979@rubyforge.org> Bugs item #7565, was opened at 2007-01-04 13:14 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=7565&group_id=797 Category: mock module Group: None Status: Open Resolution: None Priority: 3 Submitted By: Chris Hoffman (hoffman_c) Assigned to: Nobody (None) Summary: Subsequent stub! calls for method fail to override the first call to method Initial Comment: My collegue and I found a condition where subsequent calls to foo.stub!(:bar) did not override the original stubbed method, and did so silently (i.e., without informing the programmer by raising an exception). Upon further inspection, we found that the @stubs instance variable (mock_handler.rb) was being appended to in the add_stub method call. Then, when it comes time to execute this stubbed method, an array find is used (I forget where in the source) to find the appropriate return value. So, basically, the add_stub method call is dutifully adding a duplicate method to the array, and ignoring it by always retrieving the first stub matching the conditions. This hardly seems to be desired behavior. Would changing the @stubs variable to a hash be possible? I would think such an approach better than executing an array find. What follows is a contrived spec to further elucidate our findings. Obviously this example doesn't make much sense in practice, but we do need this functionality when setting up specs becomes more involved. Thanks. context 'A stub' do setup do @stub = mock("stub") @stub.stub!(:foo).and_return(1) @stub.stub!(:foo).and_return(2) end specify "should equal 2 when calling foo" do @stub.foo.should_eql 2 end end ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=7565&group_id=797 From noreply at rubyforge.org Fri Jan 5 02:13:31 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 5 Jan 2007 02:13:31 -0500 (EST) Subject: [rspec-devel] [ rspec-Feature Requests-7536 ] Mock expectations can be called more than once and ordered Message-ID: <20070105071331.797155241F8F@rubyforge.org> Feature Requests item #7536, was opened at 2007-01-02 15:26 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=7536&group_id=797 Category: None Group: None Status: Open Priority: 3 Submitted By: Brian Takita (btakita) Assigned to: Nobody (None) Summary: Mock expectations can be called more than once and ordered Initial Comment: the_mock = mock("the_mock") the_mock.should_receive(:foo).ordered the_mock.should_receive(:bar).ordered the_mock.should_receive(:foo).ordered the_mock.should_receive(:baz).ordered ---------------------------------------------------------------------- >Comment By: Brian Takita (btakita) Date: 2007-01-04 23:13 Message: require "rubygems" require "spec" context "An Ordered mock" do specify "should allow a method to be ordered twice" do the_mock = mock("the_mock") the_mock.should_receive(:foo).ordered the_mock.should_receive(:bar).ordered the_mock.should_receive(:foo).ordered the_mock.should_receive(:baz).ordered the_mock.foo the_mock.bar the_mock.foo the_mock.baz end end ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-01-02 16:17 Message: Do you have a failing spec? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=7536&group_id=797 From brian.takita at gmail.com Fri Jan 5 02:49:19 2007 From: brian.takita at gmail.com (Brian Takita) Date: Thu, 4 Jan 2007 23:49:19 -0800 Subject: [rspec-devel] Feedback on article In-Reply-To: <8d961d900701020915u18f430dfv21ae731f65dee7a0@mail.gmail.com> References: <8d961d900701020829l380f4cccr4d4da158c1eeb197@mail.gmail.com> <8d961d900701020915u18f430dfv21ae731f65dee7a0@mail.gmail.com> Message-ID: <1d7ddd110701042349m7703477dpf6e740d4bdaae585@mail.gmail.com> On 1/2/07, aslak hellesoy wrote: > > On 1/2/07, Nick Sieger wrote: > > On 1/2/07, aslak hellesoy wrote: > > > On 1/2/07, Nick Sieger wrote: > > > > Hi, I wrote an article [1] outlining some tricks I've developed > adding > > > > custom extensions into RSpec. But they all hinge upon > > > > Spec::Runner::Context#before_context_eval and the > > > > @context_eval_module ivar. So I was wondering whether this > mechanism > > can be > > > > relied on in the future, or whether this is even the best way to > wire in > > > > such extensions. If you have a recommended way I'd love to hear > about > > it so > > > > I can incorporate it into my article and make sure I don't highlight > the > > > > wrong way of doing things. > > > > > > > > > > Regarding the stability of the API - I'm a little worried about having > > > extensions use private variables. > > > > Agreed. I was still motivated to post, but I suspected you would think > that > > about the monkeypatching and the direct use of the ivar. I think I'll > put a > > small disclaimer at the top of the post, and keep it up to date to > follow > > whatever you guys think would be appropriate for an extension point API. > > > > That sounds good. We're likely to debate what this API looks like for > a while, because we only get one shot at it ;-) Here is my initial > suggestion/example: > > Spec::Runner::Context.extend do |context_eval_module| > context_eval_module.include StackMethods > end > > class Spec::Runner::Context > def self.extend(&block) > @@extension_blocks << block > end > > def initialize(name, &context_block) > @name = name > > @context_eval_module = Module.new > @context_eval_module.extend ContextEval::ModuleMethods > @context_eval_module.include ContextEval::InstanceMethods > @@extension_blocks.each{|b| b.call(@context_eval_module)} > @context_eval_module.class_eval(&context_block) > end > end > > WDYT? That looks good. It also exposes a missing feature in the Callbacks module. class Spec::Runner::Context class_callback_events :extend def initialize(name, &context_block) @name = name @context_eval_module = Module.new @context_eval_module.extend ContextEval::ModuleMethods @context_eval_module.include ContextEval::InstanceMethods notify_class_callbacks :extend, @context_eval_module @context_eval_module.class_eval(&context_block) end end > /Nick > > > > > > _______________________________________________ > > 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/20070104/6e7d6df1/attachment.html From brian.takita at gmail.com Fri Jan 5 03:03:40 2007 From: brian.takita at gmail.com (Brian Takita) Date: Fri, 5 Jan 2007 00:03:40 -0800 Subject: [rspec-devel] Feedback on article In-Reply-To: <1d7ddd110701042349m7703477dpf6e740d4bdaae585@mail.gmail.com> References: <8d961d900701020829l380f4cccr4d4da158c1eeb197@mail.gmail.com> <8d961d900701020915u18f430dfv21ae731f65dee7a0@mail.gmail.com> <1d7ddd110701042349m7703477dpf6e740d4bdaae585@mail.gmail.com> Message-ID: <1d7ddd110701050003w7546a9d9r747dcb903799d173@mail.gmail.com> On 1/4/07, Brian Takita wrote: > > On 1/2/07, aslak hellesoy wrote: > > > On 1/2/07, Nick Sieger wrote: > > > On 1/2/07, aslak hellesoy wrote: > > > > On 1/2/07, Nick Sieger wrote: > > > > > Hi, I wrote an article [1] outlining some tricks I've developed > > adding > > > > > custom extensions into RSpec. But they all hinge upon > > > > > Spec::Runner::Context#before_context_eval and the > > > > > @context_eval_module ivar. So I was wondering whether this > > mechanism > > > can be > > > > > relied on in the future, or whether this is even the best way to > > wire in > > > > > such extensions. If you have a recommended way I'd love to hear > > about > > > it so > > > > > I can incorporate it into my article and make sure I don't > > highlight the > > > > > wrong way of doing things. > > > > > > > > > > > > > Regarding the stability of the API - I'm a little worried about > > having > > > > extensions use private variables. > > > > > > Agreed. I was still motivated to post, but I suspected you would > > think that > > > about the monkeypatching and the direct use of the ivar. I think I'll > > put a > > > small disclaimer at the top of the post, and keep it up to date to > > follow > > > whatever you guys think would be appropriate for an extension point > > API. > > > > > > > That sounds good. We're likely to debate what this API looks like for > > a while, because we only get one shot at it ;-) Here is my initial > > suggestion/example: > > > > Spec::Runner::Context.extend do |context_eval_module| > > context_eval_module.include StackMethods > > end > > > > class Spec::Runner::Context > > def self.extend(&block) > > @@extension_blocks << block > > end > > > > def initialize(name, &context_block) > > @name = name > > > > @context_eval_module = Module.new > > @context_eval_module.extend ContextEval::ModuleMethods > > @context_eval_module.include ContextEval::InstanceMethods > > @@extension_blocks.each{|b| b.call(@context_eval_module)} > > @context_eval_module.class_eval(&context_block) > > end > > end > > > > WDYT? > > > That looks good. It also exposes a missing feature in the Callbacks > module. > > class Spec::Runner::Context > class_callback_events :extend > > def initialize(name, &context_block) > @name = name > > @context_eval_module = Module.new > @context_eval_module.extend ContextEval::ModuleMethods > @context_eval_module.include ContextEval::InstanceMethods > notify_class_callbacks :extend, @context_eval_module > @context_eval_module.class_eval(&context_block) > end > end > Is extend a better term than before_context_eval? Is there a better term to use? > /Nick > > > > > > > > > _______________________________________________ > > > 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/20070105/9d0d8c56/attachment-0001.html From noreply at rubyforge.org Fri Jan 5 09:09:15 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 5 Jan 2007 09:09:15 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-7591 ] When controller is missing action method, Rspec reports misleading "no id found" Message-ID: <20070105140915.A2D725240C2E@rubyforge.org> Bugs item #7591, was opened at 2007-01-05 14:09 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=7591&group_id=797 Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: Clint Bishop (norobotdiving) Assigned to: Nobody (None) Summary: When controller is missing action method, Rspec reports misleading "no id found" Initial Comment: Under Rspec 0.7.5 on Rails Edge (Jan 03 2007): The following will fail (correctly) if no "my_action" method is defined upon the my_controller controller. To error report will read "no id found" - the standard message for a method_missing failure. However, the error report is misleading, since we're expecting the ActionController to raise an UnknownAction exception. Snippet: context "Some context" do controller_name 'my_controller' specify "some spec" do xhr :post, :my_action, :a_value => true end end ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=7591&group_id=797 From noreply at rubyforge.org Fri Jan 5 19:35:25 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 5 Jan 2007 19:35:25 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-7611 ] Partial Mocks override Subclass methods Message-ID: <20070106003525.71B4552417FA@rubyforge.org> Bugs item #7611, was opened at 2007-01-05 16:35 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=7611&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Brian Takita (btakita) Assigned to: Nobody (None) Summary: Partial Mocks override Subclass methods Initial Comment: Here is a quick error case that is order dependent. The first spec must run first. I'll post a better spec later. require "rubygems" require "spec" class Foo end class Bar < Foo end context "A Partial Mock" do specify "should respect subclasses" do Foo.stub!(:new).and_return(Object.new) end specify "should" do Bar.new.class.should == Bar end end # output .F 1) 'A Partial Mock should' FAILED Foo should == Bar /home/btakita/workspace/scratch/lib/bdd/partial_mock_subclass_bug.rb:17: /home/btakita/workspace/scratch/lib/bdd/partial_mock_subclass_bug.rb:11: Finished in 0.001406 seconds 2 specifications, 1 failure ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=7611&group_id=797 From noreply at rubyforge.org Fri Jan 5 20:19:29 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 5 Jan 2007 20:19:29 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-7533 ] Spec suite fails and the process exits with a code 0 Message-ID: <20070106011929.B5E875241812@rubyforge.org> Bugs item #7533, was opened at 2007-01-02 12:40 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=7533&group_id=797 Category: runner module Group: None Status: Open Resolution: None Priority: 3 Submitted By: Brian Takita (btakita) Assigned to: Nobody (None) Summary: Spec suite fails and the process exits with a code 0 Initial Comment: The process should exit with an error code (e.g. 1) ---------------------------------------------------------------------- >Comment By: Brian Takita (btakita) Date: 2007-01-05 17:19 Message: Ouch, I got bitten by this again. ---------------------------------------------------------------------- Comment By: Brian Takita (btakita) Date: 2007-01-02 12:55 Message: It happens because I called the `ruby spec_suite.rb` instead of `spec spec_suite.rb`. Should we default CommandLine#run exit argument to true? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=7533&group_id=797 From noreply at rubyforge.org Fri Jan 5 20:21:22 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 5 Jan 2007 20:21:22 -0500 (EST) Subject: [rspec-devel] [ rspec-Feature Requests-7612 ] Add ENV['RAILS_ENV'] = 'test' at the top of spec_helper.rb Message-ID: <20070106012122.D8CE65241812@rubyforge.org> Feature Requests item #7612, was opened at 2007-01-05 17: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: Open Priority: 3 Submitted By: Brian Takita (btakita) Assigned to: Nobody (None) Summary: Add ENV['RAILS_ENV'] = 'test' at the top of spec_helper.rb Initial Comment: Otherwise, specs are run in development mode. Very confusing. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=7612&group_id=797 From noreply at rubyforge.org Fri Jan 5 20:25:34 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 5 Jan 2007 20:25:34 -0500 (EST) Subject: [rspec-devel] [ rspec-Feature Requests-7613 ] context#include should add constants into the context Message-ID: <20070106012535.25B2D5241812@rubyforge.org> Feature Requests item #7613, was opened at 2007-01-05 17:25 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=7613&group_id=797 Category: None Group: None Status: Open Priority: 3 Submitted By: Brian Takita (btakita) Assigned to: Nobody (None) Summary: context#include should add constants into the context Initial Comment: dir = File.dirname(__FILE__) require "#{dir}/spec_helper" module Foo class Bar end end context "A Context include statement" do include Foo specify "should add constants accessable in the context" do b = Bar.new end end ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=7613&group_id=797 From noreply at rubyforge.org Fri Jan 5 21:20:44 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 5 Jan 2007 21:20:44 -0500 (EST) Subject: [rspec-devel] [ rspec-Feature Requests-7612 ] Add ENV['RAILS_ENV'] = 'test' at the top of spec_helper.rb Message-ID: <20070106022044.170E05241812@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-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 brian.takita at gmail.com Sat Jan 6 05:43:52 2007 From: brian.takita at gmail.com (Brian Takita) Date: Sat, 6 Jan 2007 02:43:52 -0800 Subject: [rspec-devel] Build Breaking? Message-ID: <1d7ddd110701060243s3e8cac4dkb8d6c1ed7c9dbb29@mail.gmail.com> Hello, The build is breaking for me. 1) 'HtmlFormatter should produce HTML identical to the one we designed manually' FAILED Is anybody else having this issue? I seem to remember getting this before. Thanks, Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20070106/477cc329/attachment.html From brian.takita at gmail.com Sat Jan 6 05:56:47 2007 From: brian.takita at gmail.com (Brian Takita) Date: Sat, 6 Jan 2007 02:56:47 -0800 Subject: [rspec-devel] Build Breaking? In-Reply-To: <1d7ddd110701060243s3e8cac4dkb8d6c1ed7c9dbb29@mail.gmail.com> References: <1d7ddd110701060243s3e8cac4dkb8d6c1ed7c9dbb29@mail.gmail.com> Message-ID: <1d7ddd110701060256n3d376219j855700f44b67fef5@mail.gmail.com> It has to do with the backtraces. Actual: should fail when expected message not received Mock 'poke me' expected :poke with (any args) once, but received it 0 times ./failing_examples/mocking_example.rb:13: /home/btakita/workspace/rspec/rspec/spec/spec/runner/formatter/html_formatter_spec.rb:16: /home/btakita/workspace/rspec/rspec/spec/spec/runner/formatter/html_formatter_spec.rb:12:in `chdir' /home/btakita/workspace/rspec/rspec/spec/spec/runner/formatter/html_formatter_spec.rb:12: /home/btakita/workspace/rspec/rspec/spec/spec/runner/formatter/html_formatter_spec.rb:11:in `each' /home/btakita/workspace/rspec/rspec/spec/spec/runner/formatter/html_formatter_spec.rb:11: /home/btakita/workspace/rspec/rspec/spec/spec/runner/formatter/html_formatter_spec.rb:4: Expected: should fail when expected message not received Mock 'poke me' expected :poke with (any args) once, but received it 0 times ./failing_examples/mocking_example.rb:13: ./spec/spec/runner/formatter/html_formatter_spec.rb:16: ./spec/spec/runner/formatter/html_formatter_spec.rb:12: ./spec/spec/runner/formatter/html_formatter_spec.rb:11: On 1/6/07, Brian Takita wrote: > > Hello, > > The build is breaking for me. > > 1) 'HtmlFormatter should produce HTML identical to the one we designed > manually' FAILED > > Is anybody else having this issue? I seem to remember getting this before. > > > Thanks, > Brian > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20070106/a5bcaaa3/attachment.html From brian.takita at gmail.com Sat Jan 6 06:13:44 2007 From: brian.takita at gmail.com (Brian Takita) Date: Sat, 6 Jan 2007 03:13:44 -0800 Subject: [rspec-devel] Build Breaking? In-Reply-To: <1d7ddd110701060256n3d376219j855700f44b67fef5@mail.gmail.com> References: <1d7ddd110701060243s3e8cac4dkb8d6c1ed7c9dbb29@mail.gmail.com> <1d7ddd110701060256n3d376219j855700f44b67fef5@mail.gmail.com> Message-ID: <1d7ddd110701060313w21ce0584g538b1bd4f4781bfc@mail.gmail.com> I changed BaseTextFormatter def backtrace_line(line) line.sub(Dir.pwd, '.').sub(/\A([^:]+:\d+)$/, '\\1:') end This spec seems OS specific... /usr/local/bin/ruby /home/btakita/workspace/rspec/rspec/spec/spec/runner/formatter/html_formatter_spec.rb F 1) 'HtmlFormatter should produce HTML identical to the one we designed manually' FAILED "\n\n\n\n\n RSpec results\n \n \n \n \n \n\n\n\n
\n

RSpec Results

\n\n
\n

 

\n

 

\n
\n
\n\n
\n
\n
\n
Mocker
\n \n
should be able to call mock()
\n \n \n \n
\n should fail when expected message not received\n
\n 
Mock 'poke me'
expected :poke with (any args) once, but received it 0
times
\n 
./failing_examples/mocking_example.rb:13:\n./spec/spec/runner/formatter/html_formatter_spec.rb:16:\n./spec/spec/runner/formatter/html_formatter_spec.rb:12:in
`chdir'\n./spec/spec/runner/formatter/html_formatter_spec.rb:12:\n./spec/spec/runner/formatter/html_formatter_spec.rb:11:in
`each'\n./spec/spec/runner/formatter/html_formatter_spec.rb:11:\n./spec/spec/runner/formatter/html_formatter_spec.rb:4:
\n
\n
\n \n \n \n
\n should fail when messages are received out of order\n
\n 
Mock 'one two three'
received :three out of order
\n 
./failing_examples/mocking_example.rb:22:\n./spec/spec/runner/formatter/html_formatter_spec.rb:16:\n./spec/spec/runner/formatter/html_formatter_spec.rb:12:in
`chdir'\n./spec/spec/runner/formatter/html_formatter_spec.rb:12:\n./spec/spec/runner/formatter/html_formatter_spec.rb:11:in
`each'\n./spec/spec/runner/formatter/html_formatter_spec.rb:11:\n./spec/spec/runner/formatter/html_formatter_spec.rb:4:
\n
\n
\n \n \n \n
\n should get yelled at when sending unexpected messages\n
\n 
Mock 'don't talk to me' expected :any_message_at_all
with (any args) 0 times, but received it once
\n 
./failing_examples/mocking_example.rb:28:\n./spec/spec/runner/formatter/html_formatter_spec.rb:16:\n./spec/spec/runner/formatter/html_formatter_spec.rb:12:in
`chdir'\n./spec/spec/runner/formatter/html_formatter_spec.rb:12:\n./spec/spec/runner/formatter/html_formatter_spec.rb:11:in
`each'\n./spec/spec/runner/formatter/html_formatter_spec.rb:11:\n./spec/spec/runner/formatter/html_formatter_spec.rb:4:
\n
\n
\n
\n
\n
\n
\n
Running specs with --diff
\n \n \n \n
\n should print diff of different strings\n
\n 
"RSpec is
a\\nbehavior driven development\\nframework for Ruby\\n" should ==
"RSpec is a\\nbehaviour driven development\\nframework for
Ruby\\n"\nDiff:\n@@ -1,4 +1,4 @@\n RSpec is a\n-behavior driven
development\n+behaviour driven development\n framework for
Ruby\n
\n 
./failing_examples/diffing_spec.rb:13:\n./spec/spec/runner/formatter/html_formatter_spec.rb:16:\n./spec/spec/runner/formatter/html_formatter_spec.rb:12:in
`chdir'\n./spec/spec/runner/formatter/html_formatter_spec.rb:12:\n./spec/spec/runner/formatter/html_formatter_spec.rb:11:in
`each'\n./spec/spec/runner/formatter/html_formatter_spec.rb:11:\n./spec/spec/runner/formatter/html_formatter_spec.rb:4:
\n
\n
\n \n \n \n
\n should print diff of different objects' pretty representation\n
\n 
<Animal\nname=bob,\nspecies=giraffe\n>\n should
eql <Animal\nname=bob,\nspecies=tortoise\n>\n\nDiff:\n@@ -1,5 +1,5
@@\n <Animal\n name=bob,\n-species=giraffe\n+species=tortoise\n
>\n
\n 
./failing_examples/diffing_spec.rb:34:\n./spec/spec/runner/formatter/html_formatter_spec.rb:16:\n./spec/spec/runner/formatter/html_formatter_spec.rb:12:in
`chdir'\n./spec/spec/runner/formatter/html_formatter_spec.rb:12:\n./spec/spec/runner/formatter/html_formatter_spec.rb:11:in
`each'\n./spec/spec/runner/formatter/html_formatter_spec.rb:11:\n./spec/spec/runner/formatter/html_formatter_spec.rb:4:
\n
\n
\n
\n
\n
\n
\n
A consumer of a stub
\n \n
should be able to stub methods on any Object
\n
\n
\n
\n
\n
A stubbed method on a class
\n \n
should return the stubbed value
\n \n
should revert to the original method after each spec
\n \n
can stub! and mock the same message
\n
\n
\n
\n
\n
A mock
\n \n
can stub!
\n \n
can stub! and mock
\n \n
can stub! and mock the same message
\n
\n
\n\n\n
\n\n\n" should == "\n\n\n\n\n RSpec results\n \n \n \n \n \n\n\n\n
\n

RSpec Results

\n\n
\n

 

\n

 

\n
\n
\n\n
\n
\n
\n
Mocker
\n \n
should be able to call mock()
\n \n \n \n
\n should fail when expected message not received\n
\n 
Mock 'poke me'
expected :poke with (any args) once, but received it 0
times
\n 
./failing_examples/mocking_example.rb:13:\n./spec/spec/runner/formatter/html_formatter_spec.rb:16:\n./spec/spec/runner/formatter/html_formatter_spec.rb:12:\n./spec/spec/runner/formatter/html_formatter_spec.rb:11:
\n
\n
\n \n \n \n
\n should fail when messages are received out of order\n
\n 
Mock 'one two three'
received :three out of order
\n 
./failing_examples/mocking_example.rb:22:\n./spec/spec/runner/formatter/html_formatter_spec.rb:16:\n./spec/spec/runner/formatter/html_formatter_spec.rb:12:\n./spec/spec/runner/formatter/html_formatter_spec.rb:11:
\n
\n
\n \n \n \n
\n should get yelled at when sending unexpected messages\n
\n 
Mock 'don't talk to me' expected :any_message_at_all
with (any args) 0 times, but received it once
\n 
./failing_examples/mocking_example.rb:28:\n./spec/spec/runner/formatter/html_formatter_spec.rb:16:\n./spec/spec/runner/formatter/html_formatter_spec.rb:12:\n./spec/spec/runner/formatter/html_formatter_spec.rb:11:
\n
\n
\n
\n
\n
\n
\n
Running specs with --diff
\n \n \n \n
\n should print diff of different strings\n
\n 
"RSpec is
a\\nbehavior driven development\\nframework for Ruby\\n" should ==
"RSpec is a\\nbehaviour driven development\\nframework for
Ruby\\n"\nDiff:\n@@ -1,4 +1,4 @@\n RSpec is a\n-behavior driven
development\n+behaviour driven development\n framework for
Ruby\n
\n 
./failing_examples/diffing_spec.rb:13:\n./spec/spec/runner/formatter/html_formatter_spec.rb:16:\n./spec/spec/runner/formatter/html_formatter_spec.rb:12:\n./spec/spec/runner/formatter/html_formatter_spec.rb:11:
\n
\n
\n \n \n \n
\n should print diff of different objects' pretty representation\n
\n 
<Animal\nname=bob,\nspecies=giraffe\n>\n should
eql <Animal\nname=bob,\nspecies=tortoise\n>\n\nDiff:\n@@ -1,5 +1,5
@@\n <Animal\n name=bob,\n-species=giraffe\n+species=tortoise\n
>\n
\n 
./failing_examples/diffing_spec.rb:34:\n./spec/spec/runner/formatter/html_formatter_spec.rb:16:\n./spec/spec/runner/formatter/html_formatter_spec.rb:12:\n./spec/spec/runner/formatter/html_formatter_spec.rb:11:
\n
\n
\n
\n
\n
\n
\n
A consumer of a stub
\n \n
should be able to stub methods on any Object
\n
\n
\n
\n
\n
A stubbed method on a class
\n \n
should return the stubbed value
\n \n
should revert to the original method after each spec
\n \n
can stub! and mock the same message
\n
\n
\n
\n
\n
A mock
\n \n
can stub!
\n \n
can stub! and mock
\n \n
can stub! and mock the same message
\n
\n
\n\n\n
\n\n\n" Diff: @@ -120,11 +120,8 @@ 
Mock 'poke me' expected :poke with (any
args) once, but received it 0 times
./failing_examples/mocking_example.rb:13:
 ./spec/spec/runner/formatter/html_formatter_spec.rb:16:
-./spec/spec/runner/formatter/html_formatter_spec.rb:12:in `chdir'
 ./spec/spec/runner/formatter/html_formatter_spec.rb:12:
-./spec/spec/runner/formatter/html_formatter_spec.rb:11:in `each'
-./spec/spec/runner/formatter/html_formatter_spec.rb:11:
-./spec/spec/runner/formatter/html_formatter_spec.rb:4:
+./spec/spec/runner/formatter/html_formatter_spec.rb:11: @@ -136,11 +133,8 @@ 
Mock 'one two three' received :three out
of order
./failing_examples/mocking_example.rb:22:
 ./spec/spec/runner/formatter/html_formatter_spec.rb:16:
-./spec/spec/runner/formatter/html_formatter_spec.rb:12:in `chdir'
 ./spec/spec/runner/formatter/html_formatter_spec.rb:12:
-./spec/spec/runner/formatter/html_formatter_spec.rb:11:in `each'
-./spec/spec/runner/formatter/html_formatter_spec.rb:11:
-./spec/spec/runner/formatter/html_formatter_spec.rb:4:
+./spec/spec/runner/formatter/html_formatter_spec.rb:11: @@ -152,11 +146,8 @@ 
Mock 'don't talk to me' expected
:any_message_at_all with (any args) 0 times, but received it
once
./failing_examples/mocking_example.rb:28:
 ./spec/spec/runner/formatter/html_formatter_spec.rb:16:
-./spec/spec/runner/formatter/html_formatter_spec.rb:12:in `chdir'
 ./spec/spec/runner/formatter/html_formatter_spec.rb:12:
-./spec/spec/runner/formatter/html_formatter_spec.rb:11:in `each'
-./spec/spec/runner/formatter/html_formatter_spec.rb:11:
-./spec/spec/runner/formatter/html_formatter_spec.rb:4:
+./spec/spec/runner/formatter/html_formatter_spec.rb:11: @@ -180,11 +171,8 @@ 
./failing_examples/diffing_spec.rb:13:
 ./spec/spec/runner/formatter/html_formatter_spec.rb:16:
-./spec/spec/runner/formatter/html_formatter_spec.rb:12:in `chdir'
 ./spec/spec/runner/formatter/html_formatter_spec.rb:12:
-./spec/spec/runner/formatter/html_formatter_spec.rb:11:in `each'
-./spec/spec/runner/formatter/html_formatter_spec.rb:11:
-./spec/spec/runner/formatter/html_formatter_spec.rb:4:
+./spec/spec/runner/formatter/html_formatter_spec.rb:11: @@ -212,11 +200,8 @@ 
./failing_examples/diffing_spec.rb:34:
 ./spec/spec/runner/formatter/html_formatter_spec.rb:16:
-./spec/spec/runner/formatter/html_formatter_spec.rb:12:in `chdir'
 ./spec/spec/runner/formatter/html_formatter_spec.rb:12:
-./spec/spec/runner/formatter/html_formatter_spec.rb:11:in `each'
-./spec/spec/runner/formatter/html_formatter_spec.rb:11:
-./spec/spec/runner/formatter/html_formatter_spec.rb:4:
+./spec/spec/runner/formatter/html_formatter_spec.rb:11: ./rspec/spec/spec/runner/formatter/html_formatter_spec.rb:31: ./rspec/spec/spec/runner/formatter/html_formatter_spec.rb:12:in `chdir' ./rspec/spec/spec/runner/formatter/html_formatter_spec.rb:12: ./rspec/spec/spec/runner/formatter/html_formatter_spec.rb:11:in `each' ./rspec/spec/spec/runner/formatter/html_formatter_spec.rb:11: ./rspec/spec/spec/runner/formatter/html_formatter_spec.rb:4: Finished in 0.235957 seconds 1 specification, 1 failure Process finished with exit code 0 On 1/6/07, Brian Takita wrote: > > It has to do with the backtraces. > > Actual: > should fail when expected message not received > > Mock 'poke me' expected :poke with (any args) once, but received it 0 times > > ./failing_examples/mocking_example.rb:13: > /home/btakita/workspace/rspec/rspec/spec/spec/runner/formatter/html_formatter_spec.rb:16: > /home/btakita/workspace/rspec/rspec/spec/spec/runner/formatter/html_formatter_spec.rb:12:in `chdir' > > /home/btakita/workspace/rspec/rspec/spec/spec/runner/formatter/html_formatter_spec.rb:12: > /home/btakita/workspace/rspec/rspec/spec/spec/runner/formatter/html_formatter_spec.rb:11:in `each' > /home/btakita/workspace/rspec/rspec/spec/spec/runner/formatter/html_formatter_spec.rb:11: > > /home/btakita/workspace/rspec/rspec/spec/spec/runner/formatter/html_formatter_spec.rb:4: > > > Expected: > > should fail when expected message not received > > Mock 'poke me' expected :poke with (any args) once, but received it 0 times > > ./failing_examples/mocking_example.rb:13: > ./spec/spec/runner/formatter/html_formatter_spec.rb:16: > ./spec/spec/runner/formatter/html_formatter_spec.rb:12: > ./spec/spec/runner/formatter/html_formatter_spec.rb:11: > > > > On 1/6/07, Brian Takita wrote: > > > > Hello, > > > > The build is breaking for me. > > > > 1) 'HtmlFormatter should produce HTML identical to the one we designed > > manually' FAILED > > > > Is anybody else having this issue? I seem to remember getting this > > before. > > > > Thanks, > > Brian > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20070106/48eb5990/attachment-0001.html From dchelimsky at gmail.com Sat Jan 6 08:37:51 2007 From: dchelimsky at gmail.com (David Chelimsky) Date: Sat, 6 Jan 2007 08:37:51 -0500 Subject: [rspec-devel] Build Breaking? In-Reply-To: <1d7ddd110701060313w21ce0584g538b1bd4f4781bfc@mail.gmail.com> References: <1d7ddd110701060243s3e8cac4dkb8d6c1ed7c9dbb29@mail.gmail.com> <1d7ddd110701060256n3d376219j855700f44b67fef5@mail.gmail.com> <1d7ddd110701060313w21ce0584g538b1bd4f4781bfc@mail.gmail.com> Message-ID: <57c63afe0701060537s28b9efd3mb5ba26d76effbc55@mail.gmail.com> On 1/6/07, Brian Takita wrote: > I changed BaseTextFormatter > > def backtrace_line(line) > line.sub(Dir.pwd, '.').sub(/\A([^:]+:\d+)$/, '\\1:') > end > > This spec seems OS specific... > > /usr/local/bin/ruby > /home/btakita/workspace/rspec/rspec/spec/spec/runner/formatter/html_formatter_spec.rb Try standing in /home/btakita/workspace/rspec/rspec. That's where it's intended to be run from. > > F > > 1) > 'HtmlFormatter should produce HTML identical to the one we designed > manually' FAILED > " encoding=\"iso-8859-1\"?>\n \"-//W3C//DTD XHTML 1.0 Transitional//EN\"\n \" > http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd\">\n\n xmlns=\"http://www.w3.org/1999/xhtml\" xml:lang=\"en\" > lang=\"en\">\n\n RSpec results\n http-equiv=\"Content-Type\" content=\"text/html; charset=iso-8859-1\" />\n > \n http-equiv=\"Pragma\" content=\"no-cache\" />\n \n \n\n\n\n
\n >

RSpec Results

\n\n
\n

id=\"duration\"> 

\n

 

\n >
\n
\n\n
\n
\n
\n >
Mocker
\n \n
class=\"passed_spec_name\">should be able to call > mock()
\n \n > \n > \n
\n class=\"failed_spec_name\">should fail when expected > message not received\n
id=\"failure_1\">\n 
Mock 'poke me'
> expected :poke with (any args) once, but received it 0 times
\n >
class=\"backtrace\">
./failing_examples/mocking_example.rb:13:\n./spec/spec/runner/formatter/html_formatter_spec.rb:16:\n./spec/spec/runner/formatter/html_formatter_spec.rb:12:in
> `chdir'\n./spec/spec/runner/formatter/html_formatter_spec.rb:12:\n./spec/spec/runner/formatter/html_formatter_spec.rb:11:in
> `each'\n./spec/spec/runner/formatter/html_formatter_spec.rb:11:\n./spec/spec/runner/formatter/html_formatter_spec.rb:4:
\n >
\n
\n \n > \n > \n
\n class=\"failed_spec_name\">should fail when messages are > received out of order\n
id=\"failure_2\">\n 
Mock 'one two three'
> received :three out of order
\n
class=\"backtrace\">
./failing_examples/mocking_example.rb:22:\n./spec/spec/runner/formatter/html_formatter_spec.rb:16:\n./spec/spec/runner/formatter/html_formatter_spec.rb:12:in
> `chdir'\n./spec/spec/runner/formatter/html_formatter_spec.rb:12:\n./spec/spec/runner/formatter/html_formatter_spec.rb:11:in
> `each'\n./spec/spec/runner/formatter/html_formatter_spec.rb:11:\n./spec/spec/runner/formatter/html_formatter_spec.rb:4:
\n >
\n
\n \n > \n > \n
\n class=\"failed_spec_name\">should get yelled at when > sending unexpected messages\n
id=\"failure_3\">\n 
Mock 'don't talk to
> me' expected :any_message_at_all with (any args) 0 times, but received it
> once
\n
class=\"backtrace\">
./failing_examples/mocking_example.rb:28:\n./spec/spec/runner/formatter/html_formatter_spec.rb:16:\n./spec/spec/runner/formatter/html_formatter_spec.rb:12:in
> `chdir'\n./spec/spec/runner/formatter/html_formatter_spec.rb:12:\n./spec/spec/runner/formatter/html_formatter_spec.rb:11:in
> `each'\n./spec/spec/runner/formatter/html_formatter_spec.rb:11:\n./spec/spec/runner/formatter/html_formatter_spec.rb:4:
\n >
\n
\n
\n
\n
\n
\n >
Running specs with --diff
\n \n > \n > \n
\n class=\"failed_spec_name\">should print diff of different > strings\n
\n
class=\"message\">
"RSpec is a\\nbehavior driven
> development\\nframework for Ruby\\n" should == "RSpec is
> a\\nbehaviour driven development\\nframework for Ruby\\n"\nDiff:\n@@
> -1,4 +1,4 @@\n RSpec is a\n-behavior driven development\n+behaviour driven
> development\n framework for Ruby\n
\n
class=\"backtrace\">
./failing_examples/diffing_spec.rb:13:\n./spec/spec/runner/formatter/html_formatter_spec.rb:16:\n./spec/spec/runner/formatter/html_formatter_spec.rb:12:in
> `chdir'\n./spec/spec/runner/formatter/html_formatter_spec.rb:12:\n./spec/spec/runner/formatter/html_formatter_spec.rb:11:in
> `each'\n./spec/spec/runner/formatter/html_formatter_spec.rb:11:\n./spec/spec/runner/formatter/html_formatter_spec.rb:4:
\n >
\n
\n \n > \n > \n
\n class=\"failed_spec_name\">should print diff of different > objects' pretty representation\n
id=\"failure_5\">\n
class=\"message\">
<Animal\nname=bob,\nspecies=giraffe\n>\n
> should eql
> <Animal\nname=bob,\nspecies=tortoise\n>\n\nDiff:\n@@
> -1,5 +1,5 @@\n <Animal\n
> name=bob,\n-species=giraffe\n+species=tortoise\n
> >\n
\n
class=\"backtrace\">
./failing_examples/diffing_spec.rb:34:\n./spec/spec/runner/formatter/html_formatter_spec.rb:16:\n./spec/spec/runner/formatter/html_formatter_spec.rb:12:in
> `chdir'\n./spec/spec/runner/formatter/html_formatter_spec.rb:12:\n./spec/spec/runner/formatter/html_formatter_spec.rb:11:in
> `each'\n./spec/spec/runner/formatter/html_formatter_spec.rb:11:\n./spec/spec/runner/formatter/html_formatter_spec.rb:4:
\n >
\n
\n
\n
\n
\n
\n >
A consumer of a stub
\n \n
class=\"passed_spec_name\">should be able to stub methods > on any Object
\n
\n
\n
\n >
\n
A stubbed method on a class
\n \n
class=\"passed_spec_name\">should return the stubbed > value
\n \n
class=\"passed_spec_name\">should revert to the original > method after each spec
\n \n
class=\"passed_spec_name\">can stub! and mock the same message
\n >
\n
\n
\n
\n
A > mock
\n \n
class=\"passed_spec_name\">can stub!
\n \n
class=\"passed_spec_name\">can stub! and mock
\n \n
class=\"passed_spec_name\">can stub! and mock the same message
\n >
\n
\n\n\n
\n\n\n" should == > " encoding=\"iso-8859-1\"?>\n \"-//W3C//DTD XHTML 1.0 Transitional//EN\"\n > \"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd\ > ">\n\n lang=\"en\">\n\n RSpec results\n http-equiv=\"Content-Type\" content=\"text/html; charset=iso-8859-1\" />\n > \n http-equiv=\"Pragma\" content=\"no-cache\" />\n \n \n\n\n\n
\n >

RSpec Results

\n\n
\n

id=\"duration\"> 

\n

 

\n >
\n
\n\n
\n
\n
\n >
Mocker
\n \n
class=\"passed_spec_name\">should be able to call > mock()
\n \n > \n > \n
\n class=\"failed_spec_name\">should fail when expected > message not received\n
id=\"failure_1\">\n 
Mock 'poke me'
> expected :poke with (any args) once, but received it 0 times
\n >
class=\"backtrace\">
./failing_examples/mocking_example.rb:13:\n./spec/spec/runner/formatter/html_formatter_spec.rb:16:\n./spec/spec/runner/formatter/html_formatter_spec.rb:12:\n./spec/spec/runner/formatter/html_formatter_spec.rb:11:
\n >
\n
\n \n > \n > \n
\n class=\"failed_spec_name\">should fail when messages are > received out of order\n
id=\"failure_2\">\n 
Mock 'one two three'
> received :three out of order
\n
class=\"backtrace\">
./failing_examples/mocking_example.rb:22:\n./spec/spec/runner/formatter/html_formatter_spec.rb:16:\n./spec/spec/runner/formatter/html_formatter_spec.rb:12:\n./spec/spec/runner/formatter/html_formatter_spec.rb:11:
\n >
\n
\n \n > \n > \n
\n class=\"failed_spec_name\">should get yelled at when > sending unexpected messages\n
id=\"failure_3\">\n 
Mock 'don't talk to
> me' expected :any_message_at_all with (any args) 0 times, but received it
> once
\n
class=\"backtrace\">
./failing_examples/mocking_example.rb:28:\n./spec/spec/runner/formatter/html_formatter_spec.rb:16:\n./spec/spec/runner/formatter/html_formatter_spec.rb:12:\n./spec/spec/runner/formatter/html_formatter_spec.rb:11:
\n >
\n
\n
\n
\n
class=\"context\">\n
\n
Running specs with > --diff
\n \n > \n > \n
\n class=\"failed_spec_name\">should print diff of different > strings\n
\n
class=\"message\">
"RSpec is a\\nbehavior driven
> development\\nframework for Ruby\\n" should == "RSpec is
> a\\nbehaviour driven development\\nframework for Ruby\\n"\nDiff:\n@@
> -1,4 +1,4 @@\n RSpec is a\n-behavior driven development\n+behaviour driven
> development\n framework for Ruby\n
\n
class=\"backtrace\">
./failing_examples/diffing_spec.rb:13:\n./spec/spec/runner/formatter/html_formatter_spec.rb:16:\n./spec/spec/runner/formatter/html_formatter_spec.rb:12:\n./spec/spec/runner/formatter/html_formatter_spec.rb:11:
\n >
\n
\n \n > \n > \n
\n class=\"failed_spec_name\">should print diff of different > objects' pretty representation\n
id=\"failure_5\">\n
class=\"message\">
<Animal\nname=bob,\nspecies=giraffe\n>\n
> should eql
> <Animal\nname=bob,\nspecies=tortoise\n>\n\nDiff:\n@@
> -1,5 +1,5 @@\n <Animal\n
> name=bob,\n-species=giraffe\n+species=tortoise\n
> >\n
\n
class=\"backtrace\">
./failing_examples/diffing_spec.rb:34:\n./spec/spec/runner/formatter/html_formatter_spec.rb:16:\n./spec/spec/runner/formatter/html_formatter_spec.rb:12:\n./spec/spec/runner/formatter/html_formatter_spec.rb:11:
\n >
\n
\n
\n
\n
\n
\n >
A consumer of a stub
\n \n
class=\"passed_spec_name\">should be able to stub methods > on any Object
\n
\n
\n
\n >
\n
A stubbed method on a class
\n \n
class=\"passed_spec_name\">should return the stubbed > value
\n \n
class=\"passed_spec_name\">should revert to the original > method after each spec
\n \n
class=\"passed_spec_name\">can stub! and mock the same message
\n >
\n
\n
\n
\n
A > mock
\n \n
class=\"passed_spec_name\">can stub!
\n \n
class=\"passed_spec_name\">can stub! and mock
\n \n
class=\"passed_spec_name\">can stub! and mock the same message
\n >
\n
\n\n\n
\n\n\n" > Diff: > > @@ -120,11 +120,8 @@ > 
Mock 'poke me' expected :poke with (any
> args) once, but received it 0 times
>
class="backtrace">
./failing_examples/mocking_example.rb:13:
>  ./spec/spec/runner/formatter/html_formatter_spec.rb:16:
> -./spec/spec/runner/formatter/html_formatter_spec.rb:12:in
> `chdir'
>  ./spec/spec/runner/formatter/html_formatter_spec.rb:12:
> -./spec/spec/runner/formatter/html_formatter_spec.rb:11:in
> `each'
> -./spec/spec/runner/formatter/html_formatter_spec.rb:11:
> -./spec/spec/runner/formatter/html_formatter_spec.rb:4:
> +./spec/spec/runner/formatter/html_formatter_spec.rb:11: > > > This seems to me to be about ruby version (and what it adds to backtraces), not OS. What version of ruby are you using? > > @@ -136,11 +133,8 @@ > 
Mock 'one two three' received :three out
> of order
>
class="backtrace">
./failing_examples/mocking_example.rb:22:
>  ./spec/spec/runner/formatter/html_formatter_spec.rb:16:
> -./spec/spec/runner/formatter/html_formatter_spec.rb:12:in
> `chdir'
>  ./spec/spec/runner/formatter/html_formatter_spec.rb:12:
> -./spec/spec/runner/formatter/html_formatter_spec.rb:11:in
> `each'
> -./spec/spec/runner/formatter/html_formatter_spec.rb:11:
> -./spec/spec/runner/formatter/html_formatter_spec.rb:4:
> +./spec/spec/runner/formatter/html_formatter_spec.rb:11: > > > > > @@ -152,11 +146,8 @@ > 
Mock 'don't talk to me' expected
> :any_message_at_all with (any args) 0 times, but received it
> once
>
class="backtrace">
./failing_examples/mocking_example.rb:28:
>  ./spec/spec/runner/formatter/html_formatter_spec.rb:16:
> -./spec/spec/runner/formatter/html_formatter_spec.rb:12:in
> `chdir'
>  ./spec/spec/runner/formatter/html_formatter_spec.rb:12:
> -./spec/spec/runner/formatter/html_formatter_spec.rb:11:in
> `each'
> -./spec/spec/runner/formatter/html_formatter_spec.rb:11:
> -./spec/spec/runner/formatter/html_formatter_spec.rb:4:
> +./spec/spec/runner/formatter/html_formatter_spec.rb:11: > > > > > @@ -180,11 +171,8 @@ > >
class="backtrace">
./failing_examples/diffing_spec.rb:13:
>  ./spec/spec/runner/formatter/html_formatter_spec.rb:16:
> -./spec/spec/runner/formatter/html_formatter_spec.rb:12:in
> `chdir'
>  ./spec/spec/runner/formatter/html_formatter_spec.rb:12:
> -./spec/spec/runner/formatter/html_formatter_spec.rb:11:in
> `each'
> -./spec/spec/runner/formatter/html_formatter_spec.rb:11:
> -./spec/spec/runner/formatter/html_formatter_spec.rb:4:
> +./spec/spec/runner/formatter/html_formatter_spec.rb:11: > > > > > @@ -212,11 +200,8 @@ > >
class="backtrace">
./failing_examples/diffing_spec.rb:34:
>  ./spec/spec/runner/formatter/html_formatter_spec.rb:16:
> -./spec/spec/runner/formatter/html_formatter_spec.rb:12:in
> `chdir'
>  ./spec/spec/runner/formatter/html_formatter_spec.rb:12:
> -./spec/spec/runner/formatter/html_formatter_spec.rb:11:in
> `each'
> -./spec/spec/runner/formatter/html_formatter_spec.rb:11:
> -./spec/spec/runner/formatter/html_formatter_spec.rb:4:
> +./spec/spec/runner/formatter/html_formatter_spec.rb:11: > > > > ./rspec/spec/spec/runner/formatter/html_formatter_spec.rb:31: > ./rspec/spec/spec/runner/formatter/html_formatter_spec.rb:12:in > `chdir' > ./rspec/spec/spec/runner/formatter/html_formatter_spec.rb:12: > ./rspec/spec/spec/runner/formatter/html_formatter_spec.rb:11:in > `each' > ./rspec/spec/spec/runner/formatter/html_formatter_spec.rb:11: > ./rspec/spec/spec/runner/formatter/html_formatter_spec.rb:4: > > Finished in 0.235957 seconds > > 1 specification, 1 failure > > Process finished with exit code 0 > > > > On 1/6/07, Brian Takita < brian.takita at gmail.com> wrote: > > It has to do with the backtraces. > > > > Actual: > > should fail when expected message not received > > > > Mock 'poke me' expected :poke with (any args) once, but received it 0 > times > > > > ./failing_examples/mocking_example.rb:13: > > > /home/btakita/workspace/rspec/rspec/spec/spec/runner/formatter/html_formatter_spec.rb:16: > > > /home/btakita/workspace/rspec/rspec/spec/spec/runner/formatter/html_formatter_spec.rb:12:in > `chdir' > > > > > > > /home/btakita/workspace/rspec/rspec/spec/spec/runner/formatter/html_formatter_spec.rb:12: > > > /home/btakita/workspace/rspec/rspec/spec/spec/runner/formatter/html_formatter_spec.rb:11:in > `each' > > > /home/btakita/workspace/rspec/rspec/spec/spec/runner/formatter/html_formatter_spec.rb:11: > > > > > > > /home/btakita/workspace/rspec/rspec/spec/spec/runner/formatter/html_formatter_spec.rb:4: > > > > Expected: > > > > should fail when expected message not received > > > > Mock 'poke me' expected :poke with (any args) once, but received it 0 > times > > > > ./failing_examples/mocking_example.rb:13: > > ./spec/spec/runner/formatter/html_formatter_spec.rb:16: > > ./spec/spec/runner/formatter/html_formatter_spec.rb:12: > > ./spec/spec/runner/formatter/html_formatter_spec.rb:11: > > > > > > > > > > > > On 1/6/07, Brian Takita < brian.takita at gmail.com> wrote: > > > > > Hello, > > > > > > The build is breaking for me. > > > > > > 1) 'HtmlFormatter should produce HTML identical to the one we designed > manually' FAILED > > > > > > Is anybody else having this issue? I seem to remember getting this > before. > > > > > > Thanks, > > > Brian > > > > > > > > > > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > > From dchelimsky at gmail.com Sat Jan 6 08:39:04 2007 From: dchelimsky at gmail.com (David Chelimsky) Date: Sat, 6 Jan 2007 08:39:04 -0500 Subject: [rspec-devel] Build Breaking? In-Reply-To: <57c63afe0701060537s28b9efd3mb5ba26d76effbc55@mail.gmail.com> References: <1d7ddd110701060243s3e8cac4dkb8d6c1ed7c9dbb29@mail.gmail.com> <1d7ddd110701060256n3d376219j855700f44b67fef5@mail.gmail.com> <1d7ddd110701060313w21ce0584g538b1bd4f4781bfc@mail.gmail.com> <57c63afe0701060537s28b9efd3mb5ba26d76effbc55@mail.gmail.com> Message-ID: <57c63afe0701060539y2e37bf88v480db037aecfc22@mail.gmail.com> On 1/6/07, David Chelimsky wrote: > On 1/6/07, Brian Takita wrote: > > I changed BaseTextFormatter > > > > def backtrace_line(line) > > line.sub(Dir.pwd, '.').sub(/\A([^:]+:\d+)$/, '\\1:') > > end > > > > This spec seems OS specific... > > > > /usr/local/bin/ruby > > /home/btakita/workspace/rspec/rspec/spec/spec/runner/formatter/html_formatter_spec.rb > > Try standing in /home/btakita/workspace/rspec/rspec. That's where it's > intended to be run from. To clarify - you won't have to add the pwd replace if you run it from the rspec root (rspec/rspec in this case). > > > > > F > > > > 1) > > 'HtmlFormatter should produce HTML identical to the one we designed > > manually' FAILED > > " > encoding=\"iso-8859-1\"?>\n > \"-//W3C//DTD XHTML 1.0 Transitional//EN\"\n \" > > http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd\">\n\n > xmlns=\"http://www.w3.org/1999/xhtml\" xml:lang=\"en\" > > lang=\"en\">\n\n RSpec results\n > http-equiv=\"Content-Type\" content=\"text/html; charset=iso-8859-1\" />\n > > \n > http-equiv=\"Pragma\" content=\"no-cache\" />\n \n \n\n\n\n
\n > >

RSpec Results

\n\n
\n

> id=\"duration\"> 

\n

 

\n > >
\n
\n\n
\n
\n
\n > >
Mocker
\n \n
> class=\"passed_spec_name\">should be able to call > > mock()
\n \n > > \n > > \n
\n > class=\"failed_spec_name\">should fail when expected > > message not received\n
> id=\"failure_1\">\n 
Mock 'poke me'
> > expected :poke with (any args) once, but received it 0 times
\n > >
> class=\"backtrace\">
./failing_examples/mocking_example.rb:13:\n./spec/spec/runner/formatter/html_formatter_spec.rb:16:\n./spec/spec/runner/formatter/html_formatter_spec.rb:12:in
> > `chdir'\n./spec/spec/runner/formatter/html_formatter_spec.rb:12:\n./spec/spec/runner/formatter/html_formatter_spec.rb:11:in
> > `each'\n./spec/spec/runner/formatter/html_formatter_spec.rb:11:\n./spec/spec/runner/formatter/html_formatter_spec.rb:4:
\n > >
\n
\n \n > > \n > > \n
\n > class=\"failed_spec_name\">should fail when messages are > > received out of order\n
> id=\"failure_2\">\n 
Mock 'one two three'
> > received :three out of order
\n
> class=\"backtrace\">
./failing_examples/mocking_example.rb:22:\n./spec/spec/runner/formatter/html_formatter_spec.rb:16:\n./spec/spec/runner/formatter/html_formatter_spec.rb:12:in
> > `chdir'\n./spec/spec/runner/formatter/html_formatter_spec.rb:12:\n./spec/spec/runner/formatter/html_formatter_spec.rb:11:in
> > `each'\n./spec/spec/runner/formatter/html_formatter_spec.rb:11:\n./spec/spec/runner/formatter/html_formatter_spec.rb:4:
\n > >
\n
\n \n > > \n > > \n
\n > class=\"failed_spec_name\">should get yelled at when > > sending unexpected messages\n
> id=\"failure_3\">\n 
Mock 'don't talk to
> > me' expected :any_message_at_all with (any args) 0 times, but received it
> > once
\n
> class=\"backtrace\">
./failing_examples/mocking_example.rb:28:\n./spec/spec/runner/formatter/html_formatter_spec.rb:16:\n./spec/spec/runner/formatter/html_formatter_spec.rb:12:in
> > `chdir'\n./spec/spec/runner/formatter/html_formatter_spec.rb:12:\n./spec/spec/runner/formatter/html_formatter_spec.rb:11:in
> > `each'\n./spec/spec/runner/formatter/html_formatter_spec.rb:11:\n./spec/spec/runner/formatter/html_formatter_spec.rb:4:
\n > >
\n
\n
\n
\n
\n
\n > >
Running specs with --diff
\n \n > > \n > > \n
\n > class=\"failed_spec_name\">should print diff of different > > strings\n
\n
> class=\"message\">
"RSpec is a\\nbehavior driven
> > development\\nframework for Ruby\\n" should == "RSpec is
> > a\\nbehaviour driven development\\nframework for Ruby\\n"\nDiff:\n@@
> > -1,4 +1,4 @@\n RSpec is a\n-behavior driven development\n+behaviour driven
> > development\n framework for Ruby\n
\n
> class=\"backtrace\">
./failing_examples/diffing_spec.rb:13:\n./spec/spec/runner/formatter/html_formatter_spec.rb:16:\n./spec/spec/runner/formatter/html_formatter_spec.rb:12:in
> > `chdir'\n./spec/spec/runner/formatter/html_formatter_spec.rb:12:\n./spec/spec/runner/formatter/html_formatter_spec.rb:11:in
> > `each'\n./spec/spec/runner/formatter/html_formatter_spec.rb:11:\n./spec/spec/runner/formatter/html_formatter_spec.rb:4:
\n > >
\n
\n \n > > \n > > \n
\n > class=\"failed_spec_name\">should print diff of different > > objects' pretty representation\n
> id=\"failure_5\">\n
> class=\"message\">
<Animal\nname=bob,\nspecies=giraffe\n>\n
> > should eql
> > <Animal\nname=bob,\nspecies=tortoise\n>\n\nDiff:\n@@
> > -1,5 +1,5 @@\n <Animal\n
> > name=bob,\n-species=giraffe\n+species=tortoise\n
> > >\n
\n
> class=\"backtrace\">
./failing_examples/diffing_spec.rb:34:\n./spec/spec/runner/formatter/html_formatter_spec.rb:16:\n./spec/spec/runner/formatter/html_formatter_spec.rb:12:in
> > `chdir'\n./spec/spec/runner/formatter/html_formatter_spec.rb:12:\n./spec/spec/runner/formatter/html_formatter_spec.rb:11:in
> > `each'\n./spec/spec/runner/formatter/html_formatter_spec.rb:11:\n./spec/spec/runner/formatter/html_formatter_spec.rb:4:
\n > >
\n
\n
\n
\n
\n
\n > >
A consumer of a stub
\n \n
> class=\"passed_spec_name\">should be able to stub methods > > on any Object
\n
\n
\n
\n > >
\n
A stubbed method on a class
\n \n
> class=\"passed_spec_name\">should return the stubbed > > value
\n \n
> class=\"passed_spec_name\">should revert to the original > > method after each spec
\n \n
> class=\"passed_spec_name\">can stub! and mock the same message
\n > >
\n
\n
\n
\n
A > > mock
\n \n
> class=\"passed_spec_name\">can stub!
\n \n
> class=\"passed_spec_name\">can stub! and mock
\n \n
> class=\"passed_spec_name\">can stub! and mock the same message
\n > >
\n
\n\n\n
\n\n\n" should == > > " > encoding=\"iso-8859-1\"?>\n > \"-//W3C//DTD XHTML 1.0 Transitional//EN\"\n > > \"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd\ > > ">\n\n > lang=\"en\">\n\n RSpec results\n > http-equiv=\"Content-Type\" content=\"text/html; charset=iso-8859-1\" />\n > > \n > http-equiv=\"Pragma\" content=\"no-cache\" />\n \n \n\n\n\n
\n > >

RSpec Results

\n\n
\n

> id=\"duration\"> 

\n

 

\n > >
\n
\n\n
\n
\n
\n > >
Mocker
\n \n
> class=\"passed_spec_name\">should be able to call > > mock()
\n \n > > \n > > \n
\n > class=\"failed_spec_name\">should fail when expected > > message not received\n
> id=\"failure_1\">\n 
Mock 'poke me'
> > expected :poke with (any args) once, but received it 0 times
\n > >
> class=\"backtrace\">
./failing_examples/mocking_example.rb:13:\n./spec/spec/runner/formatter/html_formatter_spec.rb:16:\n./spec/spec/runner/formatter/html_formatter_spec.rb:12:\n./spec/spec/runner/formatter/html_formatter_spec.rb:11:
\n > >
\n
\n \n > > \n > > \n
\n > class=\"failed_spec_name\">should fail when messages are > > received out of order\n
> id=\"failure_2\">\n 
Mock 'one two three'
> > received :three out of order
\n
> class=\"backtrace\">
./failing_examples/mocking_example.rb:22:\n./spec/spec/runner/formatter/html_formatter_spec.rb:16:\n./spec/spec/runner/formatter/html_formatter_spec.rb:12:\n./spec/spec/runner/formatter/html_formatter_spec.rb:11:
\n > >
\n
\n \n > > \n > > \n
\n > class=\"failed_spec_name\">should get yelled at when > > sending unexpected messages\n
> id=\"failure_3\">\n 
Mock 'don't talk to
> > me' expected :any_message_at_all with (any args) 0 times, but received it
> > once
\n
> class=\"backtrace\">
./failing_examples/mocking_example.rb:28:\n./spec/spec/runner/formatter/html_formatter_spec.rb:16:\n./spec/spec/runner/formatter/html_formatter_spec.rb:12:\n./spec/spec/runner/formatter/html_formatter_spec.rb:11:
\n > >
\n
\n
\n
\n
> class=\"context\">\n
\n
Running specs with > > --diff
\n \n > > \n > > \n
\n > class=\"failed_spec_name\">should print diff of different > > strings\n
\n
> class=\"message\">
"RSpec is a\\nbehavior driven
> > development\\nframework for Ruby\\n" should == "RSpec is
> > a\\nbehaviour driven development\\nframework for Ruby\\n"\nDiff:\n@@
> > -1,4 +1,4 @@\n RSpec is a\n-behavior driven development\n+behaviour driven
> > development\n framework for Ruby\n
\n
> class=\"backtrace\">
./failing_examples/diffing_spec.rb:13:\n./spec/spec/runner/formatter/html_formatter_spec.rb:16:\n./spec/spec/runner/formatter/html_formatter_spec.rb:12:\n./spec/spec/runner/formatter/html_formatter_spec.rb:11:
\n > >
\n
\n \n > > \n > > \n
\n > class=\"failed_spec_name\">should print diff of different > > objects' pretty representation\n
> id=\"failure_5\">\n
> class=\"message\">
<Animal\nname=bob,\nspecies=giraffe\n>\n
> > should eql
> > <Animal\nname=bob,\nspecies=tortoise\n>\n\nDiff:\n@@
> > -1,5 +1,5 @@\n <Animal\n
> > name=bob,\n-species=giraffe\n+species=tortoise\n
> > >\n
\n
> class=\"backtrace\">
./failing_examples/diffing_spec.rb:34:\n./spec/spec/runner/formatter/html_formatter_spec.rb:16:\n./spec/spec/runner/formatter/html_formatter_spec.rb:12:\n./spec/spec/runner/formatter/html_formatter_spec.rb:11:
\n > >
\n
\n
\n
\n
\n
\n > >
A consumer of a stub
\n \n
> class=\"passed_spec_name\">should be able to stub methods > > on any Object
\n
\n
\n
\n > >
\n
A stubbed method on a class
\n \n
> class=\"passed_spec_name\">should return the stubbed > > value
\n \n
> class=\"passed_spec_name\">should revert to the original > > method after each spec
\n \n
> class=\"passed_spec_name\">can stub! and mock the same message
\n > >
\n
\n
\n
\n
A > > mock
\n \n
> class=\"passed_spec_name\">can stub!
\n \n
> class=\"passed_spec_name\">can stub! and mock
\n \n
> class=\"passed_spec_name\">can stub! and mock the same message
\n > >
\n
\n\n\n
\n\n\n" > > Diff: > > > > @@ -120,11 +120,8 @@ > > 
Mock 'poke me' expected :poke with (any
> > args) once, but received it 0 times
> >
> class="backtrace">
./failing_examples/mocking_example.rb:13:
> >  ./spec/spec/runner/formatter/html_formatter_spec.rb:16:
> > -./spec/spec/runner/formatter/html_formatter_spec.rb:12:in
> > `chdir'
> >  ./spec/spec/runner/formatter/html_formatter_spec.rb:12:
> > -./spec/spec/runner/formatter/html_formatter_spec.rb:11:in
> > `each'
> > -./spec/spec/runner/formatter/html_formatter_spec.rb:11:
> > -./spec/spec/runner/formatter/html_formatter_spec.rb:4:
> > +./spec/spec/runner/formatter/html_formatter_spec.rb:11: > > > > > > > > This seems to me to be about ruby version (and what it adds to > backtraces), not OS. What version of ruby are you using? > > > > > @@ -136,11 +133,8 @@ > > 
Mock 'one two three' received :three out
> > of order
> >
> class="backtrace">
./failing_examples/mocking_example.rb:22:
> >  ./spec/spec/runner/formatter/html_formatter_spec.rb:16:
> > -./spec/spec/runner/formatter/html_formatter_spec.rb:12:in
> > `chdir'
> >  ./spec/spec/runner/formatter/html_formatter_spec.rb:12:
> > -./spec/spec/runner/formatter/html_formatter_spec.rb:11:in
> > `each'
> > -./spec/spec/runner/formatter/html_formatter_spec.rb:11:
> > -./spec/spec/runner/formatter/html_formatter_spec.rb:4:
> > +./spec/spec/runner/formatter/html_formatter_spec.rb:11: > > > > > > > > > > @@ -152,11 +146,8 @@ > > 
Mock 'don't talk to me' expected
> > :any_message_at_all with (any args) 0 times, but received it
> > once
> >
> class="backtrace">
./failing_examples/mocking_example.rb:28:
> >  ./spec/spec/runner/formatter/html_formatter_spec.rb:16:
> > -./spec/spec/runner/formatter/html_formatter_spec.rb:12:in
> > `chdir'
> >  ./spec/spec/runner/formatter/html_formatter_spec.rb:12:
> > -./spec/spec/runner/formatter/html_formatter_spec.rb:11:in
> > `each'
> > -./spec/spec/runner/formatter/html_formatter_spec.rb:11:
> > -./spec/spec/runner/formatter/html_formatter_spec.rb:4:
> > +./spec/spec/runner/formatter/html_formatter_spec.rb:11: > > > > > > > > > > @@ -180,11 +171,8 @@ > > > >
> class="backtrace">
./failing_examples/diffing_spec.rb:13:
> >  ./spec/spec/runner/formatter/html_formatter_spec.rb:16:
> > -./spec/spec/runner/formatter/html_formatter_spec.rb:12:in
> > `chdir'
> >  ./spec/spec/runner/formatter/html_formatter_spec.rb:12:
> > -./spec/spec/runner/formatter/html_formatter_spec.rb:11:in
> > `each'
> > -./spec/spec/runner/formatter/html_formatter_spec.rb:11:
> > -./spec/spec/runner/formatter/html_formatter_spec.rb:4:
> > +./spec/spec/runner/formatter/html_formatter_spec.rb:11: > > > > > > > > > > @@ -212,11 +200,8 @@ > > > >
> class="backtrace">
./failing_examples/diffing_spec.rb:34:
> >  ./spec/spec/runner/formatter/html_formatter_spec.rb:16:
> > -./spec/spec/runner/formatter/html_formatter_spec.rb:12:in
> > `chdir'
> >  ./spec/spec/runner/formatter/html_formatter_spec.rb:12:
> > -./spec/spec/runner/formatter/html_formatter_spec.rb:11:in
> > `each'
> > -./spec/spec/runner/formatter/html_formatter_spec.rb:11:
> > -./spec/spec/runner/formatter/html_formatter_spec.rb:4:
> > +./spec/spec/runner/formatter/html_formatter_spec.rb:11: > > > > > > > > ./rspec/spec/spec/runner/formatter/html_formatter_spec.rb:31: > > ./rspec/spec/spec/runner/formatter/html_formatter_spec.rb:12:in > > `chdir' > > ./rspec/spec/spec/runner/formatter/html_formatter_spec.rb:12: > > ./rspec/spec/spec/runner/formatter/html_formatter_spec.rb:11:in > > `each' > > ./rspec/spec/spec/runner/formatter/html_formatter_spec.rb:11: > > ./rspec/spec/spec/runner/formatter/html_formatter_spec.rb:4: > > > > Finished in 0.235957 seconds > > > > 1 specification, 1 failure > > > > Process finished with exit code 0 > > > > > > > > On 1/6/07, Brian Takita < brian.takita at gmail.com> wrote: > > > It has to do with the backtraces. > > > > > > Actual: > > > should fail when expected message not received > > > > > > Mock 'poke me' expected :poke with (any args) once, but received it 0 > > times > > > > > > ./failing_examples/mocking_example.rb:13: > > > > > /home/btakita/workspace/rspec/rspec/spec/spec/runner/formatter/html_formatter_spec.rb:16: > > > > > /home/btakita/workspace/rspec/rspec/spec/spec/runner/formatter/html_formatter_spec.rb:12:in > > `chdir' > > > > > > > > > > > /home/btakita/workspace/rspec/rspec/spec/spec/runner/formatter/html_formatter_spec.rb:12: > > > > > /home/btakita/workspace/rspec/rspec/spec/spec/runner/formatter/html_formatter_spec.rb:11:in > > `each' > > > > > /home/btakita/workspace/rspec/rspec/spec/spec/runner/formatter/html_formatter_spec.rb:11: > > > > > > > > > > > /home/btakita/workspace/rspec/rspec/spec/spec/runner/formatter/html_formatter_spec.rb:4: > > > > > > Expected: > > > > > > should fail when expected message not received > > > > > > Mock 'poke me' expected :poke with (any args) once, but received it 0 > > times > > > > > > ./failing_examples/mocking_example.rb:13: > > > ./spec/spec/runner/formatter/html_formatter_spec.rb:16: > > > ./spec/spec/runner/formatter/html_formatter_spec.rb:12: > > > ./spec/spec/runner/formatter/html_formatter_spec.rb:11: > > > > > > > > > > > > > > > > > > On 1/6/07, Brian Takita < brian.takita at gmail.com> wrote: > > > > > > > Hello, > > > > > > > > The build is breaking for me. > > > > > > > > 1) 'HtmlFormatter should produce HTML identical to the one we designed > > manually' FAILED > > > > > > > > Is anybody else having this issue? I seem to remember getting this > > before. > > > > > > > > Thanks, > > > > Brian > > > > > > > > > > > > > > > > _______________________________________________ > > rspec-devel mailing list > > rspec-devel at rubyforge.org > > http://rubyforge.org/mailman/listinfo/rspec-devel > > > > > From noreply at rubyforge.org Sat Jan 6 09:03:58 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sat, 6 Jan 2007 09:03:58 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-7565 ] Subsequent stub! calls for method fail to override the first call to method Message-ID: <20070106140358.9F73E5240F10@rubyforge.org> Bugs item #7565, was opened at 2007-01-04 18:14 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=7565&group_id=797 Category: mock module Group: None >Status: Closed >Resolution: Accepted Priority: 3 Submitted By: Chris Hoffman (hoffman_c) >Assigned to: David Chelimsky (dchelimsky) Summary: Subsequent stub! calls for method fail to override the first call to method Initial Comment: My collegue and I found a condition where subsequent calls to foo.stub!(:bar) did not override the original stubbed method, and did so silently (i.e., without informing the programmer by raising an exception). Upon further inspection, we found that the @stubs instance variable (mock_handler.rb) was being appended to in the add_stub method call. Then, when it comes time to execute this stubbed method, an array find is used (I forget where in the source) to find the appropriate return value. So, basically, the add_stub method call is dutifully adding a duplicate method to the array, and ignoring it by always retrieving the first stub matching the conditions. This hardly seems to be desired behavior. Would changing the @stubs variable to a hash be possible? I would think such an approach better than executing an array find. What follows is a contrived spec to further elucidate our findings. Obviously this example doesn't make much sense in practice, but we do need this functionality when setting up specs becomes more involved. Thanks. context 'A stub' do setup do @stub = mock("stub") @stub.stub!(:foo).and_return(1) @stub.stub!(:foo).and_return(2) end specify "should equal 2 when calling foo" do @stub.foo.should_eql 2 end end ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-01-06 14:03 Message: Fixed in trunk (rev 1361) Stubs are now added to the front of the Array, so the one it finds will be the last one that was set. Perhaps not as elegant as using a Hash, but it keeps the code simpler and works just fine. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=7565&group_id=797 From dchelimsky at gmail.com Sat Jan 6 09:06:58 2007 From: dchelimsky at gmail.com (David Chelimsky) Date: Sat, 6 Jan 2007 09:06:58 -0500 Subject: [rspec-devel] Build Breaking? In-Reply-To: <57c63afe0701060539y2e37bf88v480db037aecfc22@mail.gmail.com> References: <1d7ddd110701060243s3e8cac4dkb8d6c1ed7c9dbb29@mail.gmail.com> <1d7ddd110701060256n3d376219j855700f44b67fef5@mail.gmail.com> <1d7ddd110701060313w21ce0584g538b1bd4f4781bfc@mail.gmail.com> <57c63afe0701060537s28b9efd3mb5ba26d76effbc55@mail.gmail.com> <57c63afe0701060539y2e37bf88v480db037aecfc22@mail.gmail.com> Message-ID: <57c63afe0701060606n4092fbc3n2d9132442215f95d@mail.gmail.com> On 1/6/07, David Chelimsky wrote: > On 1/6/07, David Chelimsky wrote: > > On 1/6/07, Brian Takita wrote: > > > I changed BaseTextFormatter > > > > > > def backtrace_line(line) > > > line.sub(Dir.pwd, '.').sub(/\A([^:]+:\d+)$/, '\\1:') > > > end > > > > > > This spec seems OS specific... > > > > > > /usr/local/bin/ruby > > > /home/btakita/workspace/rspec/rspec/spec/spec/runner/formatter/html_formatter_spec.rb > > > > Try standing in /home/btakita/workspace/rspec/rspec. That's where it's > > intended to be run from. > > To clarify - you won't have to add the pwd replace if you run it from > the rspec root (rspec/rspec in this case). > > > > > > > > > F > > > > > > 1) > > > 'HtmlFormatter should produce HTML identical to the one we designed > > > manually' FAILED > > > " > > encoding=\"iso-8859-1\"?>\n > > \"-//W3C//DTD XHTML 1.0 Transitional//EN\"\n \" > > > http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd\">\n\n > > xmlns=\"http://www.w3.org/1999/xhtml\" xml:lang=\"en\" > > > lang=\"en\">\n\n RSpec results\n > > http-equiv=\"Content-Type\" content=\"text/html; charset=iso-8859-1\" />\n > > > \n > > http-equiv=\"Pragma\" content=\"no-cache\" />\n \n \n\n\n\n
\n > > >

RSpec Results

\n\n
\n

> > id=\"duration\"> 

\n

 

\n > > >
\n
\n\n
\n
\n
\n > > >
Mocker
\n \n
> > class=\"passed_spec_name\">should be able to call > > > mock()
\n \n > > > \n > > > \n
\n > > class=\"failed_spec_name\">should fail when expected > > > message not received\n
> > id=\"failure_1\">\n 
Mock 'poke me'
> > > expected :poke with (any args) once, but received it 0 times
\n > > >
> > class=\"backtrace\">
./failing_examples/mocking_example.rb:13:\n./spec/spec/runner/formatter/html_formatter_spec.rb:16:\n./spec/spec/runner/formatter/html_formatter_spec.rb:12:in
> > > `chdir'\n./spec/spec/runner/formatter/html_formatter_spec.rb:12:\n./spec/spec/runner/formatter/html_formatter_spec.rb:11:in
> > > `each'\n./spec/spec/runner/formatter/html_formatter_spec.rb:11:\n./spec/spec/runner/formatter/html_formatter_spec.rb:4:
\n > > >
\n
\n \n > > > \n > > > \n
\n > > class=\"failed_spec_name\">should fail when messages are > > > received out of order\n
> > id=\"failure_2\">\n 
Mock 'one two three'
> > > received :three out of order
\n
> > class=\"backtrace\">
./failing_examples/mocking_example.rb:22:\n./spec/spec/runner/formatter/html_formatter_spec.rb:16:\n./spec/spec/runner/formatter/html_formatter_spec.rb:12:in
> > > `chdir'\n./spec/spec/runner/formatter/html_formatter_spec.rb:12:\n./spec/spec/runner/formatter/html_formatter_spec.rb:11:in
> > > `each'\n./spec/spec/runner/formatter/html_formatter_spec.rb:11:\n./spec/spec/runner/formatter/html_formatter_spec.rb:4:
\n > > >
\n
\n \n > > > \n > > > \n
\n > > class=\"failed_spec_name\">should get yelled at when > > > sending unexpected messages\n
> > id=\"failure_3\">\n 
Mock 'don't talk to
> > > me' expected :any_message_at_all with (any args) 0 times, but received it
> > > once
\n
> > class=\"backtrace\">
./failing_examples/mocking_example.rb:28:\n./spec/spec/runner/formatter/html_formatter_spec.rb:16:\n./spec/spec/runner/formatter/html_formatter_spec.rb:12:in
> > > `chdir'\n./spec/spec/runner/formatter/html_formatter_spec.rb:12:\n./spec/spec/runner/formatter/html_formatter_spec.rb:11:in
> > > `each'\n./spec/spec/runner/formatter/html_formatter_spec.rb:11:\n./spec/spec/runner/formatter/html_formatter_spec.rb:4:
\n > > >
\n
\n
\n
\n
\n
\n > > >
Running specs with --diff
\n \n > > > \n > > > \n
\n > > class=\"failed_spec_name\">should print diff of different > > > strings\n
\n
> > class=\"message\">
"RSpec is a\\nbehavior driven
> > > development\\nframework for Ruby\\n" should == "RSpec is
> > > a\\nbehaviour driven development\\nframework for Ruby\\n"\nDiff:\n@@
> > > -1,4 +1,4 @@\n RSpec is a\n-behavior driven development\n+behaviour driven
> > > development\n framework for Ruby\n
\n
> > class=\"backtrace\">
./failing_examples/diffing_spec.rb:13:\n./spec/spec/runner/formatter/html_formatter_spec.rb:16:\n./spec/spec/runner/formatter/html_formatter_spec.rb:12:in
> > > `chdir'\n./spec/spec/runner/formatter/html_formatter_spec.rb:12:\n./spec/spec/runner/formatter/html_formatter_spec.rb:11:in
> > > `each'\n./spec/spec/runner/formatter/html_formatter_spec.rb:11:\n./spec/spec/runner/formatter/html_formatter_spec.rb:4:
\n > > >
\n
\n \n > > > \n > > > \n
\n > > class=\"failed_spec_name\">should print diff of different > > > objects' pretty representation\n
> > id=\"failure_5\">\n
> > class=\"message\">
<Animal\nname=bob,\nspecies=giraffe\n>\n
> > > should eql
> > > <Animal\nname=bob,\nspecies=tortoise\n>\n\nDiff:\n@@
> > > -1,5 +1,5 @@\n <Animal\n
> > > name=bob,\n-species=giraffe\n+species=tortoise\n
> > > >\n
\n
> > class=\"backtrace\">
./failing_examples/diffing_spec.rb:34:\n./spec/spec/runner/formatter/html_formatter_spec.rb:16:\n./spec/spec/runner/formatter/html_formatter_spec.rb:12:in
> > > `chdir'\n./spec/spec/runner/formatter/html_formatter_spec.rb:12:\n./spec/spec/runner/formatter/html_formatter_spec.rb:11:in
> > > `each'\n./spec/spec/runner/formatter/html_formatter_spec.rb:11:\n./spec/spec/runner/formatter/html_formatter_spec.rb:4:
\n > > >
\n
\n
\n
\n
\n
\n > > >
A consumer of a stub
\n \n
> > class=\"passed_spec_name\">should be able to stub methods > > > on any Object
\n
\n
\n
\n > > >
\n
A stubbed method on a class
\n \n
> > class=\"passed_spec_name\">should return the stubbed > > > value
\n \n
> > class=\"passed_spec_name\">should revert to the original > > > method after each spec
\n \n
> > class=\"passed_spec_name\">can stub! and mock the same message
\n > > >
\n
\n
\n
\n
A > > > mock
\n \n
> > class=\"passed_spec_name\">can stub!
\n \n
> > class=\"passed_spec_name\">can stub! and mock
\n \n
> > class=\"passed_spec_name\">can stub! and mock the same message
\n > > >
\n
\n\n\n
\n\n\n" should == > > > " > > encoding=\"iso-8859-1\"?>\n > > \"-//W3C//DTD XHTML 1.0 Transitional//EN\"\n > > > \"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd\ > > > ">\n\n > > lang=\"en\">\n\n RSpec results\n > > http-equiv=\"Content-Type\" content=\"text/html; charset=iso-8859-1\" />\n > > > \n > > http-equiv=\"Pragma\" content=\"no-cache\" />\n \n \n\n\n\n
\n > > >

RSpec Results

\n\n
\n

> > id=\"duration\"> 

\n

 

\n > > >
\n
\n\n
\n
\n
\n > > >
Mocker
\n \n
> > class=\"passed_spec_name\">should be able to call > > > mock()
\n \n > > > \n > > > \n
\n > > class=\"failed_spec_name\">should fail when expected > > > message not received\n
> > id=\"failure_1\">\n 
Mock 'poke me'
> > > expected :poke with (any args) once, but received it 0 times
\n > > >
> > class=\"backtrace\">
./failing_examples/mocking_example.rb:13:\n./spec/spec/runner/formatter/html_formatter_spec.rb:16:\n./spec/spec/runner/formatter/html_formatter_spec.rb:12:\n./spec/spec/runner/formatter/html_formatter_spec.rb:11:
\n > > >
\n
\n \n > > > \n > > > \n
\n > > class=\"failed_spec_name\">should fail when messages are > > > received out of order\n
> > id=\"failure_2\">\n 
Mock 'one two three'
> > > received :three out of order
\n
> > class=\"backtrace\">
./failing_examples/mocking_example.rb:22:\n./spec/spec/runner/formatter/html_formatter_spec.rb:16:\n./spec/spec/runner/formatter/html_formatter_spec.rb:12:\n./spec/spec/runner/formatter/html_formatter_spec.rb:11:
\n > > >
\n
\n \n > > > \n > > > \n
\n > > class=\"failed_spec_name\">should get yelled at when > > > sending unexpected messages\n
> > id=\"failure_3\">\n 
Mock 'don't talk to
> > > me' expected :any_message_at_all with (any args) 0 times, but received it
> > > once
\n
> > class=\"backtrace\">
./failing_examples/mocking_example.rb:28:\n./spec/spec/runner/formatter/html_formatter_spec.rb:16:\n./spec/spec/runner/formatter/html_formatter_spec.rb:12:\n./spec/spec/runner/formatter/html_formatter_spec.rb:11:
\n > > >
\n
\n
\n
\n
> > class=\"context\">\n
\n
Running specs with > > > --diff
\n \n > > > \n > > > \n
\n > > class=\"failed_spec_name\">should print diff of different > > > strings\n
\n
> > class=\"message\">
"RSpec is a\\nbehavior driven
> > > development\\nframework for Ruby\\n" should == "RSpec is
> > > a\\nbehaviour driven development\\nframework for Ruby\\n"\nDiff:\n@@
> > > -1,4 +1,4 @@\n RSpec is a\n-behavior driven development\n+behaviour driven
> > > development\n framework for Ruby\n
\n
> > class=\"backtrace\">
./failing_examples/diffing_spec.rb:13:\n./spec/spec/runner/formatter/html_formatter_spec.rb:16:\n./spec/spec/runner/formatter/html_formatter_spec.rb:12:\n./spec/spec/runner/formatter/html_formatter_spec.rb:11:
\n > > >
\n
\n \n > > > \n > > > \n
\n > > class=\"failed_spec_name\">should print diff of different > > > objects' pretty representation\n
> > id=\"failure_5\">\n
> > class=\"message\">
<Animal\nname=bob,\nspecies=giraffe\n>\n
> > > should eql
> > > <Animal\nname=bob,\nspecies=tortoise\n>\n\nDiff:\n@@
> > > -1,5 +1,5 @@\n <Animal\n
> > > name=bob,\n-species=giraffe\n+species=tortoise\n
> > > >\n
\n
> > class=\"backtrace\">
./failing_examples/diffing_spec.rb:34:\n./spec/spec/runner/formatter/html_formatter_spec.rb:16:\n./spec/spec/runner/formatter/html_formatter_spec.rb:12:\n./spec/spec/runner/formatter/html_formatter_spec.rb:11:
\n > > >
\n
\n
\n
\n
\n
\n > > >
A consumer of a stub
\n \n
> > class=\"passed_spec_name\">should be able to stub methods > > > on any Object
\n
\n
\n
\n > > >
\n
A stubbed method on a class
\n \n
> > class=\"passed_spec_name\">should return the stubbed > > > value
\n \n
> > class=\"passed_spec_name\">should revert to the original > > > method after each spec
\n \n
> > class=\"passed_spec_name\">can stub! and mock the same message
\n > > >
\n
\n
\n
\n
A > > > mock
\n \n
> > class=\"passed_spec_name\">can stub!
\n \n
> > class=\"passed_spec_name\">can stub! and mock
\n \n
> > class=\"passed_spec_name\">can stub! and mock the same message
\n > > >
\n
\n\n\n
\n\n\n" > > > Diff: > > > > > > @@ -120,11 +120,8 @@ > > > 
Mock 'poke me' expected :poke with (any
> > > args) once, but received it 0 times
> > >
> > class="backtrace">
./failing_examples/mocking_example.rb:13:
> > >  ./spec/spec/runner/formatter/html_formatter_spec.rb:16:
> > > -./spec/spec/runner/formatter/html_formatter_spec.rb:12:in
> > > `chdir'
> > >  ./spec/spec/runner/formatter/html_formatter_spec.rb:12:
> > > -./spec/spec/runner/formatter/html_formatter_spec.rb:11:in
> > > `each'
> > > -./spec/spec/runner/formatter/html_formatter_spec.rb:11:
> > > -./spec/spec/runner/formatter/html_formatter_spec.rb:4:
> > > +./spec/spec/runner/formatter/html_formatter_spec.rb:11: > > > > > > > > > > > > > This seems to me to be about ruby version (and what it adds to > > backtraces), not OS. What version of ruby are you using? > > > > > > > > @@ -136,11 +133,8 @@ > > > 
Mock 'one two three' received :three out
> > > of order
> > >
> > class="backtrace">
./failing_examples/mocking_example.rb:22:
> > >  ./spec/spec/runner/formatter/html_formatter_spec.rb:16:
> > > -./spec/spec/runner/formatter/html_formatter_spec.rb:12:in
> > > `chdir'
> > >  ./spec/spec/runner/formatter/html_formatter_spec.rb:12:
> > > -./spec/spec/runner/formatter/html_formatter_spec.rb:11:in
> > > `each'
> > > -./spec/spec/runner/formatter/html_formatter_spec.rb:11:
> > > -./spec/spec/runner/formatter/html_formatter_spec.rb:4:
> > > +./spec/spec/runner/formatter/html_formatter_spec.rb:11: > > > > > > > > > > > > > > > @@ -152,11 +146,8 @@ > > > 
Mock 'don't talk to me' expected
> > > :any_message_at_all with (any args) 0 times, but received it
> > > once
> > >
> > class="backtrace">
./failing_examples/mocking_example.rb:28:
> > >  ./spec/spec/runner/formatter/html_formatter_spec.rb:16:
> > > -./spec/spec/runner/formatter/html_formatter_spec.rb:12:in
> > > `chdir'
> > >  ./spec/spec/runner/formatter/html_formatter_spec.rb:12:
> > > -./spec/spec/runner/formatter/html_formatter_spec.rb:11:in
> > > `each'
> > > -./spec/spec/runner/formatter/html_formatter_spec.rb:11:
> > > -./spec/spec/runner/formatter/html_formatter_spec.rb:4:
> > > +./spec/spec/runner/formatter/html_formatter_spec.rb:11: > > > > > > > > > > > > > > > @@ -180,11 +171,8 @@ > > > > > >
> > class="backtrace">
./failing_examples/diffing_spec.rb:13:
> > >  ./spec/spec/runner/formatter/html_formatter_spec.rb:16:
> > > -./spec/spec/runner/formatter/html_formatter_spec.rb:12:in
> > > `chdir'
> > >  ./spec/spec/runner/formatter/html_formatter_spec.rb:12:
> > > -./spec/spec/runner/formatter/html_formatter_spec.rb:11:in
> > > `each'
> > > -./spec/spec/runner/formatter/html_formatter_spec.rb:11:
> > > -./spec/spec/runner/formatter/html_formatter_spec.rb:4:
> > > +./spec/spec/runner/formatter/html_formatter_spec.rb:11: > > > > > > > > > > > > > > > @@ -212,11 +200,8 @@ > > > > > >
> > class="backtrace">
./failing_examples/diffing_spec.rb:34:
> > >  ./spec/spec/runner/formatter/html_formatter_spec.rb:16:
> > > -./spec/spec/runner/formatter/html_formatter_spec.rb:12:in
> > > `chdir'
> > >  ./spec/spec/runner/formatter/html_formatter_spec.rb:12:
> > > -./spec/spec/runner/formatter/html_formatter_spec.rb:11:in
> > > `each'
> > > -./spec/spec/runner/formatter/html_formatter_spec.rb:11:
> > > -./spec/spec/runner/formatter/html_formatter_spec.rb:4:
> > > +./spec/spec/runner/formatter/html_formatter_spec.rb:11: > > > > > > > > > > > > ./rspec/spec/spec/runner/formatter/html_formatter_spec.rb:31: > > > ./rspec/spec/spec/runner/formatter/html_formatter_spec.rb:12:in > > > `chdir' > > > ./rspec/spec/spec/runner/formatter/html_formatter_spec.rb:12: > > > ./rspec/spec/spec/runner/formatter/html_formatter_spec.rb:11:in > > > `each' > > > ./rspec/spec/spec/runner/formatter/html_formatter_spec.rb:11: > > > ./rspec/spec/spec/runner/formatter/html_formatter_spec.rb:4: > > > > > > Finished in 0.235957 seconds > > > > > > 1 specification, 1 failure > > > > > > Process finished with exit code 0 > > > > > > > > > > > > On 1/6/07, Brian Takita < brian.takita at gmail.com> wrote: > > > > It has to do with the backtraces. > > > > > > > > Actual: > > > > should fail when expected message not received > > > > > > > > Mock 'poke me' expected :poke with (any args) once, but received it 0 > > > times > > > > > > > > ./failing_examples/mocking_example.rb:13: > > > > > > > /home/btakita/workspace/rspec/rspec/spec/spec/runner/formatter/html_formatter_spec.rb:16: > > > > > > > /home/btakita/workspace/rspec/rspec/spec/spec/runner/formatter/html_formatter_spec.rb:12:in > > > `chdir' > > > > > > > > > > > > > > > /home/btakita/workspace/rspec/rspec/spec/spec/runner/formatter/html_formatter_spec.rb:12: > > > > > > > /home/btakita/workspace/rspec/rspec/spec/spec/runner/formatter/html_formatter_spec.rb:11:in > > > `each' > > > > > > > /home/btakita/workspace/rspec/rspec/spec/spec/runner/formatter/html_formatter_spec.rb:11: > > > > > > > > > > > > > > > /home/btakita/workspace/rspec/rspec/spec/spec/runner/formatter/html_formatter_spec.rb:4: > > > > > > > > Expected: > > > > > > > > should fail when expected message not received > > > > > > > > Mock 'poke me' expected :poke with (any args) once, but received it 0 > > > times > > > > > > > > ./failing_examples/mocking_example.rb:13: > > > > ./spec/spec/runner/formatter/html_formatter_spec.rb:16: > > > > ./spec/spec/runner/formatter/html_formatter_spec.rb:12: > > > > ./spec/spec/runner/formatter/html_formatter_spec.rb:11: This was already reported as a bug. It does seem to be related to ruby versions. http://rubyforge.org/tracker/index.php?func=detail&aid=7344&group_id=797&atid=3149 > > > > > > > > > > > > > > > > > > > > > > > > On 1/6/07, Brian Takita < brian.takita at gmail.com> wrote: > > > > > > > > > Hello, > > > > > > > > > > The build is breaking for me. > > > > > > > > > > 1) 'HtmlFormatter should produce HTML identical to the one we designed > > > manually' FAILED > > > > > > > > > > Is anybody else having this issue? I seem to remember getting this > > > before. > > > > > > > > > > Thanks, > > > > > Brian > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > rspec-devel mailing list > > > rspec-devel at rubyforge.org > > > http://rubyforge.org/mailman/listinfo/rspec-devel > > > > > > > > > From noreply at rubyforge.org Sat Jan 6 19:17:16 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sat, 6 Jan 2007 19:17:16 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-7636 ] drbspec not managing db connections appropriately Message-ID: <20070107001716.8FFAC5241572@rubyforge.org> Bugs item #7636, was opened at 2007-01-07 00:17 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=7636&group_id=797 Category: runner module Group: None Status: Open Resolution: None Priority: 3 Submitted By: Chris Anderson (jchris) Assigned to: Nobody (None) Summary: drbspec not managing db connections appropriately Initial Comment: I'm using the rails_spec_server and drbspec spec/ - the lastest versions (gem 0.7.6) - just generated from trunk yesterday. Running drbspec spec/ works as expected for about 30 runs, and then I start getting too many client errors from Postgres (gem 0.7.1). The same thing happens with the spec:autotest plugin - but it is just running drbspec repeatedly, as well. PGError in 'Given a generated source_report_spec.rb with fixtures loaded fixtures should load two SourceReports' FATAL: sorry, too many clients already script/rails_spec_server:16:in `run' script/rails_spec_server:37: I don't know if this is a specific to Postgres, but I do know I've never seen Postgres raise a too many clients error before in all my Rails work. Let me know if I can help with more information. jchris :: mfdz : com ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=7636&group_id=797 From noreply at rubyforge.org Sat Jan 6 19:35:43 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sat, 6 Jan 2007 19:35:43 -0500 (EST) Subject: [rspec-devel] [ rspec-Patches-7637 ] [PATCH] add skip-migration option to rspec_resource generator Message-ID: <20070107003543.BCB535241DBB@rubyforge.org> Patches item #7637, was opened at 2007-01-07 00:35 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=7637&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Chris Anderson (jchris) Assigned to: Nobody (None) Summary: [PATCH] add skip-migration option to rspec_resource generator Initial Comment: it should have this option, just like the regular Test::Unit version of it. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=7637&group_id=797 From brian.takita at gmail.com Sat Jan 6 18:05:21 2007 From: brian.takita at gmail.com (Brian Takita) Date: Sat, 6 Jan 2007 15:05:21 -0800 Subject: [rspec-devel] Build Breaking? In-Reply-To: <57c63afe0701060606n4092fbc3n2d9132442215f95d@mail.gmail.com> References: <1d7ddd110701060243s3e8cac4dkb8d6c1ed7c9dbb29@mail.gmail.com> <1d7ddd110701060256n3d376219j855700f44b67fef5@mail.gmail.com> <1d7ddd110701060313w21ce0584g538b1bd4f4781bfc@mail.gmail.com> <57c63afe0701060537s28b9efd3mb5ba26d76effbc55@mail.gmail.com> <57c63afe0701060539y2e37bf88v480db037aecfc22@mail.gmail.com> <57c63afe0701060606n4092fbc3n2d9132442215f95d@mail.gmail.com> Message-ID: <1d7ddd110701061505s74812899j9acfcb652bb86663@mail.gmail.com> On 1/6/07, David Chelimsky wrote: > > On 1/6/07, David Chelimsky wrote: > > On 1/6/07, David Chelimsky wrote: > > > On 1/6/07, Brian Takita wrote: > > > > I changed BaseTextFormatter > > > > > > > > def backtrace_line(line) > > > > line.sub(Dir.pwd, '.').sub(/\A([^:]+:\d+)$/, '\\1:') > > > > end > > > > > > > > This spec seems OS specific... > > > > > > > > /usr/local/bin/ruby > > > > > /home/btakita/workspace/rspec/rspec/spec/spec/runner/formatter/html_formatter_spec.rb > > > > > > Try standing in /home/btakita/workspace/rspec/rspec. That's where it's > > > intended to be run from. > > > To clarify - you won't have to add the pwd replace if you run it from > > the rspec root (rspec/rspec in this case). > > I ran rake from the rspec directory. Thats why Dir.pwd was the correct directory. Like you mentioned, it seems to be a difference in Ruby 1.8.5 > > > > > > > > > > F > > > > > > > > 1) > > > > 'HtmlFormatter should produce HTML identical to the one we designed > > > > manually' FAILED > > > > " > > > encoding=\"iso-8859-1\"?>\n > > > \"-//W3C//DTD XHTML 1.0 Transitional//EN\"\n \" > > > > http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd\">\n\n > > > xmlns=\"http://www.w3.org/1999/xhtml\" xml:lang=\"en\" > > > > lang=\"en\">\n\n RSpec results\n > > > http-equiv=\"Content-Type\" content=\"text/html; > charset=iso-8859-1\" />\n > > > > \n > > > http-equiv=\"Pragma\" content=\"no-cache\" />\n \n \n\n\n\n
\n > > > >

RSpec Results

\n\n
\n

> > > id=\"duration\"> 

\n

 

\n > > > >
\n
\n\n
\n
class=\"context\">\n
\n > > > >
Mocker
\n \n
> > > class=\"passed_spec_name\">should be able to call > > > > mock()
\n \n > > > > \n > > > > \n
\n > > > class=\"failed_spec_name\">should fail when expected > > > > message not received\n
> > > id=\"failure_1\">\n 
Mock 'poke
> me'
> > > > expected :poke with (any args) once, but received it 0
> times
\n > > > >
> > > > class=\"backtrace\">
./failing_examples/mocking_example.rb:13:\n./spec/spec/runner/formatter/html_formatter_spec.rb:16:\n./spec/spec/runner/formatter/html_formatter_spec.rb:12:in
> > > >
> `chdir'\n./spec/spec/runner/formatter/html_formatter_spec.rb:12:\n./spec/spec/runner/formatter/html_formatter_spec.rb:11:in
> > > >
> `each'\n./spec/spec/runner/formatter/html_formatter_spec.rb:11:\n./spec/spec/runner/formatter/html_formatter_spec.rb:4:
\n > > > >
\n
\n \n > > > > \n > > > > \n
\n > > > class=\"failed_spec_name\">should fail when messages are > > > > received out of order\n
> > > id=\"failure_2\">\n 
Mock 'one two
> three'
> > > > received :three out of order
\n
> > > > class=\"backtrace\">
./failing_examples/mocking_example.rb:22:\n./spec/spec/runner/formatter/html_formatter_spec.rb:16:\n./spec/spec/runner/formatter/html_formatter_spec.rb:12:in
> > > >
> `chdir'\n./spec/spec/runner/formatter/html_formatter_spec.rb:12:\n./spec/spec/runner/formatter/html_formatter_spec.rb:11:in
> > > >
> `each'\n./spec/spec/runner/formatter/html_formatter_spec.rb:11:\n./spec/spec/runner/formatter/html_formatter_spec.rb:4:
\n > > > >
\n
\n \n > > > > \n > > > > \n
\n > > > class=\"failed_spec_name\">should get yelled at when > > > > sending unexpected messages\n
> > > id=\"failure_3\">\n 
Mock 'don't
> talk to
> > > > me' expected :any_message_at_all with (any args) 0 times, but
> received it
> > > > once
\n
> > > > class=\"backtrace\">
./failing_examples/mocking_example.rb:28:\n./spec/spec/runner/formatter/html_formatter_spec.rb:16:\n./spec/spec/runner/formatter/html_formatter_spec.rb:12:in
> > > >
> `chdir'\n./spec/spec/runner/formatter/html_formatter_spec.rb:12:\n./spec/spec/runner/formatter/html_formatter_spec.rb:11:in
> > > >
> `each'\n./spec/spec/runner/formatter/html_formatter_spec.rb:11:\n./spec/spec/runner/formatter/html_formatter_spec.rb:4:
\n > > > >
\n
\n
\n
\n
class=\"context\">\n
\n > > > >
Running specs with --diff
\n \n > > > > \n > > > > \n
\n > > > class=\"failed_spec_name\">should print diff of different > > > > strings\n
id=\"failure_4\">\n
> > > class=\"message\">
"RSpec is a\\nbehavior driven
> > > > development\\nframework for Ruby\\n" should == "RSpec is
> > > > a\\nbehaviour driven development\\nframework for
> Ruby\\n"\nDiff:\n@@
> > > > -1,4 +1,4 @@\n RSpec is a\n-behavior driven development\n+behaviour
> driven
> > > > development\n framework for Ruby\n
\n
> > > > class=\"backtrace\">
./failing_examples/diffing_spec.rb:13:\n./spec/spec/runner/formatter/html_formatter_spec.rb:16:\n./spec/spec/runner/formatter/html_formatter_spec.rb:12:in
> > > >
> `chdir'\n./spec/spec/runner/formatter/html_formatter_spec.rb:12:\n./spec/spec/runner/formatter/html_formatter_spec.rb:11:in
> > > >
> `each'\n./spec/spec/runner/formatter/html_formatter_spec.rb:11:\n./spec/spec/runner/formatter/html_formatter_spec.rb:4:
\n > > > >
\n
\n \n > > > > \n > > > > \n
\n > > > class=\"failed_spec_name\">should print diff of different > > > > objects' pretty representation\n
> > > id=\"failure_5\">\n
> > > > class=\"message\">
<Animal\nname=bob,\nspecies=giraffe\n>\n
> > > > should eql
> > > > <Animal\nname=bob,\nspecies=tortoise\n>\n\nDiff:\n@@
> > > > -1,5 +1,5 @@\n <Animal\n
> > > > name=bob,\n-species=giraffe\n+species=tortoise\n
> > > > >\n
\n
> > > > class=\"backtrace\">
./failing_examples/diffing_spec.rb:34:\n./spec/spec/runner/formatter/html_formatter_spec.rb:16:\n./spec/spec/runner/formatter/html_formatter_spec.rb:12:in
> > > >
> `chdir'\n./spec/spec/runner/formatter/html_formatter_spec.rb:12:\n./spec/spec/runner/formatter/html_formatter_spec.rb:11:in
> > > >
> `each'\n./spec/spec/runner/formatter/html_formatter_spec.rb:11:\n./spec/spec/runner/formatter/html_formatter_spec.rb:4:
\n > > > >
\n
\n
\n
\n
class=\"context\">\n
\n > > > >
A consumer of a stub
\n \n
> > > class=\"passed_spec_name\">should be able to stub methods > > > > on any Object
\n
\n
\n
class=\"context\">\n > > > >
\n
A stubbed method on a > class
\n \n
> > > class=\"passed_spec_name\">should return the stubbed > > > > value
\n \n
> > > class=\"passed_spec_name\">should revert to the original > > > > method after each spec
\n \n
> > > class=\"passed_spec_name\">can stub! and mock the same > message
\n > > > >
\n
\n
\n
\n
id=\"context_5\">A > > > > mock
\n \n
> > > class=\"passed_spec_name\">can stub!
\n \n
> > > class=\"passed_spec_name\">can stub! and > mock
\n \n
> > > class=\"passed_spec_name\">can stub! and mock the same > message
\n > > > >
\n
\n\n\n
\n\n\n" should == > > > > " > > > encoding=\"iso-8859-1\"?>\n > > > \"-//W3C//DTD XHTML 1.0 Transitional//EN\"\n > > > > \"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd\ > > > > ">\n\n > > > lang=\"en\">\n\n RSpec results\n > > > http-equiv=\"Content-Type\" content=\"text/html; > charset=iso-8859-1\" />\n > > > > \n > > > http-equiv=\"Pragma\" content=\"no-cache\" />\n \n \n\n\n\n
\n > > > >

RSpec Results

\n\n
\n

> > > id=\"duration\"> 

\n

 

\n > > > >
\n
\n\n
\n
class=\"context\">\n
\n > > > >
Mocker
\n \n
> > > class=\"passed_spec_name\">should be able to call > > > > mock()
\n \n > > > > \n > > > > \n
\n > > > class=\"failed_spec_name\">should fail when expected > > > > message not received\n
> > > id=\"failure_1\">\n 
Mock 'poke
> me'
> > > > expected :poke with (any args) once, but received it 0
> times
\n > > > >
> > > > class=\"backtrace\">
./failing_examples/mocking_example.rb:13:\n./spec/spec/runner/formatter/html_formatter_spec.rb:16:\n./spec/spec/runner/formatter/html_formatter_spec.rb:12:\n./spec/spec/runner/formatter/html_formatter_spec.rb:11:
\n > > > >
\n
\n \n > > > > \n > > > > \n
\n > > > class=\"failed_spec_name\">should fail when messages are > > > > received out of order\n
> > > id=\"failure_2\">\n 
Mock 'one two
> three'
> > > > received :three out of order
\n
> > > > class=\"backtrace\">
./failing_examples/mocking_example.rb:22:\n./spec/spec/runner/formatter/html_formatter_spec.rb:16:\n./spec/spec/runner/formatter/html_formatter_spec.rb:12:\n./spec/spec/runner/formatter/html_formatter_spec.rb:11:
\n > > > >
\n
\n \n > > > > \n > > > > \n
\n > > > class=\"failed_spec_name\">should get yelled at when > > > > sending unexpected messages\n
> > > id=\"failure_3\">\n 
Mock 'don't
> talk to
> > > > me' expected :any_message_at_all with (any args) 0 times, but
> received it
> > > > once
\n
> > > > class=\"backtrace\">
./failing_examples/mocking_example.rb:28:\n./spec/spec/runner/formatter/html_formatter_spec.rb:16:\n./spec/spec/runner/formatter/html_formatter_spec.rb:12:\n./spec/spec/runner/formatter/html_formatter_spec.rb:11:
\n > > > >
\n
\n
\n
\n
> > > class=\"context\">\n
\n
Running specs > with > > > > --diff
\n \n > > > > \n > > > > \n
\n > > > class=\"failed_spec_name\">should print diff of different > > > > strings\n
id=\"failure_4\">\n
> > > class=\"message\">
"RSpec is a\\nbehavior driven
> > > > development\\nframework for Ruby\\n" should == "RSpec is
> > > > a\\nbehaviour driven development\\nframework for
> Ruby\\n"\nDiff:\n@@
> > > > -1,4 +1,4 @@\n RSpec is a\n-behavior driven development\n+behaviour
> driven
> > > > development\n framework for Ruby\n
\n
> > > > class=\"backtrace\">
./failing_examples/diffing_spec.rb:13:\n./spec/spec/runner/formatter/html_formatter_spec.rb:16:\n./spec/spec/runner/formatter/html_formatter_spec.rb:12:\n./spec/spec/runner/formatter/html_formatter_spec.rb:11:
\n > > > >
\n
\n \n > > > > \n > > > > \n
\n > > > class=\"failed_spec_name\">should print diff of different > > > > objects' pretty representation\n
> > > id=\"failure_5\">\n
> > > > class=\"message\">
<Animal\nname=bob,\nspecies=giraffe\n>\n
> > > > should eql
> > > > <Animal\nname=bob,\nspecies=tortoise\n>\n\nDiff:\n@@
> > > > -1,5 +1,5 @@\n <Animal\n
> > > > name=bob,\n-species=giraffe\n+species=tortoise\n
> > > > >\n
\n
> > > > class=\"backtrace\">
./failing_examples/diffing_spec.rb:34:\n./spec/spec/runner/formatter/html_formatter_spec.rb:16:\n./spec/spec/runner/formatter/html_formatter_spec.rb:12:\n./spec/spec/runner/formatter/html_formatter_spec.rb:11:
\n > > > >
\n
\n
\n
\n
class=\"context\">\n
\n > > > >
A consumer of a stub
\n \n
> > > class=\"passed_spec_name\">should be able to stub methods > > > > on any Object
\n
\n
\n
class=\"context\">\n > > > >
\n
A stubbed method on a > class
\n \n
> > > class=\"passed_spec_name\">should return the stubbed > > > > value
\n \n
> > > class=\"passed_spec_name\">should revert to the original > > > > method after each spec
\n \n
> > > class=\"passed_spec_name\">can stub! and mock the same > message
\n > > > >
\n
\n
\n
\n
id=\"context_5\">A > > > > mock
\n \n
> > > class=\"passed_spec_name\">can stub!
\n \n
> > > class=\"passed_spec_name\">can stub! and > mock
\n \n
> > > class=\"passed_spec_name\">can stub! and mock the same > message
\n > > > >
\n
\n\n\n
\n\n\n" > > > > Diff: > > > > > > > > @@ -120,11 +120,8 @@ > > > > 
Mock 'poke me' expected :poke
> with (any
> > > > args) once, but received it 0 times
> > > >
> > > class="backtrace">
./failing_examples/mocking_example.rb:13:
> > > >  ./spec/spec/runner/formatter/html_formatter_spec.rb:16:
> > > > -./spec/spec/runner/formatter/html_formatter_spec.rb:12:in
> > > > `chdir'
> > > >  ./spec/spec/runner/formatter/html_formatter_spec.rb:12:
> > > > -./spec/spec/runner/formatter/html_formatter_spec.rb:11:in
> > > > `each'
> > > > -./spec/spec/runner/formatter/html_formatter_spec.rb:11:
> > > > -./spec/spec/runner/formatter/html_formatter_spec.rb:4:
> > > > +./spec/spec/runner/formatter/html_formatter_spec.rb:11: > > > > > > > > > > > > > > > > > > This seems to me to be about ruby version (and what it adds to > > > backtraces), not OS. What version of ruby are you using? > > > > > > > > > > > @@ -136,11 +133,8 @@ > > > > 
Mock 'one two three' received
> :three out
> > > > of order
> > > >
> > > class="backtrace">
./failing_examples/mocking_example.rb:22:
> > > >  ./spec/spec/runner/formatter/html_formatter_spec.rb:16:
> > > > -./spec/spec/runner/formatter/html_formatter_spec.rb:12:in
> > > > `chdir'
> > > >  ./spec/spec/runner/formatter/html_formatter_spec.rb:12:
> > > > -./spec/spec/runner/formatter/html_formatter_spec.rb:11:in
> > > > `each'
> > > > -./spec/spec/runner/formatter/html_formatter_spec.rb:11:
> > > > -./spec/spec/runner/formatter/html_formatter_spec.rb:4:
> > > > +./spec/spec/runner/formatter/html_formatter_spec.rb:11: > > > > > > > > > > > > > > > > > > > > @@ -152,11 +146,8 @@ > > > > 
Mock 'don't talk to me' expected
> > > > :any_message_at_all with (any args) 0 times, but received it
> > > > once
> > > >
> > > class="backtrace">
./failing_examples/mocking_example.rb:28:
> > > >  ./spec/spec/runner/formatter/html_formatter_spec.rb:16:
> > > > -./spec/spec/runner/formatter/html_formatter_spec.rb:12:in
> > > > `chdir'
> > > >  ./spec/spec/runner/formatter/html_formatter_spec.rb:12:
> > > > -./spec/spec/runner/formatter/html_formatter_spec.rb:11:in
> > > > `each'
> > > > -./spec/spec/runner/formatter/html_formatter_spec.rb:11:
> > > > -./spec/spec/runner/formatter/html_formatter_spec.rb:4:
> > > > +./spec/spec/runner/formatter/html_formatter_spec.rb:11: > > > > > > > > > > > > > > > > > > > > @@ -180,11 +171,8 @@ > > > > > > > >
> > > class="backtrace">
./failing_examples/diffing_spec.rb:13:
> > > >  ./spec/spec/runner/formatter/html_formatter_spec.rb:16:
> > > > -./spec/spec/runner/formatter/html_formatter_spec.rb:12:in
> > > > `chdir'
> > > >  ./spec/spec/runner/formatter/html_formatter_spec.rb:12:
> > > > -./spec/spec/runner/formatter/html_formatter_spec.rb:11:in
> > > > `each'
> > > > -./spec/spec/runner/formatter/html_formatter_spec.rb:11:
> > > > -./spec/spec/runner/formatter/html_formatter_spec.rb:4:
> > > > +./spec/spec/runner/formatter/html_formatter_spec.rb:11: > > > > > > > > > > > > > > > > > > > > @@ -212,11 +200,8 @@ > > > > > > > >
> > > class="backtrace">
./failing_examples/diffing_spec.rb:34:
> > > >  ./spec/spec/runner/formatter/html_formatter_spec.rb:16:
> > > > -./spec/spec/runner/formatter/html_formatter_spec.rb:12:in
> > > > `chdir'
> > > >  ./spec/spec/runner/formatter/html_formatter_spec.rb:12:
> > > > -./spec/spec/runner/formatter/html_formatter_spec.rb:11:in
> > > > `each'
> > > > -./spec/spec/runner/formatter/html_formatter_spec.rb:11:
> > > > -./spec/spec/runner/formatter/html_formatter_spec.rb:4:
> > > > +./spec/spec/runner/formatter/html_formatter_spec.rb:11: > > > > > > > > > > > > > > > > ./rspec/spec/spec/runner/formatter/html_formatter_spec.rb:31: > > > > ./rspec/spec/spec/runner/formatter/html_formatter_spec.rb:12:in > > > > `chdir' > > > > ./rspec/spec/spec/runner/formatter/html_formatter_spec.rb:12: > > > > ./rspec/spec/spec/runner/formatter/html_formatter_spec.rb:11:in > > > > `each' > > > > ./rspec/spec/spec/runner/formatter/html_formatter_spec.rb:11: > > > > ./rspec/spec/spec/runner/formatter/html_formatter_spec.rb:4: > > > > > > > > Finished in 0.235957 seconds > > > > > > > > 1 specification, 1 failure > > > > > > > > Process finished with exit code 0 > > > > > > > > > > > > > > > > On 1/6/07, Brian Takita < brian.takita at gmail.com> wrote: > > > > > It has to do with the backtraces. > > > > > > > > > > Actual: > > > > > should fail when expected message not received > > > > > > > > > > Mock 'poke me' expected :poke with (any args) once, but received > it 0 > > > > times > > > > > > > > > > ./failing_examples/mocking_example.rb:13: > > > > > > > > > > /home/btakita/workspace/rspec/rspec/spec/spec/runner/formatter/html_formatter_spec.rb:16: > > > > > > > > > > /home/btakita/workspace/rspec/rspec/spec/spec/runner/formatter/html_formatter_spec.rb:12:in > > > > `chdir' > > > > > > > > > > > > > > > > > > > > /home/btakita/workspace/rspec/rspec/spec/spec/runner/formatter/html_formatter_spec.rb:12: > > > > > > > > > > /home/btakita/workspace/rspec/rspec/spec/spec/runner/formatter/html_formatter_spec.rb:11:in > > > > `each' > > > > > > > > > > /home/btakita/workspace/rspec/rspec/spec/spec/runner/formatter/html_formatter_spec.rb:11: > > > > > > > > > > > > > > > > > > > > /home/btakita/workspace/rspec/rspec/spec/spec/runner/formatter/html_formatter_spec.rb:4: > > > > > > > > > > Expected: > > > > > > > > > > should fail when expected message not received > > > > > > > > > > Mock 'poke me' expected :poke with (any args) once, but received > it 0 > > > > times > > > > > > > > > > ./failing_examples/mocking_example.rb:13: > > > > > ./spec/spec/runner/formatter/html_formatter_spec.rb:16: > > > > > ./spec/spec/runner/formatter/html_formatter_spec.rb:12: > > > > > ./spec/spec/runner/formatter/html_formatter_spec.rb:11: > > This was already reported as a bug. It does seem to be related to ruby > versions. > > > http://rubyforge.org/tracker/index.php?func=detail&aid=7344&group_id=797&atid=3149 I see. What would be a good way to make this spec less brittle? I can think of two things. 1. Make a Ruby 1.8.5 specific html file to compare against. It would need to be genetated because the absolute path is included in the backtrace. 2. Use Hpricot to specify certain parts of the document. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 1/6/07, Brian Takita < brian.takita at gmail.com> wrote: > > > > > > > > > > > Hello, > > > > > > > > > > > > The build is breaking for me. > > > > > > > > > > > > 1) 'HtmlFormatter should produce HTML identical to the one we > designed > > > > manually' FAILED > > > > > > > > > > > > Is anybody else having this issue? I seem to remember getting > this > > > > before. > > > > > > > > > > > > Thanks, > > > > > > 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/20070106/ed82f9df/attachment-0001.html From noreply at rubyforge.org Sat Jan 6 20:03:09 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sat, 6 Jan 2007 20:03:09 -0500 (EST) Subject: [rspec-devel] [ rspec-Patches-7637 ] [PATCH] add skip-migration option to rspec_resource generator Message-ID: <20070107010309.9E7F95241572@rubyforge.org> Patches item #7637, was opened at 2007-01-07 00:35 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=7637&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Chris Anderson (jchris) Assigned to: Nobody (None) Summary: [PATCH] add skip-migration option to rspec_resource generator Initial Comment: it should have this option, just like the regular Test::Unit version of it. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-01-07 01:03 Message: Where's the file? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=7637&group_id=797 From noreply at rubyforge.org Sat Jan 6 20:05:48 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sat, 6 Jan 2007 20:05:48 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-7636 ] drbspec not managing db connections appropriately Message-ID: <20070107010548.921D25241572@rubyforge.org> Bugs item #7636, was opened at 2007-01-07 00:17 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=7636&group_id=797 Category: runner module Group: None Status: Open Resolution: None Priority: 3 Submitted By: Chris Anderson (jchris) Assigned to: Nobody (None) Summary: drbspec not managing db connections appropriately Initial Comment: I'm using the rails_spec_server and drbspec spec/ - the lastest versions (gem 0.7.6) - just generated from trunk yesterday. Running drbspec spec/ works as expected for about 30 runs, and then I start getting too many client errors from Postgres (gem 0.7.1). The same thing happens with the spec:autotest plugin - but it is just running drbspec repeatedly, as well. PGError in 'Given a generated source_report_spec.rb with fixtures loaded fixtures should load two SourceReports' FATAL: sorry, too many clients already script/rails_spec_server:16:in `run' script/rails_spec_server:37: I don't know if this is a specific to Postgres, but I do know I've never seen Postgres raise a too many clients error before in all my Rails work. Let me know if I can help with more information. jchris :: mfdz : com ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-01-07 01:05 Message: Have you had a similar experience just running 'rake spec'? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=7636&group_id=797 From noreply at rubyforge.org Sat Jan 6 22:04:21 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sat, 6 Jan 2007 22:04:21 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-7533 ] Spec suite fails and the process exits with a code 0 Message-ID: <20070107030421.0B8C35241DE9@rubyforge.org> Bugs item #7533, was opened at 2007-01-02 20:40 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=7533&group_id=797 Category: runner module Group: None Status: Open Resolution: None Priority: 3 Submitted By: Brian Takita (btakita) Assigned to: Nobody (None) Summary: Spec suite fails and the process exits with a code 0 Initial Comment: The process should exit with an error code (e.g. 1) ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-01-07 03:04 Message: Fixed in trunk (rev 7533). CommandLine#run now defaults to exit=true. ---------------------------------------------------------------------- Comment By: Brian Takita (btakita) Date: 2007-01-06 01:19 Message: Ouch, I got bitten by this again. ---------------------------------------------------------------------- Comment By: Brian Takita (btakita) Date: 2007-01-02 20:55 Message: It happens because I called the `ruby spec_suite.rb` instead of `spec spec_suite.rb`. Should we default CommandLine#run exit argument to true? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=7533&group_id=797 From noreply at rubyforge.org Sat Jan 6 22:04:37 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sat, 6 Jan 2007 22:04:37 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-7533 ] Spec suite fails and the process exits with a code 0 Message-ID: <20070107030437.263C75241DE9@rubyforge.org> Bugs item #7533, was opened at 2007-01-02 20:40 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=7533&group_id=797 Category: runner module Group: None >Status: Closed >Resolution: Accepted Priority: 3 Submitted By: Brian Takita (btakita) >Assigned to: David Chelimsky (dchelimsky) Summary: Spec suite fails and the process exits with a code 0 Initial Comment: The process should exit with an error code (e.g. 1) ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-01-07 03:04 Message: Fixed in trunk (rev 7533). CommandLine#run now defaults to exit=true. ---------------------------------------------------------------------- Comment By: Brian Takita (btakita) Date: 2007-01-06 01:19 Message: Ouch, I got bitten by this again. ---------------------------------------------------------------------- Comment By: Brian Takita (btakita) Date: 2007-01-02 20:55 Message: It happens because I called the `ruby spec_suite.rb` instead of `spec spec_suite.rb`. Should we default CommandLine#run exit argument to true? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=7533&group_id=797 From wilsonb at gmail.com Sat Jan 6 23:52:19 2007 From: wilsonb at gmail.com (Wilson Bilkovich) Date: Sat, 6 Jan 2007 23:52:19 -0500 Subject: [rspec-devel] Build Breaking? In-Reply-To: <1d7ddd110701061505s74812899j9acfcb652bb86663@mail.gmail.com> References: <1d7ddd110701060243s3e8cac4dkb8d6c1ed7c9dbb29@mail.gmail.com> <1d7ddd110701060256n3d376219j855700f44b67fef5@mail.gmail.com> <1d7ddd110701060313w21ce0584g538b1bd4f4781bfc@mail.gmail.com> <57c63afe0701060537s28b9efd3mb5ba26d76effbc55@mail.gmail.com> <57c63afe0701060539y2e37bf88v480db037aecfc22@mail.gmail.com> <57c63afe0701060606n4092fbc3n2d9132442215f95d@mail.gmail.com> <1d7ddd110701061505s74812899j9acfcb652bb86663@mail.gmail.com> Message-ID: On 1/6/07, Brian Takita wrote: > On 1/6/07, David Chelimsky wrote: > > > > This was already reported as a bug. It does seem to be related to ruby > versions. > > > > > http://rubyforge.org/tracker/index.php?func=detail&aid=7344&group_id=797&atid=3149 > > I see. What would be a good way to make this spec less brittle? > I can think of two things. > 1. Make a Ruby 1.8.5 specific html file to compare against. It would need to > be genetated because the absolute path is included in the backtrace. > 2. Use Hpricot to specify certain parts of the document. > We could 'eat our own dog food' by using the assert_select port. I suppose that would introduce a dependency between the two sections of the project, though. From dchelimsky at gmail.com Sun Jan 7 06:26:35 2007 From: dchelimsky at gmail.com (David Chelimsky) Date: Sun, 7 Jan 2007 06:26:35 -0500 Subject: [rspec-devel] Build Breaking? In-Reply-To: References: <1d7ddd110701060243s3e8cac4dkb8d6c1ed7c9dbb29@mail.gmail.com> <1d7ddd110701060256n3d376219j855700f44b67fef5@mail.gmail.com> <1d7ddd110701060313w21ce0584g538b1bd4f4781bfc@mail.gmail.com> <57c63afe0701060537s28b9efd3mb5ba26d76effbc55@mail.gmail.com> <57c63afe0701060539y2e37bf88v480db037aecfc22@mail.gmail.com> <57c63afe0701060606n4092fbc3n2d9132442215f95d@mail.gmail.com> <1d7ddd110701061505s74812899j9acfcb652bb86663@mail.gmail.com> Message-ID: <57c63afe0701070326k70f9585ft101c3fac7f2e6492@mail.gmail.com> On 1/6/07, Wilson Bilkovich wrote: > On 1/6/07, Brian Takita wrote: > > On 1/6/07, David Chelimsky wrote: > > > > > > This was already reported as a bug. It does seem to be related to ruby > > versions. > > > > > > > > http://rubyforge.org/tracker/index.php?func=detail&aid=7344&group_id=797&atid=3149 > > > > I see. What would be a good way to make this spec less brittle? > > I can think of two things. > > 1. Make a Ruby 1.8.5 specific html file to compare against. It would need to > > be genetated because the absolute path is included in the backtrace. > > 2. Use Hpricot to specify certain parts of the document. > > I'm more inclined to go w/ two versions of the file. We've discovered bugs a couple of times because that file is so specific. > > We could 'eat our own dog food' by using the assert_select port. I > suppose that would introduce a dependency between the two sections of > the project, though. Right. Interesting idea, but we don't want that dependency. Thanks, David > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From brian.takita at gmail.com Sun Jan 7 16:30:44 2007 From: brian.takita at gmail.com (Brian Takita) Date: Sun, 7 Jan 2007 13:30:44 -0800 Subject: [rspec-devel] Build Breaking? In-Reply-To: <57c63afe0701070326k70f9585ft101c3fac7f2e6492@mail.gmail.com> References: <1d7ddd110701060243s3e8cac4dkb8d6c1ed7c9dbb29@mail.gmail.com> <1d7ddd110701060256n3d376219j855700f44b67fef5@mail.gmail.com> <1d7ddd110701060313w21ce0584g538b1bd4f4781bfc@mail.gmail.com> <57c63afe0701060537s28b9efd3mb5ba26d76effbc55@mail.gmail.com> <57c63afe0701060539y2e37bf88v480db037aecfc22@mail.gmail.com> <57c63afe0701060606n4092fbc3n2d9132442215f95d@mail.gmail.com> <1d7ddd110701061505s74812899j9acfcb652bb86663@mail.gmail.com> <57c63afe0701070326k70f9585ft101c3fac7f2e6492@mail.gmail.com> Message-ID: <1d7ddd110701071330m63b038abr586deaea4a8f9579@mail.gmail.com> On 1/7/07, David Chelimsky wrote: > > On 1/6/07, Wilson Bilkovich wrote: > > On 1/6/07, Brian Takita wrote: > > > On 1/6/07, David Chelimsky wrote: > > > > > > > > This was already reported as a bug. It does seem to be related to > ruby > > > versions. > > > > > > > > > > > > http://rubyforge.org/tracker/index.php?func=detail&aid=7344&group_id=797&atid=3149 > > > > > > I see. What would be a good way to make this spec less brittle? > > > I can think of two things. > > > 1. Make a Ruby 1.8.5 specific html file to compare against. It would > need to > > > be genetated because the absolute path is included in the backtrace. > > > 2. Use Hpricot to specify certain parts of the document. > > > > > I'm more inclined to go w/ two versions of the file. We've discovered > bugs a couple of times because that file is so specific. The only thing is ruby 1.8.5 has the full path in the backtrace. This wouldn't work with a static html file, but does work with erb... This does introduce the need for branching logic in the spec. Is that okay? > > > We could 'eat our own dog food' by using the assert_select port. I > > suppose that would introduce a dependency between the two sections of > > the project, though. > > Right. Interesting idea, but we don't want that dependency. > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20070107/2a4a97aa/attachment.html From noreply at rubyforge.org Mon Jan 8 20:21:12 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 8 Jan 2007 20:21:12 -0500 (EST) Subject: [rspec-devel] [ rspec-Patches-7685 ] spec_ui feedback and patch Message-ID: <20070109012112.6EA8C5241E72@rubyforge.org> Patches item #7685, was opened at 2007-01-08 18:21 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=7685&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Alvin Schur (aschur) Assigned to: Nobody (None) Summary: spec_ui feedback and patch Initial Comment: Here is a patch that helps me use spec_ui on WinXP. I use IE and I do not use rails. Fixtures are loaded manually and work well with context_setup, and setup. The spec_ui bundle helps me keep the project clean :) However, I am having difficulty with the screen snapshot feature: * either I get a screen snapshot of the DOS box I run rake in * OR I get the message: Insufficient image data in file `' which I am still investigating. Alvin Schur. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=7685&group_id=797 From noreply at rubyforge.org Tue Jan 9 20:20:04 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 9 Jan 2007 20:20:04 -0500 (EST) Subject: [rspec-devel] [ rspec-Feature Requests-7721 ] create date proximity expectation Message-ID: <20070110012005.00A9D524142D@rubyforge.org> Feature Requests item #7721, was opened at 2007-01-10 01:20 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=7721&group_id=797 Category: None Group: None Status: Open Priority: 3 Submitted By: Steve Ross (sxross) Assigned to: Nobody (None) Summary: create date proximity expectation Initial Comment: Often I am testing dates, but don't need absolute equality (time ticks away between lines of code, or the date matters but the time doesn't). Proposal: extend Time, DateTime, and Date to have expectations like: some_date.should_be_close_to(1.week.ago, :days => 1) There may be some nicer syntax for this, but I stole it from a simple implementation (below) I did in Test::Unit. module Test module Unit module Assertions SECONDS_IN_MINUTE = 60 SECONDS_IN_HOUR = SECONDS_IN_MINUTE * 60 SECONDS_IN_DAY = SECONDS_IN_HOUR * 24 def assert_date_proximity(expected_date, observed_date, fuzziness = {}) raise "first date must be of type Time" unless expected_date.class == Time raise "second date must be of type Time" unless observed_date.class == Time options = {:seconds => 0, :minutes => 1, :hours => 0, :days => 0}.merge(fuzziness) time_threshold = 0 time_threshold += options[:days] * SECONDS_IN_DAY if options[:days] time_threshold += options[:hours] * SECONDS_IN_HOUR if options[:hours] time_threshold += options[:minutes] * SECONDS_IN_MINUTE if options[:minutes] time_threshold += options[:seconds] if options[:seconds] assert_block('date not within specified threshold. expected <%s> / got <%s> thresh. <%d sec>' % [expected_date, observed_date, time_threshold]) do (observed_date - expected_date).abs <= time_threshold end end end end end ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=7721&group_id=797 From dchelimsky at gmail.com Tue Jan 9 23:11:33 2007 From: dchelimsky at gmail.com (David Chelimsky) Date: Tue, 9 Jan 2007 22:11:33 -0600 Subject: [rspec-devel] rspec.should embrace_change Message-ID: <57c63afe0701092011x2192cf28j12904bac88f911e8@mail.gmail.com> All, I just committed a small change to rspec that could have far-reaching implications: context "a dog" do specify "should say hi" do dog = Dog.new dog.should say_hi("woof") end end The thing to pay attention to there is this line: dog.should say_hi("woof") What's happening is that #should is accepting the result of say_hi("woof"), which is a method that returns an object that responds to #met_by?(target) and #failure_message: class SayHi def initialize(greeting) @expected = greeting end def met_by?(target) @actual = target.say_hi @actual == @expected end def failure_message "expected say_hi to return #{@expected} but got {@actual}" end end This allows us to do a couple of things. One, we can move towards having only one method on Object and NO SUGAR! We can do this by converting all of the current should_xyz methods into xyz methods that return XyzExpectation instances. These methods would need to be made available to all specs. We can deprecate the existing should_xyz methods and, when the time comes to remove them, modifying specs is just a matter of replacing should_xyz with should xyz. Simple! Second, it opens the door for custom expectations: module MyCustomExpectations class SayHi ... end end context "visiting day at the zoo" do include MyCustomExpectations specify "a dog should say hi" do Dog.new.should say_hi('arf') end specify "a cow should say hi" do Cow.new.should say_hi('moo') end end I'm really excited about the implications of this and I'm curious to hear your feedback. David From dchelimsky at gmail.com Tue Jan 9 23:13:53 2007 From: dchelimsky at gmail.com (David Chelimsky) Date: Tue, 9 Jan 2007 22:13:53 -0600 Subject: [rspec-devel] rspec.should embrace_change In-Reply-To: <57c63afe0701092011x2192cf28j12904bac88f911e8@mail.gmail.com> References: <57c63afe0701092011x2192cf28j12904bac88f911e8@mail.gmail.com> Message-ID: <57c63afe0701092013r476cb87cw657e3858cffef0f9@mail.gmail.com> On 1/9/07, David Chelimsky wrote: > All, > > I just committed a small change to rspec that could have far-reaching > implications: > > context "a dog" do > specify "should say hi" do > dog = Dog.new > dog.should say_hi("woof") > end > end > > The thing to pay attention to there is this line: > > dog.should say_hi("woof") > > What's happening is that #should is accepting the result of > say_hi("woof"), which is a method that returns an object that responds > to #met_by?(target) and #failure_message: > > class SayHi > def initialize(greeting) > @expected = greeting > end > > def met_by?(target) > @actual = target.say_hi > @actual == @expected > end > > def failure_message > "expected say_hi to return #{@expected} but got {@actual}" > end > end > > This allows us to do a couple of things. One, we can move towards > having only one method on Object and NO SUGAR! We can do this by > converting all of the current should_xyz methods into xyz methods that > return XyzExpectation instances. These methods would need to be made > available to all specs. > > We can deprecate the existing should_xyz methods and, when the time > comes to remove them, modifying specs is just a matter of replacing > should_xyz with should xyz. Simple! > > Second, it opens the door for custom expectations: > > module MyCustomExpectations > class SayHi > ... > end > end > > context "visiting day at the zoo" do > include MyCustomExpectations > specify "a dog should say hi" do > Dog.new.should say_hi('arf') > end > specify "a cow should say hi" do > Cow.new.should say_hi('moo') > end > end > > I'm really excited about the implications of this and I'm curious to > hear your feedback. > > David I should point out that this idea comes from Dan North, with whom I've been batting around ideas for a story_runner and some changes to the current syntax in order to clean things up and improve the BDD focus. Cheers, David From noreply at rubyforge.org Wed Jan 10 23:09:35 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 10 Jan 2007 23:09:35 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-7743 ] specing private class methods messes with their scope Message-ID: <20070111040935.364FD5241822@rubyforge.org> Bugs item #7743, was opened at 2007-01-11 04:09 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=7743&group_id=797 Category: mock module Group: None Status: Open Resolution: None Priority: 3 Submitted By: Chris Anderson (jchris) Assigned to: Nobody (None) Summary: specing private class methods messes with their scope Initial Comment: When a class is speced as 'should_receive' a for a private method, later calls to a public class method which then calls the private method are treated as though they came from outside the class (eg: the private method called error is raised). If you then call the same public class method in a later context, you get an undefined method error when it calls the private method. specs attached. Thanks! This looks like a tough one... ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=7743&group_id=797 From noreply at rubyforge.org Thu Jan 11 00:02:55 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 11 Jan 2007 00:02:55 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-7743 ] specing private class methods messes with their scope Message-ID: <20070111050255.10F1252418B5@rubyforge.org> Bugs item #7743, was opened at 2007-01-11 04:09 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=7743&group_id=797 Category: mock module Group: None >Status: Closed >Resolution: Rejected Priority: 3 Submitted By: Chris Anderson (jchris) >Assigned to: David Chelimsky (dchelimsky) Summary: specing private class methods messes with their scope Initial Comment: When a class is speced as 'should_receive' a for a private method, later calls to a public class method which then calls the private method are treated as though they came from outside the class (eg: the private method called error is raised). If you then call the same public class method in a later context, you get an undefined method error when it calls the private method. specs attached. Thanks! This looks like a tough one... ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-01-11 05:02 Message: Mocking private methods (instance or class) is not supported by RSpec. I'll make this clear in the docs for the next release. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=7743&group_id=797 From noreply at rubyforge.org Thu Jan 11 07:58:33 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 11 Jan 2007 07:58:33 -0500 (EST) Subject: [rspec-devel] [ rspec-Feature Requests-7721 ] create date proximity expectation Message-ID: <20070111125833.B37B452410B8@rubyforge.org> Feature Requests item #7721, was opened at 2007-01-10 01:20 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=7721&group_id=797 >Category: expectation module Group: None >Status: Closed Priority: 3 Submitted By: Steve Ross (sxross) >Assigned to: David Chelimsky (dchelimsky) Summary: create date proximity expectation Initial Comment: Often I am testing dates, but don't need absolute equality (time ticks away between lines of code, or the date matters but the time doesn't). Proposal: extend Time, DateTime, and Date to have expectations like: some_date.should_be_close_to(1.week.ago, :days => 1) There may be some nicer syntax for this, but I stole it from a simple implementation (below) I did in Test::Unit. module Test module Unit module Assertions SECONDS_IN_MINUTE = 60 SECONDS_IN_HOUR = SECONDS_IN_MINUTE * 60 SECONDS_IN_DAY = SECONDS_IN_HOUR * 24 def assert_date_proximity(expected_date, observed_date, fuzziness = {}) raise "first date must be of type Time" unless expected_date.class == Time raise "second date must be of type Time" unless observed_date.class == Time options = {:seconds => 0, :minutes => 1, :hours => 0, :days => 0}.merge(fuzziness) time_threshold = 0 time_threshold += options[:days] * SECONDS_IN_DAY if options[:days] time_threshold += options[:hours] * SECONDS_IN_HOUR if options[:hours] time_threshold += options[:minutes] * SECONDS_IN_MINUTE if options[:minutes] time_threshold += options[:seconds] if options[:seconds] assert_block('date not within specified threshold. expected <%s> / got <%s> thresh. <%d sec>' % [expected_date, observed_date, time_threshold]) do (observed_date - expected_date).abs <= time_threshold end end end end end ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-01-11 12:58 Message: Rather than adding a new expectations, we've provided a mechanism for easily creating your own custom expectations (as of trunk-1371). This will be documented and part of the next release (0.7.6 || 0.8) ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=7721&group_id=797 From noreply at rubyforge.org Thu Jan 11 10:19:08 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 11 Jan 2007 10:19:08 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-7754 ] Command-R fails to run spec in TextMate Message-ID: <20070111151908.CAACE5241551@rubyforge.org> Bugs item #7754, was opened at 2007-01-11 07:19 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=7754&group_id=797 Category: RSpec.tmbundle Group: None Status: Open Resolution: None Priority: 3 Submitted By: Brian Yamabe (byamabe) Assigned to: Aslak Helles?y (aslak_hellesoy) Summary: Command-R fails to run spec in TextMate Initial Comment: When trying to run a spec from TextMate using command-r, I get: /Library/Application Support/TextMate/Bundles/RSpec.tmbundle/Support/lib/spec_mate.rb:1:in `require': No such file to load -- rubygems (LoadError) from /Library/Application Support/TextMate/Bundles/RSpec.tmbundle/Support/lib/spec_mate.rb:1 from /tmp/temp_textmate.EMYXc6:3:in `require' from /tmp/temp_textmate.EMYXc6:3 TM_RUBY is set properly (/opt/local/bin/ruby) Tried the following at Aslak suggestion and it ran without errors. 1) Create a file called foo.rb 2) Add one line to it: require 'rubygems' 3) Open it in TextMate 4) Run it from TextMate (Cmd-R - Run) ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=7754&group_id=797 From noreply at rubyforge.org Thu Jan 11 10:29:29 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 11 Jan 2007 10:29:29 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-7754 ] Command-R fails to run spec in TextMate Message-ID: <20070111152929.E11A8524154F@rubyforge.org> Bugs item #7754, was opened at 2007-01-11 15:19 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=7754&group_id=797 Category: RSpec.tmbundle Group: None Status: Open Resolution: None Priority: 3 Submitted By: Brian Yamabe (byamabe) Assigned to: Aslak Helles?y (aslak_hellesoy) Summary: Command-R fails to run spec in TextMate Initial Comment: When trying to run a spec from TextMate using command-r, I get: /Library/Application Support/TextMate/Bundles/RSpec.tmbundle/Support/lib/spec_mate.rb:1:in `require': No such file to load -- rubygems (LoadError) from /Library/Application Support/TextMate/Bundles/RSpec.tmbundle/Support/lib/spec_mate.rb:1 from /tmp/temp_textmate.EMYXc6:3:in `require' from /tmp/temp_textmate.EMYXc6:3 TM_RUBY is set properly (/opt/local/bin/ruby) Tried the following at Aslak suggestion and it ran without errors. 1) Create a file called foo.rb 2) Add one line to it: require 'rubygems' 3) Open it in TextMate 4) Run it from TextMate (Cmd-R - Run) ---------------------------------------------------------------------- >Comment By: Luke Redpath (lukeredpath) Date: 2007-01-11 15:29 Message: I had this problem too - the reason is that files with a shebang line (like the RSpec command in textmate) do not run the Textmate init script that picks up the system path it needs to find rubygems. To fix this problem, you also need to add the path to your ~/.MacOSX/ environment.plist file - here is mine: PATH /usr/local/bin:/usr/local/sbin:/usr/local/mysql/bin:/Users/luke/ bin:/opt/local/bin:/usr/local/mysql/bin Modify as necessary - you'll need to log out and log back in again for this to take effect. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=7754&group_id=797 From noreply at rubyforge.org Fri Jan 12 14:12:03 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 12 Jan 2007 14:12:03 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-7781 ] rspec will not install on RubyGems 0.9.1 Message-ID: <20070112191203.A25185241AD4@rubyforge.org> Bugs item #7781, was opened at 2007-01-12 11:12 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=7781&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Eric Hodel (drbrain) Assigned to: Nobody (None) Summary: rspec will not install on RubyGems 0.9.1 Initial Comment: Due to a security flaw in RubyGems, 0.9.1 and newer will no longer allow rspec to be installed: $ gem --version # actually, the downloaded 0.9.0.10 doesn't have the patch, use SVN 0.9.0.10 $ sudo gem install rspec --version 0.7.5 ERROR: While executing gem ... (Gem::InstallError) attempt to install file into "../web_spec/web_test_html_formatter.rb" ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=7781&group_id=797 From noreply at rubyforge.org Sat Jan 13 08:37:02 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sat, 13 Jan 2007 08:37:02 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-7795 ] form_tag renders action="/view_spec" in view specs Message-ID: <20070113133702.3788E524122B@rubyforge.org> Bugs item #7795, was opened at 2007-01-13 13:37 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=7795&group_id=797 Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: David Chelimsky (dchelimsky) Assigned to: Nobody (None) Summary: form_tag renders action="/view_spec" in view specs Initial Comment: Given the following view spec: context "login/login" do setup do render 'login/login' end specify "should display login form" do response.should_have_tag 'form', :attributes => {:action => '/login/login'} ... end end And the following code in /login/login.rhtml: <% form_tag do %> ... <% end %> The spec fails as follows: 'login/login should display login form' FAILED
....
Apparently, because 'spec/rails' uses a ViewSpecController to render views, form_tag is using that. Note that this ends up rendering the correct thing when running the app:
...
---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=7795&group_id=797 From noreply at rubyforge.org Sat Jan 13 20:59:06 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sat, 13 Jan 2007 20:59:06 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-7805 ] Stubs aren't being removed from modules Message-ID: <20070114015906.15005524218D@rubyforge.org> Bugs item #7805, was opened at 2007-01-14 01:59 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=7805&group_id=797 Category: mock module Group: None Status: Open Resolution: None Priority: 3 Submitted By: Michal Kwiatkowski (infrared) Assigned to: Nobody (None) Summary: Stubs aren't being removed from modules Initial Comment: Stubs aren't removed after running specs, which doesn't break things for modules begin tested, but can be source of bugs if you're stubbing classes from stdlib. Example code stubs File.open and manages to break RSpec code itself. Place attached Rakefile and spec in the same directory, then run "rake --trace" to see: undefined method `<' for nil:NilClass /usr/lib/ruby/gems/1.8/gems/rspec-0.7.5/lib/spec/rake/verify_rcov.rb:42:in `define' Source of this error is 'total_coverage' variable which doesn't get initialized because File.open doesn't yield nor return anything useful (because it's still stubbed). As you see in the stack report, I'm using rspec 0.7.5. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=7805&group_id=797 From noreply at rubyforge.org Sat Jan 13 21:00:42 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sat, 13 Jan 2007 21:00:42 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-7805 ] Stubs aren't being removed from modules Message-ID: <20070114020042.9D1325242190@rubyforge.org> Bugs item #7805, was opened at 2007-01-14 01:59 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=7805&group_id=797 Category: mock module Group: None Status: Open Resolution: None Priority: 3 Submitted By: Michal Kwiatkowski (infrared) Assigned to: Nobody (None) Summary: Stubs aren't being removed from modules Initial Comment: Stubs aren't removed after running specs, which doesn't break things for modules begin tested, but can be source of bugs if you're stubbing classes from stdlib. Example code stubs File.open and manages to break RSpec code itself. Place attached Rakefile and spec in the same directory, then run "rake --trace" to see: undefined method `<' for nil:NilClass /usr/lib/ruby/gems/1.8/gems/rspec-0.7.5/lib/spec/rake/verify_rcov.rb:42:in `define' Source of this error is 'total_coverage' variable which doesn't get initialized because File.open doesn't yield nor return anything useful (because it's still stubbed). As you see in the stack report, I'm using rspec 0.7.5. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=7805&group_id=797 From noreply at rubyforge.org Sun Jan 14 00:04:49 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 14 Jan 2007 00:04:49 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-7805 ] Stubs aren't being removed from modules Message-ID: <20070114050449.95A7C52421DE@rubyforge.org> Bugs item #7805, was opened at 2007-01-14 01:59 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=7805&group_id=797 Category: mock module Group: None Status: Open Resolution: None Priority: 3 Submitted By: Michal Kwiatkowski (infrared) Assigned to: Nobody (None) Summary: Stubs aren't being removed from modules Initial Comment: Stubs aren't removed after running specs, which doesn't break things for modules begin tested, but can be source of bugs if you're stubbing classes from stdlib. Example code stubs File.open and manages to break RSpec code itself. Place attached Rakefile and spec in the same directory, then run "rake --trace" to see: undefined method `<' for nil:NilClass /usr/lib/ruby/gems/1.8/gems/rspec-0.7.5/lib/spec/rake/verify_rcov.rb:42:in `define' Source of this error is 'total_coverage' variable which doesn't get initialized because File.open doesn't yield nor return anything useful (because it's still stubbed). As you see in the stack report, I'm using rspec 0.7.5. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-01-14 05:04 Message: There is a problem here but it is different from what you suggest. I created a file called stubs_should_restore_methods.rb (attached). Here's the code and the command line session: require 'spec' context "stubs" do specify "1 - stub the open method" do File.stub!(:open).and_return("something") File.open.should == "something" end specify "2 - use File.open to create example.txt" do filename = "example-#{Time.now.to_i}.txt" file = File.open(filename,'w') file << "some text" file.close end end [david at mac tmp]$ ls -al total 0 drwxr-xr-x 2 david david 68 Jan 13 23:01 . drwxr-xr-x 9 david david 306 Jan 13 23:01 .. [david at mac tmp]$ mv ../stubs_should_restore_methods.rb . [david at mac tmp]$ ls -al total 8 drwxr-xr-x 3 david david 102 Jan 13 23:02 . drwxr-xr-x 8 david david 272 Jan 13 23:02 .. -rw-r--r-- 1 david david 348 Jan 13 22:54 stubs_should_restore_methods.rb [david at mac tmp]$ ruby stubs_should_restore_methods.rb -fs stubs - 1 - stub the open method - 2 - use File.open to create example.txt Finished in 0.001414 seconds 2 specifications, 0 failures [david at mac tmp]$ ls -al total 16 drwxr-xr-x 4 david david 136 Jan 13 23:02 . drwxr-xr-x 8 david david 272 Jan 13 23:02 .. -rw-r--r-- 1 david david 9 Jan 13 23:02 example-1168750953.txt -rw-r--r-- 1 david david 348 Jan 13 22:54 stubs_should_restore_methods.rb [david at mac tmp]$ ruby stubs_should_restore_methods.rb -fs stubs - 1 - stub the open method - 2 - use File.open to create example.txt Finished in 0.001393 seconds 2 specifications, 0 failures [david at mac tmp]$ ls -al total 24 drwxr-xr-x 5 david david 170 Jan 13 23:02 . drwxr-xr-x 8 david david 272 Jan 13 23:02 .. -rw-r--r-- 1 david david 9 Jan 13 23:02 example-1168750953.txt -rw-r--r-- 1 david david 9 Jan 13 23:02 example-1168750963.txt -rw-r--r-- 1 david david 348 Jan 13 22:54 stubs_should_restore_methods.rb As you can see, each time the spec is run, the second spec creates a new file using File.open, even though File.open had been stubbed in the first spec. I think the problem is that rcov is trying to use File.open to create and/or write to a file DURING the spec. If that's correct, I don't see what we would be able to do about that from RSpec. What do you think? Cheers, David ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=7805&group_id=797 From noreply at rubyforge.org Sun Jan 14 00:06:17 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 14 Jan 2007 00:06:17 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-7805 ] Stubs aren't being removed from modules Message-ID: <20070114050618.8A12752421E0@rubyforge.org> Bugs item #7805, was opened at 2007-01-14 01:59 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=7805&group_id=797 Category: mock module Group: None Status: Open Resolution: None Priority: 3 Submitted By: Michal Kwiatkowski (infrared) Assigned to: Nobody (None) Summary: Stubs aren't being removed from modules Initial Comment: Stubs aren't removed after running specs, which doesn't break things for modules begin tested, but can be source of bugs if you're stubbing classes from stdlib. Example code stubs File.open and manages to break RSpec code itself. Place attached Rakefile and spec in the same directory, then run "rake --trace" to see: undefined method `<' for nil:NilClass /usr/lib/ruby/gems/1.8/gems/rspec-0.7.5/lib/spec/rake/verify_rcov.rb:42:in `define' Source of this error is 'total_coverage' variable which doesn't get initialized because File.open doesn't yield nor return anything useful (because it's still stubbed). As you see in the stack report, I'm using rspec 0.7.5. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-01-14 05:04 Message: There is a problem here but it is different from what you suggest. I created a file called stubs_should_restore_methods.rb (attached). Here's the code and the command line session: require 'spec' context "stubs" do specify "1 - stub the open method" do File.stub!(:open).and_return("something") File.open.should == "something" end specify "2 - use File.open to create example.txt" do filename = "example-#{Time.now.to_i}.txt" file = File.open(filename,'w') file << "some text" file.close end end [david at mac tmp]$ ls -al total 0 drwxr-xr-x 2 david david 68 Jan 13 23:01 . drwxr-xr-x 9 david david 306 Jan 13 23:01 .. [david at mac tmp]$ mv ../stubs_should_restore_methods.rb . [david at mac tmp]$ ls -al total 8 drwxr-xr-x 3 david david 102 Jan 13 23:02 . drwxr-xr-x 8 david david 272 Jan 13 23:02 .. -rw-r--r-- 1 david david 348 Jan 13 22:54 stubs_should_restore_methods.rb [david at mac tmp]$ ruby stubs_should_restore_methods.rb -fs stubs - 1 - stub the open method - 2 - use File.open to create example.txt Finished in 0.001414 seconds 2 specifications, 0 failures [david at mac tmp]$ ls -al total 16 drwxr-xr-x 4 david david 136 Jan 13 23:02 . drwxr-xr-x 8 david david 272 Jan 13 23:02 .. -rw-r--r-- 1 david david 9 Jan 13 23:02 example-1168750953.txt -rw-r--r-- 1 david david 348 Jan 13 22:54 stubs_should_restore_methods.rb [david at mac tmp]$ ruby stubs_should_restore_methods.rb -fs stubs - 1 - stub the open method - 2 - use File.open to create example.txt Finished in 0.001393 seconds 2 specifications, 0 failures [david at mac tmp]$ ls -al total 24 drwxr-xr-x 5 david david 170 Jan 13 23:02 . drwxr-xr-x 8 david david 272 Jan 13 23:02 .. -rw-r--r-- 1 david david 9 Jan 13 23:02 example-1168750953.txt -rw-r--r-- 1 david david 9 Jan 13 23:02 example-1168750963.txt -rw-r--r-- 1 david david 348 Jan 13 22:54 stubs_should_restore_methods.rb As you can see, each time the spec is run, the second spec creates a new file using File.open, even though File.open had been stubbed in the first spec. I think the problem is that rcov is trying to use File.open to create and/or write to a file DURING the spec. If that's correct, I don't see what we would be able to do about that from RSpec. What do you think? Cheers, David ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=7805&group_id=797 From noreply at rubyforge.org Sun Jan 14 06:22:26 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 14 Jan 2007 06:22:26 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-7805 ] Stubs aren't being removed from modules Message-ID: <20070114112226.595AF5240BCF@rubyforge.org> Bugs item #7805, was opened at 2007-01-14 01:59 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=7805&group_id=797 Category: mock module Group: None Status: Open Resolution: None Priority: 3 Submitted By: Michal Kwiatkowski (infrared) Assigned to: Nobody (None) Summary: Stubs aren't being removed from modules Initial Comment: Stubs aren't removed after running specs, which doesn't break things for modules begin tested, but can be source of bugs if you're stubbing classes from stdlib. Example code stubs File.open and manages to break RSpec code itself. Place attached Rakefile and spec in the same directory, then run "rake --trace" to see: undefined method `<' for nil:NilClass /usr/lib/ruby/gems/1.8/gems/rspec-0.7.5/lib/spec/rake/verify_rcov.rb:42:in `define' Source of this error is 'total_coverage' variable which doesn't get initialized because File.open doesn't yield nor return anything useful (because it's still stubbed). As you see in the stack report, I'm using rspec 0.7.5. ---------------------------------------------------------------------- >Comment By: Michal Kwiatkowski (infrared) Date: 2007-01-14 11:22 Message: The bug seems to occur only in conjunction with rake and/or rcov but stack trace originates from rspec code (file spec/rake/verify_rcov.rb, line 42), within define of VerifyTask, which is run by rake only *after* the spec task completes (see the attached Rakefile). So it's not true that this code is run during the spec. Error presented by me isn't the only one that can happen because of stubbing File.open. Let me show you another one: Spec file contains (attached as spec_that_coredumps.rb): require 'rubygems' require 'spec' context "stubs" do specify "1 - stub the open method" do puts "BEFORE spec 1" File.stub!(:open).and_return("something") File.open.should == "something" puts "AFTER spec 1" end specify "2 - use File.open to create example.txt" do puts "BEFORE spec 1" File.open.should == "something" puts "AFTER spec 2" end end After running "rake --trace" I get a core dump: $ rake --trace (in /tmp/foobar) ** Invoke default (first_time) ** Invoke verify_rcov (first_time) ** Invoke spec_with_rcov (first_time) ** Invoke clobber_spec_with_rcov (first_time) ** Execute clobber_spec_with_rcov rm -r coverage ** Execute spec_with_rcov /usr/bin/ruby1.8 -I"/usr/lib/ruby/gems/1.8/gems/rspec-0.7.5/lib" -S rcov --exclude lib\/spec,bin\/spec -o "coverage" "/usr/lib/ruby/gems/1.8/gems/rspec-0.7.5/bin/spec" -- "foo.rb" BEFORE spec 1 AFTER spec 1 .BEFORE spec 1 [BUG] Segmentation fault ruby 1.8.4 (2005-12-24) [i486-linux] rake aborted! Command failed with status (): [/usr/bin/ruby1.8 -I"/usr/lib/ruby/gems/1.8...] /usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:722:in `sh' /usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:729:in `sh' /usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:812:in `sh' /usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:807:in `sh' /usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:747:in `ruby' /usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:812:in `ruby' /usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:807:in `ruby' /usr/lib/ruby/gems/1.8/gems/rspec-0.7.5/lib/spec/rake/spectask.rb:131:in `define' /usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:831:in `verbose' /usr/lib/ruby/gems/1.8/gems/rspec-0.7.5/lib/spec/rake/spectask.rb:110:in `define' /usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:387:in `execute' /usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:387:in `execute' /usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:357:in `invoke' /usr/lib/ruby/1.8/thread.rb:135:in `synchronize' /usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:350:in `invoke' /usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:364:in `invoke_prerequisites' /usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:999:in `each' /usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:363:in `invoke_prerequisites' /usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:356:in `invoke' /usr/lib/ruby/1.8/thread.rb:135:in `synchronize' /usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:350:in `invoke' /usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:364:in `invoke_prerequisites' /usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:999:in `each' /usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:363:in `invoke_prerequisites' /usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:356:in `invoke' /usr/lib/ruby/1.8/thread.rb:135:in `synchronize' /usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:350:in `invoke' /usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:1906:in `run' /usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:1906:in `run' /usr/lib/ruby/gems/1.8/gems/rake-0.7.1/bin/rake:7 /usr/bin/rake:18 If stub would be removed and state in the begining of spec2 would be exactly the same as before running spec1 error should not happen. Making spec2 the first spec in context will yield expected result: ArgumentError from File.open. Also, changing a line in spec2 to other that doesn't involve File.open will stop rake from coredumping, but original "undefined method `<' for nil:NilClass" error will still be there. Any ideas? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-01-14 05:04 Message: There is a problem here but it is different from what you suggest. I created a file called stubs_should_restore_methods.rb (attached). Here's the code and the command line session: require 'spec' context "stubs" do specify "1 - stub the open method" do File.stub!(:open).and_return("something") File.open.should == "something" end specify "2 - use File.open to create example.txt" do filename = "example-#{Time.now.to_i}.txt" file = File.open(filename,'w') file << "some text" file.close end end [david at mac tmp]$ ls -al total 0 drwxr-xr-x 2 david david 68 Jan 13 23:01 . drwxr-xr-x 9 david david 306 Jan 13 23:01 .. [david at mac tmp]$ mv ../stubs_should_restore_methods.rb . [david at mac tmp]$ ls -al total 8 drwxr-xr-x 3 david david 102 Jan 13 23:02 . drwxr-xr-x 8 david david 272 Jan 13 23:02 .. -rw-r--r-- 1 david david 348 Jan 13 22:54 stubs_should_restore_methods.rb [david at mac tmp]$ ruby stubs_should_restore_methods.rb -fs stubs - 1 - stub the open method - 2 - use File.open to create example.txt Finished in 0.001414 seconds 2 specifications, 0 failures [david at mac tmp]$ ls -al total 16 drwxr-xr-x 4 david david 136 Jan 13 23:02 . drwxr-xr-x 8 david david 272 Jan 13 23:02 .. -rw-r--r-- 1 david david 9 Jan 13 23:02 example-1168750953.txt -rw-r--r-- 1 david david 348 Jan 13 22:54 stubs_should_restore_methods.rb [david at mac tmp]$ ruby stubs_should_restore_methods.rb -fs stubs - 1 - stub the open method - 2 - use File.open to create example.txt Finished in 0.001393 seconds 2 specifications, 0 failures [david at mac tmp]$ ls -al total 24 drwxr-xr-x 5 david david 170 Jan 13 23:02 . drwxr-xr-x 8 david david 272 Jan 13 23:02 .. -rw-r--r-- 1 david david 9 Jan 13 23:02 example-1168750953.txt -rw-r--r-- 1 david david 9 Jan 13 23:02 example-1168750963.txt -rw-r--r-- 1 david david 348 Jan 13 22:54 stubs_should_restore_methods.rb As you can see, each time the spec is run, the second spec creates a new file using File.open, even though File.open had been stubbed in the first spec. I think the problem is that rcov is trying to use File.open to create and/or write to a file DURING the spec. If that's correct, I don't see what we would be able to do about that from RSpec. What do you think? Cheers, David ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=7805&group_id=797 From noreply at rubyforge.org Sun Jan 14 06:23:11 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 14 Jan 2007 06:23:11 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-7805 ] Stubs aren't being removed from modules Message-ID: <20070114112311.6C5E65240BF4@rubyforge.org> Bugs item #7805, was opened at 2007-01-14 01:59 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=7805&group_id=797 Category: mock module Group: None Status: Open Resolution: None Priority: 3 Submitted By: Michal Kwiatkowski (infrared) Assigned to: Nobody (None) Summary: Stubs aren't being removed from modules Initial Comment: Stubs aren't removed after running specs, which doesn't break things for modules begin tested, but can be source of bugs if you're stubbing classes from stdlib. Example code stubs File.open and manages to break RSpec code itself. Place attached Rakefile and spec in the same directory, then run "rake --trace" to see: undefined method `<' for nil:NilClass /usr/lib/ruby/gems/1.8/gems/rspec-0.7.5/lib/spec/rake/verify_rcov.rb:42:in `define' Source of this error is 'total_coverage' variable which doesn't get initialized because File.open doesn't yield nor return anything useful (because it's still stubbed). As you see in the stack report, I'm using rspec 0.7.5. ---------------------------------------------------------------------- Comment By: Michal Kwiatkowski (infrared) Date: 2007-01-14 11:22 Message: The bug seems to occur only in conjunction with rake and/or rcov but stack trace originates from rspec code (file spec/rake/verify_rcov.rb, line 42), within define of VerifyTask, which is run by rake only *after* the spec task completes (see the attached Rakefile). So it's not true that this code is run during the spec. Error presented by me isn't the only one that can happen because of stubbing File.open. Let me show you another one: Spec file contains (attached as spec_that_coredumps.rb): require 'rubygems' require 'spec' context "stubs" do specify "1 - stub the open method" do puts "BEFORE spec 1" File.stub!(:open).and_return("something") File.open.should == "something" puts "AFTER spec 1" end specify "2 - use File.open to create example.txt" do puts "BEFORE spec 1" File.open.should == "something" puts "AFTER spec 2" end end After running "rake --trace" I get a core dump: $ rake --trace (in /tmp/foobar) ** Invoke default (first_time) ** Invoke verify_rcov (first_time) ** Invoke spec_with_rcov (first_time) ** Invoke clobber_spec_with_rcov (first_time) ** Execute clobber_spec_with_rcov rm -r coverage ** Execute spec_with_rcov /usr/bin/ruby1.8 -I"/usr/lib/ruby/gems/1.8/gems/rspec-0.7.5/lib" -S rcov --exclude lib\/spec,bin\/spec -o "coverage" "/usr/lib/ruby/gems/1.8/gems/rspec-0.7.5/bin/spec" -- "foo.rb" BEFORE spec 1 AFTER spec 1 .BEFORE spec 1 [BUG] Segmentation fault ruby 1.8.4 (2005-12-24) [i486-linux] rake aborted! Command failed with status (): [/usr/bin/ruby1.8 -I"/usr/lib/ruby/gems/1.8...] /usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:722:in `sh' /usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:729:in `sh' /usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:812:in `sh' /usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:807:in `sh' /usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:747:in `ruby' /usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:812:in `ruby' /usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:807:in `ruby' /usr/lib/ruby/gems/1.8/gems/rspec-0.7.5/lib/spec/rake/spectask.rb:131:in `define' /usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:831:in `verbose' /usr/lib/ruby/gems/1.8/gems/rspec-0.7.5/lib/spec/rake/spectask.rb:110:in `define' /usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:387:in `execute' /usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:387:in `execute' /usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:357:in `invoke' /usr/lib/ruby/1.8/thread.rb:135:in `synchronize' /usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:350:in `invoke' /usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:364:in `invoke_prerequisites' /usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:999:in `each' /usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:363:in `invoke_prerequisites' /usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:356:in `invoke' /usr/lib/ruby/1.8/thread.rb:135:in `synchronize' /usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:350:in `invoke' /usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:364:in `invoke_prerequisites' /usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:999:in `each' /usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:363:in `invoke_prerequisites' /usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:356:in `invoke' /usr/lib/ruby/1.8/thread.rb:135:in `synchronize' /usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:350:in `invoke' /usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:1906:in `run' /usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:1906:in `run' /usr/lib/ruby/gems/1.8/gems/rake-0.7.1/bin/rake:7 /usr/bin/rake:18 If stub would be removed and state in the begining of spec2 would be exactly the same as before running spec1 error should not happen. Making spec2 the first spec in context will yield expected result: ArgumentError from File.open. Also, changing a line in spec2 to other that doesn't involve File.open will stop rake from coredumping, but original "undefined method `<' for nil:NilClass" error will still be there. Any ideas? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-01-14 05:04 Message: There is a problem here but it is different from what you suggest. I created a file called stubs_should_restore_methods.rb (attached). Here's the code and the command line session: require 'spec' context "stubs" do specify "1 - stub the open method" do File.stub!(:open).and_return("something") File.open.should == "something" end specify "2 - use File.open to create example.txt" do filename = "example-#{Time.now.to_i}.txt" file = File.open(filename,'w') file << "some text" file.close end end [david at mac tmp]$ ls -al total 0 drwxr-xr-x 2 david david 68 Jan 13 23:01 . drwxr-xr-x 9 david david 306 Jan 13 23:01 .. [david at mac tmp]$ mv ../stubs_should_restore_methods.rb . [david at mac tmp]$ ls -al total 8 drwxr-xr-x 3 david david 102 Jan 13 23:02 . drwxr-xr-x 8 david david 272 Jan 13 23:02 .. -rw-r--r-- 1 david david 348 Jan 13 22:54 stubs_should_restore_methods.rb [david at mac tmp]$ ruby stubs_should_restore_methods.rb -fs stubs - 1 - stub the open method - 2 - use File.open to create example.txt Finished in 0.001414 seconds 2 specifications, 0 failures [david at mac tmp]$ ls -al total 16 drwxr-xr-x 4 david david 136 Jan 13 23:02 . drwxr-xr-x 8 david david 272 Jan 13 23:02 .. -rw-r--r-- 1 david david 9 Jan 13 23:02 example-1168750953.txt -rw-r--r-- 1 david david 348 Jan 13 22:54 stubs_should_restore_methods.rb [david at mac tmp]$ ruby stubs_should_restore_methods.rb -fs stubs - 1 - stub the open method - 2 - use File.open to create example.txt Finished in 0.001393 seconds 2 specifications, 0 failures [david at mac tmp]$ ls -al total 24 drwxr-xr-x 5 david david 170 Jan 13 23:02 . drwxr-xr-x 8 david david 272 Jan 13 23:02 .. -rw-r--r-- 1 david david 9 Jan 13 23:02 example-1168750953.txt -rw-r--r-- 1 david david 9 Jan 13 23:02 example-1168750963.txt -rw-r--r-- 1 david david 348 Jan 13 22:54 stubs_should_restore_methods.rb As you can see, each time the spec is run, the second spec creates a new file using File.open, even though File.open had been stubbed in the first spec. I think the problem is that rcov is trying to use File.open to create and/or write to a file DURING the spec. If that's correct, I don't see what we would be able to do about that from RSpec. What do you think? Cheers, David ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=7805&group_id=797 From noreply at rubyforge.org Sun Jan 14 14:43:31 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 14 Jan 2007 14:43:31 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-7826 ] RSpect.tmbundle web page out of date Message-ID: <20070114194331.5AA81524224C@rubyforge.org> Bugs item #7826, was opened at 2007-01-14 13:43 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=7826&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Mark Fredrickson (mfredrickson) Assigned to: Nobody (None) Summary: RSpect.tmbundle web page out of date Initial Comment: Hello, The information at: http://rspec.rubyforge.org/tools/extensions/editors/textmate.html Is out of date. The correct URL to use to get the bundle from source is: svn co svn://rubyforge.org/var/svn/rspec/trunk/RSpec.tmbundle Thanks! ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=7826&group_id=797 From noreply at rubyforge.org Tue Jan 16 14:48:15 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 16 Jan 2007 14:48:15 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-6112 ] Rspec on Rails: Postgresql reports WARNING: there is already a transaction in progress Message-ID: <20070116194815.6F1225241C65@rubyforge.org> Bugs item #6112, was opened at 2006-10-12 07:35 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6112&group_id=797 Category: None Group: None >Status: Open >Resolution: Rejected Priority: 3 Submitted By: David Lee (davidlee) Assigned to: Nobody (None) Summary: Rspec on Rails: Postgresql reports WARNING: there is already a transaction in progress Initial Comment: This has been verified on Arch Linux (gimmick) and OS X Tiger (postgres 8.1 via darwinports), using Rails 1.1.2 and RSpec 0.6.4 & the rspec rails plugin. Description (output from skeletal rails project): /tmp/foo % spec spec/models/tester_spec.rb WARNING: there is already a transaction in progress WARNING: there is no transaction in progress .WARNING: there is already a transaction in progress WARNING: there is no transaction in progress F 1) Spec::Expectations::ExpectationNotMetError in 'Tester class with fixtures loaded should have more specifications' not enough specs ./spec/models/tester_spec.rb:11:in `should have more specifications' Finished in 0.326214 seconds 2 specifications, 1 failure ____ 2 lines of warnings are generated per specify block. When running a substantial spec, voluminous WARNINGs are generated, such that it is necessary to run spec spec/models/* 2> /dev/null to prevent the test output being lost in noise. ---------------------------------------------------------------------- >Comment By: Brian Takita (btakita) Date: 2007-01-16 11:48 Message: This is happening with me on Version 0.7.5 ---------------------------------------------------------------------- Comment By: David Lee (davidlee) Date: 2006-12-12 02:54 Message: This no longer seems to be an issue with the current release, on account of it being substantially rewritten and choc full of awesome. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-12-07 18:27 Message: David - is this still a problem with 0.7.4? Things have changed quite a bit since 0.6. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6112&group_id=797 From noreply at rubyforge.org Tue Jan 16 14:50:58 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 16 Jan 2007 14:50:58 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-6112 ] Rspec on Rails: Postgresql reports WARNING: there is already a transaction in progress Message-ID: <20070116195059.01DC65241C6D@rubyforge.org> Bugs item #6112, was opened at 2006-10-12 07:35 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6112&group_id=797 Category: None Group: None >Status: Closed >Resolution: Accepted Priority: 3 Submitted By: David Lee (davidlee) Assigned to: Nobody (None) Summary: Rspec on Rails: Postgresql reports WARNING: there is already a transaction in progress Initial Comment: This has been verified on Arch Linux (gimmick) and OS X Tiger (postgres 8.1 via darwinports), using Rails 1.1.2 and RSpec 0.6.4 & the rspec rails plugin. Description (output from skeletal rails project): /tmp/foo % spec spec/models/tester_spec.rb WARNING: there is already a transaction in progress WARNING: there is no transaction in progress .WARNING: there is already a transaction in progress WARNING: there is no transaction in progress F 1) Spec::Expectations::ExpectationNotMetError in 'Tester class with fixtures loaded should have more specifications' not enough specs ./spec/models/tester_spec.rb:11:in `should have more specifications' Finished in 0.326214 seconds 2 specifications, 1 failure ____ 2 lines of warnings are generated per specify block. When running a substantial spec, voluminous WARNINGs are generated, such that it is necessary to run spec spec/models/* 2> /dev/null to prevent the test output being lost in noise. ---------------------------------------------------------------------- >Comment By: Brian Takita (btakita) Date: 2007-01-16 11:50 Message: Actually there was a constraint issue in the data. ---------------------------------------------------------------------- Comment By: Brian Takita (btakita) Date: 2007-01-16 11:48 Message: This is happening with me on Version 0.7.5 ---------------------------------------------------------------------- Comment By: David Lee (davidlee) Date: 2006-12-12 02:54 Message: This no longer seems to be an issue with the current release, on account of it being substantially rewritten and choc full of awesome. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-12-07 18:27 Message: David - is this still a problem with 0.7.4? Things have changed quite a bit since 0.6. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6112&group_id=797 From noreply at rubyforge.org Wed Jan 17 18:24:11 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 17 Jan 2007 18:24:11 -0500 (EST) Subject: [rspec-devel] [ rspec-Feature Requests-6791 ] stub return values for all instances of a class Message-ID: <20070117232411.433705241CFB@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: 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 noreply at rubyforge.org Wed Jan 17 20:29:18 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 17 Jan 2007 20:29:18 -0500 (EST) Subject: [rspec-devel] [ rspec-Feature Requests-6791 ] stub return values for all instances of a class Message-ID: <20070118012918.4C0FC5241D13@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: 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 noreply at rubyforge.org Wed Jan 17 23:23:57 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 17 Jan 2007 23:23:57 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-7781 ] rspec will not install on RubyGems 0.9.1 Message-ID: <20070118042357.CE14B5241D47@rubyforge.org> Bugs item #7781, was opened at 2007-01-12 14:12 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=7781&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Eric Hodel (drbrain) Assigned to: Nobody (None) Summary: rspec will not install on RubyGems 0.9.1 Initial Comment: Due to a security flaw in RubyGems, 0.9.1 and newer will no longer allow rspec to be installed: $ gem --version # actually, the downloaded 0.9.0.10 doesn't have the patch, use SVN 0.9.0.10 $ sudo gem install rspec --version 0.7.5 ERROR: While executing gem ... (Gem::InstallError) attempt to install file into "../web_spec/web_test_html_formatter.rb" ---------------------------------------------------------------------- Comment By: Jay Levitt (jaylev) Date: 2007-01-17 23:23 Message: The unintential creation of the ../web_spec directory seems to be an artifact of the old trunk layout. Can it safely be removed or updated from the Rakefile in trunk? Gem 0.9.1 is now released and considered a "required upgrade", so anyone with a properly secured system can no longer install rspec.. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=7781&group_id=797 From noreply at rubyforge.org Wed Jan 17 23:47:45 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 17 Jan 2007 23:47:45 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-7781 ] rspec will not install on RubyGems 0.9.1 Message-ID: <20070118044745.AB2065241D5D@rubyforge.org> Bugs item #7781, was opened at 2007-01-12 19:12 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=7781&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Eric Hodel (drbrain) Assigned to: Nobody (None) Summary: rspec will not install on RubyGems 0.9.1 Initial Comment: Due to a security flaw in RubyGems, 0.9.1 and newer will no longer allow rspec to be installed: $ gem --version # actually, the downloaded 0.9.0.10 doesn't have the patch, use SVN 0.9.0.10 $ sudo gem install rspec --version 0.7.5 ERROR: While executing gem ... (Gem::InstallError) attempt to install file into "../web_spec/web_test_html_formatter.rb" ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-01-18 04:47 Message: Unfortunately, the trunk is not in a good condition to release right now. I'm hoping to get a 0.7.5.1 release out over the weekend (branched from the 0.7.5 release). ---------------------------------------------------------------------- Comment By: Jay Levitt (jaylev) Date: 2007-01-18 04:23 Message: The unintential creation of the ../web_spec directory seems to be an artifact of the old trunk layout. Can it safely be removed or updated from the Rakefile in trunk? Gem 0.9.1 is now released and considered a "required upgrade", so anyone with a properly secured system can no longer install rspec.. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=7781&group_id=797 From noreply at rubyforge.org Thu Jan 18 12:14:19 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 18 Jan 2007 12:14:19 -0500 (EST) Subject: [rspec-devel] [ rspec-Patches-7637 ] [PATCH] add skip-migration option to rspec_resource generator Message-ID: <20070118171420.2B22952426B2@rubyforge.org> Patches item #7637, was opened at 2007-01-06 19:35 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=7637&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Chris Anderson (jchris) Assigned to: Nobody (None) Summary: [PATCH] add skip-migration option to rspec_resource generator Initial Comment: it should have this option, just like the regular Test::Unit version of it. ---------------------------------------------------------------------- >Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-01-18 12:14 Message: Make sure you check the checkbox if you attach it again ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-01-06 20:03 Message: Where's the file? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=7637&group_id=797 From noreply at rubyforge.org Thu Jan 18 13:33:50 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 18 Jan 2007 13:33:50 -0500 (EST) Subject: [rspec-devel] [ rspec-Patches-7685 ] spec_ui feedback and patch Message-ID: <20070118183350.31E1D52426D1@rubyforge.org> Patches item #7685, was opened at 2007-01-08 20:21 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=7685&group_id=797 Category: None Group: None >Status: Closed >Resolution: Accepted Priority: 3 Submitted By: Alvin Schur (aschur) Assigned to: Nobody (None) Summary: spec_ui feedback and patch Initial Comment: Here is a patch that helps me use spec_ui on WinXP. I use IE and I do not use rails. Fixtures are loaded manually and work well with context_setup, and setup. The spec_ui bundle helps me keep the project clean :) However, I am having difficulty with the screen snapshot feature: * either I get a screen snapshot of the DOS box I run rake in * OR I get the message: Insufficient image data in file `' which I am still investigating. Alvin Schur. ---------------------------------------------------------------------- >Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-01-18 13:33 Message: Applied, sith some modifications. Please check out the whole trunk and build/install your own RSpec gem - the spec_ui relies on unreleased RSpec features. You also need win32screenshot 0.0.3 spec_ui now tells you what to do when it encounters "Insufficient image data in file" (enlarge your IE window) ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=7685&group_id=797 From noreply at rubyforge.org Thu Jan 18 14:05:55 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 18 Jan 2007 14:05:55 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-7591 ] When controller is missing action method, Rspec reports misleading " no id found" Message-ID: <20070118190556.0653E52426DE@rubyforge.org> Bugs item #7591, was opened at 2007-01-05 14:09 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=7591&group_id=797 Category: rails plugin Group: None >Status: Deleted Resolution: None Priority: 3 Submitted By: Clint Bishop (norobotdiving) Assigned to: Nobody (None) >Summary: When controller is missing action method, Rspec reports misleading "no id found" Initial Comment: Under Rspec 0.7.5 on Rails Edge (Jan 03 2007): The following will fail (correctly) if no "my_action" method is defined upon the my_controller controller. To error report will read "no id found" - the standard message for a method_missing failure. However, the error report is misleading, since we're expecting the ActionController to raise an UnknownAction exception. Snippet: context "Some context" do controller_name 'my_controller' specify "some spec" do xhr :post, :my_action, :a_value => true end end ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=7591&group_id=797 From noreply at rubyforge.org Thu Jan 18 14:12:01 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 18 Jan 2007 14:12:01 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-7591 ] When controller is missing action method, Rspec reports misleading " no id found" Message-ID: <20070118191202.22E1152426E5@rubyforge.org> Bugs item #7591, was opened at 2007-01-05 14:09 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=7591&group_id=797 Category: rails plugin Group: None Status: Deleted Resolution: None Priority: 3 Submitted By: Clint Bishop (norobotdiving) Assigned to: Nobody (None) Summary: When controller is missing action method, Rspec reports misleading "no id found" Initial Comment: Under Rspec 0.7.5 on Rails Edge (Jan 03 2007): The following will fail (correctly) if no "my_action" method is defined upon the my_controller controller. To error report will read "no id found" - the standard message for a method_missing failure. However, the error report is misleading, since we're expecting the ActionController to raise an UnknownAction exception. Snippet: context "Some context" do controller_name 'my_controller' specify "some spec" do xhr :post, :my_action, :a_value => true end end ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-01-18 19:12 Message: Who set this to deleted? Please indicate why it was changed. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=7591&group_id=797 From noreply at rubyforge.org Thu Jan 18 14:15:51 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 18 Jan 2007 14:15:51 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-7591 ] When controller is missing action method, Rspec reports misleading & quot; no id found& quot; Message-ID: <20070118191551.5E3D752426D7@rubyforge.org> Bugs item #7591, was opened at 2007-01-05 14:09 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=7591&group_id=797 Category: rails plugin Group: None Status: Deleted Resolution: None Priority: 3 Submitted By: Clint Bishop (norobotdiving) Assigned to: Nobody (None) >Summary: When controller is missing action method, Rspec reports misleading &quot;no id found&quot; Initial Comment: Under Rspec 0.7.5 on Rails Edge (Jan 03 2007): The following will fail (correctly) if no "my_action" method is defined upon the my_controller controller. To error report will read "no id found" - the standard message for a method_missing failure. However, the error report is misleading, since we're expecting the ActionController to raise an UnknownAction exception. Snippet: context "Some context" do controller_name 'my_controller' specify "some spec" do xhr :post, :my_action, :a_value => true end end ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-01-18 19:12 Message: Who set this to deleted? Please indicate why it was changed. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=7591&group_id=797 From noreply at rubyforge.org Thu Jan 18 14:17:26 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 18 Jan 2007 14:17:26 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-7591 ] When controller is missing action method, Rspec reports misleading & amp; quot; no id found& amp; quot; Message-ID: <20070118191727.0342E5242683@rubyforge.org> Bugs item #7591, was opened at 2007-01-05 14:09 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=7591&group_id=797 Category: rails plugin Group: None Status: Deleted Resolution: None Priority: 3 Submitted By: Clint Bishop (norobotdiving) Assigned to: Nobody (None) >Summary: When controller is missing action method, Rspec reports misleading &amp;quot;no id found&amp;quot; Initial Comment: Under Rspec 0.7.5 on Rails Edge (Jan 03 2007): The following will fail (correctly) if no "my_action" method is defined upon the my_controller controller. To error report will read "no id found" - the standard message for a method_missing failure. However, the error report is misleading, since we're expecting the ActionController to raise an UnknownAction exception. Snippet: context "Some context" do controller_name 'my_controller' specify "some spec" do xhr :post, :my_action, :a_value => true end end ---------------------------------------------------------------------- >Comment By: Clint Bishop (norobotdiving) Date: 2007-01-18 19:17 Message: It turns out this had to do with our rails settings on edge, and not RSpec. It looked to be coming from RSpec from the stack trace but it turned out to be unrelated. Should've commented on that, sorry. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-01-18 19:12 Message: Who set this to deleted? Please indicate why it was changed. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=7591&group_id=797 From noreply at rubyforge.org Thu Jan 18 14:20:04 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 18 Jan 2007 14:20:04 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-7591 ] When controller is missing action method, Rspec reports misleading & amp; quot; no id found& amp; quot; Message-ID: <20070118192004.8D73B52426B9@rubyforge.org> Bugs item #7591, was opened at 2007-01-05 14:09 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=7591&group_id=797 Category: rails plugin Group: None Status: Deleted Resolution: None Priority: 3 Submitted By: Clint Bishop (norobotdiving) Assigned to: Nobody (None) Summary: When controller is missing action method, Rspec reports misleading &amp;quot;no id found&amp;quot; Initial Comment: Under Rspec 0.7.5 on Rails Edge (Jan 03 2007): The following will fail (correctly) if no "my_action" method is defined upon the my_controller controller. To error report will read "no id found" - the standard message for a method_missing failure. However, the error report is misleading, since we're expecting the ActionController to raise an UnknownAction exception. Snippet: context "Some context" do controller_name 'my_controller' specify "some spec" do xhr :post, :my_action, :a_value => true end end ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-01-18 19:20 Message: Clint - I've seen this problem against edge too. What setting are you changing to alleviate it? Thanks, David ---------------------------------------------------------------------- Comment By: Clint Bishop (norobotdiving) Date: 2007-01-18 19:17 Message: It turns out this had to do with our rails settings on edge, and not RSpec. It looked to be coming from RSpec from the stack trace but it turned out to be unrelated. Should've commented on that, sorry. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-01-18 19:12 Message: Who set this to deleted? Please indicate why it was changed. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=7591&group_id=797 From noreply at rubyforge.org Thu Jan 18 18:31:50 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 18 Jan 2007 18:31:50 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-7591 ] When controller is missing action method, Rspec reports misleading & amp; quot; no id found& amp; quot; Message-ID: <20070118233151.0EA705242745@rubyforge.org> Bugs item #7591, was opened at 2007-01-05 08:09 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=7591&group_id=797 Category: rails plugin Group: None Status: Deleted Resolution: None Priority: 3 Submitted By: Clint Bishop (norobotdiving) Assigned to: Nobody (None) Summary: When controller is missing action method, Rspec reports misleading &amp;quot;no id found&amp;quot; Initial Comment: Under Rspec 0.7.5 on Rails Edge (Jan 03 2007): The following will fail (correctly) if no "my_action" method is defined upon the my_controller controller. To error report will read "no id found" - the standard message for a method_missing failure. However, the error report is misleading, since we're expecting the ActionController to raise an UnknownAction exception. Snippet: context "Some context" do controller_name 'my_controller' specify "some spec" do xhr :post, :my_action, :a_value => true end end ---------------------------------------------------------------------- Comment By: S. Potter (mbbx6spp) Date: 2007-01-18 17:31 Message: I broke down and added empty action methods, but I would also like to know what the code patch is. I am using RSpec 0.7.5 with the 0.7.5 RSpec on Rails plugin with Rails 1.2. I even took out custom methods and helpers in spec/spec_helper.rb to see if I still received the error on running "rake spec", which I did. Thanks, SP ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-01-18 13:20 Message: Clint - I've seen this problem against edge too. What setting are you changing to alleviate it? Thanks, David ---------------------------------------------------------------------- Comment By: Clint Bishop (norobotdiving) Date: 2007-01-18 13:17 Message: It turns out this had to do with our rails settings on edge, and not RSpec. It looked to be coming from RSpec from the stack trace but it turned out to be unrelated. Should've commented on that, sorry. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-01-18 13:12 Message: Who set this to deleted? Please indicate why it was changed. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=7591&group_id=797 From noreply at rubyforge.org Thu Jan 18 18:57:43 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 18 Jan 2007 18:57:43 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-7781 ] rspec will not install on RubyGems 0.9.1 Message-ID: <20070118235743.5BC565242748@rubyforge.org> Bugs item #7781, was opened at 2007-01-12 19:12 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=7781&group_id=797 Category: None Group: None >Status: Closed >Resolution: Accepted Priority: 3 Submitted By: Eric Hodel (drbrain) Assigned to: Nobody (None) Summary: rspec will not install on RubyGems 0.9.1 Initial Comment: Due to a security flaw in RubyGems, 0.9.1 and newer will no longer allow rspec to be installed: $ gem --version # actually, the downloaded 0.9.0.10 doesn't have the patch, use SVN 0.9.0.10 $ sudo gem install rspec --version 0.7.5 ERROR: While executing gem ... (Gem::InstallError) attempt to install file into "../web_spec/web_test_html_formatter.rb" ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-01-18 23:57 Message: Fixed in release 0.7.5.1. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-01-18 04:47 Message: Unfortunately, the trunk is not in a good condition to release right now. I'm hoping to get a 0.7.5.1 release out over the weekend (branched from the 0.7.5 release). ---------------------------------------------------------------------- Comment By: Jay Levitt (jaylev) Date: 2007-01-18 04:23 Message: The unintential creation of the ../web_spec directory seems to be an artifact of the old trunk layout. Can it safely be removed or updated from the Rakefile in trunk? Gem 0.9.1 is now released and considered a "required upgrade", so anyone with a properly secured system can no longer install rspec.. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=7781&group_id=797 From noreply at rubyforge.org Thu Jan 18 19:49:52 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 18 Jan 2007 19:49:52 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-7781 ] rspec will not install on RubyGems 0.9.1 Message-ID: <20070119004952.D8DC1524275E@rubyforge.org> Bugs item #7781, was opened at 2007-01-12 14:12 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=7781&group_id=797 Category: None Group: None >Status: Open Resolution: Accepted Priority: 3 Submitted By: Eric Hodel (drbrain) >Assigned to: David Chelimsky (dchelimsky) Summary: rspec will not install on RubyGems 0.9.1 Initial Comment: Due to a security flaw in RubyGems, 0.9.1 and newer will no longer allow rspec to be installed: $ gem --version # actually, the downloaded 0.9.0.10 doesn't have the patch, use SVN 0.9.0.10 $ sudo gem install rspec --version 0.7.5 ERROR: While executing gem ... (Gem::InstallError) attempt to install file into "../web_spec/web_test_html_formatter.rb" ---------------------------------------------------------------------- >Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-01-18 19:49 Message: Looks like it's not fixed on trunk yet, so I'm leaving this open until the maintenance fixes have been merged back to trunk. I noticed there were some doc changes too.... ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-01-18 18:57 Message: Fixed in release 0.7.5.1. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-01-17 23:47 Message: Unfortunately, the trunk is not in a good condition to release right now. I'm hoping to get a 0.7.5.1 release out over the weekend (branched from the 0.7.5 release). ---------------------------------------------------------------------- Comment By: Jay Levitt (jaylev) Date: 2007-01-17 23:23 Message: The unintential creation of the ../web_spec directory seems to be an artifact of the old trunk layout. Can it safely be removed or updated from the Rakefile in trunk? Gem 0.9.1 is now released and considered a "required upgrade", so anyone with a properly secured system can no longer install rspec.. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=7781&group_id=797 From noreply at rubyforge.org Thu Jan 18 21:22:49 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 18 Jan 2007 21:22:49 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-7781 ] rspec will not install on RubyGems 0.9.1 Message-ID: <20070119022249.F0DCD524276F@rubyforge.org> Bugs item #7781, was opened at 2007-01-12 19:12 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=7781&group_id=797 Category: None Group: None >Status: Closed Resolution: Accepted Priority: 3 Submitted By: Eric Hodel (drbrain) Assigned to: David Chelimsky (dchelimsky) Summary: rspec will not install on RubyGems 0.9.1 Initial Comment: Due to a security flaw in RubyGems, 0.9.1 and newer will no longer allow rspec to be installed: $ gem --version # actually, the downloaded 0.9.0.10 doesn't have the patch, use SVN 0.9.0.10 $ sudo gem install rspec --version 0.7.5 ERROR: While executing gem ... (Gem::InstallError) attempt to install file into "../web_spec/web_test_html_formatter.rb" ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-01-19 02:22 Message: This is not a problem in the trunk. You can prove that by building and installing the gem locally (after installing rubygems 0.9.1). You can do so w/ the trunk, but you can not from the 0.7.5 release. Also, the docs were changed in trunk a while back. Closing this back up. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-01-19 00:49 Message: Looks like it's not fixed on trunk yet, so I'm leaving this open until the maintenance fixes have been merged back to trunk. I noticed there were some doc changes too.... ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-01-18 23:57 Message: Fixed in release 0.7.5.1. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-01-18 04:47 Message: Unfortunately, the trunk is not in a good condition to release right now. I'm hoping to get a 0.7.5.1 release out over the weekend (branched from the 0.7.5 release). ---------------------------------------------------------------------- Comment By: Jay Levitt (jaylev) Date: 2007-01-18 04:23 Message: The unintential creation of the ../web_spec directory seems to be an artifact of the old trunk layout. Can it safely be removed or updated from the Rakefile in trunk? Gem 0.9.1 is now released and considered a "required upgrade", so anyone with a properly secured system can no longer install rspec.. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=7781&group_id=797 From dchelimsky at gmail.com Thu Jan 18 21:23:13 2007 From: dchelimsky at gmail.com (David Chelimsky) Date: Thu, 18 Jan 2007 20:23:13 -0600 Subject: [rspec-devel] [ANN] RSpec 0.7.5.1 Message-ID: <57c63afe0701181823ub9b7d1bq63d85f6627ffc3d4@mail.gmail.com> Announcing the release of RSpec 0.7.5.1. This release fixes a bug that prevents you from installing RSpec with rubygems 0.9.1. It does not include any other fixes, so we do not recommend that you upgrade to this if you are already using 0.7.5. Thank you, The RSpec Development Team From noreply at rubyforge.org Thu Jan 18 21:38:07 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 18 Jan 2007 21:38:07 -0500 (EST) Subject: [rspec-devel] [ rspec-Feature Requests-7496 ] Need a way to freeze the RSpec gem in a rails project Message-ID: <20070119023807.E3B78524278C@rubyforge.org> Feature Requests item #7496, was opened at 2006-12-30 03:22 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=7496&group_id=797 Category: rails plugin Group: None Status: Open Priority: 3 Submitted By: Steve Jorgensen (jorgens) Assigned to: Nobody (None) Summary: Need a way to freeze the RSpec gem in a rails project Initial Comment: The freeze_other_gems task doesn't work with RSpec, and my host doesn't have the RSpec gem installed. Therefore, when I upload my application, I can't run -any- rake tasks until I delete the rspec_on_rails_plugin. Needless to say, I can't then run my specs on the host server. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-01-19 02:38 Message: You can do this by either unpacking the gem in vendor/plugins or by installing the rspec core as a plugin: ruby script/plugin install svn://rubyforge.org/var/svn/rspec/tags/REL_0_7_5_1/rspec The only trick is that if you don't have any rspec gem installed you'll have to use the spec command in vendor/plugins/rspec/bin/spec. I'll leave this open until we add more explicit support for running rspec and rspec_on_rails as plugins with no gem installed, but the above info should get you functional in the mean time. David ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=7496&group_id=797 From noreply at rubyforge.org Fri Jan 19 04:30:19 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 19 Jan 2007 04:30:19 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-7826 ] RSpect.tmbundle web page out of date Message-ID: <20070119093020.0F9CB5240944@rubyforge.org> Bugs item #7826, was opened at 2007-01-14 14:43 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=7826&group_id=797 Category: None Group: None >Status: Closed >Resolution: Accepted Priority: 3 Submitted By: Mark Fredrickson (mfredrickson) >Assigned to: Aslak Helles?y (aslak_hellesoy) Summary: RSpect.tmbundle web page out of date Initial Comment: Hello, The information at: http://rspec.rubyforge.org/tools/extensions/editors/textmate.html Is out of date. The correct URL to use to get the bundle from source is: svn co svn://rubyforge.org/var/svn/rspec/trunk/RSpec.tmbundle Thanks! ---------------------------------------------------------------------- >Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-01-19 04:30 Message: Fixed in r1400 ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=7826&group_id=797 From noreply at rubyforge.org Fri Jan 19 04:35:03 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 19 Jan 2007 04:35:03 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-7636 ] drbspec not managing db connections appropriately Message-ID: <20070119093503.ABB5352409A4@rubyforge.org> Bugs item #7636, was opened at 2007-01-06 19:17 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=7636&group_id=797 Category: runner module Group: None Status: Open Resolution: None Priority: 3 Submitted By: Chris Anderson (jchris) Assigned to: Nobody (None) Summary: drbspec not managing db connections appropriately Initial Comment: I'm using the rails_spec_server and drbspec spec/ - the lastest versions (gem 0.7.6) - just generated from trunk yesterday. Running drbspec spec/ works as expected for about 30 runs, and then I start getting too many client errors from Postgres (gem 0.7.1). The same thing happens with the spec:autotest plugin - but it is just running drbspec repeatedly, as well. PGError in 'Given a generated source_report_spec.rb with fixtures loaded fixtures should load two SourceReports' FATAL: sorry, too many clients already script/rails_spec_server:16:in `run' script/rails_spec_server:37: I don't know if this is a specific to Postgres, but I do know I've never seen Postgres raise a too many clients error before in all my Rails work. Let me know if I can help with more information. jchris :: mfdz : com ---------------------------------------------------------------------- >Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-01-19 04:35 Message: I haven't looked into this yet, but from now on you should use spec --drb instead of drbspec. I doubt it will solve the problem though. It sounds like Rails (launched by rails_spec_server) is re-opening a new connection every time spec --drb connects to it. It could be a Rails problem. rails_spec_server essentially resets Rails in the same way as script/server in development mode. Do you get the same problem if you run your app in development mode and hit an AR-accessing controller as well? If that's the case, it's a Rails problem. Please try with Rails 1.2.1 and see if the problem still persists. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-01-06 20:05 Message: Have you had a similar experience just running 'rake spec'? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=7636&group_id=797 From noreply at rubyforge.org Fri Jan 19 04:44:11 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 19 Jan 2007 04:44:11 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-7754 ] Command-R fails to run spec in TextMate Message-ID: <20070119094411.E5DE35240993@rubyforge.org> Bugs item #7754, was opened at 2007-01-11 10:19 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=7754&group_id=797 Category: RSpec.tmbundle Group: None >Status: Closed >Resolution: Accepted Priority: 3 Submitted By: Brian Yamabe (byamabe) Assigned to: Aslak Helles?y (aslak_hellesoy) Summary: Command-R fails to run spec in TextMate Initial Comment: When trying to run a spec from TextMate using command-r, I get: /Library/Application Support/TextMate/Bundles/RSpec.tmbundle/Support/lib/spec_mate.rb:1:in `require': No such file to load -- rubygems (LoadError) from /Library/Application Support/TextMate/Bundles/RSpec.tmbundle/Support/lib/spec_mate.rb:1 from /tmp/temp_textmate.EMYXc6:3:in `require' from /tmp/temp_textmate.EMYXc6:3 TM_RUBY is set properly (/opt/local/bin/ruby) Tried the following at Aslak suggestion and it ran without errors. 1) Create a file called foo.rb 2) Add one line to it: require 'rubygems' 3) Open it in TextMate 4) Run it from TextMate (Cmd-R - Run) ---------------------------------------------------------------------- >Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-01-19 04:44 Message: Instructions added to docs in r1401 ---------------------------------------------------------------------- Comment By: Luke Redpath (lukeredpath) Date: 2007-01-11 10:29 Message: I had this problem too - the reason is that files with a shebang line (like the RSpec command in textmate) do not run the Textmate init script that picks up the system path it needs to find rubygems. To fix this problem, you also need to add the path to your ~/.MacOSX/ environment.plist file - here is mine: PATH /usr/local/bin:/usr/local/sbin:/usr/local/mysql/bin:/Users/luke/ bin:/opt/local/bin:/usr/local/mysql/bin Modify as necessary - you'll need to log out and log back in again for this to take effect. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=7754&group_id=797 From noreply at rubyforge.org Fri Jan 19 04:56:57 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 19 Jan 2007 04:56:57 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-6541 ] catch-22 using named routes Message-ID: <20070119095657.50508524098C@rubyforge.org> Bugs item #6541, was opened at 2006-11-07 08:39 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6541&group_id=797 Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: Nobody (None) Assigned to: Nobody (None) Summary: catch-22 using named routes Initial Comment: The recommended way specify controller redirects is to use controller.should_redirect_to 'path or hash' *before* calling the action. However, you cannot use named routes (XXX_url) until the action has been called (it gives 'rewrite' undefined for nil when it tries to call an instance variable in the controller). Can the mock be improved sufficiently to allow named routes to work in advance of the action? One workaround is to instantiate an ActionController::Integration::Session and delegate the named routes to that. ---------------------------------------------------------------------- Comment By: Eric Peden (ericpeden) Date: 2007-01-19 03:56 Message: I'm of the opinion that simply setting expectations post-action is insufficient. For example, I have a case where I simply want to verify that a named route points to the correct url. I'd like to simply do: docs_url.should == 'http://test.host/applicant/first-last/docs' without having to make a dummy call to the controller. I have a patch that I think fixes this problem. I extend ActionController::Base so that its @url variable is accessible and then initialize that in context_extra. This is what initialize_current_url does; I'm just doing it earlier. This allows named routes to be called at any point in the spec. I've added a spec to verify the new behavior, but I'm not sure if it runs properly. I get scores of errors when trying to run the specs for the rspec_for_rails plugin. I don't appear to be able to attach files to this request. Should I submit the patch in the patch tracker and then link to it here? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-12-07 10:05 Message: I'd say you should set your expectations post-action: response.should_be_redirect response.redirect_url.should == my_named_url ---------------------------------------------------------------------- Comment By: Brandon Keepers (brandon) Date: 2006-12-07 09:28 Message: Does anyone have any suggestions for a workaround for this? I tried sending :initialize_current_url to my controller in the setup and that doesn't seem to do anything. ---------------------------------------------------------------------- Comment By: Jerry West (jjw) Date: 2006-11-07 15:37 Message: PS: def redirect controller.url_for(response.redirected_to) end # that's because named routes return the path. While should_redirect_to takes paths, response.redirected_to is a Hash. Yes, I know, I know, I've just found out about should_have_redirected_to or whatever it is. I'm still coming to grips with the new equality rules and latest functionality! ---------------------------------------------------------------------- Comment By: Jerry West (jjw) Date: 2006-11-07 15:25 Message: Sorry, failing spec as requested... ---------------------------------------------------------- require File.dirname(__FILE__) + '/../spec_helper' # just so we have something to test class TestController < ApplicationController def index render :text => 'testing' # don't look for view end end # probably redundant with 0.7? context "All controllers (via ApplicationController)" do controller_name :test specify 'should redirect to login if protected page sought and not logged in' do controller.should_redirect_to login_url get :index controller.should_not_be_logged_in redirect.should == login_url end end ---------------------------------------------------------- spec -fs spec/controllers/application_controller_spec.rb /home/jjw/work/northants/config/environment.rb:31: warning: already initialized constant RAILS_CONNECTION_ADAPTERS Creating sqlite in memory database... All controllers (via ApplicationController) - should redirect to login if protected page sought and not logged in (FAILED - 1) 1) NoMethodError in 'All controllers (via ApplicationController) should redirect to login if protected page sought and not logged in' You have a nil object when you didn't expect it! The error occured while evaluating nil.rewrite generated/routing/named_routes/login.rb:2:in `login_url' ./spec/controllers/application_controller_spec.rb:17:in `should redirect to login if protected page sought and not logged in' Finished in 0.004108 seconds 1 specification, 1 failure --------------------------------------------------------- commenting out the offending 'should_redirect_to' shows that the code itself is fine and login_url valid after the call to get:- All controllers (via ApplicationController) - should redirect to login if protected page sought and not logged in Finished in 0.006735 seconds 1 specification, 0 failures ---------------------------------------------------------- Examining the code for ActionController::Base shows that the nil value is an unset instance variable (@url). There is a method 'initialize_current_url' (line 927) which passes @request and @params to UrlRewriter.new, if that's any help. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-07 11:46 Message: Could you please attach a failing spec as explained here? http://rspec.rubyforge.org/contribute.html ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6541&group_id=797 From noreply at rubyforge.org Fri Jan 19 05:11:30 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 19 Jan 2007 05:11:30 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-6541 ] catch-22 using named routes Message-ID: <20070119101130.5BAAA5240993@rubyforge.org> Bugs item #6541, was opened at 2006-11-07 08:39 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6541&group_id=797 Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: Nobody (None) Assigned to: Nobody (None) Summary: catch-22 using named routes Initial Comment: The recommended way specify controller redirects is to use controller.should_redirect_to 'path or hash' *before* calling the action. However, you cannot use named routes (XXX_url) until the action has been called (it gives 'rewrite' undefined for nil when it tries to call an instance variable in the controller). Can the mock be improved sufficiently to allow named routes to work in advance of the action? One workaround is to instantiate an ActionController::Integration::Session and delegate the named routes to that. ---------------------------------------------------------------------- Comment By: Eric Peden (ericpeden) Date: 2007-01-19 04:11 Message: You know, the more I think about it, the more I wonder if named routes should only appear in integration tests and not at all in specs. I'd also wanted to be able to do things like: get docs_url controller.should_render :template => 'docs/index' but it does feel like I'm crossing boundaries by bringing routing into the controller spec, since routing is what connects the public interface of my app (namly, the URLs) with the semi-backend (the controllers). But I really like RSpec's should_ syntax and don't want to have to go back to asserts in my integration tests. ;) ---------------------------------------------------------------------- Comment By: Eric Peden (ericpeden) Date: 2007-01-19 03:56 Message: I'm of the opinion that simply setting expectations post-action is insufficient. For example, I have a case where I simply want to verify that a named route points to the correct url. I'd like to simply do: docs_url.should == 'http://test.host/applicant/first-last/docs' without having to make a dummy call to the controller. I have a patch that I think fixes this problem. I extend ActionController::Base so that its @url variable is accessible and then initialize that in context_extra. This is what initialize_current_url does; I'm just doing it earlier. This allows named routes to be called at any point in the spec. I've added a spec to verify the new behavior, but I'm not sure if it runs properly. I get scores of errors when trying to run the specs for the rspec_for_rails plugin. I don't appear to be able to attach files to this request. Should I submit the patch in the patch tracker and then link to it here? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-12-07 10:05 Message: I'd say you should set your expectations post-action: response.should_be_redirect response.redirect_url.should == my_named_url ---------------------------------------------------------------------- Comment By: Brandon Keepers (brandon) Date: 2006-12-07 09:28 Message: Does anyone have any suggestions for a workaround for this? I tried sending :initialize_current_url to my controller in the setup and that doesn't seem to do anything. ---------------------------------------------------------------------- Comment By: Jerry West (jjw) Date: 2006-11-07 15:37 Message: PS: def redirect controller.url_for(response.redirected_to) end # that's because named routes return the path. While should_redirect_to takes paths, response.redirected_to is a Hash. Yes, I know, I know, I've just found out about should_have_redirected_to or whatever it is. I'm still coming to grips with the new equality rules and latest functionality! ---------------------------------------------------------------------- Comment By: Jerry West (jjw) Date: 2006-11-07 15:25 Message: Sorry, failing spec as requested... ---------------------------------------------------------- require File.dirname(__FILE__) + '/../spec_helper' # just so we have something to test class TestController < ApplicationController def index render :text => 'testing' # don't look for view end end # probably redundant with 0.7? context "All controllers (via ApplicationController)" do controller_name :test specify 'should redirect to login if protected page sought and not logged in' do controller.should_redirect_to login_url get :index controller.should_not_be_logged_in redirect.should == login_url end end ---------------------------------------------------------- spec -fs spec/controllers/application_controller_spec.rb /home/jjw/work/northants/config/environment.rb:31: warning: already initialized constant RAILS_CONNECTION_ADAPTERS Creating sqlite in memory database... All controllers (via ApplicationController) - should redirect to login if protected page sought and not logged in (FAILED - 1) 1) NoMethodError in 'All controllers (via ApplicationController) should redirect to login if protected page sought and not logged in' You have a nil object when you didn't expect it! The error occured while evaluating nil.rewrite generated/routing/named_routes/login.rb:2:in `login_url' ./spec/controllers/application_controller_spec.rb:17:in `should redirect to login if protected page sought and not logged in' Finished in 0.004108 seconds 1 specification, 1 failure --------------------------------------------------------- commenting out the offending 'should_redirect_to' shows that the code itself is fine and login_url valid after the call to get:- All controllers (via ApplicationController) - should redirect to login if protected page sought and not logged in Finished in 0.006735 seconds 1 specification, 0 failures ---------------------------------------------------------- Examining the code for ActionController::Base shows that the nil value is an unset instance variable (@url). There is a method 'initialize_current_url' (line 927) which passes @request and @params to UrlRewriter.new, if that's any help. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-07 11:46 Message: Could you please attach a failing spec as explained here? http://rspec.rubyforge.org/contribute.html ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6541&group_id=797 From noreply at rubyforge.org Fri Jan 19 05:13:34 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 19 Jan 2007 05:13:34 -0500 (EST) Subject: [rspec-devel] [ rspec-Feature Requests-7496 ] Need a way to freeze the RSpec gem in a rails project Message-ID: <20070119101334.E7535524098A@rubyforge.org> Feature Requests item #7496, was opened at 2006-12-29 22:22 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=7496&group_id=797 Category: rails plugin Group: None >Status: Closed Priority: 3 Submitted By: Steve Jorgensen (jorgens) >Assigned to: Aslak Helles?y (aslak_hellesoy) Summary: Need a way to freeze the RSpec gem in a rails project Initial Comment: The freeze_other_gems task doesn't work with RSpec, and my host doesn't have the RSpec gem installed. Therefore, when I upload my application, I can't run -any- rake tasks until I delete the rspec_on_rails_plugin. Needless to say, I can't then run my specs on the host server. ---------------------------------------------------------------------- >Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-01-19 05:13 Message: I have documented how to do this here: http://rubyforge.org/viewvc/trunk/doc/src/documentation/rails/install.page?root=rspec&view=markup After the next release, you'll see it here: http://rspec.rubyforge.org/documentation/rails/install.html Please note that the described approach will only work from release 0.7.6, so for no you have to use the trunk HEAD approach. I'm closing this. Please reopen this issue if it doesn't work for you. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-01-18 21:38 Message: You can do this by either unpacking the gem in vendor/plugins or by installing the rspec core as a plugin: ruby script/plugin install svn://rubyforge.org/var/svn/rspec/tags/REL_0_7_5_1/rspec The only trick is that if you don't have any rspec gem installed you'll have to use the spec command in vendor/plugins/rspec/bin/spec. I'll leave this open until we add more explicit support for running rspec and rspec_on_rails as plugins with no gem installed, but the above info should get you functional in the mean time. David ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=7496&group_id=797 From noreply at rubyforge.org Fri Jan 19 05:15:21 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 19 Jan 2007 05:15:21 -0500 (EST) Subject: [rspec-devel] [ rspec-Feature Requests-6807 ] port assert_select Message-ID: <20070119101521.AB2855240993@rubyforge.org> Feature Requests item #6807, was opened at 2006-11-21 14:27 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6807&group_id=797 Category: rails plugin Group: None Status: Open Priority: 3 Submitted By: David Chelimsky (dchelimsky) Assigned to: David Chelimsky (dchelimsky) Summary: port assert_select Initial Comment: Add an rspec implementation of assert_select. Need to decide whether to just duplicate existing API (using repsonse.should_have?????) or actually devise a more integrated API like this: repsonse.should_include(:form).with(:action => "blah") or response.should_include(:form).with do |form| form.should_include(:input).with(:name => 'age', :type => 'text') end or some such. ---------------------------------------------------------------------- >Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-01-19 05:15 Message: AFAICT assert_select is part of Rails core now. Can't we just use that? It seems like a lot of work to maintain our own. What's really missing now is doco on how to use this. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-12-13 05:43 Message: This is working w/ 1.2.0 and edge(5717) as of rspec rev 1286. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-12-08 17:00 Message: I checked in a preliminary port (rev 1276). It only works w/ 1.1.6 right now, but it works just like assert_select for everything except rjs: response.should_have (for tags w/ x-path like syntax) response.should_have_encoded response.should_have_email response.should_have_feed Remaining TODO: Get it to work w/ 1.2.0 and edge Figure out what to do about rjs (need a name other than should_have_rjs) Clean up the docs ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-22 08:00 Message: Josh - a plugin would be great. Could you use should_have instead of should_select (which doesn't really mean anything in this context): response.should_have "form>input[name=age][type=text]" I'm assuming you've got this implemented on ResponseBody, so there should be no conflict w/ Should#have. ---------------------------------------------------------------------- Comment By: Josh Chisholm (joshchisholm) Date: 2006-11-22 04:48 Message: I implemented a basic response.should_select by mixing in scrAPI. Haven't brought it up to date with rspec 0.72 yet, but I will if someone advises the best way to do so (assuming we don't want a scrAPI dependency in rspec core? - a plugin??). > The third seems to promote really detailed expectations about the HTML, and I think that way lies madness. If I understand correcly the second example implies the form has a child (somewhere unspecified) with certain specified attributes. I don't find this too detailed and if I remember correctly this can be done with a single selector: response.should_select "form>input[name=age][type=text]" This syntax is all I have needed so far. ---------------------------------------------------------------------- Comment By: Wilson Bilkovich (wilson) Date: 2006-11-21 17:43 Message: I like the: repsonse.should_include(:form).with(:action => "blah") version, myself. The third seems to promote really detailed expectations about the HTML, and I think that way lies madness. If someone writes the specs for it, I will code it. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6807&group_id=797 From noreply at rubyforge.org Fri Jan 19 07:48:28 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 19 Jan 2007 07:48:28 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-6541 ] catch-22 using named routes Message-ID: <20070119124828.9AFF75240B0C@rubyforge.org> Bugs item #6541, was opened at 2006-11-07 14:39 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6541&group_id=797 Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: Nobody (None) Assigned to: Nobody (None) Summary: catch-22 using named routes Initial Comment: The recommended way specify controller redirects is to use controller.should_redirect_to 'path or hash' *before* calling the action. However, you cannot use named routes (XXX_url) until the action has been called (it gives 'rewrite' undefined for nil when it tries to call an instance variable in the controller). Can the mock be improved sufficiently to allow named routes to work in advance of the action? One workaround is to instantiate an ActionController::Integration::Session and delegate the named routes to that. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-01-19 12:48 Message: Agreed that we should move the routing specs outside controller specs. I'll add a separate Feature Request for this. If you're satisfied w/ that, I'll leave it to you to close this bug. We will eventually add a Story Runner for acceptance-level (high level integration) testing. In the mean time, what I do personally is use rails integtration testing with rspec's expectations. For 0.7.5 and prior, you just require 'spec'. For future versions you'll also have to include a module, but this will be explained when we release. ---------------------------------------------------------------------- Comment By: Eric Peden (ericpeden) Date: 2007-01-19 10:11 Message: You know, the more I think about it, the more I wonder if named routes should only appear in integration tests and not at all in specs. I'd also wanted to be able to do things like: get docs_url controller.should_render :template => 'docs/index' but it does feel like I'm crossing boundaries by bringing routing into the controller spec, since routing is what connects the public interface of my app (namly, the URLs) with the semi-backend (the controllers). But I really like RSpec's should_ syntax and don't want to have to go back to asserts in my integration tests. ;) ---------------------------------------------------------------------- Comment By: Eric Peden (ericpeden) Date: 2007-01-19 09:56 Message: I'm of the opinion that simply setting expectations post-action is insufficient. For example, I have a case where I simply want to verify that a named route points to the correct url. I'd like to simply do: docs_url.should == 'http://test.host/applicant/first-last/docs' without having to make a dummy call to the controller. I have a patch that I think fixes this problem. I extend ActionController::Base so that its @url variable is accessible and then initialize that in context_extra. This is what initialize_current_url does; I'm just doing it earlier. This allows named routes to be called at any point in the spec. I've added a spec to verify the new behavior, but I'm not sure if it runs properly. I get scores of errors when trying to run the specs for the rspec_for_rails plugin. I don't appear to be able to attach files to this request. Should I submit the patch in the patch tracker and then link to it here? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-12-07 16:05 Message: I'd say you should set your expectations post-action: response.should_be_redirect response.redirect_url.should == my_named_url ---------------------------------------------------------------------- Comment By: Brandon Keepers (brandon) Date: 2006-12-07 15:28 Message: Does anyone have any suggestions for a workaround for this? I tried sending :initialize_current_url to my controller in the setup and that doesn't seem to do anything. ---------------------------------------------------------------------- Comment By: Jerry West (jjw) Date: 2006-11-07 21:37 Message: PS: def redirect controller.url_for(response.redirected_to) end # that's because named routes return the path. While should_redirect_to takes paths, response.redirected_to is a Hash. Yes, I know, I know, I've just found out about should_have_redirected_to or whatever it is. I'm still coming to grips with the new equality rules and latest functionality! ---------------------------------------------------------------------- Comment By: Jerry West (jjw) Date: 2006-11-07 21:25 Message: Sorry, failing spec as requested... ---------------------------------------------------------- require File.dirname(__FILE__) + '/../spec_helper' # just so we have something to test class TestController < ApplicationController def index render :text => 'testing' # don't look for view end end # probably redundant with 0.7? context "All controllers (via ApplicationController)" do controller_name :test specify 'should redirect to login if protected page sought and not logged in' do controller.should_redirect_to login_url get :index controller.should_not_be_logged_in redirect.should == login_url end end ---------------------------------------------------------- spec -fs spec/controllers/application_controller_spec.rb /home/jjw/work/northants/config/environment.rb:31: warning: already initialized constant RAILS_CONNECTION_ADAPTERS Creating sqlite in memory database... All controllers (via ApplicationController) - should redirect to login if protected page sought and not logged in (FAILED - 1) 1) NoMethodError in 'All controllers (via ApplicationController) should redirect to login if protected page sought and not logged in' You have a nil object when you didn't expect it! The error occured while evaluating nil.rewrite generated/routing/named_routes/login.rb:2:in `login_url' ./spec/controllers/application_controller_spec.rb:17:in `should redirect to login if protected page sought and not logged in' Finished in 0.004108 seconds 1 specification, 1 failure --------------------------------------------------------- commenting out the offending 'should_redirect_to' shows that the code itself is fine and login_url valid after the call to get:- All controllers (via ApplicationController) - should redirect to login if protected page sought and not logged in Finished in 0.006735 seconds 1 specification, 0 failures ---------------------------------------------------------- Examining the code for ActionController::Base shows that the nil value is an unset instance variable (@url). There is a method 'initialize_current_url' (line 927) which passes @request and @params to UrlRewriter.new, if that's any help. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-07 17:46 Message: Could you please attach a failing spec as explained here? http://rspec.rubyforge.org/contribute.html ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6541&group_id=797 From noreply at rubyforge.org Fri Jan 19 07:57:40 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 19 Jan 2007 07:57:40 -0500 (EST) Subject: [rspec-devel] [ rspec-Feature Requests-8001 ] separate out routing specs Message-ID: <20070119125740.470775240B0C@rubyforge.org> Feature Requests item #8001, was opened at 2007-01-19 12:57 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=8001&group_id=797 Category: rails plugin Group: None Status: Open Priority: 3 Submitted By: David Chelimsky (dchelimsky) Assigned to: Nobody (None) Summary: separate out routing specs Initial Comment: Routing happens outside of controllers and should be spec'able separately from controllers. This should be either part of a higher level integration spec or Story Runner, OR should be a new component category parallel w/ models, views, controllers and helpers. Routing specs should support both route processing and route generation. For example: route_for(:controller => "people", :action => "edit", :id => 1).should == "/people/1;edit" AND "/people/1;edit".should route_to(:controller => "people", :action => "edit", :id => 1) The latter example would be extremely useful for custom mappings like this: "/".should route_to(:controller => 'welcome') ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=8001&group_id=797 From noreply at rubyforge.org Fri Jan 19 08:00:15 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 19 Jan 2007 08:00:15 -0500 (EST) Subject: [rspec-devel] [ rspec-Feature Requests-6807 ] port assert_select Message-ID: <20070119130015.DB18E5240AE7@rubyforge.org> Feature Requests item #6807, was opened at 2006-11-21 19:27 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6807&group_id=797 Category: rails plugin Group: None Status: Open Priority: 3 Submitted By: David Chelimsky (dchelimsky) Assigned to: David Chelimsky (dchelimsky) Summary: port assert_select Initial Comment: Add an rspec implementation of assert_select. Need to decide whether to just duplicate existing API (using repsonse.should_have?????) or actually devise a more integrated API like this: repsonse.should_include(:form).with(:action => "blah") or response.should_include(:form).with do |form| form.should_include(:input).with(:name => 'age', :type => 'text') end or some such. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-01-19 13:00 Message: We can't use it as/is because it's all bound to test/unit. Right now there are 2 different implementations in the trunk. Over the next few days I'll clean this all up, doc it, and all will be right w/ the world. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-01-19 10:15 Message: AFAICT assert_select is part of Rails core now. Can't we just use that? It seems like a lot of work to maintain our own. What's really missing now is doco on how to use this. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-12-13 10:43 Message: This is working w/ 1.2.0 and edge(5717) as of rspec rev 1286. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-12-08 22:00 Message: I checked in a preliminary port (rev 1276). It only works w/ 1.1.6 right now, but it works just like assert_select for everything except rjs: response.should_have (for tags w/ x-path like syntax) response.should_have_encoded response.should_have_email response.should_have_feed Remaining TODO: Get it to work w/ 1.2.0 and edge Figure out what to do about rjs (need a name other than should_have_rjs) Clean up the docs ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-22 13:00 Message: Josh - a plugin would be great. Could you use should_have instead of should_select (which doesn't really mean anything in this context): response.should_have "form>input[name=age][type=text]" I'm assuming you've got this implemented on ResponseBody, so there should be no conflict w/ Should#have. ---------------------------------------------------------------------- Comment By: Josh Chisholm (joshchisholm) Date: 2006-11-22 09:48 Message: I implemented a basic response.should_select by mixing in scrAPI. Haven't brought it up to date with rspec 0.72 yet, but I will if someone advises the best way to do so (assuming we don't want a scrAPI dependency in rspec core? - a plugin??). > The third seems to promote really detailed expectations about the HTML, and I think that way lies madness. If I understand correcly the second example implies the form has a child (somewhere unspecified) with certain specified attributes. I don't find this too detailed and if I remember correctly this can be done with a single selector: response.should_select "form>input[name=age][type=text]" This syntax is all I have needed so far. ---------------------------------------------------------------------- Comment By: Wilson Bilkovich (wilson) Date: 2006-11-21 22:43 Message: I like the: repsonse.should_include(:form).with(:action => "blah") version, myself. The third seems to promote really detailed expectations about the HTML, and I think that way lies madness. If someone writes the specs for it, I will code it. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6807&group_id=797 From noreply at rubyforge.org Fri Jan 19 08:59:19 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 19 Jan 2007 08:59:19 -0500 (EST) Subject: [rspec-devel] [ rspec-Feature Requests-5663 ] context_setup Message-ID: <20070119135919.36A765240CBF@rubyforge.org> Feature Requests item #5663, was opened at 2006-09-07 12:51 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=5663&group_id=797 Category: None Group: None >Status: Closed Priority: 3 Submitted By: David Chelimsky (dchelimsky) Assigned to: Nobody (None) Summary: context_setup Initial Comment: There should be a context_setup (or similar construct) that only executes once within a given context. In fact, perhaps there could be such a thing with wider scope. The primary reason for this request has to do w/ using selenium. When you run the examples in ~/vendor/selenium, it fires up the browser once per spec. It would be nice to do that only once per run. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-01-19 13:59 Message: This was fixed in revision 1323. The Patch (https://rubyforge.org/tracker/index.php?func=detail&aid=7345&group_id=797&atid=3151) got closed, but this one didn't. Closing it now. ---------------------------------------------------------------------- Comment By: Bob Cotton (bcotton) Date: 2006-12-18 18:41 Message: Patch submitted in patch tracker: https://rubyforge.org/tracker/index.php?func=detail&aid=7345&group_id=797&atid=3151 ---------------------------------------------------------------------- Comment By: Bob Cotton (bcotton) Date: 2006-12-05 12:40 Message: This is a useful feature for defining acceptanct testing, where mocking is not an option. Additionally it would be great to allow instance variables from the context_setup to be visisble to all the specs. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-09-12 21:12 Message: Implementing this feature would potentially lead people to write specs that violate the principle of independent specs. Specs with sideffects. I've checked in a patchfile that deomstrates how to achieve a browser to be started only once. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=5663&group_id=797 From noreply at rubyforge.org Fri Jan 19 09:42:00 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 19 Jan 2007 09:42:00 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-7754 ] Command-R fails to run spec in TextMate Message-ID: <20070119144200.97FBC5240D17@rubyforge.org> Bugs item #7754, was opened at 2007-01-11 07:19 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=7754&group_id=797 Category: RSpec.tmbundle Group: None Status: Closed Resolution: Accepted Priority: 3 Submitted By: Brian Yamabe (byamabe) Assigned to: Aslak Helles?y (aslak_hellesoy) Summary: Command-R fails to run spec in TextMate Initial Comment: When trying to run a spec from TextMate using command-r, I get: /Library/Application Support/TextMate/Bundles/RSpec.tmbundle/Support/lib/spec_mate.rb:1:in `require': No such file to load -- rubygems (LoadError) from /Library/Application Support/TextMate/Bundles/RSpec.tmbundle/Support/lib/spec_mate.rb:1 from /tmp/temp_textmate.EMYXc6:3:in `require' from /tmp/temp_textmate.EMYXc6:3 TM_RUBY is set properly (/opt/local/bin/ruby) Tried the following at Aslak suggestion and it ran without errors. 1) Create a file called foo.rb 2) Add one line to it: require 'rubygems' 3) Open it in TextMate 4) Run it from TextMate (Cmd-R - Run) ---------------------------------------------------------------------- >Comment By: Brian Yamabe (byamabe) Date: 2007-01-19 06:42 Message: This helped, but now I get: /opt/local/lib/ruby/gems/1.8/gems/rspec-0.7.5/lib/spec/expectations/ sugar.rb:13:in `call': undefined method `controller_name' for # (NoMethodError) from /opt/local/lib/ruby/gems/1.8/gems/rspec-0.7.5/lib/ spec/expectations/sugar.rb:13:in `_method_missing' from /opt/local/lib/ ruby/gems/1.8/gems/rspec-0.7.5/lib/spec/expectations/sugar.rb:9:in `method_missing' from /opt/local/lib/ruby/gems/1.8/gems/rspec-0.7.5/ lib/spec/runner/context_eval.rb:46:in `method_missing' from ./ home_controller_spec.rb:5 from /opt/local/lib/ruby/gems/1.8/gems/ rspec-0.7.5/lib/spec/runner/context.rb:14:in `class_eval' from /opt/local/ lib/ruby/gems/1.8/gems/rspec-0.7.5/lib/spec/runner/context.rb:14:in `initialize' from /Users/byamabe/joyfulgames/work/trivia/config/../vendor/ plugins/rspec_on_rails/lib/spec/rails/context_factory.rb:18:in `new' from / Users/byamabe/joyfulgames/work/trivia/config/../vendor/plugins/ rspec_on_rails/lib/spec/rails/context_factory.rb:18:in `create' from /Users/ byamabe/joyfulgames/work/trivia/vendor/plugins/rspec_on_rails/lib/spec/ rails/extensions/kernel.rb:4:in `context' from ./home_controller_spec.rb:4 from /opt/local/lib/ruby/gems/1.8/gems/rspec-0.7.5/lib/spec/runner/ command_line.rb:21:in `load' from /opt/local/lib/ruby/gems/1.8/gems/ rspec-0.7.5/lib/spec/runner/command_line.rb:21:in `run' from /opt/local/ lib/ruby/gems/1.8/gems/rspec-0.7.5/lib/spec/runner/command_line.rb: 15:in `each' from /opt/local/lib/ruby/gems/1.8/gems/rspec-0.7.5/lib/spec/ runner/command_line.rb:15:in `run' from /Library/Application Support/ TextMate/Bundles/RSpec.tmbundle/Support/lib/spec_mate.rb:31:in `run' from /Library/Application Support/TextMate/Bundles/RSpec.tmbundle/ Support/lib/spec_mate.rb:9:in `run_file' from /tmp/temp_textmate.6oaSVX:4 ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-01-19 01:44 Message: Instructions added to docs in r1401 ---------------------------------------------------------------------- Comment By: Luke Redpath (lukeredpath) Date: 2007-01-11 07:29 Message: I had this problem too - the reason is that files with a shebang line (like the RSpec command in textmate) do not run the Textmate init script that picks up the system path it needs to find rubygems. To fix this problem, you also need to add the path to your ~/.MacOSX/ environment.plist file - here is mine: PATH /usr/local/bin:/usr/local/sbin:/usr/local/mysql/bin:/Users/luke/ bin:/opt/local/bin:/usr/local/mysql/bin Modify as necessary - you'll need to log out and log back in again for this to take effect. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=7754&group_id=797 From noreply at rubyforge.org Fri Jan 19 09:57:55 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 19 Jan 2007 09:57:55 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-7754 ] Command-R fails to run spec in TextMate Message-ID: <20070119145755.4A31B5240D21@rubyforge.org> Bugs item #7754, was opened at 2007-01-11 10:19 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=7754&group_id=797 Category: RSpec.tmbundle Group: None Status: Closed Resolution: Accepted Priority: 3 Submitted By: Brian Yamabe (byamabe) Assigned to: Aslak Helles?y (aslak_hellesoy) Summary: Command-R fails to run spec in TextMate Initial Comment: When trying to run a spec from TextMate using command-r, I get: /Library/Application Support/TextMate/Bundles/RSpec.tmbundle/Support/lib/spec_mate.rb:1:in `require': No such file to load -- rubygems (LoadError) from /Library/Application Support/TextMate/Bundles/RSpec.tmbundle/Support/lib/spec_mate.rb:1 from /tmp/temp_textmate.EMYXc6:3:in `require' from /tmp/temp_textmate.EMYXc6:3 TM_RUBY is set properly (/opt/local/bin/ruby) Tried the following at Aslak suggestion and it ran without errors. 1) Create a file called foo.rb 2) Add one line to it: require 'rubygems' 3) Open it in TextMate 4) Run it from TextMate (Cmd-R - Run) ---------------------------------------------------------------------- >Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-01-19 09:57 Message: What do you get when you run the specs from the command line? ---------------------------------------------------------------------- Comment By: Brian Yamabe (byamabe) Date: 2007-01-19 09:42 Message: This helped, but now I get: /opt/local/lib/ruby/gems/1.8/gems/rspec-0.7.5/lib/spec/expectations/ sugar.rb:13:in `call': undefined method `controller_name' for # (NoMethodError) from /opt/local/lib/ruby/gems/1.8/gems/rspec-0.7.5/lib/ spec/expectations/sugar.rb:13:in `_method_missing' from /opt/local/lib/ ruby/gems/1.8/gems/rspec-0.7.5/lib/spec/expectations/sugar.rb:9:in `method_missing' from /opt/local/lib/ruby/gems/1.8/gems/rspec-0.7.5/ lib/spec/runner/context_eval.rb:46:in `method_missing' from ./ home_controller_spec.rb:5 from /opt/local/lib/ruby/gems/1.8/gems/ rspec-0.7.5/lib/spec/runner/context.rb:14:in `class_eval' from /opt/local/ lib/ruby/gems/1.8/gems/rspec-0.7.5/lib/spec/runner/context.rb:14:in `initialize' from /Users/byamabe/joyfulgames/work/trivia/config/../vendor/ plugins/rspec_on_rails/lib/spec/rails/context_factory.rb:18:in `new' from / Users/byamabe/joyfulgames/work/trivia/config/../vendor/plugins/ rspec_on_rails/lib/spec/rails/context_factory.rb:18:in `create' from /Users/ byamabe/joyfulgames/work/trivia/vendor/plugins/rspec_on_rails/lib/spec/ rails/extensions/kernel.rb:4:in `context' from ./home_controller_spec.rb:4 from /opt/local/lib/ruby/gems/1.8/gems/rspec-0.7.5/lib/spec/runner/ command_line.rb:21:in `load' from /opt/local/lib/ruby/gems/1.8/gems/ rspec-0.7.5/lib/spec/runner/command_line.rb:21:in `run' from /opt/local/ lib/ruby/gems/1.8/gems/rspec-0.7.5/lib/spec/runner/command_line.rb: 15:in `each' from /opt/local/lib/ruby/gems/1.8/gems/rspec-0.7.5/lib/spec/ runner/command_line.rb:15:in `run' from /Library/Application Support/ TextMate/Bundles/RSpec.tmbundle/Support/lib/spec_mate.rb:31:in `run' from /Library/Application Support/TextMate/Bundles/RSpec.tmbundle/ Support/lib/spec_mate.rb:9:in `run_file' from /tmp/temp_textmate.6oaSVX:4 ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-01-19 04:44 Message: Instructions added to docs in r1401 ---------------------------------------------------------------------- Comment By: Luke Redpath (lukeredpath) Date: 2007-01-11 10:29 Message: I had this problem too - the reason is that files with a shebang line (like the RSpec command in textmate) do not run the Textmate init script that picks up the system path it needs to find rubygems. To fix this problem, you also need to add the path to your ~/.MacOSX/ environment.plist file - here is mine: PATH /usr/local/bin:/usr/local/sbin:/usr/local/mysql/bin:/Users/luke/ bin:/opt/local/bin:/usr/local/mysql/bin Modify as necessary - you'll need to log out and log back in again for this to take effect. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=7754&group_id=797 From noreply at rubyforge.org Fri Jan 19 10:00:19 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 19 Jan 2007 10:00:19 -0500 (EST) Subject: [rspec-devel] [ rspec-Feature Requests-8001 ] separate out routing specs Message-ID: <20070119150019.221985240D9E@rubyforge.org> Feature Requests item #8001, was opened at 2007-01-19 07:57 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=8001&group_id=797 Category: rails plugin Group: None Status: Open Priority: 3 Submitted By: David Chelimsky (dchelimsky) Assigned to: Nobody (None) Summary: separate out routing specs Initial Comment: Routing happens outside of controllers and should be spec'able separately from controllers. This should be either part of a higher level integration spec or Story Runner, OR should be a new component category parallel w/ models, views, controllers and helpers. Routing specs should support both route processing and route generation. For example: route_for(:controller => "people", :action => "edit", :id => 1).should == "/people/1;edit" AND "/people/1;edit".should route_to(:controller => "people", :action => "edit", :id => 1) The latter example would be extremely useful for custom mappings like this: "/".should route_to(:controller => 'welcome') ---------------------------------------------------------------------- >Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-01-19 10:00 Message: I LOVE that idea. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=8001&group_id=797 From noreply at rubyforge.org Fri Jan 19 11:34:51 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 19 Jan 2007 11:34:51 -0500 (EST) Subject: [rspec-devel] [ rspec-Feature Requests-8001 ] separate out routing specs Message-ID: <20070119163451.C2A825241074@rubyforge.org> Feature Requests item #8001, was opened at 2007-01-19 12:57 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=8001&group_id=797 Category: rails plugin Group: None Status: Open Priority: 3 Submitted By: David Chelimsky (dchelimsky) Assigned to: Nobody (None) Summary: separate out routing specs Initial Comment: Routing happens outside of controllers and should be spec'able separately from controllers. This should be either part of a higher level integration spec or Story Runner, OR should be a new component category parallel w/ models, views, controllers and helpers. Routing specs should support both route processing and route generation. For example: route_for(:controller => "people", :action => "edit", :id => 1).should == "/people/1;edit" AND "/people/1;edit".should route_to(:controller => "people", :action => "edit", :id => 1) The latter example would be extremely useful for custom mappings like this: "/".should route_to(:controller => 'welcome') ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-01-19 16:34 Message: I'd LOVE to take credit for it, but it comes from a comment by Eric Peden to [#6541]: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6541&group_id=797 Thanks for the idea Eric! ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-01-19 15:00 Message: I LOVE that idea. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=8001&group_id=797 From noreply at rubyforge.org Fri Jan 19 12:00:03 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 19 Jan 2007 12:00:03 -0500 (EST) Subject: [rspec-devel] [ rspec-Patches-8008 ] Correct generated specs for view when calling resource generator Message-ID: <20070119170003.C473B5240F80@rubyforge.org> Patches item #8008, was opened at 19/01/2007 18:00 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=8008&group_id=797 Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: Jonathan Tron (jonathant) Assigned to: Nobody (None) Summary: Correct generated specs for view when calling resource generator Initial Comment: The resource generator contains misplaced <% end -%> tags leading a poor little parenthesis to generate a syntax error in view specs. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=8008&group_id=797 From noreply at rubyforge.org Fri Jan 19 12:05:32 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 19 Jan 2007 12:05:32 -0500 (EST) Subject: [rspec-devel] [ rspec-Patches-8008 ] Correct generated specs for view when calling resource generator Message-ID: <20070119170533.5F2235241113@rubyforge.org> Patches item #8008, was opened at 19/01/2007 18:00 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=8008&group_id=797 Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: Jonathan Tron (jonathant) Assigned to: Nobody (None) Summary: Correct generated specs for view when calling resource generator Initial Comment: The resource generator contains misplaced <% end -%> tags leading a poor little parenthesis to generate a syntax error in view specs. ---------------------------------------------------------------------- >Comment By: Jonathan Tron (jonathant) Date: 19/01/2007 18:05 Message: First patch result from a bad svn help diff :p ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=8008&group_id=797 From noreply at rubyforge.org Fri Jan 19 12:18:33 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 19 Jan 2007 12:18:33 -0500 (EST) Subject: [rspec-devel] [ rspec-Patches-8008 ] Correct generated specs for view when calling resource generator Message-ID: <20070119171833.CA1175240D48@rubyforge.org> Patches item #8008, was opened at 2007-01-19 12:00 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=8008&group_id=797 Category: rails plugin Group: None >Status: Closed >Resolution: Accepted Priority: 3 Submitted By: Jonathan Tron (jonathant) >Assigned to: Aslak Helles?y (aslak_hellesoy) Summary: Correct generated specs for view when calling resource generator Initial Comment: The resource generator contains misplaced <% end -%> tags leading a poor little parenthesis to generate a syntax error in view specs. ---------------------------------------------------------------------- >Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-01-19 12:18 Message: Thanks. Applied on trunk in r1408 ---------------------------------------------------------------------- Comment By: Jonathan Tron (jonathant) Date: 2007-01-19 12:05 Message: First patch result from a bad svn help diff :p ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=8008&group_id=797 From noreply at rubyforge.org Fri Jan 19 16:10:08 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 19 Jan 2007 16:10:08 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-7754 ] Command-R fails to run spec in TextMate Message-ID: <20070119211008.B72635241388@rubyforge.org> Bugs item #7754, was opened at 2007-01-11 07:19 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=7754&group_id=797 Category: RSpec.tmbundle Group: None Status: Closed Resolution: Accepted Priority: 3 Submitted By: Brian Yamabe (byamabe) Assigned to: Aslak Helles?y (aslak_hellesoy) Summary: Command-R fails to run spec in TextMate Initial Comment: When trying to run a spec from TextMate using command-r, I get: /Library/Application Support/TextMate/Bundles/RSpec.tmbundle/Support/lib/spec_mate.rb:1:in `require': No such file to load -- rubygems (LoadError) from /Library/Application Support/TextMate/Bundles/RSpec.tmbundle/Support/lib/spec_mate.rb:1 from /tmp/temp_textmate.EMYXc6:3:in `require' from /tmp/temp_textmate.EMYXc6:3 TM_RUBY is set properly (/opt/local/bin/ruby) Tried the following at Aslak suggestion and it ran without errors. 1) Create a file called foo.rb 2) Add one line to it: require 'rubygems' 3) Open it in TextMate 4) Run it from TextMate (Cmd-R - Run) ---------------------------------------------------------------------- >Comment By: Brian Yamabe (byamabe) Date: 2007-01-19 13:10 Message: Running 'spec ' or 'rake spec' executes the test properly. In the terminal window running 'script/server' I do have this: Spec::Rails::HelperEvalContextController: missing default helper path spec/rails/ helper_eval_context_helper Spec::Rails::ViewSpecController: missing default helper path spec/rails/ view_spec_helper ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-01-19 06:57 Message: What do you get when you run the specs from the command line? ---------------------------------------------------------------------- Comment By: Brian Yamabe (byamabe) Date: 2007-01-19 06:42 Message: This helped, but now I get: /opt/local/lib/ruby/gems/1.8/gems/rspec-0.7.5/lib/spec/expectations/ sugar.rb:13:in `call': undefined method `controller_name' for # (NoMethodError) from /opt/local/lib/ruby/gems/1.8/gems/rspec-0.7.5/lib/ spec/expectations/sugar.rb:13:in `_method_missing' from /opt/local/lib/ ruby/gems/1.8/gems/rspec-0.7.5/lib/spec/expectations/sugar.rb:9:in `method_missing' from /opt/local/lib/ruby/gems/1.8/gems/rspec-0.7.5/ lib/spec/runner/context_eval.rb:46:in `method_missing' from ./ home_controller_spec.rb:5 from /opt/local/lib/ruby/gems/1.8/gems/ rspec-0.7.5/lib/spec/runner/context.rb:14:in `class_eval' from /opt/local/ lib/ruby/gems/1.8/gems/rspec-0.7.5/lib/spec/runner/context.rb:14:in `initialize' from /Users/byamabe/joyfulgames/work/trivia/config/../vendor/ plugins/rspec_on_rails/lib/spec/rails/context_factory.rb:18:in `new' from / Users/byamabe/joyfulgames/work/trivia/config/../vendor/plugins/ rspec_on_rails/lib/spec/rails/context_factory.rb:18:in `create' from /Users/ byamabe/joyfulgames/work/trivia/vendor/plugins/rspec_on_rails/lib/spec/ rails/extensions/kernel.rb:4:in `context' from ./home_controller_spec.rb:4 from /opt/local/lib/ruby/gems/1.8/gems/rspec-0.7.5/lib/spec/runner/ command_line.rb:21:in `load' from /opt/local/lib/ruby/gems/1.8/gems/ rspec-0.7.5/lib/spec/runner/command_line.rb:21:in `run' from /opt/local/ lib/ruby/gems/1.8/gems/rspec-0.7.5/lib/spec/runner/command_line.rb: 15:in `each' from /opt/local/lib/ruby/gems/1.8/gems/rspec-0.7.5/lib/spec/ runner/command_line.rb:15:in `run' from /Library/Application Support/ TextMate/Bundles/RSpec.tmbundle/Support/lib/spec_mate.rb:31:in `run' from /Library/Application Support/TextMate/Bundles/RSpec.tmbundle/ Support/lib/spec_mate.rb:9:in `run_file' from /tmp/temp_textmate.6oaSVX:4 ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-01-19 01:44 Message: Instructions added to docs in r1401 ---------------------------------------------------------------------- Comment By: Luke Redpath (lukeredpath) Date: 2007-01-11 07:29 Message: I had this problem too - the reason is that files with a shebang line (like the RSpec command in textmate) do not run the Textmate init script that picks up the system path it needs to find rubygems. To fix this problem, you also need to add the path to your ~/.MacOSX/ environment.plist file - here is mine: PATH /usr/local/bin:/usr/local/sbin:/usr/local/mysql/bin:/Users/luke/ bin:/opt/local/bin:/usr/local/mysql/bin Modify as necessary - you'll need to log out and log back in again for this to take effect. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=7754&group_id=797 From noreply at rubyforge.org Fri Jan 19 19:21:22 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 19 Jan 2007 19:21:22 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-7805 ] Stubs aren't being removed from modules Message-ID: <20070120002122.6DC1452415D7@rubyforge.org> Bugs item #7805, was opened at 2007-01-14 01:59 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=7805&group_id=797 Category: mock module Group: None Status: Open Resolution: None Priority: 3 Submitted By: Michal Kwiatkowski (infrared) Assigned to: Nobody (None) Summary: Stubs aren't being removed from modules Initial Comment: Stubs aren't removed after running specs, which doesn't break things for modules begin tested, but can be source of bugs if you're stubbing classes from stdlib. Example code stubs File.open and manages to break RSpec code itself. Place attached Rakefile and spec in the same directory, then run "rake --trace" to see: undefined method `<' for nil:NilClass /usr/lib/ruby/gems/1.8/gems/rspec-0.7.5/lib/spec/rake/verify_rcov.rb:42:in `define' Source of this error is 'total_coverage' variable which doesn't get initialized because File.open doesn't yield nor return anything useful (because it's still stubbed). As you see in the stack report, I'm using rspec 0.7.5. ---------------------------------------------------------------------- >Comment By: Michal Kwiatkowski (infrared) Date: 2007-01-20 00:21 Message: Can anyone confirm this bug? I found even a simpler example: ----- $ ls mock_on_file_causes_error.rb Rakefile $ cat Rakefile require 'spec/rake/spectask' require 'spec/rake/verify_rcov' Spec::Rake::SpecTask.new(:spec_with_rcov) do |t| t.spec_files = FileList['mock_on_file_causes_error.rb'] t.rcov = true end RCov::VerifyTask.new(:verify_rcov => :spec_with_rcov) do |t| t.threshold = 100 end task :default => :verify_rcov $ cat mock_on_file_causes_error.rb require 'rubygems' require 'spec' context "mocks" do specify "mock the File class" do File.should_not_receive :open end end $ rake (in /tmp/blah) rm -r coverage /usr/bin/ruby1.8 -I"/usr/lib/ruby/gems/1.8/gems/rspec-0.7.5/lib" -S rcov --exclude lib\/spec,bin\/spec -o "coverage" "/usr/lib/ruby/gems/1.8/gems/rspec-0.7.5/bin/spec" -- "mock_on_file_causes_error.rb" . Finished in 0.002439 seconds 1 specification, 0 failures Coverage: % (threshold: 100%) rake aborted! undefined method `<' for nil:NilClass (See full trace by running task with --trace) ----- As you can see not only stubbing, but mocking as well causes errors. ---------------------------------------------------------------------- Comment By: Michal Kwiatkowski (infrared) Date: 2007-01-14 11:22 Message: The bug seems to occur only in conjunction with rake and/or rcov but stack trace originates from rspec code (file spec/rake/verify_rcov.rb, line 42), within define of VerifyTask, which is run by rake only *after* the spec task completes (see the attached Rakefile). So it's not true that this code is run during the spec. Error presented by me isn't the only one that can happen because of stubbing File.open. Let me show you another one: Spec file contains (attached as spec_that_coredumps.rb): require 'rubygems' require 'spec' context "stubs" do specify "1 - stub the open method" do puts "BEFORE spec 1" File.stub!(:open).and_return("something") File.open.should == "something" puts "AFTER spec 1" end specify "2 - use File.open to create example.txt" do puts "BEFORE spec 1" File.open.should == "something" puts "AFTER spec 2" end end After running "rake --trace" I get a core dump: $ rake --trace (in /tmp/foobar) ** Invoke default (first_time) ** Invoke verify_rcov (first_time) ** Invoke spec_with_rcov (first_time) ** Invoke clobber_spec_with_rcov (first_time) ** Execute clobber_spec_with_rcov rm -r coverage ** Execute spec_with_rcov /usr/bin/ruby1.8 -I"/usr/lib/ruby/gems/1.8/gems/rspec-0.7.5/lib" -S rcov --exclude lib\/spec,bin\/spec -o "coverage" "/usr/lib/ruby/gems/1.8/gems/rspec-0.7.5/bin/spec" -- "foo.rb" BEFORE spec 1 AFTER spec 1 .BEFORE spec 1 [BUG] Segmentation fault ruby 1.8.4 (2005-12-24) [i486-linux] rake aborted! Command failed with status (): [/usr/bin/ruby1.8 -I"/usr/lib/ruby/gems/1.8...] /usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:722:in `sh' /usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:729:in `sh' /usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:812:in `sh' /usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:807:in `sh' /usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:747:in `ruby' /usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:812:in `ruby' /usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:807:in `ruby' /usr/lib/ruby/gems/1.8/gems/rspec-0.7.5/lib/spec/rake/spectask.rb:131:in `define' /usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:831:in `verbose' /usr/lib/ruby/gems/1.8/gems/rspec-0.7.5/lib/spec/rake/spectask.rb:110:in `define' /usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:387:in `execute' /usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:387:in `execute' /usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:357:in `invoke' /usr/lib/ruby/1.8/thread.rb:135:in `synchronize' /usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:350:in `invoke' /usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:364:in `invoke_prerequisites' /usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:999:in `each' /usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:363:in `invoke_prerequisites' /usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:356:in `invoke' /usr/lib/ruby/1.8/thread.rb:135:in `synchronize' /usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:350:in `invoke' /usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:364:in `invoke_prerequisites' /usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:999:in `each' /usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:363:in `invoke_prerequisites' /usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:356:in `invoke' /usr/lib/ruby/1.8/thread.rb:135:in `synchronize' /usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:350:in `invoke' /usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:1906:in `run' /usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:1906:in `run' /usr/lib/ruby/gems/1.8/gems/rake-0.7.1/bin/rake:7 /usr/bin/rake:18 If stub would be removed and state in the begining of spec2 would be exactly the same as before running spec1 error should not happen. Making spec2 the first spec in context will yield expected result: ArgumentError from File.open. Also, changing a line in spec2 to other that doesn't involve File.open will stop rake from coredumping, but original "undefined method `<' for nil:NilClass" error will still be there. Any ideas? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-01-14 05:04 Message: There is a problem here but it is different from what you suggest. I created a file called stubs_should_restore_methods.rb (attached). Here's the code and the command line session: require 'spec' context "stubs" do specify "1 - stub the open method" do File.stub!(:open).and_return("something") File.open.should == "something" end specify "2 - use File.open to create example.txt" do filename = "example-#{Time.now.to_i}.txt" file = File.open(filename,'w') file << "some text" file.close end end [david at mac tmp]$ ls -al total 0 drwxr-xr-x 2 david david 68 Jan 13 23:01 . drwxr-xr-x 9 david david 306 Jan 13 23:01 .. [david at mac tmp]$ mv ../stubs_should_restore_methods.rb . [david at mac tmp]$ ls -al total 8 drwxr-xr-x 3 david david 102 Jan 13 23:02 . drwxr-xr-x 8 david david 272 Jan 13 23:02 .. -rw-r--r-- 1 david david 348 Jan 13 22:54 stubs_should_restore_methods.rb [david at mac tmp]$ ruby stubs_should_restore_methods.rb -fs stubs - 1 - stub the open method - 2 - use File.open to create example.txt Finished in 0.001414 seconds 2 specifications, 0 failures [david at mac tmp]$ ls -al total 16 drwxr-xr-x 4 david david 136 Jan 13 23:02 . drwxr-xr-x 8 david david 272 Jan 13 23:02 .. -rw-r--r-- 1 david david 9 Jan 13 23:02 example-1168750953.txt -rw-r--r-- 1 david david 348 Jan 13 22:54 stubs_should_restore_methods.rb [david at mac tmp]$ ruby stubs_should_restore_methods.rb -fs stubs - 1 - stub the open method - 2 - use File.open to create example.txt Finished in 0.001393 seconds 2 specifications, 0 failures [david at mac tmp]$ ls -al total 24 drwxr-xr-x 5 david david 170 Jan 13 23:02 . drwxr-xr-x 8 david david 272 Jan 13 23:02 .. -rw-r--r-- 1 david david 9 Jan 13 23:02 example-1168750953.txt -rw-r--r-- 1 david david 9 Jan 13 23:02 example-1168750963.txt -rw-r--r-- 1 david david 348 Jan 13 22:54 stubs_should_restore_methods.rb As you can see, each time the spec is run, the second spec creates a new file using File.open, even though File.open had been stubbed in the first spec. I think the problem is that rcov is trying to use File.open to create and/or write to a file DURING the spec. If that's correct, I don't see what we would be able to do about that from RSpec. What do you think? Cheers, David ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=7805&group_id=797 From noreply at rubyforge.org Fri Jan 19 19:22:03 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 19 Jan 2007 19:22:03 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-7805 ] Stubs aren't being removed from modules Message-ID: <20070120002203.E278352415D9@rubyforge.org> Bugs item #7805, was opened at 2007-01-14 01:59 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=7805&group_id=797 Category: mock module Group: None Status: Open Resolution: None Priority: 3 Submitted By: Michal Kwiatkowski (infrared) Assigned to: Nobody (None) Summary: Stubs aren't being removed from modules Initial Comment: Stubs aren't removed after running specs, which doesn't break things for modules begin tested, but can be source of bugs if you're stubbing classes from stdlib. Example code stubs File.open and manages to break RSpec code itself. Place attached Rakefile and spec in the same directory, then run "rake --trace" to see: undefined method `<' for nil:NilClass /usr/lib/ruby/gems/1.8/gems/rspec-0.7.5/lib/spec/rake/verify_rcov.rb:42:in `define' Source of this error is 'total_coverage' variable which doesn't get initialized because File.open doesn't yield nor return anything useful (because it's still stubbed). As you see in the stack report, I'm using rspec 0.7.5. ---------------------------------------------------------------------- Comment By: Michal Kwiatkowski (infrared) Date: 2007-01-20 00:21 Message: Can anyone confirm this bug? I found even a simpler example: ----- $ ls mock_on_file_causes_error.rb Rakefile $ cat Rakefile require 'spec/rake/spectask' require 'spec/rake/verify_rcov' Spec::Rake::SpecTask.new(:spec_with_rcov) do |t| t.spec_files = FileList['mock_on_file_causes_error.rb'] t.rcov = true end RCov::VerifyTask.new(:verify_rcov => :spec_with_rcov) do |t| t.threshold = 100 end task :default => :verify_rcov $ cat mock_on_file_causes_error.rb require 'rubygems' require 'spec' context "mocks" do specify "mock the File class" do File.should_not_receive :open end end $ rake (in /tmp/blah) rm -r coverage /usr/bin/ruby1.8 -I"/usr/lib/ruby/gems/1.8/gems/rspec-0.7.5/lib" -S rcov --exclude lib\/spec,bin\/spec -o "coverage" "/usr/lib/ruby/gems/1.8/gems/rspec-0.7.5/bin/spec" -- "mock_on_file_causes_error.rb" . Finished in 0.002439 seconds 1 specification, 0 failures Coverage: % (threshold: 100%) rake aborted! undefined method `<' for nil:NilClass (See full trace by running task with --trace) ----- As you can see not only stubbing, but mocking as well causes errors. ---------------------------------------------------------------------- Comment By: Michal Kwiatkowski (infrared) Date: 2007-01-14 11:22 Message: The bug seems to occur only in conjunction with rake and/or rcov but stack trace originates from rspec code (file spec/rake/verify_rcov.rb, line 42), within define of VerifyTask, which is run by rake only *after* the spec task completes (see the attached Rakefile). So it's not true that this code is run during the spec. Error presented by me isn't the only one that can happen because of stubbing File.open. Let me show you another one: Spec file contains (attached as spec_that_coredumps.rb): require 'rubygems' require 'spec' context "stubs" do specify "1 - stub the open method" do puts "BEFORE spec 1" File.stub!(:open).and_return("something") File.open.should == "something" puts "AFTER spec 1" end specify "2 - use File.open to create example.txt" do puts "BEFORE spec 1" File.open.should == "something" puts "AFTER spec 2" end end After running "rake --trace" I get a core dump: $ rake --trace (in /tmp/foobar) ** Invoke default (first_time) ** Invoke verify_rcov (first_time) ** Invoke spec_with_rcov (first_time) ** Invoke clobber_spec_with_rcov (first_time) ** Execute clobber_spec_with_rcov rm -r coverage ** Execute spec_with_rcov /usr/bin/ruby1.8 -I"/usr/lib/ruby/gems/1.8/gems/rspec-0.7.5/lib" -S rcov --exclude lib\/spec,bin\/spec -o "coverage" "/usr/lib/ruby/gems/1.8/gems/rspec-0.7.5/bin/spec" -- "foo.rb" BEFORE spec 1 AFTER spec 1 .BEFORE spec 1 [BUG] Segmentation fault ruby 1.8.4 (2005-12-24) [i486-linux] rake aborted! Command failed with status (): [/usr/bin/ruby1.8 -I"/usr/lib/ruby/gems/1.8...] /usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:722:in `sh' /usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:729:in `sh' /usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:812:in `sh' /usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:807:in `sh' /usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:747:in `ruby' /usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:812:in `ruby' /usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:807:in `ruby' /usr/lib/ruby/gems/1.8/gems/rspec-0.7.5/lib/spec/rake/spectask.rb:131:in `define' /usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:831:in `verbose' /usr/lib/ruby/gems/1.8/gems/rspec-0.7.5/lib/spec/rake/spectask.rb:110:in `define' /usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:387:in `execute' /usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:387:in `execute' /usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:357:in `invoke' /usr/lib/ruby/1.8/thread.rb:135:in `synchronize' /usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:350:in `invoke' /usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:364:in `invoke_prerequisites' /usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:999:in `each' /usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:363:in `invoke_prerequisites' /usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:356:in `invoke' /usr/lib/ruby/1.8/thread.rb:135:in `synchronize' /usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:350:in `invoke' /usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:364:in `invoke_prerequisites' /usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:999:in `each' /usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:363:in `invoke_prerequisites' /usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:356:in `invoke' /usr/lib/ruby/1.8/thread.rb:135:in `synchronize' /usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:350:in `invoke' /usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:1906:in `run' /usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:1906:in `run' /usr/lib/ruby/gems/1.8/gems/rake-0.7.1/bin/rake:7 /usr/bin/rake:18 If stub would be removed and state in the begining of spec2 would be exactly the same as before running spec1 error should not happen. Making spec2 the first spec in context will yield expected result: ArgumentError from File.open. Also, changing a line in spec2 to other that doesn't involve File.open will stop rake from coredumping, but original "undefined method `<' for nil:NilClass" error will still be there. Any ideas? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-01-14 05:04 Message: There is a problem here but it is different from what you suggest. I created a file called stubs_should_restore_methods.rb (attached). Here's the code and the command line session: require 'spec' context "stubs" do specify "1 - stub the open method" do File.stub!(:open).and_return("something") File.open.should == "something" end specify "2 - use File.open to create example.txt" do filename = "example-#{Time.now.to_i}.txt" file = File.open(filename,'w') file << "some text" file.close end end [david at mac tmp]$ ls -al total 0 drwxr-xr-x 2 david david 68 Jan 13 23:01 . drwxr-xr-x 9 david david 306 Jan 13 23:01 .. [david at mac tmp]$ mv ../stubs_should_restore_methods.rb . [david at mac tmp]$ ls -al total 8 drwxr-xr-x 3 david david 102 Jan 13 23:02 . drwxr-xr-x 8 david david 272 Jan 13 23:02 .. -rw-r--r-- 1 david david 348 Jan 13 22:54 stubs_should_restore_methods.rb [david at mac tmp]$ ruby stubs_should_restore_methods.rb -fs stubs - 1 - stub the open method - 2 - use File.open to create example.txt Finished in 0.001414 seconds 2 specifications, 0 failures [david at mac tmp]$ ls -al total 16 drwxr-xr-x 4 david david 136 Jan 13 23:02 . drwxr-xr-x 8 david david 272 Jan 13 23:02 .. -rw-r--r-- 1 david david 9 Jan 13 23:02 example-1168750953.txt -rw-r--r-- 1 david david 348 Jan 13 22:54 stubs_should_restore_methods.rb [david at mac tmp]$ ruby stubs_should_restore_methods.rb -fs stubs - 1 - stub the open method - 2 - use File.open to create example.txt Finished in 0.001393 seconds 2 specifications, 0 failures [david at mac tmp]$ ls -al total 24 drwxr-xr-x 5 david david 170 Jan 13 23:02 . drwxr-xr-x 8 david david 272 Jan 13 23:02 .. -rw-r--r-- 1 david david 9 Jan 13 23:02 example-1168750953.txt -rw-r--r-- 1 david david 9 Jan 13 23:02 example-1168750963.txt -rw-r--r-- 1 david david 348 Jan 13 22:54 stubs_should_restore_methods.rb As you can see, each time the spec is run, the second spec creates a new file using File.open, even though File.open had been stubbed in the first spec. I think the problem is that rcov is trying to use File.open to create and/or write to a file DURING the spec. If that's correct, I don't see what we would be able to do about that from RSpec. What do you think? Cheers, David ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=7805&group_id=797 From noreply at rubyforge.org Sat Jan 20 13:46:50 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sat, 20 Jan 2007 13:46:50 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-8027 ] should_change works but should_not_change appears not to. Message-ID: <20070120184650.6DF135240D22@rubyforge.org> Bugs item #8027, was opened at 2007-01-20 10:46 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=8027&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: steve ross (cwd) Assigned to: Nobody (None) Summary: should_change works but should_not_change appears not to. Initial Comment: Rspec v. 0.8.0 (trunk) Given the code: context "Given a Bug (in general)" do specify "Should be able to add a valid record" do lambda { Bug.create(:title => 'a valid bug', :description => 'a valid description') }.should_change(Bug, :count).by(1) end specify "Should not be able to add an invalid record" do lambda { Bug.create(:description => 'a valid description') }.should_not_change(Bug, :count).by(1) end end The result is: 1) 'Given a Bug (in general) Should not be able to add an invalid record' FAILED count should have been changed by 1, but was changed by 0 ./spec/models/bug_spec.rb:18: Model code, bug.rb, is: class Bug < ActiveRecord::Base validates_presence_of :title end ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=8027&group_id=797 From noreply at rubyforge.org Sat Jan 20 13:50:53 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sat, 20 Jan 2007 13:50:53 -0500 (EST) Subject: [rspec-devel] [ rspec-Feature Requests-8028 ] version mismatch checking too strict Message-ID: <20070120185053.94A7C5240CFB@rubyforge.org> Feature Requests item #8028, was opened at 2007-01-20 10:50 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=8028&group_id=797 Category: rails plugin Group: None Status: Open Priority: 3 Submitted By: steve ross (cwd) Assigned to: Nobody (None) Summary: version mismatch checking too strict Initial Comment: When building from trunk, sometimes the gem gets a version update before the rails plugin or vice-versa. Can version checking be expanded to a range check so that the plugin only rails the version check if versions of rspec that are clearly outside the acceptable range (i.e., versions that will break the rails plugin) are rejected? I'm building from trunk and trying to be a good citizen about testing the latest and greatest, but I have three active and two dormant projects using rspec. Relaxing the requirement would save a lot of time. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=8028&group_id=797 From noreply at rubyforge.org Sun Jan 21 06:14:21 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 21 Jan 2007 06:14:21 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-8027 ] should_change works but should_not_change appears not to. Message-ID: <20070121111421.D86345240BAF@rubyforge.org> Bugs item #8027, was opened at 2007-01-20 18:46 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=8027&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: steve ross (cwd) Assigned to: Nobody (None) Summary: should_change works but should_not_change appears not to. Initial Comment: Rspec v. 0.8.0 (trunk) Given the code: context "Given a Bug (in general)" do specify "Should be able to add a valid record" do lambda { Bug.create(:title => 'a valid bug', :description => 'a valid description') }.should_change(Bug, :count).by(1) end specify "Should not be able to add an invalid record" do lambda { Bug.create(:description => 'a valid description') }.should_not_change(Bug, :count).by(1) end end The result is: 1) 'Given a Bug (in general) Should not be able to add an invalid record' FAILED count should have been changed by 1, but was changed by 0 ./spec/models/bug_spec.rb:18: Model code, bug.rb, is: class Bug < ActiveRecord::Base validates_presence_of :title end ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-01-21 11:14 Message: should_not_change is only spec'd to work without any extensions. i.e. Bug.create(:description => 'a valid description') }.should_not_change(Bug, :count) (without to, from or by) We have two choices to deal w/ this: 1 - disallow use of to, from or by with should_not_change 2 - support it My feeling about this is that if you're using should_not_change you shouldn't be using the extensions, so I'd go for 1. Other opinions? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=8027&group_id=797 From noreply at rubyforge.org Sun Jan 21 14:38:33 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 21 Jan 2007 14:38:33 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-8027 ] should_change works but should_not_change appears not to. Message-ID: <20070121193833.E5C8D52412A8@rubyforge.org> Bugs item #8027, was opened at 2007-01-20 13:46 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=8027&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: steve ross (cwd) Assigned to: Nobody (None) Summary: should_change works but should_not_change appears not to. Initial Comment: Rspec v. 0.8.0 (trunk) Given the code: context "Given a Bug (in general)" do specify "Should be able to add a valid record" do lambda { Bug.create(:title => 'a valid bug', :description => 'a valid description') }.should_change(Bug, :count).by(1) end specify "Should not be able to add an invalid record" do lambda { Bug.create(:description => 'a valid description') }.should_not_change(Bug, :count).by(1) end end The result is: 1) 'Given a Bug (in general) Should not be able to add an invalid record' FAILED count should have been changed by 1, but was changed by 0 ./spec/models/bug_spec.rb:18: Model code, bug.rb, is: class Bug < ActiveRecord::Base validates_presence_of :title end ---------------------------------------------------------------------- Comment By: Wilson Bilkovich (wilson) Date: 2007-01-21 14:38 Message: I should have disallowed it originally, in my opinion, making this a real bug. However, if we assume for a moment that we wanted to support it, how would it work? given: lambda {}.should_not_change(Thing, :count) The current code 'knows' that that expectation should fail as soon as it can compare the before and after values. lambda {}.should_not_change(Thing, :count).by(2) would, I would expect, pass if the count changed by 1. This means that the bare version without 'by' would fail, but the 'by' version would pass. Given that the bare 'should_not_change' has no way of knowing whether it will have 'by' called on it, I don't see a way to implement that. Every other extension type makes the expectation MORE specific, not less. This would violate that guideline, and I'm not sure it is implementable. Any ideas? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-01-21 06:14 Message: should_not_change is only spec'd to work without any extensions. i.e. Bug.create(:description => 'a valid description') }.should_not_change(Bug, :count) (without to, from or by) We have two choices to deal w/ this: 1 - disallow use of to, from or by with should_not_change 2 - support it My feeling about this is that if you're using should_not_change you shouldn't be using the extensions, so I'd go for 1. Other opinions? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=8027&group_id=797 From noreply at rubyforge.org Sun Jan 21 15:16:36 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 21 Jan 2007 15:16:36 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-8027 ] should_change works but should_not_change appears not to. Message-ID: <20070121201636.C9D0752412B2@rubyforge.org> Bugs item #8027, was opened at 2007-01-20 10:46 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=8027&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: steve ross (cwd) Assigned to: Nobody (None) Summary: should_change works but should_not_change appears not to. Initial Comment: Rspec v. 0.8.0 (trunk) Given the code: context "Given a Bug (in general)" do specify "Should be able to add a valid record" do lambda { Bug.create(:title => 'a valid bug', :description => 'a valid description') }.should_change(Bug, :count).by(1) end specify "Should not be able to add an invalid record" do lambda { Bug.create(:description => 'a valid description') }.should_not_change(Bug, :count).by(1) end end The result is: 1) 'Given a Bug (in general) Should not be able to add an invalid record' FAILED count should have been changed by 1, but was changed by 0 ./spec/models/bug_spec.rb:18: Model code, bug.rb, is: class Bug < ActiveRecord::Base validates_presence_of :title end ---------------------------------------------------------------------- >Comment By: steve ross (cwd) Date: 2007-01-21 12:16 Message: It would seem that most expectations also have a negative expectation associated with them (i.e., should_nnn has a corresponding should_not_nnn). The expected behavior, then would be that if the object changed by any number other than the specified one, it would fail. Is there value to adding this? Am I right about the parallelism among expectations? ---------------------------------------------------------------------- Comment By: Wilson Bilkovich (wilson) Date: 2007-01-21 11:38 Message: I should have disallowed it originally, in my opinion, making this a real bug. However, if we assume for a moment that we wanted to support it, how would it work? given: lambda {}.should_not_change(Thing, :count) The current code 'knows' that that expectation should fail as soon as it can compare the before and after values. lambda {}.should_not_change(Thing, :count).by(2) would, I would expect, pass if the count changed by 1. This means that the bare version without 'by' would fail, but the 'by' version would pass. Given that the bare 'should_not_change' has no way of knowing whether it will have 'by' called on it, I don't see a way to implement that. Every other extension type makes the expectation MORE specific, not less. This would violate that guideline, and I'm not sure it is implementable. Any ideas? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-01-21 03:14 Message: should_not_change is only spec'd to work without any extensions. i.e. Bug.create(:description => 'a valid description') }.should_not_change(Bug, :count) (without to, from or by) We have two choices to deal w/ this: 1 - disallow use of to, from or by with should_not_change 2 - support it My feeling about this is that if you're using should_not_change you shouldn't be using the extensions, so I'd go for 1. Other opinions? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=8027&group_id=797 From noreply at rubyforge.org Sun Jan 21 15:22:21 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 21 Jan 2007 15:22:21 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-8027 ] should_change works but should_not_change appears not to. Message-ID: <20070121202221.73E7F52412C7@rubyforge.org> Bugs item #8027, was opened at 2007-01-20 18:46 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=8027&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: steve ross (cwd) Assigned to: Nobody (None) Summary: should_change works but should_not_change appears not to. Initial Comment: Rspec v. 0.8.0 (trunk) Given the code: context "Given a Bug (in general)" do specify "Should be able to add a valid record" do lambda { Bug.create(:title => 'a valid bug', :description => 'a valid description') }.should_change(Bug, :count).by(1) end specify "Should not be able to add an invalid record" do lambda { Bug.create(:description => 'a valid description') }.should_not_change(Bug, :count).by(1) end end The result is: 1) 'Given a Bug (in general) Should not be able to add an invalid record' FAILED count should have been changed by 1, but was changed by 0 ./spec/models/bug_spec.rb:18: Model code, bug.rb, is: class Bug < ActiveRecord::Base validates_presence_of :title end ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-01-21 20:22 Message: I think it's OK to not be parallel. For example, these two mean the same thing: team.should_not have_at_least(4).players team.should have_at_most(3).players Would you EVER want to use the first? Talk about making specs unclear! Being able to say proc.should_not change(Model, :count).by(1) is like saying - it's OK for this to cause a change, but whatever you do, don't change it by 1. That's just a bit too non-deterministic for my stomach. ---------------------------------------------------------------------- Comment By: steve ross (cwd) Date: 2007-01-21 20:16 Message: It would seem that most expectations also have a negative expectation associated with them (i.e., should_nnn has a corresponding should_not_nnn). The expected behavior, then would be that if the object changed by any number other than the specified one, it would fail. Is there value to adding this? Am I right about the parallelism among expectations? ---------------------------------------------------------------------- Comment By: Wilson Bilkovich (wilson) Date: 2007-01-21 19:38 Message: I should have disallowed it originally, in my opinion, making this a real bug. However, if we assume for a moment that we wanted to support it, how would it work? given: lambda {}.should_not_change(Thing, :count) The current code 'knows' that that expectation should fail as soon as it can compare the before and after values. lambda {}.should_not_change(Thing, :count).by(2) would, I would expect, pass if the count changed by 1. This means that the bare version without 'by' would fail, but the 'by' version would pass. Given that the bare 'should_not_change' has no way of knowing whether it will have 'by' called on it, I don't see a way to implement that. Every other extension type makes the expectation MORE specific, not less. This would violate that guideline, and I'm not sure it is implementable. Any ideas? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-01-21 11:14 Message: should_not_change is only spec'd to work without any extensions. i.e. Bug.create(:description => 'a valid description') }.should_not_change(Bug, :count) (without to, from or by) We have two choices to deal w/ this: 1 - disallow use of to, from or by with should_not_change 2 - support it My feeling about this is that if you're using should_not_change you shouldn't be using the extensions, so I'd go for 1. Other opinions? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=8027&group_id=797 From noreply at rubyforge.org Sun Jan 21 15:29:56 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 21 Jan 2007 15:29:56 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-8027 ] should_change works but should_not_change appears not to. Message-ID: <20070121202956.821F452412C6@rubyforge.org> Bugs item #8027, was opened at 2007-01-20 10:46 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=8027&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: steve ross (cwd) Assigned to: Nobody (None) Summary: should_change works but should_not_change appears not to. Initial Comment: Rspec v. 0.8.0 (trunk) Given the code: context "Given a Bug (in general)" do specify "Should be able to add a valid record" do lambda { Bug.create(:title => 'a valid bug', :description => 'a valid description') }.should_change(Bug, :count).by(1) end specify "Should not be able to add an invalid record" do lambda { Bug.create(:description => 'a valid description') }.should_not_change(Bug, :count).by(1) end end The result is: 1) 'Given a Bug (in general) Should not be able to add an invalid record' FAILED count should have been changed by 1, but was changed by 0 ./spec/models/bug_spec.rb:18: Model code, bug.rb, is: class Bug < ActiveRecord::Base validates_presence_of :title end ---------------------------------------------------------------------- >Comment By: steve ross (cwd) Date: 2007-01-21 12:29 Message: Let's talk about how something this obtuse comes about. Typically, I spec positive expectations first to make sure what I think will happen does indeed happen. Then I add negative expectations to weed out some corner cases. This may seem duplicative, but the specs might read: "should be able to add a valid record" and "should not be able to add an invalid record." Clearly copy/paste is a quick way to get this kind of template set up, but the change in sugar is why it doesn't work quite as simply as adding *not*. This is user error, but it might come up again. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-01-21 12:22 Message: I think it's OK to not be parallel. For example, these two mean the same thing: team.should_not have_at_least(4).players team.should have_at_most(3).players Would you EVER want to use the first? Talk about making specs unclear! Being able to say proc.should_not change(Model, :count).by(1) is like saying - it's OK for this to cause a change, but whatever you do, don't change it by 1. That's just a bit too non-deterministic for my stomach. ---------------------------------------------------------------------- Comment By: steve ross (cwd) Date: 2007-01-21 12:16 Message: It would seem that most expectations also have a negative expectation associated with them (i.e., should_nnn has a corresponding should_not_nnn). The expected behavior, then would be that if the object changed by any number other than the specified one, it would fail. Is there value to adding this? Am I right about the parallelism among expectations? ---------------------------------------------------------------------- Comment By: Wilson Bilkovich (wilson) Date: 2007-01-21 11:38 Message: I should have disallowed it originally, in my opinion, making this a real bug. However, if we assume for a moment that we wanted to support it, how would it work? given: lambda {}.should_not_change(Thing, :count) The current code 'knows' that that expectation should fail as soon as it can compare the before and after values. lambda {}.should_not_change(Thing, :count).by(2) would, I would expect, pass if the count changed by 1. This means that the bare version without 'by' would fail, but the 'by' version would pass. Given that the bare 'should_not_change' has no way of knowing whether it will have 'by' called on it, I don't see a way to implement that. Every other extension type makes the expectation MORE specific, not less. This would violate that guideline, and I'm not sure it is implementable. Any ideas? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-01-21 03:14 Message: should_not_change is only spec'd to work without any extensions. i.e. Bug.create(:description => 'a valid description') }.should_not_change(Bug, :count) (without to, from or by) We have two choices to deal w/ this: 1 - disallow use of to, from or by with should_not_change 2 - support it My feeling about this is that if you're using should_not_change you shouldn't be using the extensions, so I'd go for 1. Other opinions? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=8027&group_id=797 From noreply at rubyforge.org Sun Jan 21 16:20:42 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 21 Jan 2007 16:20:42 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-8027 ] should_change works but should_not_change appears not to. Message-ID: <20070121212042.446B2524131C@rubyforge.org> Bugs item #8027, was opened at 2007-01-20 18:46 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=8027&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: steve ross (cwd) Assigned to: Nobody (None) Summary: should_change works but should_not_change appears not to. Initial Comment: Rspec v. 0.8.0 (trunk) Given the code: context "Given a Bug (in general)" do specify "Should be able to add a valid record" do lambda { Bug.create(:title => 'a valid bug', :description => 'a valid description') }.should_change(Bug, :count).by(1) end specify "Should not be able to add an invalid record" do lambda { Bug.create(:description => 'a valid description') }.should_not_change(Bug, :count).by(1) end end The result is: 1) 'Given a Bug (in general) Should not be able to add an invalid record' FAILED count should have been changed by 1, but was changed by 0 ./spec/models/bug_spec.rb:18: Model code, bug.rb, is: class Bug < ActiveRecord::Base validates_presence_of :title end ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-01-21 21:20 Message: Steve, I agree that there are many cases where negative expectations make perfect sense. Generally, I think there should be a parallel negative. It's the weird ones like should_change(obj, :sym).by(1) that, in my view, make specs more confusing than explicit that make me think absolute parallelism is not a necessity. ---------------------------------------------------------------------- Comment By: steve ross (cwd) Date: 2007-01-21 20:29 Message: Let's talk about how something this obtuse comes about. Typically, I spec positive expectations first to make sure what I think will happen does indeed happen. Then I add negative expectations to weed out some corner cases. This may seem duplicative, but the specs might read: "should be able to add a valid record" and "should not be able to add an invalid record." Clearly copy/paste is a quick way to get this kind of template set up, but the change in sugar is why it doesn't work quite as simply as adding *not*. This is user error, but it might come up again. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-01-21 20:22 Message: I think it's OK to not be parallel. For example, these two mean the same thing: team.should_not have_at_least(4).players team.should have_at_most(3).players Would you EVER want to use the first? Talk about making specs unclear! Being able to say proc.should_not change(Model, :count).by(1) is like saying - it's OK for this to cause a change, but whatever you do, don't change it by 1. That's just a bit too non-deterministic for my stomach. ---------------------------------------------------------------------- Comment By: steve ross (cwd) Date: 2007-01-21 20:16 Message: It would seem that most expectations also have a negative expectation associated with them (i.e., should_nnn has a corresponding should_not_nnn). The expected behavior, then would be that if the object changed by any number other than the specified one, it would fail. Is there value to adding this? Am I right about the parallelism among expectations? ---------------------------------------------------------------------- Comment By: Wilson Bilkovich (wilson) Date: 2007-01-21 19:38 Message: I should have disallowed it originally, in my opinion, making this a real bug. However, if we assume for a moment that we wanted to support it, how would it work? given: lambda {}.should_not_change(Thing, :count) The current code 'knows' that that expectation should fail as soon as it can compare the before and after values. lambda {}.should_not_change(Thing, :count).by(2) would, I would expect, pass if the count changed by 1. This means that the bare version without 'by' would fail, but the 'by' version would pass. Given that the bare 'should_not_change' has no way of knowing whether it will have 'by' called on it, I don't see a way to implement that. Every other extension type makes the expectation MORE specific, not less. This would violate that guideline, and I'm not sure it is implementable. Any ideas? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-01-21 11:14 Message: should_not_change is only spec'd to work without any extensions. i.e. Bug.create(:description => 'a valid description') }.should_not_change(Bug, :count) (without to, from or by) We have two choices to deal w/ this: 1 - disallow use of to, from or by with should_not_change 2 - support it My feeling about this is that if you're using should_not_change you shouldn't be using the extensions, so I'd go for 1. Other opinions? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=8027&group_id=797 From noreply at rubyforge.org Sun Jan 21 16:21:22 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 21 Jan 2007 16:21:22 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-8027 ] should_change works but should_not_change appears not to. Message-ID: <20070121212122.A38665241324@rubyforge.org> Bugs item #8027, was opened at 2007-01-20 18:46 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=8027&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: steve ross (cwd) Assigned to: Nobody (None) Summary: should_change works but should_not_change appears not to. Initial Comment: Rspec v. 0.8.0 (trunk) Given the code: context "Given a Bug (in general)" do specify "Should be able to add a valid record" do lambda { Bug.create(:title => 'a valid bug', :description => 'a valid description') }.should_change(Bug, :count).by(1) end specify "Should not be able to add an invalid record" do lambda { Bug.create(:description => 'a valid description') }.should_not_change(Bug, :count).by(1) end end The result is: 1) 'Given a Bug (in general) Should not be able to add an invalid record' FAILED count should have been changed by 1, but was changed by 0 ./spec/models/bug_spec.rb:18: Model code, bug.rb, is: class Bug < ActiveRecord::Base validates_presence_of :title end ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-01-21 21:21 Message: Sorry... that should have been "should_not_change(obj, :sym).by(1)" ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-01-21 21:20 Message: Steve, I agree that there are many cases where negative expectations make perfect sense. Generally, I think there should be a parallel negative. It's the weird ones like should_change(obj, :sym).by(1) that, in my view, make specs more confusing than explicit that make me think absolute parallelism is not a necessity. ---------------------------------------------------------------------- Comment By: steve ross (cwd) Date: 2007-01-21 20:29 Message: Let's talk about how something this obtuse comes about. Typically, I spec positive expectations first to make sure what I think will happen does indeed happen. Then I add negative expectations to weed out some corner cases. This may seem duplicative, but the specs might read: "should be able to add a valid record" and "should not be able to add an invalid record." Clearly copy/paste is a quick way to get this kind of template set up, but the change in sugar is why it doesn't work quite as simply as adding *not*. This is user error, but it might come up again. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-01-21 20:22 Message: I think it's OK to not be parallel. For example, these two mean the same thing: team.should_not have_at_least(4).players team.should have_at_most(3).players Would you EVER want to use the first? Talk about making specs unclear! Being able to say proc.should_not change(Model, :count).by(1) is like saying - it's OK for this to cause a change, but whatever you do, don't change it by 1. That's just a bit too non-deterministic for my stomach. ---------------------------------------------------------------------- Comment By: steve ross (cwd) Date: 2007-01-21 20:16 Message: It would seem that most expectations also have a negative expectation associated with them (i.e., should_nnn has a corresponding should_not_nnn). The expected behavior, then would be that if the object changed by any number other than the specified one, it would fail. Is there value to adding this? Am I right about the parallelism among expectations? ---------------------------------------------------------------------- Comment By: Wilson Bilkovich (wilson) Date: 2007-01-21 19:38 Message: I should have disallowed it originally, in my opinion, making this a real bug. However, if we assume for a moment that we wanted to support it, how would it work? given: lambda {}.should_not_change(Thing, :count) The current code 'knows' that that expectation should fail as soon as it can compare the before and after values. lambda {}.should_not_change(Thing, :count).by(2) would, I would expect, pass if the count changed by 1. This means that the bare version without 'by' would fail, but the 'by' version would pass. Given that the bare 'should_not_change' has no way of knowing whether it will have 'by' called on it, I don't see a way to implement that. Every other extension type makes the expectation MORE specific, not less. This would violate that guideline, and I'm not sure it is implementable. Any ideas? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-01-21 11:14 Message: should_not_change is only spec'd to work without any extensions. i.e. Bug.create(:description => 'a valid description') }.should_not_change(Bug, :count) (without to, from or by) We have two choices to deal w/ this: 1 - disallow use of to, from or by with should_not_change 2 - support it My feeling about this is that if you're using should_not_change you shouldn't be using the extensions, so I'd go for 1. Other opinions? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=8027&group_id=797 From noreply at rubyforge.org Sun Jan 21 16:24:26 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 21 Jan 2007 16:24:26 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-8027 ] should_change works but should_not_change appears not to. Message-ID: <20070121212426.C1BB5524131C@rubyforge.org> Bugs item #8027, was opened at 2007-01-20 10:46 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=8027&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: steve ross (cwd) Assigned to: Nobody (None) Summary: should_change works but should_not_change appears not to. Initial Comment: Rspec v. 0.8.0 (trunk) Given the code: context "Given a Bug (in general)" do specify "Should be able to add a valid record" do lambda { Bug.create(:title => 'a valid bug', :description => 'a valid description') }.should_change(Bug, :count).by(1) end specify "Should not be able to add an invalid record" do lambda { Bug.create(:description => 'a valid description') }.should_not_change(Bug, :count).by(1) end end The result is: 1) 'Given a Bug (in general) Should not be able to add an invalid record' FAILED count should have been changed by 1, but was changed by 0 ./spec/models/bug_spec.rb:18: Model code, bug.rb, is: class Bug < ActiveRecord::Base validates_presence_of :title end ---------------------------------------------------------------------- >Comment By: steve ross (cwd) Date: 2007-01-21 13:24 Message: Ok, how about we make this an RFE: Where a positive expectation exists without a corresponding negative one, a note in the docs should reflect that. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-01-21 13:21 Message: Sorry... that should have been "should_not_change(obj, :sym).by(1)" ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-01-21 13:20 Message: Steve, I agree that there are many cases where negative expectations make perfect sense. Generally, I think there should be a parallel negative. It's the weird ones like should_change(obj, :sym).by(1) that, in my view, make specs more confusing than explicit that make me think absolute parallelism is not a necessity. ---------------------------------------------------------------------- Comment By: steve ross (cwd) Date: 2007-01-21 12:29 Message: Let's talk about how something this obtuse comes about. Typically, I spec positive expectations first to make sure what I think will happen does indeed happen. Then I add negative expectations to weed out some corner cases. This may seem duplicative, but the specs might read: "should be able to add a valid record" and "should not be able to add an invalid record." Clearly copy/paste is a quick way to get this kind of template set up, but the change in sugar is why it doesn't work quite as simply as adding *not*. This is user error, but it might come up again. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-01-21 12:22 Message: I think it's OK to not be parallel. For example, these two mean the same thing: team.should_not have_at_least(4).players team.should have_at_most(3).players Would you EVER want to use the first? Talk about making specs unclear! Being able to say proc.should_not change(Model, :count).by(1) is like saying - it's OK for this to cause a change, but whatever you do, don't change it by 1. That's just a bit too non-deterministic for my stomach. ---------------------------------------------------------------------- Comment By: steve ross (cwd) Date: 2007-01-21 12:16 Message: It would seem that most expectations also have a negative expectation associated with them (i.e., should_nnn has a corresponding should_not_nnn). The expected behavior, then would be that if the object changed by any number other than the specified one, it would fail. Is there value to adding this? Am I right about the parallelism among expectations? ---------------------------------------------------------------------- Comment By: Wilson Bilkovich (wilson) Date: 2007-01-21 11:38 Message: I should have disallowed it originally, in my opinion, making this a real bug. However, if we assume for a moment that we wanted to support it, how would it work? given: lambda {}.should_not_change(Thing, :count) The current code 'knows' that that expectation should fail as soon as it can compare the before and after values. lambda {}.should_not_change(Thing, :count).by(2) would, I would expect, pass if the count changed by 1. This means that the bare version without 'by' would fail, but the 'by' version would pass. Given that the bare 'should_not_change' has no way of knowing whether it will have 'by' called on it, I don't see a way to implement that. Every other extension type makes the expectation MORE specific, not less. This would violate that guideline, and I'm not sure it is implementable. Any ideas? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-01-21 03:14 Message: should_not_change is only spec'd to work without any extensions. i.e. Bug.create(:description => 'a valid description') }.should_not_change(Bug, :count) (without to, from or by) We have two choices to deal w/ this: 1 - disallow use of to, from or by with should_not_change 2 - support it My feeling about this is that if you're using should_not_change you shouldn't be using the extensions, so I'd go for 1. Other opinions? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=8027&group_id=797 From noreply at rubyforge.org Sun Jan 21 16:51:46 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 21 Jan 2007 16:51:46 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-8027 ] should_change works but should_not_change appears not to. Message-ID: <20070121215146.A25BF5241354@rubyforge.org> Bugs item #8027, was opened at 2007-01-20 18:46 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=8027&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: steve ross (cwd) Assigned to: Nobody (None) Summary: should_change works but should_not_change appears not to. Initial Comment: Rspec v. 0.8.0 (trunk) Given the code: context "Given a Bug (in general)" do specify "Should be able to add a valid record" do lambda { Bug.create(:title => 'a valid bug', :description => 'a valid description') }.should_change(Bug, :count).by(1) end specify "Should not be able to add an invalid record" do lambda { Bug.create(:description => 'a valid description') }.should_not_change(Bug, :count).by(1) end end The result is: 1) 'Given a Bug (in general) Should not be able to add an invalid record' FAILED count should have been changed by 1, but was changed by 0 ./spec/models/bug_spec.rb:18: Model code, bug.rb, is: class Bug < ActiveRecord::Base validates_presence_of :title end ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-01-21 21:51 Message: You can add that to the Documentation tracker if you like, but be aware that this can become outdated when new expectations are added later. Also, there is a syntax change afoot (never fear, we'll be providing a translator) that you can read about here: http://blog.davidchelimsky.net/articles/2007/01/10/rspec-should-use_a_little_less_magic This will change things a bit and make it easy to ensure that expectations that don't support their negatives will tell you. ---------------------------------------------------------------------- Comment By: steve ross (cwd) Date: 2007-01-21 21:24 Message: Ok, how about we make this an RFE: Where a positive expectation exists without a corresponding negative one, a note in the docs should reflect that. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-01-21 21:21 Message: Sorry... that should have been "should_not_change(obj, :sym).by(1)" ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-01-21 21:20 Message: Steve, I agree that there are many cases where negative expectations make perfect sense. Generally, I think there should be a parallel negative. It's the weird ones like should_change(obj, :sym).by(1) that, in my view, make specs more confusing than explicit that make me think absolute parallelism is not a necessity. ---------------------------------------------------------------------- Comment By: steve ross (cwd) Date: 2007-01-21 20:29 Message: Let's talk about how something this obtuse comes about. Typically, I spec positive expectations first to make sure what I think will happen does indeed happen. Then I add negative expectations to weed out some corner cases. This may seem duplicative, but the specs might read: "should be able to add a valid record" and "should not be able to add an invalid record." Clearly copy/paste is a quick way to get this kind of template set up, but the change in sugar is why it doesn't work quite as simply as adding *not*. This is user error, but it might come up again. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-01-21 20:22 Message: I think it's OK to not be parallel. For example, these two mean the same thing: team.should_not have_at_least(4).players team.should have_at_most(3).players Would you EVER want to use the first? Talk about making specs unclear! Being able to say proc.should_not change(Model, :count).by(1) is like saying - it's OK for this to cause a change, but whatever you do, don't change it by 1. That's just a bit too non-deterministic for my stomach. ---------------------------------------------------------------------- Comment By: steve ross (cwd) Date: 2007-01-21 20:16 Message: It would seem that most expectations also have a negative expectation associated with them (i.e., should_nnn has a corresponding should_not_nnn). The expected behavior, then would be that if the object changed by any number other than the specified one, it would fail. Is there value to adding this? Am I right about the parallelism among expectations? ---------------------------------------------------------------------- Comment By: Wilson Bilkovich (wilson) Date: 2007-01-21 19:38 Message: I should have disallowed it originally, in my opinion, making this a real bug. However, if we assume for a moment that we wanted to support it, how would it work? given: lambda {}.should_not_change(Thing, :count) The current code 'knows' that that expectation should fail as soon as it can compare the before and after values. lambda {}.should_not_change(Thing, :count).by(2) would, I would expect, pass if the count changed by 1. This means that the bare version without 'by' would fail, but the 'by' version would pass. Given that the bare 'should_not_change' has no way of knowing whether it will have 'by' called on it, I don't see a way to implement that. Every other extension type makes the expectation MORE specific, not less. This would violate that guideline, and I'm not sure it is implementable. Any ideas? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-01-21 11:14 Message: should_not_change is only spec'd to work without any extensions. i.e. Bug.create(:description => 'a valid description') }.should_not_change(Bug, :count) (without to, from or by) We have two choices to deal w/ this: 1 - disallow use of to, from or by with should_not_change 2 - support it My feeling about this is that if you're using should_not_change you shouldn't be using the extensions, so I'd go for 1. Other opinions? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=8027&group_id=797 From noreply at rubyforge.org Sun Jan 21 18:32:48 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 21 Jan 2007 18:32:48 -0500 (EST) Subject: [rspec-devel] [ rspec-Feature Requests-8028 ] version mismatch checking too strict Message-ID: <20070121233248.BE8815241818@rubyforge.org> Feature Requests item #8028, was opened at 2007-01-20 18:50 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=8028&group_id=797 Category: rails plugin Group: None >Status: Closed Priority: 3 Submitted By: steve ross (cwd) >Assigned to: David Chelimsky (dchelimsky) Summary: version mismatch checking too strict Initial Comment: When building from trunk, sometimes the gem gets a version update before the rails plugin or vice-versa. Can version checking be expanded to a range check so that the plugin only rails the version check if versions of rspec that are clearly outside the acceptable range (i.e., versions that will break the rails plugin) are rejected? I'm building from trunk and trying to be a good citizen about testing the latest and greatest, but I have three active and two dormant projects using rspec. Relaxing the requirement would save a lot of time. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-01-21 23:32 Message: For the time being at least, we really need to keep this strict because rspec and rspec_on_rails development are so tightly bound. Anytime something under the hood changes, it might change in both places. Once we hit 1.0 this will be less of an issue and we can revisit this. In the mean time, what I do when developing against the trunk is to install rspec and rspec_as_rails as gems in the rails app. You can use the rake spec:* tasks or the vendor/plugins/rspec_on_rails/bin/spec command. Hope that's helpful. Cheers, David ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=8028&group_id=797 From noreply at rubyforge.org Tue Jan 23 02:14:17 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 23 Jan 2007 02:14:17 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-8077 ] Stubbing :new on Active base class causes sub class :new to return base type Message-ID: <20070123071417.61F415241A7E@rubyforge.org> Bugs item #8077, was opened at 2007-01-22 23:14 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=8077&group_id=797 Category: mock module Group: None Status: Open Resolution: None Priority: 3 Submitted By: Scott Fleckenstein (nullstyle) Assigned to: Nobody (None) Summary: Stubbing :new on Active base class causes sub class :new to return base type Initial Comment: Quite a subject sentence, huh? Before I get to my description, attached to this report is a stand-alone ruby file that will reproduce the bug I am seeing, given you have the sqlite3 gem installed. Also note that this is surfacing when using Rspec 0.7.5.1 along with the corresponding Rspec on Rails plugin; Ruby 1.8.5 on OS X 10.4.latest Basically, I have a situation where I am employing single-table-inheritance with my active record classes. I have a set of specs that stub! :new on the base class. After the stubbing specs are run, any calls to subclass.new return an instance of the base class. Example: Foo < ActiveRecord::Base ; end Bar < Foo ; end p Bar.new.class # => Bar Foo.stub!(:new) Foo.__reset_mock p Bar.new.class # => Foo I tried working up a patch, but I don't have enough skill with the rspec codebase to get it done. Thanks, Scott Fleckenstein ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=8077&group_id=797 From noreply at rubyforge.org Tue Jan 23 07:45:27 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 23 Jan 2007 07:45:27 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-8077 ] Stubbing :new on Active base class causes sub class :new to return base type Message-ID: <20070123124527.E43F15240B7A@rubyforge.org> Bugs item #8077, was opened at 2007-01-23 07:14 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=8077&group_id=797 Category: mock module Group: None >Status: Closed >Resolution: Rejected Priority: 3 Submitted By: Scott Fleckenstein (nullstyle) >Assigned to: David Chelimsky (dchelimsky) Summary: Stubbing :new on Active base class causes sub class :new to return base type Initial Comment: Quite a subject sentence, huh? Before I get to my description, attached to this report is a stand-alone ruby file that will reproduce the bug I am seeing, given you have the sqlite3 gem installed. Also note that this is surfacing when using Rspec 0.7.5.1 along with the corresponding Rspec on Rails plugin; Ruby 1.8.5 on OS X 10.4.latest Basically, I have a situation where I am employing single-table-inheritance with my active record classes. I have a set of specs that stub! :new on the base class. After the stubbing specs are run, any calls to subclass.new return an instance of the base class. Example: Foo < ActiveRecord::Base ; end Bar < Foo ; end p Bar.new.class # => Bar Foo.stub!(:new) Foo.__reset_mock p Bar.new.class # => Foo I tried working up a patch, but I don't have enough skill with the rspec codebase to get it done. Thanks, Scott Fleckenstein ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-01-23 12:45 Message: Very nice bug report. Thank you. However, it is a duplicate of [#7611] http://rubyforge.org/tracker/index.php?func=detail&aid=7611&group_id=797&atid=3149 Apologies for the "Rejected" resolution. We are not offered an "Is Duplication" option. Cheers, David ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=8077&group_id=797 From noreply at rubyforge.org Tue Jan 23 09:57:14 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 23 Jan 2007 09:57:14 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-8077 ] Stubbing :new on Active base class causes sub class :new to return base type Message-ID: <20070123145714.809755240DFF@rubyforge.org> Bugs item #8077, was opened at 2007-01-22 23:14 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=8077&group_id=797 Category: mock module Group: None Status: Closed Resolution: Rejected Priority: 3 Submitted By: Scott Fleckenstein (nullstyle) Assigned to: David Chelimsky (dchelimsky) Summary: Stubbing :new on Active base class causes sub class :new to return base type Initial Comment: Quite a subject sentence, huh? Before I get to my description, attached to this report is a stand-alone ruby file that will reproduce the bug I am seeing, given you have the sqlite3 gem installed. Also note that this is surfacing when using Rspec 0.7.5.1 along with the corresponding Rspec on Rails plugin; Ruby 1.8.5 on OS X 10.4.latest Basically, I have a situation where I am employing single-table-inheritance with my active record classes. I have a set of specs that stub! :new on the base class. After the stubbing specs are run, any calls to subclass.new return an instance of the base class. Example: Foo < ActiveRecord::Base ; end Bar < Foo ; end p Bar.new.class # => Bar Foo.stub!(:new) Foo.__reset_mock p Bar.new.class # => Foo I tried working up a patch, but I don't have enough skill with the rspec codebase to get it done. Thanks, Scott Fleckenstein ---------------------------------------------------------------------- >Comment By: Scott Fleckenstein (nullstyle) Date: 2007-01-23 06:57 Message: Oops, sorry about the duplicate. Didn't mean to clutter things up. I glanced at the bugs but obviously didn't look hard enough. -Scott ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-01-23 04:45 Message: Very nice bug report. Thank you. However, it is a duplicate of [#7611] http://rubyforge.org/tracker/index.php?func=detail&aid=7611&group_id=797&atid=3149 Apologies for the "Rejected" resolution. We are not offered an "Is Duplication" option. Cheers, David ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=8077&group_id=797 From noreply at rubyforge.org Tue Jan 23 10:22:53 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 23 Jan 2007 10:22:53 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-8077 ] Stubbing :new on Active base class causes sub class :new to return base type Message-ID: <20070123152253.EE70C5240D6C@rubyforge.org> Bugs item #8077, was opened at 2007-01-23 07:14 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=8077&group_id=797 Category: mock module Group: None Status: Closed Resolution: Rejected Priority: 3 Submitted By: Scott Fleckenstein (nullstyle) Assigned to: David Chelimsky (dchelimsky) Summary: Stubbing :new on Active base class causes sub class :new to return base type Initial Comment: Quite a subject sentence, huh? Before I get to my description, attached to this report is a stand-alone ruby file that will reproduce the bug I am seeing, given you have the sqlite3 gem installed. Also note that this is surfacing when using Rspec 0.7.5.1 along with the corresponding Rspec on Rails plugin; Ruby 1.8.5 on OS X 10.4.latest Basically, I have a situation where I am employing single-table-inheritance with my active record classes. I have a set of specs that stub! :new on the base class. After the stubbing specs are run, any calls to subclass.new return an instance of the base class. Example: Foo < ActiveRecord::Base ; end Bar < Foo ; end p Bar.new.class # => Bar Foo.stub!(:new) Foo.__reset_mock p Bar.new.class # => Foo I tried working up a patch, but I don't have enough skill with the rspec codebase to get it done. Thanks, Scott Fleckenstein ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-01-23 15:22 Message: No worries. While the advance search is appreciated, I'd rather see dups than not see bugs. Cheers, David ---------------------------------------------------------------------- Comment By: Scott Fleckenstein (nullstyle) Date: 2007-01-23 14:57 Message: Oops, sorry about the duplicate. Didn't mean to clutter things up. I glanced at the bugs but obviously didn't look hard enough. -Scott ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-01-23 12:45 Message: Very nice bug report. Thank you. However, it is a duplicate of [#7611] http://rubyforge.org/tracker/index.php?func=detail&aid=7611&group_id=797&atid=3149 Apologies for the "Rejected" resolution. We are not offered an "Is Duplication" option. Cheers, David ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=8077&group_id=797 From noreply at rubyforge.org Wed Jan 24 02:22:14 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 24 Jan 2007 02:22:14 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-8103 ] RSpec not installing spec script correctly Message-ID: <20070124072214.6F78E5241D59@rubyforge.org> Bugs item #8103, was opened at 2007-01-24 02:22 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=8103&group_id=797 Category: runner module Group: v1.0 (example) Status: Open Resolution: None Priority: 3 Submitted By: Aslak Helles?y (aslak_hellesoy) Assigned to: Aslak Helles?y (aslak_hellesoy) Summary: RSpec not installing spec script correctly Initial Comment: >From Charles Oliver Nutter: Hey, I just noticed this today...installed RSpec with JRuby, and at the top of the spec script: #!/usr/bin/env ruby That dog won't hunt, Monsignor. Rails and rake install scripts that correctly run with JRuby, so that's probably good examples to follow. Unfortunately I have no clue how they do it. - Charlie ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=8103&group_id=797 From noreply at rubyforge.org Wed Jan 24 09:29:03 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 24 Jan 2007 09:29:03 -0500 (EST) Subject: [rspec-devel] [ rspec-Patches-8113 ] Better Watir exception for bad URLs Message-ID: <20070124142903.6BED95240C11@rubyforge.org> Patches item #8113, was opened at 2007-01-24 09:29 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=8113&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Aslak Helles?y (aslak_hellesoy) Assigned to: Aslak Helles?y (aslak_hellesoy) Summary: Better Watir exception for bad URLs Initial Comment: class Watir::Browser def kill! close end alias contain_text? contains_text alias old_goto goto def goto(url) begin old_goto(url) rescue => e e.message << "\nURL: #{url}" raise e end end end ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=8113&group_id=797 From noreply at rubyforge.org Wed Jan 24 10:39:03 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 24 Jan 2007 10:39:03 -0500 (EST) Subject: [rspec-devel] [ rspec-Patches-8113 ] Better Watir exception for bad URLs Message-ID: <20070124153904.476645240CC0@rubyforge.org> Patches item #8113, was opened at 2007-01-24 09:29 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=8113&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Aslak Helles?y (aslak_hellesoy) Assigned to: Aslak Helles?y (aslak_hellesoy) Summary: Better Watir exception for bad URLs Initial Comment: class Watir::Browser def kill! close end alias contain_text? contains_text alias old_goto goto def goto(url) begin old_goto(url) rescue => e e.message << "\nURL: #{url}" raise e end end end ---------------------------------------------------------------------- >Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-01-24 10:39 Message: Add this too, to webapp_helper.rb (and remove it from the rake) raise "$RSPEC_IMG_DIR must be defined" if ENV['RSPEC_IMG_DIR'].nil? FileUtils.mkdir_p(ENV['RSPEC_IMG_DIR']) unless File.exist?(ENV['RSPEC_IMG_DIR']) ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=8113&group_id=797 From noreply at rubyforge.org Wed Jan 24 13:08:11 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 24 Jan 2007 13:08:11 -0500 (EST) Subject: [rspec-devel] [ rspec-Patches-8113 ] Better Watir exception for bad URLs Message-ID: <20070124180811.917C45240DFE@rubyforge.org> Patches item #8113, was opened at 2007-01-24 09:29 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=8113&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Aslak Helles?y (aslak_hellesoy) Assigned to: Aslak Helles?y (aslak_hellesoy) Summary: Better Watir exception for bad URLs Initial Comment: class Watir::Browser def kill! close end alias contain_text? contains_text alias old_goto goto def goto(url) begin old_goto(url) rescue => e e.message << "\nURL: #{url}" raise e end end end ---------------------------------------------------------------------- >Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-01-24 13:08 Message: A good tip - monkey patch the watir stuff in your spec_helper.rb module Spec module Ui class WebappHelper def context_setup quick_db_web @browser = Watir::Browser.new ::Win32::Screenshot.setForegroundWindow(ie.getIE.hwnd) end end end end require 'spec/ui/watir_helper' ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-01-24 10:39 Message: Add this too, to webapp_helper.rb (and remove it from the rake) raise "$RSPEC_IMG_DIR must be defined" if ENV['RSPEC_IMG_DIR'].nil? FileUtils.mkdir_p(ENV['RSPEC_IMG_DIR']) unless File.exist?(ENV['RSPEC_IMG_DIR']) ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=8113&group_id=797 From jcfischer.lists at gmail.com Wed Jan 24 14:52:41 2007 From: jcfischer.lists at gmail.com (Jens-Christian Fischer) Date: Wed, 24 Jan 2007 20:52:41 +0100 Subject: [rspec-devel] huge setup methods? I think I'm on the wrong path Message-ID: I'm relatively new to RSpec and am still struggling with some basics: Consider the following view spec: context "Given a request to render rooms/show" do setup do @room = mock("room") @room.stub!(:name).and_return("Liftchat") @message = mock("message") @messages = [@message] @u1 = mock("user1") @u2 = mock("user2") @u1.stub!(:nickname).and_return("jcfischer") @u2.stub!(:nickname).and_return("lau") @u1.stub!(:active?).and_return(true) @u2.stub!(:active?).and_return(false) @u1.stub!(:style).and_return("") @u2.stub!(:style).and_return("") @u1.stub!(:id).and_return(1) @u2.stub!(:id).and_return(2) users = [@u1, @u2] @room.stub!(:users).and_return(users) admins = [@u1] @room.stub!(:admins).and_return(admins) @room.stub!(:is_admin?).and_return(true) @message.stub!(:user).and_return(@u1) @message.stub!(:msg).and_return("bla") @message.stub!(:id).and_return(1) @room.stub!(:messages).and_return(@messages) assigns[:room] = @room assigns[:messages] = @messages end specify "should dispaly the userlist" do render 'rooms/show' #response.should_have "h1", :text => "Liftchat" #response.should_have "ul[id=users]" response.should_have "li>a", :text => "jcfischer" response.should_have "li>a", :text => "lau" end end It seems to me, that I'm doing something completely stupid, because my setup method is growing and growing, stubbing every method call that my views are making. Is this supposed to look like this or am I missing something completely obvious? thanks jc From dchelimsky at gmail.com Wed Jan 24 15:40:36 2007 From: dchelimsky at gmail.com (David Chelimsky) Date: Wed, 24 Jan 2007 14:40:36 -0600 Subject: [rspec-devel] huge setup methods? I think I'm on the wrong path In-Reply-To: References: Message-ID: <57c63afe0701241240g58f81e2ek3218a1800f43c2e5@mail.gmail.com> On 1/24/07, Jens-Christian Fischer wrote: > I'm relatively new to RSpec and am still struggling with some basics: > > Consider the following view spec: > > context "Given a request to render rooms/show" do > setup do > @room = mock("room") > @room.stub!(:name).and_return("Liftchat") > @message = mock("message") > @messages = [@message] > @u1 = mock("user1") > @u2 = mock("user2") > @u1.stub!(:nickname).and_return("jcfischer") > @u2.stub!(:nickname).and_return("lau") > @u1.stub!(:active?).and_return(true) > @u2.stub!(:active?).and_return(false) > @u1.stub!(:style).and_return("") > @u2.stub!(:style).and_return("") > @u1.stub!(:id).and_return(1) > @u2.stub!(:id).and_return(2) > > users = [@u1, @u2] > @room.stub!(:users).and_return(users) > admins = [@u1] > @room.stub!(:admins).and_return(admins) > @room.stub!(:is_admin?).and_return(true) > @message.stub!(:user).and_return(@u1) > @message.stub!(:msg).and_return("bla") > @message.stub!(:id).and_return(1) > @room.stub!(:messages).and_return(@messages) > assigns[:room] = @room > assigns[:messages] = @messages > end > > specify "should dispaly the userlist" do > > render 'rooms/show' > #response.should_have "h1", :text => "Liftchat" > #response.should_have "ul[id=users]" > response.should_have "li>a", :text => "jcfischer" > response.should_have "li>a", :text => "lau" > end > > end > > It seems to me, that I'm doing something completely stupid, because > my setup method is growing and growing, stubbing every method call > that my views are making. Is this supposed to look like this or am I > missing something completely obvious? If the view needs to ask a lot of questions, then your setup is going to look something like that. You can, though, clean things up a little bit: context "Given a request to render rooms/show" do def create_user(name, active, style, id) user = mock(name) user.stub!(:nickname).and_return(name) user.stub!(:active?).and_return(active) user.stub!(:style).and_return(style) user.stub!(:id).and_return(id) end setup do @u1 = create_user("jcfischer", true, "", 1) @u2 = create_user("lau", false, "", 2) ... Another thing you can do is to tell the mock to act like a Null Object [GOF], like so: user = mock("user", :null_object => true) This will cause the mock to ignore calls that it isn't interested in, so you won't get failures by sending messages. If, however, your view has any trainwrecks in it (user.address.zipcode), then you'd have to supply something specific to return for address. The other thing is that, since you're really using a stub (i.e. the verification is that the right stuff shows up in the tags), you could use OpenStruct: require 'ostruct' context "...." do specify "..." do @u1 = OpenStruct.new(:name => "jcfischer", :etc => "otherstuff") end ... Hope that helps. David > > thanks > jc > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From jcfischer.lists at gmail.com Wed Jan 24 16:26:29 2007 From: jcfischer.lists at gmail.com (Jens-Christian Fischer) Date: Wed, 24 Jan 2007 22:26:29 +0100 Subject: [rspec-devel] huge setup methods? I think I'm on the wrong path In-Reply-To: <57c63afe0701241240g58f81e2ek3218a1800f43c2e5@mail.gmail.com> References: <57c63afe0701241240g58f81e2ek3218a1800f43c2e5@mail.gmail.com> Message-ID: <9271F7BB-B4D7-4DF7-9835-BE2A1D825538@gmail.com> > > If the view needs to ask a lot of questions, then your setup is going > to look something like that. You can, though, clean things up a little > bit: > [... snip ...] > This will cause the mock to ignore calls that it isn't interested in, > so you won't get failures by sending messages. If, however, your view > has any trainwrecks in it (user.address.zipcode), then you'd have to > supply something specific to return for address. > Yes - there are quite a few trainwrecks :-) That's the first time I heard that - it sounds like there are some negative cononations with that - true? > The other thing is that, since you're really using a stub (i.e. the > verification is that the right stuff shows up in the tags), you could > use OpenStruct: > > require 'ostruct' > > context "...." do > specify "..." do > @u1 = OpenStruct.new(:name => "jcfischer", :etc => "otherstuff") > end > ... > > Hope that helps. that helps a lot - thanks! jc From dchelimsky at gmail.com Wed Jan 24 16:36:19 2007 From: dchelimsky at gmail.com (David Chelimsky) Date: Wed, 24 Jan 2007 15:36:19 -0600 Subject: [rspec-devel] huge setup methods? I think I'm on the wrong path In-Reply-To: <9271F7BB-B4D7-4DF7-9835-BE2A1D825538@gmail.com> References: <57c63afe0701241240g58f81e2ek3218a1800f43c2e5@mail.gmail.com> <9271F7BB-B4D7-4DF7-9835-BE2A1D825538@gmail.com> Message-ID: <57c63afe0701241336i7357e767w4898cd0309d96a5e@mail.gmail.com> On 1/24/07, Jens-Christian Fischer wrote: > > > > If the view needs to ask a lot of questions, then your setup is going > > to look something like that. You can, though, clean things up a little > > bit: > > > [... snip ...] > > This will cause the mock to ignore calls that it isn't interested in, > > so you won't get failures by sending messages. If, however, your view > > has any trainwrecks in it (user.address.zipcode), then you'd have to > > supply something specific to return for address. > > > > Yes - there are quite a few trainwrecks :-) That's the first time I > heard that - it sounds like there are some negative cononations with > that - true? Google "Law of Demeter". Note that it is called a Law, which makes it sound absolute. Some refer to it lovingly as the "Suggestion of Demeter" (I believe Fowler first wrote that). It is a useful guideline that should be applied when you're feeling pain (which it seems that you are in this case). Cheers, David From matt at eastmedia.com Wed Jan 24 17:40:16 2007 From: matt at eastmedia.com (Matt Pelletier) Date: Wed, 24 Jan 2007 17:40:16 -0500 Subject: [rspec-devel] huge setup methods? I think I'm on the wrong path In-Reply-To: <57c63afe0701241336i7357e767w4898cd0309d96a5e@mail.gmail.com> References: <57c63afe0701241240g58f81e2ek3218a1800f43c2e5@mail.gmail.com> <9271F7BB-B4D7-4DF7-9835-BE2A1D825538@gmail.com> <57c63afe0701241336i7357e767w4898cd0309d96a5e@mail.gmail.com> Message-ID: On Jan 24, 2007, at 4:36 PM, David Chelimsky wrote: > On 1/24/07, Jens-Christian Fischer wrote: >>> >>> If the view needs to ask a lot of questions, then your setup is >>> going >>> to look something like that. You can, though, clean things up a >>> little >>> bit: >> >>> [... snip ...] >>> This will cause the mock to ignore calls that it isn't interested >>> in, >>> so you won't get failures by sending messages. If, however, your >>> view >>> has any trainwrecks in it (user.address.zipcode), then you'd have to >>> supply something specific to return for address. >>> >> >> Yes - there are quite a few trainwrecks :-) That's the first time I >> heard that - it sounds like there are some negative cononations with >> that - true? A few comments on the above. These topics have led to long discussions here and we've come up with a few idioms to handle the various less-than-conveniences. Big thanks to Wilson Bilkovich and Bryan Helmkamp for crafting this together. We have gotten into the practice of writing predicate methods on models (in Rails). These accomplish a few things: 1. Keep the Demeterites happy 2. Make code easier to read 3. Make code easier to spec A simple example: class Client < ActiveRecord::Base has_many :people end class Person < ActiveRecord::Base belongs_to :person def client_name client.name end end Now instead of: client = mock('client') client.stub!(:name).and_return('fred') person = mock('person') person.stub!(:client).and_return(client) You can just do: person = mock('person') person.stub!(:client_name).and_return('fred') The level of convenience increases proportionally to the number of association proxy calls (aka the Pit of Despair) you would normally be required to make. This does mean a small amount of extra code in your app, but really not too much, and probably less than you'd be adding to your specs to stub around it. We wrote a plugin that will create some of these for you automatically that wrap Rails' association proxies. It's part of a set of other convenient tools and Rails 'hacks' (hello Pot, this is Kettle). http://svn.eastmedia.com/svn/code/plugins/model_extensions/lib/ associations.rb If you want to install the plugin directly, use: $ ./script/plugin install http://svn.eastmedia.com/svn/code/plugins/ model_extensions We also use some of the delegator methods built into Ruby for cases where we want to directly reference an object's method. These are roughly the same as Rails' 'delegate' method, which is basically a re- implementation of this existing functionality, they're just not as easy to understand at first glance. The above model code could be written as: class Client < ActiveRecord::Base has_many :people end class Person < ActiveRecord::Base belongs_to :person # The following gives you @person.client_name. # You can omit the last param if you want to use @person.name, assuming it won't conflict def_delegator :client, :name, :client_name end As for long-winding-road setups, even with this convenience you are still going to run into them. What we've done is define a module that has a method with the innards of #setup, and you just include the module in your context, and call the method name from inside setup. This is especially useful if you need similar setups from multiple contexts. You can either define the module at the top of your _spec.rb or put it in fixtures/ somewhere. module PersonSetup def setup_person @client = Client.create! :name => "Fredder" @person = @client.build_person :first_name => "Chuck" end end context "A person being assigned a task" do include PersonSetup setup do setup_person end end If the method you need is simple and you're ok with just throwing the def X at the top of the _spec.rb, we've done that too. Finally... there are some mocking / stubbing convenience tricks you can do. We have added the following to our spec_helper.rb class. Thanks to Wilson for his work on this. I modified it to allow for additional stubs to be defined in the method call using a simple stubbing method. I don't think it's 'juuuust' right yet in the Goldilocks sense of the word, but it works for now and saves lots o' lines. context "A person completing a task" setup do mock_model(:client, :name => 'Heys') mock_model(:person, :client => @campaign, :first_name => "Joe", :tasks => []) end # ... end The following code can be crammed into spec_helper.rb inside EvalContext. I wrote it here just wrapped in a class_eval. Wilson originally posted mock_model on his blog (http://metaclass.org/ 2006/12/22/making-a-mockery-of-activerecord). This is a slightly modified version. Spec::Rails::class EvalContext.class_eval do def mock_model(name, stubs = {}) name = name.to_s m = mock(name) instance_variable_set("@#{name}", m) id = rand(10_000) m.stub!(:id).and_return(id) m.stub!(:to_param).and_return(id) m.stub!(:new_record?).and_return(false) klass = name.singularize.camelize m.send(:__mock_handler).instance_eval <<-CODE def @target.is_a?(other) other == #{klass} end def @target.class #{klass} end CODE add_stubs(m,stubs) yield m if block_given? m end # Will add stubs to a new or existing object. # Passing a symbol or string will create a new mock, passing anything else # will create a new mock and add stubs to that def add_stubs(object, stubs = {}) m = object.class.in?([String, Symbol]) ? mock(object.to_s) : object stubs.each {|k,v| m.stub!(k).and_return(v)} m end end Hope that helps. Matt > > Google "Law of Demeter". Note that it is called a Law, which makes it > sound absolute. Some refer to it lovingly as the "Suggestion of > Demeter" (I believe Fowler first wrote that). It is a useful guideline > that should be applied when you're feeling pain (which it seems that > you are in this case). > > Cheers, > David > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel ------------------ Matt Pelletier http://www.eastmedia.com -- EastMedia http://www.informit.com/title/0321483502 -- The Mongrel Book http://identity.eastmedia.com -- OpenID, Identity 2.0 From noreply at rubyforge.org Wed Jan 24 20:25:12 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 24 Jan 2007 20:25:12 -0500 (EST) Subject: [rspec-devel] [ rspec-Feature Requests-8126 ] Nested specify blocks Message-ID: <20070125012513.04569524141C@rubyforge.org> Feature Requests item #8126, was opened at 2007-01-25 01:25 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=8126&group_id=797 Category: expectation module Group: None Status: Open Priority: 3 Submitted By: Wincent Colaiuta (wincent) Assigned to: Nobody (None) Summary: Nested specify blocks Initial Comment: I know that the idea of nested contexts has come up on the devel list before (Google for "pipermail rspec nested contexts") and most were not in favor of the idea. For me, more useful than nested contexts would be nested specifications ("specify" blocks). Currently I have specs which look like this: context 'outer' do specify 'inner' do this.should == that end end If a spec is not satisfied then rspec prints a message of the form "outer inner". I sometimes find myself wishing that I could nest the specify blocks to fine tune the failure message: context 'outer' do specify 'inner' do specify 'innermost' do this.should == that end end end In this case rspec would print "outer inner innermost" on failure. Let me flesh it out a bit with more of a concrete example; basically I often find myself wanting to write this: context 'applying a regexp to a string' do specify 'should be able to match "zero or more" times' do specify 'with input that matches zero times' do # test zero-match case end specify 'with input that matches one time' do # test one-match case end specify 'with input that matches two times' do # test two-match case end end end Because I can't be bothered writing this: context 'applying a regexp to a string' do specify 'should be able to match "zero or more" times (with input that matches zero times)' do # test zero-match case end specify 'should be able to match "zero or more" times (with input that matches one time)' do # test one-match case end specify 'should be able to match "zero or more" times (with input that matches two times)' do # test two-match case end end But I end up writing this: context 'applying a regexp to a string' do specify 'should be able to match "zero or more" times' do # test zero-match case # test one-match case # test two-match case end end This isn't ideal because if the first assertion fails then the others aren't even tested. I'd rather keep the number of assertions in each specify block a bit lower, and the ability to nest specify blocks would help me to do that. What do people think? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=8126&group_id=797 From jcfischer.lists at gmail.com Thu Jan 25 01:05:23 2007 From: jcfischer.lists at gmail.com (Jens-Christian Fischer) Date: Thu, 25 Jan 2007 07:05:23 +0100 Subject: [rspec-devel] huge setup methods? I think I'm on the wrong path In-Reply-To: References: <57c63afe0701241240g58f81e2ek3218a1800f43c2e5@mail.gmail.com> <9271F7BB-B4D7-4DF7-9835-BE2A1D825538@gmail.com> <57c63afe0701241336i7357e767w4898cd0309d96a5e@mail.gmail.com> Message-ID: <25615A08-1040-493C-B9C3-6CEA3464A634@gmail.com> > 1. Keep the Demeterites happy > 2. Make code easier to read > 3. Make code easier to spec > > A simple example: > > class Client < ActiveRecord::Base > has_many :people > end > > class Person < ActiveRecord::Base > belongs_to :person > > def client_name > client.name > end > end > [...} > You can just do: > > person = mock('person') > person.stub!(:client_name).and_return('fred') Ahh - I have been using this a lot in an other application. Thanks for providing some background information on *why* I have been doing this! > This does mean a small amount of extra code in your app, but really > not too much, and probably less than you'd be adding to your specs to > stub around it. True. Compared to the stubbing, it's nothing! > > We wrote a plugin that will create some of these for you > automatically that wrap Rails' association proxies. It's part of a > set of other convenient tools and Rails 'hacks' (hello Pot, this is > Kettle). I will check that out - sounds useful! > Goldilocks sense of the word, but it works for now and saves lots o' > lines. > > context "A person completing a task" > setup do > mock_model(:client, :name => 'Heys') > mock_model(:person, :client => @campaign, :first_name => > "Joe", :tasks => []) > end > # ... > end That looks extremely helpful as well. Thanks for pointing these things out. While BDD seems so simple in the beginning, it's the nitty gritty that makes for some headscratching. thanks jc From noreply at rubyforge.org Thu Jan 25 01:26:04 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 25 Jan 2007 01:26:04 -0500 (EST) Subject: [rspec-devel] [ rspec-Patches-8132 ] [PATCH] RSpec breaks "rake db:sessions:create" in a rails project that has the rspec_on_rails plugin Message-ID: <20070125062604.5CC8252414B3@rubyforge.org> Patches item #8132, was opened at 2007-01-25 01:26 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=8132&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Erik Kastner (kastner) Assigned to: Nobody (None) Summary: [PATCH] RSpec breaks "rake db:sessions:create" in a rails project that has the rspec_on_rails plugin Initial Comment: running rake db:sessions:create (to create the migration for ActiveRecord based sessions) in a project that has the rspec_on_rails plugin causes this error: undefined local variable or method `file_name' for # The problem is that spectask.rb (in lib/spec/rake) has a method "file_list". Changing that method name (and all calls to it) seems to fix the problem. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=8132&group_id=797 From jcfischer.lists at gmail.com Thu Jan 25 01:57:26 2007 From: jcfischer.lists at gmail.com (Jens-Christian Fischer) Date: Thu, 25 Jan 2007 07:57:26 +0100 Subject: [rspec-devel] huge setup methods? I think I'm on the wrong path In-Reply-To: References: <57c63afe0701241240g58f81e2ek3218a1800f43c2e5@mail.gmail.com> <9271F7BB-B4D7-4DF7-9835-BE2A1D825538@gmail.com> <57c63afe0701241336i7357e767w4898cd0309d96a5e@mail.gmail.com> Message-ID: <73820125-3D15-428C-BF1D-8731484A37C3@gmail.com> > > The following code can be crammed into spec_helper.rb inside > EvalContext. I wrote it here just wrapped in a class_eval. Wilson > originally posted mock_model on his blog (http://metaclass.org/ > 2006/12/22/making-a-mockery-of-activerecord). This is a slightly > modified version. > > Spec::Rails::class EvalContext.class_eval do > > def mock_model(name, stubs = {}) > name = name.to_s > m = mock(name) > instance_variable_set("@#{name}", m) > id = rand(10_000) > m.stub!(:id).and_return(id) > m.stub!(:to_param).and_return(id) > m.stub!(:new_record?).and_return(false) > klass = name.singularize.camelize > m.send(:__mock_handler).instance_eval <<-CODE > def @target.is_a?(other) > other == #{klass} > end > def @target.class > #{klass} > end > CODE > add_stubs(m,stubs) > yield m if block_given? > m > end > > # Will add stubs to a new or existing object. > # Passing a symbol or string will create a new mock, passing > anything else > # will create a new mock and add stubs to that > def add_stubs(object, stubs = {}) > m = object.class.in?([String, Symbol]) ? mock(object.to_s) : > object > stubs.each {|k,v| m.stub!(k).and_return(v)} > m > end > end Was playing around with this... It breaks on Rails 1.2.1 with a Anonymous modules have no name to be referenced by (eval):5:in `class' ./spec/views/users/../../spec_helper.rb:68:in `add_stubs' ./spec/views/users/../../spec_helper.rb:40:in `mock_model' ./spec/views/users/show_view_spec.rb:12: error. I have traced that to /usr/local/lib/ruby/gems/1.8/gems/activesupport-1.4.0/lib/ active_support/dependencies.rb in the to_contant_name method. My Ruby- Fu sadly lacks, so I haven't been able to figure out a cure to this problem. Using the block form: mock_model :u1 do |m| m.stub!(:nickname).and_return("jcfischer") m.stub!(:rooms).and_return(rooms) end works fine Any ideas? jc From aslak.hellesoy at gmail.com Thu Jan 25 06:17:00 2007 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Thu, 25 Jan 2007 12:17:00 +0100 Subject: [rspec-devel] huge setup methods? I think I'm on the wrong path In-Reply-To: References: <57c63afe0701241240g58f81e2ek3218a1800f43c2e5@mail.gmail.com> <9271F7BB-B4D7-4DF7-9835-BE2A1D825538@gmail.com> <57c63afe0701241336i7357e767w4898cd0309d96a5e@mail.gmail.com> Message-ID: <8d961d900701250317j50336770sa5baef72e0a4970a@mail.gmail.com> This is good stuff. I'll add it to spec/rails and the rspec_resource generator! Aslak On 1/24/07, Matt Pelletier wrote: > > On Jan 24, 2007, at 4:36 PM, David Chelimsky wrote: > > > On 1/24/07, Jens-Christian Fischer wrote: > >>> > >>> If the view needs to ask a lot of questions, then your setup is > >>> going > >>> to look something like that. You can, though, clean things up a > >>> little > >>> bit: > >> > >>> [... snip ...] > >>> This will cause the mock to ignore calls that it isn't interested > >>> in, > >>> so you won't get failures by sending messages. If, however, your > >>> view > >>> has any trainwrecks in it (user.address.zipcode), then you'd have to > >>> supply something specific to return for address. > >>> > >> > >> Yes - there are quite a few trainwrecks :-) That's the first time I > >> heard that - it sounds like there are some negative cononations with > >> that - true? > > A few comments on the above. These topics have led to long > discussions here and we've come up with a few idioms to handle the > various less-than-conveniences. Big thanks to Wilson Bilkovich and > Bryan Helmkamp for crafting this together. > > We have gotten into the practice of writing predicate methods on > models (in Rails). These accomplish a few things: > > 1. Keep the Demeterites happy > 2. Make code easier to read > 3. Make code easier to spec > > A simple example: > > class Client < ActiveRecord::Base > has_many :people > end > > class Person < ActiveRecord::Base > belongs_to :person > > def client_name > client.name > end > end > > Now instead of: > > client = mock('client') > client.stub!(:name).and_return('fred') > > person = mock('person') > person.stub!(:client).and_return(client) > > You can just do: > > person = mock('person') > person.stub!(:client_name).and_return('fred') > > The level of convenience increases proportionally to the number of > association proxy calls (aka the Pit of Despair) you would normally > be required to make. > > This does mean a small amount of extra code in your app, but really > not too much, and probably less than you'd be adding to your specs to > stub around it. > > We wrote a plugin that will create some of these for you > automatically that wrap Rails' association proxies. It's part of a > set of other convenient tools and Rails 'hacks' (hello Pot, this is > Kettle). > > http://svn.eastmedia.com/svn/code/plugins/model_extensions/lib/ > associations.rb > > If you want to install the plugin directly, use: > > $ ./script/plugin install http://svn.eastmedia.com/svn/code/plugins/ > model_extensions > > We also use some of the delegator methods built into Ruby for cases > where we want to directly reference an object's method. These are > roughly the same as Rails' 'delegate' method, which is basically a re- > implementation of this existing functionality, they're just not as > easy to understand at first glance. > > The above model code could be written as: > > class Client < ActiveRecord::Base > has_many :people > end > > class Person < ActiveRecord::Base > belongs_to :person > # The following gives you @person.client_name. > # You can omit the last param if you want to use @person.name, > assuming it won't conflict > def_delegator :client, :name, :client_name > end > > As for long-winding-road setups, even with this convenience you are > still going to run into them. What we've done is define a module that > has a method with the innards of #setup, and you just include the > module in your context, and call the method name from inside setup. > This is especially useful if you need similar setups from multiple > contexts. You can either define the module at the top of your > _spec.rb or put it in fixtures/ somewhere. > > module PersonSetup > def setup_person > @client = Client.create! :name => "Fredder" > @person = @client.build_person :first_name => "Chuck" > end > end > > context "A person being assigned a task" do > include PersonSetup > setup do > setup_person > end > end > > If the method you need is simple and you're ok with just throwing the > def X at the top of the _spec.rb, we've done that too. > > Finally... there are some mocking / stubbing convenience tricks you > can do. We have added the following to our spec_helper.rb class. > Thanks to Wilson for his work on this. I modified it to allow for > additional stubs to be defined in the method call using a simple > stubbing method. I don't think it's 'juuuust' right yet in the > Goldilocks sense of the word, but it works for now and saves lots o' > lines. > > context "A person completing a task" > setup do > mock_model(:client, :name => 'Heys') > mock_model(:person, :client => @campaign, :first_name => > "Joe", :tasks => []) > end > # ... > end > > The following code can be crammed into spec_helper.rb inside > EvalContext. I wrote it here just wrapped in a class_eval. Wilson > originally posted mock_model on his blog (http://metaclass.org/ > 2006/12/22/making-a-mockery-of-activerecord). This is a slightly > modified version. > > Spec::Rails::class EvalContext.class_eval do > > def mock_model(name, stubs = {}) > name = name.to_s > m = mock(name) > instance_variable_set("@#{name}", m) > id = rand(10_000) > m.stub!(:id).and_return(id) > m.stub!(:to_param).and_return(id) > m.stub!(:new_record?).and_return(false) > klass = name.singularize.camelize > m.send(:__mock_handler).instance_eval <<-CODE > def @target.is_a?(other) > other == #{klass} > end > def @target.class > #{klass} > end > CODE > add_stubs(m,stubs) > yield m if block_given? > m > end > > # Will add stubs to a new or existing object. > # Passing a symbol or string will create a new mock, passing > anything else > # will create a new mock and add stubs to that > def add_stubs(object, stubs = {}) > m = object.class.in?([String, Symbol]) ? mock(object.to_s) : > object > stubs.each {|k,v| m.stub!(k).and_return(v)} > m > end > end > > Hope that helps. > > Matt > > > > > > Google "Law of Demeter". Note that it is called a Law, which makes it > > sound absolute. Some refer to it lovingly as the "Suggestion of > > Demeter" (I believe Fowler first wrote that). It is a useful guideline > > that should be applied when you're feeling pain (which it seems that > > you are in this case). > > > > Cheers, > > David > > _______________________________________________ > > rspec-devel mailing list > > rspec-devel at rubyforge.org > > http://rubyforge.org/mailman/listinfo/rspec-devel > > ------------------ > Matt Pelletier > http://www.eastmedia.com -- EastMedia > http://www.informit.com/title/0321483502 -- The Mongrel Book > http://identity.eastmedia.com -- OpenID, Identity 2.0 > > > > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From noreply at rubyforge.org Thu Jan 25 06:28:16 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 25 Jan 2007 06:28:16 -0500 (EST) Subject: [rspec-devel] [ rspec-Feature Requests-8139 ] "not implemented" message for specs yet to be implemented Message-ID: <20070125112816.902D85240D93@rubyforge.org> Feature Requests item #8139, was opened at 2007-01-25 11:28 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=8139&group_id=797 Category: runner module Group: None Status: Open Priority: 3 Submitted By: David Chelimsky (dchelimsky) Assigned to: Nobody (None) Summary: "not implemented" message for specs yet to be implemented Initial Comment: If I am defining the behaviour of a class, I might make a list like this: Money behaviour: - should parse - should add - should subtract - should multiply - should handle division by 0 - should handle conversion I may not know what all of those mean yet, but that is a starting point. I'd like to be able to put that right into specs and have RSpec tell me that I have yet to implement them: context "Money behaviour" do specify "should parse" specify "should add" specify "should subtract" specify "should multiply" specify "should handle division by 0" specify "should handle conversion" end Note that each specify message has no block. Given some command line option, RSpec would collect these during a spec run and add the count to the summary: ===== Finished in 3.212354 seconds 647 specifications, 0 failures, 25 not yet implemented ===== Combined with the --format specdoc (or -fs) option, the report would look like this: ===== Money behaviour: - should parse - should add - should subtract - should multiply - should handle division by 0 (NOT IMPLEMENTED - should handle conversion (NOT IMPLEMENTED) Finished in 0.212354 seconds 6 specifications, 0 failures, 2 not yet implemented ===== This would a great aid in monitoring progress during an iteration. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=8139&group_id=797 From noreply at rubyforge.org Thu Jan 25 10:35:35 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 25 Jan 2007 10:35:35 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-8145 ] fixture use in context_setup bails Message-ID: <20070125153535.C98865240FA5@rubyforge.org> Bugs item #8145, was opened at 2007-01-25 10:35 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=8145&group_id=797 Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: Jodi Showers (jodishowers) Assigned to: Nobody (None) Summary: fixture use in context_setup bails Initial Comment: It appears that fixtures are not permissible within a context_setup. context "Given a Project fixture, " do fixtures :projects context_setup do @project = projects(:project_one) end .... end Results: 1) NoMethodError in 'Given a Project fixture, context_setup' You have a nil object when you didn't expect it! You might have expected an instance of Array. The error occurred while evaluating nil.[] ./spec/models/project_spec.rb:56: ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=8145&group_id=797 From yrashk at gmail.com Thu Jan 25 12:52:34 2007 From: yrashk at gmail.com (Yurii Rashkovskii) Date: Thu, 25 Jan 2007 19:52:34 +0200 Subject: [rspec-devel] specify_negatively Message-ID: <6948E7C1-CAF6-40C7-8BF8-063256535BC5@gmail.com> Hello, I have played a bit on a negative specification idea: http://rashkovskii.com/articles/2007/1/25/rspec-specify_negatively What do you think about it? Yurii Rashkovskii Technology Director Railsware.com From noreply at rubyforge.org Thu Jan 25 13:55:31 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 25 Jan 2007 13:55:31 -0500 (EST) Subject: [rspec-devel] [ rspec-Feature Requests-8149 ] specify_negatively Message-ID: <20070125185531.D85745240FA4@rubyforge.org> Feature Requests item #8149, was opened at 2007-01-25 20:55 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=8149&group_id=797 Category: runner module Group: None Status: Open Priority: 3 Submitted By: Yurii Rashkovskii (yrashk) Assigned to: Nobody (None) Summary: specify_negatively Initial Comment: The idea is pretty simple: to let declare some specifications as those that _should_ fail: context "Math behaviour" do specify "addition should give you the right answer" do (2+2).should == 4 end specify_negatively "addition should not give you the wrong answer (should fail)" do (2+2).should == 5 end specify_negatively "addition should not give you the wrong answer (bad negative test)"" do (2+2).should == 4 end end Math behaviour - addition should give you the right answer - addition should not give you the wrong answer (should fail) - addition should not give you the wrong answer (bad negative test) (FAILED - 1) 1) 'addition should not give you the wrong answer (bad negative test)' FAILED This specification was expected to fail, but nothing failed Finished in 0.041288 seconds 3 specifications, 1 failure You can read discussion here: http://rashkovskii.com/articles/2007/1/25/rspec-specify_negatively ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=8149&group_id=797 From noreply at rubyforge.org Thu Jan 25 14:08:51 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 25 Jan 2007 14:08:51 -0500 (EST) Subject: [rspec-devel] [ rspec-Feature Requests-8149 ] specify_negatively Message-ID: <20070125190851.7E4DC52410A4@rubyforge.org> Feature Requests item #8149, was opened at 2007-01-25 13:55 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=8149&group_id=797 Category: runner module Group: None Status: Open Priority: 3 Submitted By: Yurii Rashkovskii (yrashk) Assigned to: Nobody (None) Summary: specify_negatively Initial Comment: The idea is pretty simple: to let declare some specifications as those that _should_ fail: context "Math behaviour" do specify "addition should give you the right answer" do (2+2).should == 4 end specify_negatively "addition should not give you the wrong answer (should fail)" do (2+2).should == 5 end specify_negatively "addition should not give you the wrong answer (bad negative test)"" do (2+2).should == 4 end end Math behaviour - addition should give you the right answer - addition should not give you the wrong answer (should fail) - addition should not give you the wrong answer (bad negative test) (FAILED - 1) 1) 'addition should not give you the wrong answer (bad negative test)' FAILED This specification was expected to fail, but nothing failed Finished in 0.041288 seconds 3 specifications, 1 failure You can read discussion here: http://rashkovskii.com/articles/2007/1/25/rspec-specify_negatively ---------------------------------------------------------------------- >Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-01-25 14:08 Message: Maybe I'm missing something here, but would this work for you? (already supported) lambda do (2+2).should == 5 end.should_raise ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=8149&group_id=797 From noreply at rubyforge.org Thu Jan 25 17:39:12 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 25 Jan 2007 17:39:12 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-8155 ] rspec clashing with rubyclr Message-ID: <20070125223912.DDC9D5241099@rubyforge.org> Bugs item #8155, was opened at 2007-01-25 15:39 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=8155&group_id=797 Category: expectation module Group: None Status: Open Resolution: None Priority: 3 Submitted By: Kevin Williams (kevwil) Assigned to: Nobody (None) Summary: rspec clashing with rubyclr Initial Comment: I'm running Ruby 1.8.5 on Windows XP SP2. I have RubyGems 0.9.1, rspec 0.7.5.1, and rubyclr 0.5.2. I have both .NET 1.1 and 2.0 installed on this box. I don't know if this is due to rspec behavior or rubyclr behavior, so this may not be an rspec issue. I'm trying to use rspec with .NET code. I've toyed with rubyclr before and it works. For example, the following prints out "count = 0": require 'rubyclr' include System::Collections list = ArrayList.new puts "count = #{list.Count}" Now, when I try to do something similar using rspec, I get errors. __Code__: require 'rubyclr' include System::Collections context "An array list" do setup do @list = ArrayList.new end specify "starts empty" do @list.Count.should == 0 end end __Error__: C:\>spec arraylist_spec.rb -f s An array list - starts empty (ERROR - 1) 1) NoMethodError in 'An array list starts empty' undefined method `ldc_i4' for # ./arraylist_spec.rb:5:in `new' ./arraylist_spec.rb:5: Finished in 0.141 seconds 1 specification, 1 failure It appears to by trying to call a method (an overloaded constructor, I think) on a Generator object. It shouldn't be a Generator object as far as I know, so I thought perhaps this comes from rspec. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=8155&group_id=797 From noreply at rubyforge.org Thu Jan 25 18:22:52 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 25 Jan 2007 18:22:52 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-8155 ] rspec clashing with rubyclr Message-ID: <20070125232252.AC2D25241504@rubyforge.org> Bugs item #8155, was opened at 2007-01-25 22:39 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=8155&group_id=797 Category: expectation module Group: None Status: Open Resolution: None Priority: 3 Submitted By: Kevin Williams (kevwil) Assigned to: Nobody (None) Summary: rspec clashing with rubyclr Initial Comment: I'm running Ruby 1.8.5 on Windows XP SP2. I have RubyGems 0.9.1, rspec 0.7.5.1, and rubyclr 0.5.2. I have both .NET 1.1 and 2.0 installed on this box. I don't know if this is due to rspec behavior or rubyclr behavior, so this may not be an rspec issue. I'm trying to use rspec with .NET code. I've toyed with rubyclr before and it works. For example, the following prints out "count = 0": require 'rubyclr' include System::Collections list = ArrayList.new puts "count = #{list.Count}" Now, when I try to do something similar using rspec, I get errors. __Code__: require 'rubyclr' include System::Collections context "An array list" do setup do @list = ArrayList.new end specify "starts empty" do @list.Count.should == 0 end end __Error__: C:\>spec arraylist_spec.rb -f s An array list - starts empty (ERROR - 1) 1) NoMethodError in 'An array list starts empty' undefined method `ldc_i4' for # ./arraylist_spec.rb:5:in `new' ./arraylist_spec.rb:5: Finished in 0.141 seconds 1 specification, 1 failure It appears to by trying to call a method (an overloaded constructor, I think) on a Generator object. It shouldn't be a Generator object as far as I know, so I thought perhaps this comes from rspec. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-01-25 23:22 Message: I'm pretty sure this is not RSpec. We don't have any class named Generator. The stack trace you are seeing is trimmed down by RSpec. You can see the full trace doing this: spec arraylist_spec.rb -fs -b Does that help you see better where the problem might be? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=8155&group_id=797 From noreply at rubyforge.org Thu Jan 25 21:59:43 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 25 Jan 2007 21:59:43 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-8165 ] Partial Mock Errors when respond_to? is true but the method is not in the object Message-ID: <20070126025943.144325241730@rubyforge.org> Bugs item #8165, was opened at 2007-01-25 18:59 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=8165&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Brian Takita (btakita) Assigned to: Nobody (None) Summary: Partial Mock Errors when respond_to? is true but the method is not in the object Initial Comment: Unfortunately, this happens with ActiveRecord until #define_read_methods is called. dir = File.dirname(__FILE__) require "#{dir}/spec_helper" context "An object where respond_to? is true and does not have method" do specify "should not raise an exception" do obj = Object.new obj.should_receive(:respond_to?).with(:foobar).and_return(true) obj.should_receive(:foobar).and_return(:baz) obj.foobar.should == :baz end end Here is an ActiveRecord case: context "An object where respond_to? is true and does not have method" do specify "should not raise an exception" do obj = Person.new obj.should_receive(:respond_to?).with(:foobar).and_return(true) obj.should_receive(:foobar).and_return(:baz) obj.foobar.should == :baz end end ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=8165&group_id=797 From matt at eastmedia.com Thu Jan 25 22:29:41 2007 From: matt at eastmedia.com (Matt Pelletier) Date: Thu, 25 Jan 2007 22:29:41 -0500 Subject: [rspec-devel] huge setup methods? I think I'm on the wrong path In-Reply-To: <73820125-3D15-428C-BF1D-8731484A37C3@gmail.com> References: <57c63afe0701241240g58f81e2ek3218a1800f43c2e5@mail.gmail.com> <9271F7BB-B4D7-4DF7-9835-BE2A1D825538@gmail.com> <57c63afe0701241336i7357e767w4898cd0309d96a5e@mail.gmail.com> <73820125-3D15-428C-BF1D-8731484A37C3@gmail.com> Message-ID: <0014E37F-FADD-4197-9213-F1EF1259F3EF@eastmedia.com> On Jan 25, 2007, at 1:57 AM, Jens-Christian Fischer wrote: >> >> The following code can be crammed into spec_helper.rb inside >> EvalContext. I wrote it here just wrapped in a class_eval. Wilson >> originally posted mock_model on his blog (http://metaclass.org/ >> 2006/12/22/making-a-mockery-of-activerecord). This is a slightly >> modified version. >> >> Spec::Rails::class EvalContext.class_eval do >> >> def mock_model(name, stubs = {}) >> name = name.to_s >> m = mock(name) >> instance_variable_set("@#{name}", m) >> id = rand(10_000) >> m.stub!(:id).and_return(id) >> m.stub!(:to_param).and_return(id) >> m.stub!(:new_record?).and_return(false) >> klass = name.singularize.camelize >> m.send(:__mock_handler).instance_eval <<-CODE >> def @target.is_a?(other) >> other == #{klass} >> end >> def @target.class >> #{klass} >> end >> CODE >> add_stubs(m,stubs) >> yield m if block_given? >> m >> end >> >> # Will add stubs to a new or existing object. >> # Passing a symbol or string will create a new mock, passing >> anything else >> # will create a new mock and add stubs to that >> def add_stubs(object, stubs = {}) >> m = object.class.in?([String, Symbol]) ? mock(object.to_s) : >> object >> stubs.each {|k,v| m.stub!(k).and_return(v)} >> m >> end >> end > > > Was playing around with this... It breaks on Rails 1.2.1 with a > > Anonymous modules have no name to be referenced by > (eval):5:in `class' > ./spec/views/users/../../spec_helper.rb:68:in `add_stubs' > ./spec/views/users/../../spec_helper.rb:40:in `mock_model' > ./spec/views/users/show_view_spec.rb:12: > > > error. I have traced that to > > /usr/local/lib/ruby/gems/1.8/gems/activesupport-1.4.0/lib/ > active_support/dependencies.rb in the to_contant_name method. My Ruby- > Fu sadly lacks, so I haven't been able to figure out a cure to this > problem. Using the block form: > > mock_model :u1 do |m| > m.stub!(:nickname).and_return("jcfischer") > m.stub!(:rooms).and_return(rooms) > end > > works fine Did you figure it out or is it still causing problems? I realized that in add_stubs I am calling a method that I always use in my projects (sugar for #include?): You can either add this to your project, like so: # from Technoblog # http://tech.rufy.com/entry/81 class Object def in?(collection) collection.respond_to?(:include?) ? collection.include?(self) : false end end or, if Aslak is adding this to the RSpec Rails plugin, just change add_stub to use #include?. Here is an updated version of both methods (I just cleaned up mock_model so it would allow you to override the default stubs): # Adds stubs on a new or existing object. A new mock will be created if the # first param is a Symbol or String. def add_stubs(object, stubs = {}) m = [String, Symbol].include?(object.class) ? mock (object.to_s) : object stubs.each {|k,v| m.stub!(k).and_return(v)} m end # Creates a mock for an ActiveRecord model and places it in an instance variable. # Automatically creates stubs for commonly called methods such as #id, #to_param, # and #new_record?. You can pass a hash of stubs you would like created (these # will override the defaults). It also accepts an optional block. def mock_model(name, stubs = {}) name = name.to_s m = mock(name) instance_variable_set("@#{name}", m) id = stubs[:id] || rand(10_000) stubs.reverse_merge! :id => id, :to_param => id, :new_record? => false klass = name.singularize.camelize m.send(:__mock_handler).instance_eval <<-CODE def @target.is_a?(other) other == #{klass} end def @target.class #{klass} end CODE add_stubs(m,stubs) yield m if block_given? m end Thanks, Matt > > Any ideas? > jc > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel ------------------ Matt Pelletier http://www.eastmedia.com -- EastMedia http://www.informit.com/title/0321483502 -- The Mongrel Book http://identity.eastmedia.com -- OpenID, Identity 2.0 From matt at eastmedia.com Thu Jan 25 22:30:57 2007 From: matt at eastmedia.com (Matt Pelletier) Date: Thu, 25 Jan 2007 22:30:57 -0500 Subject: [rspec-devel] huge setup methods? I think I'm on the wrong path In-Reply-To: <8d961d900701250317j50336770sa5baef72e0a4970a@mail.gmail.com> References: <57c63afe0701241240g58f81e2ek3218a1800f43c2e5@mail.gmail.com> <9271F7BB-B4D7-4DF7-9835-BE2A1D825538@gmail.com> <57c63afe0701241336i7357e767w4898cd0309d96a5e@mail.gmail.com> <8d961d900701250317j50336770sa5baef72e0a4970a@mail.gmail.com> Message-ID: <2E9C9A91-C63C-4533-8035-2E33F7B43B0C@eastmedia.com> On Jan 25, 2007, at 6:17 AM, aslak hellesoy wrote: > This is good stuff. I'll add it to spec/rails and the > rspec_resource generator! > Great! Thanks. I just sent an updated version to this thread. I'll include it here as well. # Adds stubs on a new or existing object. A new mock will be created if the # first param is a Symbol or String. def add_stubs(object, stubs = {}) m = [String, Symbol].include?(object.class) ? mock (object.to_s) : object stubs.each {|k,v| m.stub!(k).and_return(v)} m end # Creates a mock for an ActiveRecord model and places it in an instance variable. # Automatically creates stubs for commonly called methods such as #id, #to_param, # and #new_record?. You can pass a hash of stubs you would like created (these # will override the defaults). It also accepts an optional block. def mock_model(name, stubs = {}) name = name.to_s m = mock(name) instance_variable_set("@#{name}", m) id = stubs[:id] || rand(10_000) stubs.reverse_merge! :id => id, :to_param => id, :new_record? => false klass = name.singularize.camelize m.send(:__mock_handler).instance_eval <<-CODE def @target.is_a?(other) other == #{klass} end def @target.class #{klass} end CODE add_stubs(m,stubs) yield m if block_given? m end > Aslak > > On 1/24/07, Matt Pelletier wrote: >> >> On Jan 24, 2007, at 4:36 PM, David Chelimsky wrote: >> >>> On 1/24/07, Jens-Christian Fischer >>> wrote: >>>>> >>>>> If the view needs to ask a lot of questions, then your setup is >>>>> going >>>>> to look something like that. You can, though, clean things up a >>>>> little >>>>> bit: >>>> >>>>> [... snip ...] >>>>> This will cause the mock to ignore calls that it isn't interested >>>>> in, >>>>> so you won't get failures by sending messages. If, however, your >>>>> view >>>>> has any trainwrecks in it (user.address.zipcode), then you'd >>>>> have to >>>>> supply something specific to return for address. >>>>> >>>> >>>> Yes - there are quite a few trainwrecks :-) That's the first time I >>>> heard that - it sounds like there are some negative cononations >>>> with >>>> that - true? >> >> A few comments on the above. These topics have led to long >> discussions here and we've come up with a few idioms to handle the >> various less-than-conveniences. Big thanks to Wilson Bilkovich and >> Bryan Helmkamp for crafting this together. >> >> We have gotten into the practice of writing predicate methods on >> models (in Rails). These accomplish a few things: >> >> 1. Keep the Demeterites happy >> 2. Make code easier to read >> 3. Make code easier to spec >> >> A simple example: >> >> class Client < ActiveRecord::Base >> has_many :people >> end >> >> class Person < ActiveRecord::Base >> belongs_to :person >> >> def client_name >> client.name >> end >> end >> >> Now instead of: >> >> client = mock('client') >> client.stub!(:name).and_return('fred') >> >> person = mock('person') >> person.stub!(:client).and_return(client) >> >> You can just do: >> >> person = mock('person') >> person.stub!(:client_name).and_return('fred') >> >> The level of convenience increases proportionally to the number of >> association proxy calls (aka the Pit of Despair) you would normally >> be required to make. >> >> This does mean a small amount of extra code in your app, but really >> not too much, and probably less than you'd be adding to your specs to >> stub around it. >> >> We wrote a plugin that will create some of these for you >> automatically that wrap Rails' association proxies. It's part of a >> set of other convenient tools and Rails 'hacks' (hello Pot, this is >> Kettle). >> >> http://svn.eastmedia.com/svn/code/plugins/model_extensions/lib/ >> associations.rb >> >> If you want to install the plugin directly, use: >> >> $ ./script/plugin install http://svn.eastmedia.com/svn/code/plugins/ >> model_extensions >> >> We also use some of the delegator methods built into Ruby for cases >> where we want to directly reference an object's method. These are >> roughly the same as Rails' 'delegate' method, which is basically a >> re- >> implementation of this existing functionality, they're just not as >> easy to understand at first glance. >> >> The above model code could be written as: >> >> class Client < ActiveRecord::Base >> has_many :people >> end >> >> class Person < ActiveRecord::Base >> belongs_to :person >> # The following gives you @person.client_name. >> # You can omit the last param if you want to use @person.name, >> assuming it won't conflict >> def_delegator :client, :name, :client_name >> end >> >> As for long-winding-road setups, even with this convenience you are >> still going to run into them. What we've done is define a module that >> has a method with the innards of #setup, and you just include the >> module in your context, and call the method name from inside setup. >> This is especially useful if you need similar setups from multiple >> contexts. You can either define the module at the top of your >> _spec.rb or put it in fixtures/ somewhere. >> >> module PersonSetup >> def setup_person >> @client = Client.create! :name => "Fredder" >> @person = @client.build_person :first_name => "Chuck" >> end >> end >> >> context "A person being assigned a task" do >> include PersonSetup >> setup do >> setup_person >> end >> end >> >> If the method you need is simple and you're ok with just throwing the >> def X at the top of the _spec.rb, we've done that too. >> >> Finally... there are some mocking / stubbing convenience tricks you >> can do. We have added the following to our spec_helper.rb class. >> Thanks to Wilson for his work on this. I modified it to allow for >> additional stubs to be defined in the method call using a simple >> stubbing method. I don't think it's 'juuuust' right yet in the >> Goldilocks sense of the word, but it works for now and saves lots o' >> lines. >> >> context "A person completing a task" >> setup do >> mock_model(:client, :name => 'Heys') >> mock_model(:person, :client => @campaign, :first_name => >> "Joe", :tasks => []) >> end >> # ... >> end >> >> The following code can be crammed into spec_helper.rb inside >> EvalContext. I wrote it here just wrapped in a class_eval. Wilson >> originally posted mock_model on his blog (http://metaclass.org/ >> 2006/12/22/making-a-mockery-of-activerecord). This is a slightly >> modified version. >> >> Spec::Rails::class EvalContext.class_eval do >> >> def mock_model(name, stubs = {}) >> name = name.to_s >> m = mock(name) >> instance_variable_set("@#{name}", m) >> id = rand(10_000) >> m.stub!(:id).and_return(id) >> m.stub!(:to_param).and_return(id) >> m.stub!(:new_record?).and_return(false) >> klass = name.singularize.camelize >> m.send(:__mock_handler).instance_eval <<-CODE >> def @target.is_a?(other) >> other == #{klass} >> end >> def @target.class >> #{klass} >> end >> CODE >> add_stubs(m,stubs) >> yield m if block_given? >> m >> end >> >> # Will add stubs to a new or existing object. >> # Passing a symbol or string will create a new mock, passing >> anything else >> # will create a new mock and add stubs to that >> def add_stubs(object, stubs = {}) >> m = object.class.in?([String, Symbol]) ? mock(object.to_s) : >> object >> stubs.each {|k,v| m.stub!(k).and_return(v)} >> m >> end >> end >> >> Hope that helps. >> >> Matt >> >> >>> >>> Google "Law of Demeter". Note that it is called a Law, which >>> makes it >>> sound absolute. Some refer to it lovingly as the "Suggestion of >>> Demeter" (I believe Fowler first wrote that). It is a useful >>> guideline >>> that should be applied when you're feeling pain (which it seems that >>> you are in this case). >>> >>> Cheers, >>> David >>> _______________________________________________ >>> rspec-devel mailing list >>> rspec-devel at rubyforge.org >>> http://rubyforge.org/mailman/listinfo/rspec-devel >> >> ------------------ >> Matt Pelletier >> http://www.eastmedia.com -- EastMedia >> http://www.informit.com/title/0321483502 -- The Mongrel Book >> http://identity.eastmedia.com -- OpenID, Identity 2.0 >> >> >> >> _______________________________________________ >> 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 ------------------ Matt Pelletier http://www.eastmedia.com -- EastMedia http://www.informit.com/title/0321483502 -- The Mongrel Book http://identity.eastmedia.com -- OpenID, Identity 2.0 From noreply at rubyforge.org Fri Jan 26 01:32:32 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 26 Jan 2007 01:32:32 -0500 (EST) Subject: [rspec-devel] [ rspec-Feature Requests-8139 ] "not implemented" message for specs yet to be implemented Message-ID: <20070126063232.C9AB9524181B@rubyforge.org> Feature Requests item #8139, was opened at 2007-01-25 06:28 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=8139&group_id=797 Category: runner module Group: None Status: Open Priority: 3 Submitted By: David Chelimsky (dchelimsky) Assigned to: Nobody (None) Summary: "not implemented" message for specs yet to be implemented Initial Comment: If I am defining the behaviour of a class, I might make a list like this: Money behaviour: - should parse - should add - should subtract - should multiply - should handle division by 0 - should handle conversion I may not know what all of those mean yet, but that is a starting point. I'd like to be able to put that right into specs and have RSpec tell me that I have yet to implement them: context "Money behaviour" do specify "should parse" specify "should add" specify "should subtract" specify "should multiply" specify "should handle division by 0" specify "should handle conversion" end Note that each specify message has no block. Given some command line option, RSpec would collect these during a spec run and add the count to the summary: ===== Finished in 3.212354 seconds 647 specifications, 0 failures, 25 not yet implemented ===== Combined with the --format specdoc (or -fs) option, the report would look like this: ===== Money behaviour: - should parse - should add - should subtract - should multiply - should handle division by 0 (NOT IMPLEMENTED - should handle conversion (NOT IMPLEMENTED) Finished in 0.212354 seconds 6 specifications, 0 failures, 2 not yet implemented ===== This would a great aid in monitoring progress during an iteration. ---------------------------------------------------------------------- Comment By: Wilson Bilkovich (wilson) Date: 2007-01-26 01:32 Message: Duplicate? :) http://rubyforge.org/tracker/index.php?func=detail&aid=6396&group_id=797&atid=3152 ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=8139&group_id=797 From noreply at rubyforge.org Fri Jan 26 06:29:04 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 26 Jan 2007 06:29:04 -0500 (EST) Subject: [rspec-devel] [ rspec-Feature Requests-8139 ] " not implemented" message for specs yet to be implemented Message-ID: <20070126112904.5AD4D5240DB3@rubyforge.org> Feature Requests item #8139, was opened at 2007-01-25 11:28 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=8139&group_id=797 Category: runner module Group: None Status: Open Priority: 3 Submitted By: David Chelimsky (dchelimsky) Assigned to: Nobody (None) >Summary: "not implemented" message for specs yet to be implemented Initial Comment: If I am defining the behaviour of a class, I might make a list like this: Money behaviour: - should parse - should add - should subtract - should multiply - should handle division by 0 - should handle conversion I may not know what all of those mean yet, but that is a starting point. I'd like to be able to put that right into specs and have RSpec tell me that I have yet to implement them: context "Money behaviour" do specify "should parse" specify "should add" specify "should subtract" specify "should multiply" specify "should handle division by 0" specify "should handle conversion" end Note that each specify message has no block. Given some command line option, RSpec would collect these during a spec run and add the count to the summary: ===== Finished in 3.212354 seconds 647 specifications, 0 failures, 25 not yet implemented ===== Combined with the --format specdoc (or -fs) option, the report would look like this: ===== Money behaviour: - should parse - should add - should subtract - should multiply - should handle division by 0 (NOT IMPLEMENTED - should handle conversion (NOT IMPLEMENTED) Finished in 0.212354 seconds 6 specifications, 0 failures, 2 not yet implemented ===== This would a great aid in monitoring progress during an iteration. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-01-26 11:29 Message: Hi Wilson, Funny - I forgot about that. OK - first of all these requests aren't the same. What [#6396] is asking for is a way to stop code from being executed using a keyword disable_specify. What I'm proposing here is different. It's a non-code place-holder right in the spec so I don't have to keep it elsewhere. Now, reading through the comments on that thread, I see that this idea was already proposed (by me, as it turns out - I'm a bit too young for senility - perhaps a vacation is in order), however even in that proposal I was talking about a special keyword. This proposal is a little different. It lets me do the same thing but with something that feels more integrated to me - it's the same keyword (specify), and it is noted as something different only by the absence of the block. So to resolve the un-implemented specs I have to add a block and add code, not change keywords. I guess you could argue that the keyword would make things more obvious when looking at the code, but if we're adding keywords I'd rather have them be more aligned w/ the BDD message - things like "story" and "behaviour". ---------------------------------------------------------------------- Comment By: Wilson Bilkovich (wilson) Date: 2007-01-26 06:32 Message: Duplicate? :) http://rubyforge.org/tracker/index.php?func=detail&aid=6396&group_id=797&atid=3152 ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=8139&group_id=797 From noreply at rubyforge.org Fri Jan 26 15:02:43 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 26 Jan 2007 15:02:43 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-8155 ] rspec clashing with rubyclr Message-ID: <20070126200243.4BA8D524181D@rubyforge.org> Bugs item #8155, was opened at 2007-01-25 15:39 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=8155&group_id=797 Category: expectation module Group: None Status: Open Resolution: None Priority: 3 Submitted By: Kevin Williams (kevwil) Assigned to: Nobody (None) Summary: rspec clashing with rubyclr Initial Comment: I'm running Ruby 1.8.5 on Windows XP SP2. I have RubyGems 0.9.1, rspec 0.7.5.1, and rubyclr 0.5.2. I have both .NET 1.1 and 2.0 installed on this box. I don't know if this is due to rspec behavior or rubyclr behavior, so this may not be an rspec issue. I'm trying to use rspec with .NET code. I've toyed with rubyclr before and it works. For example, the following prints out "count = 0": require 'rubyclr' include System::Collections list = ArrayList.new puts "count = #{list.Count}" Now, when I try to do something similar using rspec, I get errors. __Code__: require 'rubyclr' include System::Collections context "An array list" do setup do @list = ArrayList.new end specify "starts empty" do @list.Count.should == 0 end end __Error__: C:\>spec arraylist_spec.rb -f s An array list - starts empty (ERROR - 1) 1) NoMethodError in 'An array list starts empty' undefined method `ldc_i4' for # ./arraylist_spec.rb:5:in `new' ./arraylist_spec.rb:5: Finished in 0.141 seconds 1 specification, 1 failure It appears to by trying to call a method (an overloaded constructor, I think) on a Generator object. It shouldn't be a Generator object as far as I know, so I thought perhaps this comes from rspec. ---------------------------------------------------------------------- >Comment By: Kevin Williams (kevwil) Date: 2007-01-26 13:02 Message: Well, it doesn't help _me_ see the problem. :) I'll probably have to post this to the rubyclr team as well, but I know with John Lam moving to Seattle and starting that new brainwashing^H^H^H^H^H^H^H^H^H^H^H^H^Hjob, the rubyclr project is a bit dark these days. :( (Just kidding, John.) Here's the output: C:\>spec arraylist_spec.rb -f s -b An array list - starts empty (ERROR - 1) 1) NoMethodError in 'An array list starts empty' undefined method `ldc_i4' for # c:/ruby/lib/ruby/gems/1.8/gems/rspec- 0.7.5.1/lib/spec/expectations/sugar.rb:13:in `call' c:/ruby/lib/ruby/gems/1.8/gems/rspec- 0.7.5.1/lib/spec/expectations/sugar.rb:13:in `_method_missing' c:/ruby/lib/ruby/gems/1.8/gems/rspec- 0.7.5.1/lib/spec/expectations/sugar.rb:9:in `method_missing' c:/ruby/lib/ruby/gems/1.8/gems/rubyclr-0.5.2- mswin32/Src/Ruby/generate.rb:31:in `match_sig' c:/ruby/lib/ruby/gems/1.8/gems/rubyclr-0.5.2- mswin32/Src/Ruby/generate.rb:156:in `ctor_shim' c:/ruby/lib/ruby/gems/1.8/gems/rubyclr-0.5.2- mswin32/Src/Ruby/dynamicmethod.rb:63:in `instance_eval' c:/ruby/lib/ruby/gems/1.8/gems/rubyclr-0.5.2- mswin32/Src/Ruby/dynamicmethod.rb:63:in `core_create_sa fe_ruby_method' c:/ruby/lib/ruby/gems/1.8/gems/rubyclr-0.5.2- mswin32/Src/Ruby/dynamicmethod.rb:48:in `core_create_ru by_method' c:/ruby/lib/ruby/gems/1.8/gems/rubyclr-0.5.2- mswin32/Src/Ruby/dynamicmethod.rb:61:in `core_create_sa fe_ruby_method' c:/ruby/lib/ruby/gems/1.8/gems/rubyclr-0.5.2- mswin32/Src/Ruby/dynamicmethod.rb:89:in `create_safe_ru by_instance_method' c:/ruby/lib/ruby/gems/1.8/gems/rubyclr-0.5.2- mswin32/Src/Ruby/generate.rb:153:in `ctor_shim' c:/ruby/lib/ruby/gems/1.8/gems/rubyclr-0.5.2- mswin32/Src/Ruby/core.rb:21:in `initialize' ./arraylist_spec.rb:7:in `new' ./arraylist_spec.rb:7: c:/ruby/lib/ruby/gems/1.8/gems/rspec- 0.7.5.1/lib/spec/runner/context_eval.rb:129:in `instance_eval' c:/ruby/lib/ruby/gems/1.8/gems/rspec- 0.7.5.1/lib/spec/runner/context_eval.rb:129:in `create_block_fr om_parts' c:/ruby/lib/ruby/gems/1.8/gems/rspec- 0.7.5.1/lib/spec/runner/context_eval.rb:125:in `each' c:/ruby/lib/ruby/gems/1.8/gems/rspec- 0.7.5.1/lib/spec/runner/context_eval.rb:125:in `create_block_fr om_parts' c:/ruby/lib/ruby/gems/1.8/gems/rspec- 0.7.5.1/lib/spec/runner/specification.rb:47:in `instance_eval' c:/ruby/lib/ruby/gems/1.8/gems/rspec- 0.7.5.1/lib/spec/runner/specification.rb:47:in `setup_spec' c:/ruby/lib/ruby/gems/1.8/gems/rspec- 0.7.5.1/lib/spec/runner/specification.rb:29:in `run' c:/ruby/lib/ruby/gems/1.8/gems/rspec- 0.7.5.1/lib/spec/runner/context.rb:57:in `run' c:/ruby/lib/ruby/gems/1.8/gems/rspec- 0.7.5.1/lib/spec/runner/context.rb:54:in `each' c:/ruby/lib/ruby/gems/1.8/gems/rspec- 0.7.5.1/lib/spec/runner/context.rb:54:in `run' c:/ruby/lib/ruby/gems/1.8/gems/rspec- 0.7.5.1/lib/spec/runner/context_runner.rb:23:in `run' c:/ruby/lib/ruby/gems/1.8/gems/rspec- 0.7.5.1/lib/spec/runner/context_runner.rb:22:in `each' c:/ruby/lib/ruby/gems/1.8/gems/rspec- 0.7.5.1/lib/spec/runner/context_runner.rb:22:in `run' c:/ruby/lib/ruby/gems/1.8/gems/rspec- 0.7.5.1/lib/spec/runner/command_line.rb:26:in `run' c:/ruby/lib/ruby/gems/1.8/gems/rspec-0.7.5.1/bin/spec:4 c:/ruby/bin/spec:16:in `load' c:/ruby/bin/spec:16 Finished in 0.157 seconds 1 specification, 1 failure ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-01-25 16:22 Message: I'm pretty sure this is not RSpec. We don't have any class named Generator. The stack trace you are seeing is trimmed down by RSpec. You can see the full trace doing this: spec arraylist_spec.rb -fs -b Does that help you see better where the problem might be? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=8155&group_id=797 From noreply at rubyforge.org Fri Jan 26 19:12:42 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 26 Jan 2007 19:12:42 -0500 (EST) Subject: [rspec-devel] [ rspec-Feature Requests-8139 ] " not implemented" message for specs yet to be implemented Message-ID: <20070127001243.3246F524189F@rubyforge.org> Feature Requests item #8139, was opened at 2007-01-25 06:28 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=8139&group_id=797 Category: runner module Group: None Status: Open Priority: 3 Submitted By: David Chelimsky (dchelimsky) Assigned to: Nobody (None) Summary: "not implemented" message for specs yet to be implemented Initial Comment: If I am defining the behaviour of a class, I might make a list like this: Money behaviour: - should parse - should add - should subtract - should multiply - should handle division by 0 - should handle conversion I may not know what all of those mean yet, but that is a starting point. I'd like to be able to put that right into specs and have RSpec tell me that I have yet to implement them: context "Money behaviour" do specify "should parse" specify "should add" specify "should subtract" specify "should multiply" specify "should handle division by 0" specify "should handle conversion" end Note that each specify message has no block. Given some command line option, RSpec would collect these during a spec run and add the count to the summary: ===== Finished in 3.212354 seconds 647 specifications, 0 failures, 25 not yet implemented ===== Combined with the --format specdoc (or -fs) option, the report would look like this: ===== Money behaviour: - should parse - should add - should subtract - should multiply - should handle division by 0 (NOT IMPLEMENTED - should handle conversion (NOT IMPLEMENTED) Finished in 0.212354 seconds 6 specifications, 0 failures, 2 not yet implemented ===== This would a great aid in monitoring progress during an iteration. ---------------------------------------------------------------------- Comment By: Wilson Bilkovich (wilson) Date: 2007-01-26 19:12 Message: Hi David, I was just giving you a hard time. I remain highly in favor of this feature. I would be happy to help implement it, and/or stuff people who don't like it into trashcans at RailsConf. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-01-26 06:29 Message: Hi Wilson, Funny - I forgot about that. OK - first of all these requests aren't the same. What [#6396] is asking for is a way to stop code from being executed using a keyword disable_specify. What I'm proposing here is different. It's a non-code place-holder right in the spec so I don't have to keep it elsewhere. Now, reading through the comments on that thread, I see that this idea was already proposed (by me, as it turns out - I'm a bit too young for senility - perhaps a vacation is in order), however even in that proposal I was talking about a special keyword. This proposal is a little different. It lets me do the same thing but with something that feels more integrated to me - it's the same keyword (specify), and it is noted as something different only by the absence of the block. So to resolve the un-implemented specs I have to add a block and add code, not change keywords. I guess you could argue that the keyword would make things more obvious when looking at the code, but if we're adding keywords I'd rather have them be more aligned w/ the BDD message - things like "story" and "behaviour". ---------------------------------------------------------------------- Comment By: Wilson Bilkovich (wilson) Date: 2007-01-26 01:32 Message: Duplicate? :) http://rubyforge.org/tracker/index.php?func=detail&aid=6396&group_id=797&atid=3152 ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=8139&group_id=797 From noreply at rubyforge.org Sat Jan 27 05:19:47 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sat, 27 Jan 2007 05:19:47 -0500 (EST) Subject: [rspec-devel] [ rspec-Feature Requests-8149 ] specify_negatively Message-ID: <20070127101947.1963152409A1@rubyforge.org> Feature Requests item #8149, was opened at 2007-01-25 13:55 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=8149&group_id=797 Category: runner module Group: None >Status: Closed Priority: 3 Submitted By: Yurii Rashkovskii (yrashk) >Assigned to: Aslak Helles?y (aslak_hellesoy) Summary: specify_negatively Initial Comment: The idea is pretty simple: to let declare some specifications as those that _should_ fail: context "Math behaviour" do specify "addition should give you the right answer" do (2+2).should == 4 end specify_negatively "addition should not give you the wrong answer (should fail)" do (2+2).should == 5 end specify_negatively "addition should not give you the wrong answer (bad negative test)"" do (2+2).should == 4 end end Math behaviour - addition should give you the right answer - addition should not give you the wrong answer (should fail) - addition should not give you the wrong answer (bad negative test) (FAILED - 1) 1) 'addition should not give you the wrong answer (bad negative test)' FAILED This specification was expected to fail, but nothing failed Finished in 0.041288 seconds 3 specifications, 1 failure You can read discussion here: http://rashkovskii.com/articles/2007/1/25/rspec-specify_negatively ---------------------------------------------------------------------- >Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-01-27 05:19 Message: I'm closing this since Proc.should_raise can be used to achieve a similar effect ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-01-25 14:08 Message: Maybe I'm missing something here, but would this work for you? (already supported) lambda do (2+2).should == 5 end.should_raise ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=8149&group_id=797 From noreply at rubyforge.org Sat Jan 27 10:46:44 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sat, 27 Jan 2007 10:46:44 -0500 (EST) Subject: [rspec-devel] [ rspec-Feature Requests-8216 ] shortcut for creating object stub Message-ID: <20070127154644.9758D524122F@rubyforge.org> Feature Requests item #8216, was opened at 2007-01-27 15:46 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=8216&group_id=797 Category: runner module Group: None Status: Open Priority: 3 Submitted By: David Chelimsky (dchelimsky) Assigned to: David Chelimsky (dchelimsky) Summary: shortcut for creating object stub Initial Comment: I'd like to easily set up a mock w/ multiple pre-defined method stubs: thing_stub = stub("thing", :a => "A", :b => "B") thing_stub.a == "A" => true thing_stub.b == "B" => true ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=8216&group_id=797 From noreply at rubyforge.org Sat Jan 27 10:50:29 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sat, 27 Jan 2007 10:50:29 -0500 (EST) Subject: [rspec-devel] [ rspec-Feature Requests-8216 ] shortcut for creating object stub Message-ID: <20070127155029.B675F524122F@rubyforge.org> Feature Requests item #8216, was opened at 2007-01-27 15:46 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=8216&group_id=797 Category: runner module Group: None >Status: Closed Priority: 3 Submitted By: David Chelimsky (dchelimsky) Assigned to: David Chelimsky (dchelimsky) Summary: shortcut for creating object stub Initial Comment: I'd like to easily set up a mock w/ multiple pre-defined method stubs: thing_stub = stub("thing", :a => "A", :b => "B") thing_stub.a == "A" => true thing_stub.b == "B" => true ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-01-27 15:50 Message: Added to trunk (rev 1439). ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=8216&group_id=797 From noreply at rubyforge.org Sat Jan 27 10:53:30 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sat, 27 Jan 2007 10:53:30 -0500 (EST) Subject: [rspec-devel] [ rspec-Feature Requests-8126 ] Nested specify blocks Message-ID: <20070127155330.9E2925241232@rubyforge.org> Feature Requests item #8126, was opened at 2007-01-25 01:25 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=8126&group_id=797 Category: expectation module Group: None Status: Open Priority: 3 Submitted By: Wincent Colaiuta (wincent) Assigned to: Nobody (None) Summary: Nested specify blocks Initial Comment: I know that the idea of nested contexts has come up on the devel list before (Google for "pipermail rspec nested contexts") and most were not in favor of the idea. For me, more useful than nested contexts would be nested specifications ("specify" blocks). Currently I have specs which look like this: context 'outer' do specify 'inner' do this.should == that end end If a spec is not satisfied then rspec prints a message of the form "outer inner". I sometimes find myself wishing that I could nest the specify blocks to fine tune the failure message: context 'outer' do specify 'inner' do specify 'innermost' do this.should == that end end end In this case rspec would print "outer inner innermost" on failure. Let me flesh it out a bit with more of a concrete example; basically I often find myself wanting to write this: context 'applying a regexp to a string' do specify 'should be able to match "zero or more" times' do specify 'with input that matches zero times' do # test zero-match case end specify 'with input that matches one time' do # test one-match case end specify 'with input that matches two times' do # test two-match case end end end Because I can't be bothered writing this: context 'applying a regexp to a string' do specify 'should be able to match "zero or more" times (with input that matches zero times)' do # test zero-match case end specify 'should be able to match "zero or more" times (with input that matches one time)' do # test one-match case end specify 'should be able to match "zero or more" times (with input that matches two times)' do # test two-match case end end But I end up writing this: context 'applying a regexp to a string' do specify 'should be able to match "zero or more" times' do # test zero-match case # test one-match case # test two-match case end end This isn't ideal because if the first assertion fails then the others aren't even tested. I'd rather keep the number of assertions in each specify block a bit lower, and the ability to nest specify blocks would help me to do that. What do people think? ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-01-27 15:53 Message: I love this idea, but I think nesting specify would be confusing to look at. How about this: context specify example context 'applying a regexp to a string' do specify 'should be able to match "zero or more" times' do example "zero-match case" do example "one-match case" do example "two-match case" do end end ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=8126&group_id=797 From noreply at rubyforge.org Sat Jan 27 11:42:56 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sat, 27 Jan 2007 11:42:56 -0500 (EST) Subject: [rspec-devel] [ rspec-Feature Requests-8126 ] Nested specify blocks Message-ID: <20070127164256.154D652412BE@rubyforge.org> Feature Requests item #8126, was opened at 2007-01-25 01:25 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=8126&group_id=797 Category: expectation module Group: None Status: Open Priority: 3 Submitted By: Wincent Colaiuta (wincent) Assigned to: Nobody (None) Summary: Nested specify blocks Initial Comment: I know that the idea of nested contexts has come up on the devel list before (Google for "pipermail rspec nested contexts") and most were not in favor of the idea. For me, more useful than nested contexts would be nested specifications ("specify" blocks). Currently I have specs which look like this: context 'outer' do specify 'inner' do this.should == that end end If a spec is not satisfied then rspec prints a message of the form "outer inner". I sometimes find myself wishing that I could nest the specify blocks to fine tune the failure message: context 'outer' do specify 'inner' do specify 'innermost' do this.should == that end end end In this case rspec would print "outer inner innermost" on failure. Let me flesh it out a bit with more of a concrete example; basically I often find myself wanting to write this: context 'applying a regexp to a string' do specify 'should be able to match "zero or more" times' do specify 'with input that matches zero times' do # test zero-match case end specify 'with input that matches one time' do # test one-match case end specify 'with input that matches two times' do # test two-match case end end end Because I can't be bothered writing this: context 'applying a regexp to a string' do specify 'should be able to match "zero or more" times (with input that matches zero times)' do # test zero-match case end specify 'should be able to match "zero or more" times (with input that matches one time)' do # test one-match case end specify 'should be able to match "zero or more" times (with input that matches two times)' do # test two-match case end end But I end up writing this: context 'applying a regexp to a string' do specify 'should be able to match "zero or more" times' do # test zero-match case # test one-match case # test two-match case end end This isn't ideal because if the first assertion fails then the others aren't even tested. I'd rather keep the number of assertions in each specify block a bit lower, and the ability to nest specify blocks would help me to do that. What do people think? ---------------------------------------------------------------------- >Comment By: Wincent Colaiuta (wincent) Date: 2007-01-27 16:42 Message: Yes, I think that "context/specify/example" would be a great way to split things up, and the language you've proposed maps well onto the behaviour-driven way of thinking about software development ("in this context ... this should happen ... example ..."). About the only thing I would change in your example is that I would start each example with the word "for" so that when the three strings are chained together they would read like, "applying a regexp to a string should be able to match 'zero or more' times for the zero-match case" etc: context 'applying a regexp to a string' do specify 'should be able to match "zero or more" times' do example 'for the zero-match case' do ... end example 'for the one-match case' do ... end example 'for the two-match case' do ... end end end This has the added benefit that the line introducing each example in the specification reads as "example for zero- match case" etc, which is highly readable and descriptive. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-01-27 15:53 Message: I love this idea, but I think nesting specify would be confusing to look at. How about this: context specify example context 'applying a regexp to a string' do specify 'should be able to match "zero or more" times' do example "zero-match case" do example "one-match case" do example "two-match case" do end end ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=8126&group_id=797 From noreply at rubyforge.org Sat Jan 27 13:45:29 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sat, 27 Jan 2007 13:45:29 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-8218 ] heckle_runner.rb doesn't work with heckle >= 1.2.0 Message-ID: <20070127184531.1170A5241586@rubyforge.org> Bugs item #8218, was opened at 2007-01-27 18:45 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=8218&group_id=797 Category: runner module Group: None Status: Open Resolution: None Priority: 3 Submitted By: Michal Kwiatkowski (infrared) Assigned to: Nobody (None) Summary: heckle_runner.rb doesn't work with heckle >= 1.2.0 Initial Comment: Heckle::Base class dissapeared in heckle 1.2, so definition of Heckler in heckle_runner.rb is invalid and yields an error. In 1.2 there is no Heckle module, just a global Heckle class. I've attached a patch (against current trunk) that fixes this issue. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=8218&group_id=797 From noreply at rubyforge.org Sat Jan 27 23:41:59 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sat, 27 Jan 2007 23:41:59 -0500 (EST) Subject: [rspec-devel] [ rspec-Feature Requests-8139 ] & quot; not implemented& quot; message for specs yet to be implemented Message-ID: <20070128044159.40BE75241B0C@rubyforge.org> Feature Requests item #8139, was opened at 2007-01-25 03:28 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=8139&group_id=797 Category: runner module Group: None Status: Open Priority: 3 Submitted By: David Chelimsky (dchelimsky) Assigned to: Nobody (None) >Summary: &quot;not implemented&quot; message for specs yet to be implemented Initial Comment: If I am defining the behaviour of a class, I might make a list like this: Money behaviour: - should parse - should add - should subtract - should multiply - should handle division by 0 - should handle conversion I may not know what all of those mean yet, but that is a starting point. I'd like to be able to put that right into specs and have RSpec tell me that I have yet to implement them: context "Money behaviour" do specify "should parse" specify "should add" specify "should subtract" specify "should multiply" specify "should handle division by 0" specify "should handle conversion" end Note that each specify message has no block. Given some command line option, RSpec would collect these during a spec run and add the count to the summary: ===== Finished in 3.212354 seconds 647 specifications, 0 failures, 25 not yet implemented ===== Combined with the --format specdoc (or -fs) option, the report would look like this: ===== Money behaviour: - should parse - should add - should subtract - should multiply - should handle division by 0 (NOT IMPLEMENTED - should handle conversion (NOT IMPLEMENTED) Finished in 0.212354 seconds 6 specifications, 0 failures, 2 not yet implemented ===== This would a great aid in monitoring progress during an iteration. ---------------------------------------------------------------------- >Comment By: Brian Takita (btakita) Date: 2007-01-27 20:41 Message: This looks like a good feature. I like the idea of being able to specify what the software is supposed to do before implementing it. The specify method without a block transition s naturally to implementing a full spec. I remember the conclusion of the other feature request was to use a TODO statement, which in my opinion in not very semantic. ---------------------------------------------------------------------- Comment By: Wilson Bilkovich (wilson) Date: 2007-01-26 16:12 Message: Hi David, I was just giving you a hard time. I remain highly in favor of this feature. I would be happy to help implement it, and/or stuff people who don't like it into trashcans at RailsConf. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-01-26 03:29 Message: Hi Wilson, Funny - I forgot about that. OK - first of all these requests aren't the same. What [#6396] is asking for is a way to stop code from being executed using a keyword disable_specify. What I'm proposing here is different. It's a non-code place-holder right in the spec so I don't have to keep it elsewhere. Now, reading through the comments on that thread, I see that this idea was already proposed (by me, as it turns out - I'm a bit too young for senility - perhaps a vacation is in order), however even in that proposal I was talking about a special keyword. This proposal is a little different. It lets me do the same thing but with something that feels more integrated to me - it's the same keyword (specify), and it is noted as something different only by the absence of the block. So to resolve the un-implemented specs I have to add a block and add code, not change keywords. I guess you could argue that the keyword would make things more obvious when looking at the code, but if we're adding keywords I'd rather have them be more aligned w/ the BDD message - things like "story" and "behaviour". ---------------------------------------------------------------------- Comment By: Wilson Bilkovich (wilson) Date: 2007-01-25 22:32 Message: Duplicate? :) http://rubyforge.org/tracker/index.php?func=detail&aid=6396&group_id=797&atid=3152 ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=8139&group_id=797 From noreply at rubyforge.org Sun Jan 28 17:48:45 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 28 Jan 2007 17:48:45 -0500 (EST) Subject: [rspec-devel] [ rspec-Feature Requests-8139 ] & quot; not implemented& quot; message for specs yet to be implemented Message-ID: <20070128224846.0BCB65240EF5@rubyforge.org> Feature Requests item #8139, was opened at 2007-01-25 03:28 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=8139&group_id=797 Category: runner module Group: None Status: Open Priority: 3 Submitted By: David Chelimsky (dchelimsky) Assigned to: Nobody (None) Summary: &quot;not implemented&quot; message for specs yet to be implemented Initial Comment: If I am defining the behaviour of a class, I might make a list like this: Money behaviour: - should parse - should add - should subtract - should multiply - should handle division by 0 - should handle conversion I may not know what all of those mean yet, but that is a starting point. I'd like to be able to put that right into specs and have RSpec tell me that I have yet to implement them: context "Money behaviour" do specify "should parse" specify "should add" specify "should subtract" specify "should multiply" specify "should handle division by 0" specify "should handle conversion" end Note that each specify message has no block. Given some command line option, RSpec would collect these during a spec run and add the count to the summary: ===== Finished in 3.212354 seconds 647 specifications, 0 failures, 25 not yet implemented ===== Combined with the --format specdoc (or -fs) option, the report would look like this: ===== Money behaviour: - should parse - should add - should subtract - should multiply - should handle division by 0 (NOT IMPLEMENTED - should handle conversion (NOT IMPLEMENTED) Finished in 0.212354 seconds 6 specifications, 0 failures, 2 not yet implemented ===== This would a great aid in monitoring progress during an iteration. ---------------------------------------------------------------------- Comment By: Ian Dees (undees) Date: 2007-01-28 14:48 Message: At work, we have a tool that generates context/specify blocks from our test case descriptions. Here's what we use: 1) A NonImplementedTest class with an "implemented?" method returning false. 2) A module-level this_test method returning an instance of NonImplementedTest. So our tool can generate blocks that look like this: context "A widget" do specify "should foobar the frobnitz" do # Text from test case: # 1) Click the widget button. # 2) Make sure the frobnitz is foobar'ed. this_test.should_be_implemented end end That way, we start off red until all the tests are implemented and the software passes them. ---------------------------------------------------------------------- Comment By: Brian Takita (btakita) Date: 2007-01-27 20:41 Message: This looks like a good feature. I like the idea of being able to specify what the software is supposed to do before implementing it. The specify method without a block transition s naturally to implementing a full spec. I remember the conclusion of the other feature request was to use a TODO statement, which in my opinion in not very semantic. ---------------------------------------------------------------------- Comment By: Wilson Bilkovich (wilson) Date: 2007-01-26 16:12 Message: Hi David, I was just giving you a hard time. I remain highly in favor of this feature. I would be happy to help implement it, and/or stuff people who don't like it into trashcans at RailsConf. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-01-26 03:29 Message: Hi Wilson, Funny - I forgot about that. OK - first of all these requests aren't the same. What [#6396] is asking for is a way to stop code from being executed using a keyword disable_specify. What I'm proposing here is different. It's a non-code place-holder right in the spec so I don't have to keep it elsewhere. Now, reading through the comments on that thread, I see that this idea was already proposed (by me, as it turns out - I'm a bit too young for senility - perhaps a vacation is in order), however even in that proposal I was talking about a special keyword. This proposal is a little different. It lets me do the same thing but with something that feels more integrated to me - it's the same keyword (specify), and it is noted as something different only by the absence of the block. So to resolve the un-implemented specs I have to add a block and add code, not change keywords. I guess you could argue that the keyword would make things more obvious when looking at the code, but if we're adding keywords I'd rather have them be more aligned w/ the BDD message - things like "story" and "behaviour". ---------------------------------------------------------------------- Comment By: Wilson Bilkovich (wilson) Date: 2007-01-25 22:32 Message: Duplicate? :) http://rubyforge.org/tracker/index.php?func=detail&aid=6396&group_id=797&atid=3152 ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=8139&group_id=797 From noreply at rubyforge.org Sun Jan 28 19:22:59 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 28 Jan 2007 19:22:59 -0500 (EST) Subject: [rspec-devel] [ rspec-Patches-8235 ] Fixes problem with "nil" in failure messages raised from the Not class Message-ID: <20070129002259.389265241004@rubyforge.org> Patches item #8235, was opened at 2007-01-29 00:22 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=8235&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Tobias Grimm (e-tobi) Assigned to: Nobody (None) Summary: Fixes problem with "nil" in failure messages raised from the Not class Initial Comment: The failure messages raised from the not class contain a "nil", because the expected values gets not passed as the second argument to default_message(). ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=8235&group_id=797 From noreply at rubyforge.org Sun Jan 28 19:46:24 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 28 Jan 2007 19:46:24 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-8236 ] Problem with "nil" in failure messages raised from the Not class Message-ID: <20070129004624.34D4B524104E@rubyforge.org> Bugs item #8236, was opened at 2007-01-29 00:46 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=8236&group_id=797 Category: expectation module Group: None Status: Open Resolution: None Priority: 3 Submitted By: Tobias Grimm (e-tobi) Assigned to: Nobody (None) Summary: Problem with "nil" in failure messages raised from the Not class Initial Comment: The failure messages raised from the not class contains a "nil", because the expected value gets not passed as the second argument to default_message(). try: "1.should_not == 1" which results in "1 should not == 1 nil" see patch #8235, which contains exploit and fix: http://rubyforge.org/tracker/index.php?func=detail&aid=8235&group_id=797&atid=3151 Tobias ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=8236&group_id=797 From noreply at rubyforge.org Sun Jan 28 19:55:36 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 28 Jan 2007 19:55:36 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-8237 ] "should_not_be ==" doesn't work Message-ID: <20070129005536.B528D524104A@rubyforge.org> Bugs item #8237, was opened at 2007-01-29 00:55 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=8237&group_id=797 Category: expectation module Group: None Status: Open Resolution: None Priority: 3 Submitted By: Tobias Grimm (e-tobi) Assigned to: Nobody (None) Summary: "should_not_be ==" doesn't work Initial Comment: Even if it's marked as "gone in 0.9" it fails in 0.7.5.1: "1.should_not_be == 1" runs successfully, where it should fail. Cause of the problem is Not.be() using :no_arg instead of :___no_arg. The expected argument of the method be() in class Not is passed from should_not_be() with :___no_arg. Tobias ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=8237&group_id=797 From noreply at rubyforge.org Sun Jan 28 20:41:14 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 28 Jan 2007 20:41:14 -0500 (EST) Subject: [rspec-devel] [ rspec-Patches-7637 ] [PATCH] add skip-migration option to rspec_resource generator Message-ID: <20070129014114.89F0B52410BE@rubyforge.org> Patches item #7637, was opened at 2007-01-07 00:35 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=7637&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Chris Anderson (jchris) Assigned to: Nobody (None) Summary: [PATCH] add skip-migration option to rspec_resource generator Initial Comment: it should have this option, just like the regular Test::Unit version of it. ---------------------------------------------------------------------- >Comment By: Chris Anderson (jchris) Date: 2007-01-29 01:41 Message: Sorry, I haven't been keeping up with this ticket. The patch should be attached by now. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-01-18 17:14 Message: Make sure you check the checkbox if you attach it again ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-01-07 01:03 Message: Where's the file? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=7637&group_id=797 From noreply at rubyforge.org Sun Jan 28 20:47:10 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 28 Jan 2007 20:47:10 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-8238 ] spec route generation in Rails trunk Message-ID: <20070129014710.845115241101@rubyforge.org> Bugs item #8238, was opened at 2007-01-29 01:47 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=8238&group_id=797 Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: Chris Anderson (jchris) Assigned to: Nobody (None) Summary: spec route generation in Rails trunk Initial Comment: Route-generation in specs is broken as of Rails trunk r6062. With Rails r6061, all specs pass, but in 6062 I get a trace like this every time my controller generates a route: TypeError in 'Requesting /artists/1 using PUT should redirect to the artist' can't convert Fixnum into String (eval):19:in `artist_url' /Users/jchris/ruby/rails/grabbit/config/../app/controllers/artists_controller.rb:59:in `update' /Users/jchris/ruby/rails/grabbit/config/../app/controllers/artists_controller.rb:56:in `update' ./spec/controllers/artists_controller_spec.rb:267:in `do_update' ./spec/controllers/artists_controller_spec.rb:287: The issue affects both RSpec and RSpec on Rails at revision 1359 and 1440. Parallel Test::Unit tests aren't showing any signs of breakage. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=8238&group_id=797 From noreply at rubyforge.org Sun Jan 28 21:38:49 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 28 Jan 2007 21:38:49 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-8237 ] "should_not_be ==" doesn't work Message-ID: <20070129023849.2D56D5241222@rubyforge.org> Bugs item #8237, was opened at 2007-01-29 00:55 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=8237&group_id=797 Category: expectation module Group: None >Status: Closed >Resolution: Rejected Priority: 3 Submitted By: Tobias Grimm (e-tobi) >Assigned to: David Chelimsky (dchelimsky) >Summary: "should_not_be ==" doesn't work Initial Comment: Even if it's marked as "gone in 0.9" it fails in 0.7.5.1: "1.should_not_be == 1" runs successfully, where it should fail. Cause of the problem is Not.be() using :no_arg instead of :___no_arg. The expected argument of the method be() in class Not is passed from should_not_be() with :___no_arg. Tobias ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-01-29 02:38 Message: http://rspec.rubyforge.org/documentation/expectations.html Use this instead: actual.should_not == 1 ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=8237&group_id=797 From noreply at rubyforge.org Sun Jan 28 22:24:06 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 28 Jan 2007 22:24:06 -0500 (EST) Subject: [rspec-devel] [ rspec-Patches-8235 ] Fixes problem with "nil" in failure messages raised from the Not class Message-ID: <20070129032406.34C8A5241223@rubyforge.org> Patches item #8235, was opened at 2007-01-29 00:22 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=8235&group_id=797 >Category: expectation module Group: None Status: Open Resolution: None Priority: 3 Submitted By: Tobias Grimm (e-tobi) >Assigned to: David Chelimsky (dchelimsky) >Summary: Fixes problem with "nil" in failure messages raised from the Not class Initial Comment: The failure messages raised from the not class contain a "nil", because the expected values gets not passed as the second argument to default_message(). ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-01-29 03:24 Message: For some unknown reason I can't open that file. Would you please upload it uncompressed? Thx ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=8235&group_id=797 From noreply at rubyforge.org Sun Jan 28 22:26:28 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 28 Jan 2007 22:26:28 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-8240 ] Cryptic error message when no controller_name Message-ID: <20070129032628.82E3D524122B@rubyforge.org> Bugs item #8240, was opened at 2007-01-28 22:26 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=8240&group_id=797 Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: Fran?ois Beausoleil (fbos) Assigned to: Nobody (None) Summary: Cryptic error message when no controller_name Initial Comment: In the following spec: context "A project owner" do specify "can assign roles to other users" do # ... end end I get the following cryptic error message: 1) NoMethodError in 'A project owner can assign roles to other users' undefined method `session=' for # /home/francois/src/smrty2/vendor/plugins/rspec_on_rails/lib/spec/rails/context/controller.rb:134:in `setup_extra' /home/francois/src/smrty2/vendor/plugins/rspec_on_rails/lib/spec/rails/functional_eval_context.rb:22:in `setup' /home/francois/src/smrty2/vendor/plugins/rspec_on_rails/lib/spec/rails/context/controller.rb:151:in `setup' Line 134 of controller.rb is: @controller.session = session We are probably only missing a check to ensure that @controller is somehow defined. Failing that should simply say "You forgot to define controller_name in your controller spec". This is on 0.7.5.1. Thanks ! -- Fran?ois Beausoleil ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=8240&group_id=797 From noreply at rubyforge.org Sun Jan 28 22:37:35 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 28 Jan 2007 22:37:35 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-8241 ] "no id given" if controller method does not exist Message-ID: <20070129033735.D96FC5241240@rubyforge.org> Bugs item #8241, was opened at 2007-01-28 22:37 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=8241&group_id=797 Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: Fran?ois Beausoleil (fbos) Assigned to: Nobody (None) Summary: "no id given" if controller method does not exist Initial Comment: Given this controller: class RolesController < ApplicationController end And this specification: context "A project owner" do controller_name :roles specify "can assign roles to other users" do post :create, :project_id => 27, :role => {:name => "user"}, :user => {:email => "jim at teksol.info"} response.should_redirect_to dashboard_url end end The spec fails like this: 1) ArgumentError in 'A project owner can assign roles to other users' no id given /usr/lib/ruby/gems/1.8/gems/rspec-0.7.5.1/lib/spec/expectations/sugar.rb:13:in `method_missing' /usr/lib/ruby/gems/1.8/gems/rspec-0.7.5.1/lib/spec/expectations/sugar.rb:13:in `_method_missing' /usr/lib/ruby/gems/1.8/gems/rspec-0.7.5.1/lib/spec/expectations/sugar.rb:9:in `method_missing' /home/francois/src/smrty2/config/../vendor/rails/actionpack/lib/action_controller/base.rb:1098:in `perform_action_without_filters' /home/francois/src/smrty2/config/../vendor/rails/actionpack/lib/action_controller/filters.rb:632:in `call_filter' /home/francois/src/smrty2/config/../vendor/rails/actionpack/lib/action_controller/filters.rb:638:in `call_filter' /home/francois/src/smrty2/config/../vendor/rails/actionpack/lib/action_controller/filters.rb:438:in `call' /home/francois/src/smrty2/config/../vendor/rails/actionpack/lib/action_controller/filters.rb:637:in `call_filter' /home/francois/src/smrty2/config/../vendor/rails/actionpack/lib/action_controller/filters.rb:638:in `call_filter' /home/francois/src/smrty2/config/../vendor/rails/actionpack/lib/action_controller/filters.rb:438:in `call' /home/francois/src/smrty2/config/../vendor/rails/actionpack/lib/action_controller/filters.rb:637:in `call_filter' /home/francois/src/smrty2/config/../vendor/rails/actionpack/lib/action_controller/filters.rb:619:in `perform_action_without_benchmark' /home/francois/src/smrty2/config/../vendor/rails/actionpack/lib/action_controller/benchmarking.rb:66:in `perform_action_without_rescue' /usr/lib/ruby/1.8/benchmark.rb:293:in `measure' /home/francois/src/smrty2/config/../vendor/rails/actionpack/lib/action_controller/benchmarking.rb:66:in `perform_action_without_rescue' /home/francois/src/smrty2/config/../vendor/rails/actionpack/lib/action_controller/rescue.rb:83:in `perform_action' /home/francois/src/smrty2/config/../vendor/rails/actionpack/lib/action_controller/base.rb:430:in `process_without_filters' /home/francois/src/smrty2/config/../vendor/rails/actionpack/lib/action_controller/filters.rb:624:in `process_without_session_management_support' /home/francois/src/smrty2/config/../vendor/rails/actionpack/lib/action_controller/session_management.rb:114:in `process_without_test' /home/francois/src/smrty2/config/../vendor/rails/actionpack/lib/action_controller/test_process.rb:15:in `process' /home/francois/src/smrty2/config/../vendor/rails/actionpack/lib/action_controller/test_process.rb:382:in `process' /home/francois/src/smrty2/config/../vendor/rails/actionpack/lib/action_controller/test_process.rb:353:in `post' ./spec/controllers/roles_spec.rb:26: /usr/lib/ruby/gems/1.8/gems/rspec-0.7.5.1/lib/spec/runner/specification.rb:55:in `execute_spec' /usr/lib/ruby/gems/1.8/gems/rspec-0.7.5.1/lib/spec/runner/specification.rb:30:in `run' /usr/lib/ruby/gems/1.8/gems/rspec-0.7.5.1/lib/spec/runner/context.rb:57:in `run' /usr/lib/ruby/gems/1.8/gems/rspec-0.7.5.1/lib/spec/runner/context.rb:54:in `run' /usr/lib/ruby/gems/1.8/gems/rspec-0.7.5.1/lib/spec/runner/context_runner.rb:23:in `run' /usr/lib/ruby/gems/1.8/gems/rspec-0.7.5.1/lib/spec/runner/context_runner.rb:22:in `run' /usr/lib/ruby/gems/1.8/gems/rspec-0.7.5.1/lib/spec/runner/command_line.rb:26:in `run' /usr/lib/ruby/gems/1.8/gems/rspec-0.7.5.1/bin/spec:4: /usr/bin/spec:16: I resolved my issue by creating the method. I would have expected rspec to complain that "the action does not exist". Thanks ! Fran?ois Beausoleil ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=8241&group_id=797 From noreply at rubyforge.org Sun Jan 28 23:05:22 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 28 Jan 2007 23:05:22 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-6896 ] should_render fails with respond_to Message-ID: <20070129040522.7966F524123B@rubyforge.org> Bugs item #6896, was opened at 2006-11-26 18:40 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6896&group_id=797 Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: Pat Maddox (pergesu) Assigned to: David Chelimsky (dchelimsky) Summary: should_render fails with respond_to Initial Comment: Spec: specify "should show the form" do controller.should_render :template => "people/new" end Controller code: def new @person = Person.new respond_to do |format| format.html end end Failure: {:template=>"people/new"} should == {:action=>"new", :content_type=>#} ---------------------------------------------------------------------- Comment By: Fran?ois Beausoleil (fbos) Date: 2007-01-28 23:05 Message: On a related note: context "A project owner" do controller_name :roles specify "can assign roles to other users" do post :create, :project_id => 27, :role => {:name => "user"}, :user => {:email => "jim at teksol.info"} response.should_redirect_to "/" end end Given this controller implementation: class RolesController < ApplicationController def create @target = User.find_by_email!(params[:user][:email]) @target.set_project_role(current_project, params[:role][:name]) respond_to do |wants| wants.js wants.html { redirect_to dashboard_path } end end end Fails like this: 1) 'A project owner can assign roles to other users' FAILED expected redirect to http://test.host/ but there was no redirect /home/francois/src/smrty2/vendor/plugins/rspec_on_rails/lib/spec/rails/extensions/action_controller/test_response.rb:55:in `should_redirect_to' ./spec/controllers/roles_spec.rb:27: ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-27 21:44 Message: I committed a first step towards this in trunk (rev 1160). It now supports format.html only. So far.... ---------------------------------------------------------------------- Comment By: Pat Maddox (pergesu) Date: 2006-11-26 19:20 Message: Edge rails, 0.7.3 ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-26 19:20 Message: versions???? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6896&group_id=797 From noreply at rubyforge.org Sun Jan 28 23:20:49 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 28 Jan 2007 23:20:49 -0500 (EST) Subject: [rspec-devel] [ rspec-Feature Requests-6511 ] controller.should_assign Message-ID: <20070129042049.D0D265241237@rubyforge.org> Feature Requests item #6511, was opened at 2006-11-06 03:23 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6511&group_id=797 Category: rails plugin Group: None >Status: Closed Priority: 3 Submitted By: David Chelimsky (dchelimsky) >Assigned to: David Chelimsky (dchelimsky) Summary: controller.should_assign Initial Comment: (reopened 6502) In 0.7, there are a number of expectations added to the controller designed to be expressed in advance of the action: controller.should_redirect_to 'destination' controller.should_render :template => 'blah' etc but to set expectations about assigns, we have to use this: assigns[key].should_eql value I'd like to add controller.should_assign. Here are a couple of syntax candidates: controller.should_assign(value).to(:variable_name) controller.should_assign(:variable_name).value(value) controller.should_assign { @variable_name = value } My personal favorite is the last one because you see @variable_name the same way you see it in your views, so there's less context shifting. It also makes more clear which is the variable and which is the value. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-01-29 04:20 Message: Never mind. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6511&group_id=797 From noreply at rubyforge.org Sun Jan 28 23:27:01 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 28 Jan 2007 23:27:01 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-7039 ] should_render_rjs :page, 'e', :replace_html, /t/ FAILS (tries to match incorrectly) Message-ID: <20070129042701.D30835241237@rubyforge.org> Bugs item #7039, was opened at 2006-12-04 13:04 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=7039&group_id=797 Category: rails plugin Group: None >Status: Closed >Resolution: Out of Date Priority: 3 Submitted By: Michael Johnston (lastobelus) >Assigned to: David Chelimsky (dchelimsky) Summary: should_render_rjs :page, 'e', :replace_html, /t/ FAILS (tries to match incorrectly) Initial Comment: given the following action: def stuff render :update { |page| page[:bob].replace_html "sometext" } end the following spec: specify "should replace bob with 'sometext' on AJAX request to stuff" do get 'stuff' controller.should_render_rjs :page, 'bob', :replace_html, /some/ end Fails with the following report: should replace bob with bob's string on AJAX request to stuff "$(\bob\).update(\wtf!!!!!\);" should match /\$\("bob"\)\.update\(""\)\.\(\?\-mix:some\)\(\);/ /Users/lasto/clients/ibc/project_n/vendor/plugins/rspec/lib/spec/rails/rjs_expectations.rb:26:in `should_page' /Users/lasto/clients/ibc/project_n/vendor/plugins/rspec/lib/spec/rails/rjs_expectations.rb:8:in `send' /Users/lasto/clients/ibc/project_n/vendor/plugins/rspec/lib/spec/rails/rjs_expectations.rb:8:in `should_have_rjs' /Users/lasto/clients/ibc/project_n/vendor/plugins/rspec/lib/extensions/action_controller/test_response.rb:6:in `should_have_rjs' /Users/lasto/clients/ibc/project_n/vendor/plugins/rspec/lib/spec/rails/render_matcher.rb:58:in `should_render_rjs' /Users/lasto/clients/ibc/project_n/vendor/plugins/rspec/lib/spec/rails/context/controller.rb:66:in `should_render_rjs' ./spec/controllers/ad_controller_spec.rb:84: IE, the regex is simply being appended to the update call instead of matching inside the parameter to the update call. I had a go at figuring it out, but it was beyond my ability to understand in the amount of time I had to spend on it. I think some extra parsing has to be done after the call to JavascriptGenerator? I don't know whether JavascriptGenerator is supposed to be able to stick a regex.to_s inside the update() call and the signature of the call to it is wrong, or if an empty "update" template needs to be retrieved from JavascriptGenerator and the regex inserted into it. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-01-29 04:27 Message: We're replacing should_have_rjs with should be_rjs, which wraps assert_select so you'll be to do everything you can do w/ assert_select. This is already implemented in the trunk (rev 1440) so if you're using the trunk, look at the rdocs for Spec::Rails::Matchers (though the specific module may move to Spec::Expectations::Matchers before the release). ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-12-20 01:30 Message: Actually, it looks like ARTS, from which should_have_rjs was ported, doesn't even support this. It only supports the following forms of page['id']: page['some_id'].toggle page['some_id'].style.color = 'red' I'm working on an assert_select wrapper for rspec right now. If this ends up supporting spec'ing the forms you're looking for we probably won't go any farther on should_have_rjs. I'll follow up as things evolve. In the mean time, if you use this form in your app: page.replace 'mydiv', 'replacement text' you can spec it. David ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-12-20 01:07 Message: You're fine - we didn't have any specs using :page and :replace_..... Working on it now. Sadly, just released 0.7.5, so it'll be a bit before the fix is released, but you can grab the trunk as soon as we get the fix in. David ---------------------------------------------------------------------- Comment By: Michael Johnston (lastobelus) Date: 2006-12-19 23:38 Message: Hi David, Any feedback on this? If I'm doing something stupid I would really appreciate finding out what it is. As it stands, the should_render_rjs seems simply not to work. I tried it with non-edge rails and got the same result. BTW, I did notice I put the wrong div name in the second spec (changed now in the linked archive) HOWEVER this has no effect on the result as the error is unrelated to that. Can we re-open the bug? Maybe somebody else has an answer. ---------------------------------------------------------------------- Comment By: Michael Johnston (lastobelus) Date: 2006-12-05 17:11 Message: I created a brand new edge rails app, using the following procedure: 281 rails rjstest 282 cd rjstest/ 283 rake rails:freeze:edge 284 script/plugin install svn://rubyforge.org/var/svn/rspec/tags/ REL_0_7_4/vendor/rspec_on_rails/vendor/plugins/rspec 289 ruby script/generate rspec_controller bob 290 mate . 292 ruby script/generate rspec 295 spec spec/controllers/bob_controller_spec.rb Both problems are demonstrated. Here is a link to an archive of it: http://www.lastmetal.com/misc/rjstest.tgz ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-12-05 16:24 Message: Would you mind posting your the spec and controller code? ---------------------------------------------------------------------- Comment By: Michael Johnston (lastobelus) Date: 2006-12-05 16:18 Message: Ok, I certainly tried it that way. However in my setup ALL the should_render_rjs forms report: 1) NoMethodError in 'The HomeController should replace bob with 'sometext' on AJAX request to stuff' nil does not respond to `rjs' or `has_rjs?' when the should_render_rjs is called before the GET. I posted about this a few days ago on the mailing list, but haven't found an answer as to why. I am using edge rails, and to my knowledge there is nothing extra or unusual in my setup And, I discovered, the other forms of should_render_rjs do work correctly with the call after the request. I believe the two issues are orthogonal. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-12-05 16:01 Message: http://rspec.rubyforge.org/documentation/rails/writing/controllers.html You have to put the controller.should_render_rjs call BEFORE the get: specify "should replace bob with 'sometext' on AJAX request to stuff" do controller.should_render_rjs :page, 'bob', :replace_html, /some/ get 'stuff' end ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=7039&group_id=797 From noreply at rubyforge.org Mon Jan 29 04:26:43 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 29 Jan 2007 04:26:43 -0500 (EST) Subject: [rspec-devel] [ rspec-Patches-8235 ] Fixes problem with " nil" in failure messages raised from the Not class Message-ID: <20070129092644.0B793524163F@rubyforge.org> Patches item #8235, was opened at 2007-01-29 00:22 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=8235&group_id=797 Category: expectation module Group: None Status: Open Resolution: None Priority: 3 Submitted By: Tobias Grimm (e-tobi) Assigned to: David Chelimsky (dchelimsky) >Summary: Fixes problem with "nil" in failure messages raised from the Not class Initial Comment: The failure messages raised from the not class contain a "nil", because the expected values gets not passed as the second argument to default_message(). ---------------------------------------------------------------------- >Comment By: Tobias Grimm (e-tobi) Date: 2007-01-29 09:26 Message: Ok,here it is uncompressed. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-01-29 03:24 Message: For some unknown reason I can't open that file. Would you please upload it uncompressed? Thx ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=8235&group_id=797 From noreply at rubyforge.org Mon Jan 29 17:40:39 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 29 Jan 2007 17:40:39 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-8300 ] version 7.5.1 - error code returns 'nil'; should be 'ExpectationNotMet' Message-ID: <20070129224039.898BD5243393@rubyforge.org> Bugs item #8300, was opened at 2007-01-29 16:40 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=8300&group_id=797 Category: expectation module Group: None Status: Open Resolution: None Priority: 3 Submitted By: Ron Lambkin (rlambkin) Assigned to: Nobody (None) Summary: version 7.5.1 - error code returns 'nil'; should be 'ExpectationNotMet' Initial Comment: -- stack_spec.rb require File.dirname(__FILE__) + "/stack" context "A new stack" do setup do @stack = Stack.new end specify "should be empty" do @stack.should_be_empty end end -- stack.rb class Stack def empty? false end end =========== $ spec stack_spec.rb -f s A new stack - should be empty (FAILED - 1) 1) 'A new stack should be empty' FAILED # should be empty nil # <= wrong error message ./stack_spec.rb:7: NOTE: correct error returned in version 7.5 ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=8300&group_id=797 From noreply at rubyforge.org Mon Jan 29 17:47:56 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 29 Jan 2007 17:47:56 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-8300 ] version 7.5.1 - error code returns 'nil'; should be 'ExpectationNotMet' Message-ID: <20070129224756.AD03D5243392@rubyforge.org> Bugs item #8300, was opened at 2007-01-29 22:40 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=8300&group_id=797 Category: expectation module Group: None >Status: Closed >Resolution: Out of Date Priority: 3 Submitted By: Ron Lambkin (rlambkin) >Assigned to: David Chelimsky (dchelimsky) Summary: version 7.5.1 - error code returns 'nil'; should be 'ExpectationNotMet' Initial Comment: -- stack_spec.rb require File.dirname(__FILE__) + "/stack" context "A new stack" do setup do @stack = Stack.new end specify "should be empty" do @stack.should_be_empty end end -- stack.rb class Stack def empty? false end end =========== $ spec stack_spec.rb -f s A new stack - should be empty (FAILED - 1) 1) 'A new stack should be empty' FAILED # should be empty nil # <= wrong error message ./stack_spec.rb:7: NOTE: correct error returned in version 7.5 ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-01-29 22:47 Message: Duplicate of 8236 http://rubyforge.org/tracker/index.php?func=detail&aid=8236&group_id=797&atid=3149 ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=8300&group_id=797 From dchelimsky at gmail.com Mon Jan 29 21:13:29 2007 From: dchelimsky at gmail.com (David Chelimsky) Date: Mon, 29 Jan 2007 20:13:29 -0600 Subject: [rspec-devel] moved diff handling Message-ID: <57c63afe0701291813i74df9bb8pf76eb2f54eabca75@mail.gmail.com> Heads up that I'm in the middle of changing the way diffs are handled so that they are accessible to all the matchers. Also - changes in rails trunk are causing problems w/ rspec_on_rails so I've disabled running the plugin specs against edge as a prerequisite for committing. Cheers, David From noreply at rubyforge.org Mon Jan 29 21:35:12 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 29 Jan 2007 21:35:12 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-8302 ] Strange side effect when mocking a class method Message-ID: <20070130023512.8041452433C5@rubyforge.org> Bugs item #8302, was opened at 2007-01-30 02:35 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=8302&group_id=797 Category: mock module Group: None Status: Open Resolution: None Priority: 3 Submitted By: Tobias Grimm (e-tobi) Assigned to: Nobody (None) Summary: Strange side effect when mocking a class method Initial Comment: Hi! This one is really driving me mad: class Foo def Foo.bar(arg) end end context "Context" do specify "spec 1" do Foo.should_not_receive(:bar).with(Array.new) end specify "spec 2" do Foo.bar(Array.new) end end Running these specs results in this failure: ArgumentError in 'Context 1 spec 1.2' wrong number of arguments (0 for 1) ./xxx_controller_spec.rb:14:in `bar' ./xxx_controller_spec.rb:14:in `bar' ./xxx_controller_spec.rb:12: Finished in 0.002342 seconds If I comment out the mocking of bar() in spec 1 it works. If I pass a string instead of an empty array in spec 1.2 it works too. I also can add a default value for the arg parameter in bar() and it will work. But in the above constellation, it doesn't work. Maybe there's something going wrong with the define_method() call in the MockHandler class, that puts the original method of the mocked class back in place. This might also be a Ruby bug - I'm not sure. Any ideas? bye, Tobias ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=8302&group_id=797 From noreply at rubyforge.org Mon Jan 29 22:15:28 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 29 Jan 2007 22:15:28 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-8236 ] Problem with "nil" in failure messages raised from the Not class Message-ID: <20070130031528.DB2DB524304B@rubyforge.org> Bugs item #8236, was opened at 2007-01-29 00:46 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=8236&group_id=797 Category: expectation module Group: None >Status: Closed >Resolution: Accepted Priority: 3 Submitted By: Tobias Grimm (e-tobi) >Assigned to: David Chelimsky (dchelimsky) >Summary: Problem with "nil" in failure messages raised from the Not class Initial Comment: The failure messages raised from the not class contains a "nil", because the expected value gets not passed as the second argument to default_message(). try: "1.should_not == 1" which results in "1 should not == 1 nil" see patch #8235, which contains exploit and fix: http://rubyforge.org/tracker/index.php?func=detail&aid=8235&group_id=797&atid=3151 Tobias ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-01-30 03:15 Message: The messages are all being reworked right now in order to make them all more consistent and available to the diff functionality. This bug is already addressed by that change as of rev 1442. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=8236&group_id=797 From noreply at rubyforge.org Mon Jan 29 22:20:36 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 29 Jan 2007 22:20:36 -0500 (EST) Subject: [rspec-devel] [ rspec-Feature Requests-6807 ] port assert_select Message-ID: <20070130032036.3263552433C6@rubyforge.org> Feature Requests item #6807, was opened at 2006-11-21 19:27 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6807&group_id=797 Category: rails plugin Group: None >Status: Closed Priority: 3 Submitted By: David Chelimsky (dchelimsky) Assigned to: David Chelimsky (dchelimsky) Summary: port assert_select Initial Comment: Add an rspec implementation of assert_select. Need to decide whether to just duplicate existing API (using repsonse.should_have?????) or actually devise a more integrated API like this: repsonse.should_include(:form).with(:action => "blah") or response.should_include(:form).with do |form| form.should_include(:input).with(:name => 'age', :type => 'text') end or some such. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-01-30 03:20 Message: This was finished a few revs back (currently at 1442) - there is now support for: response.should have_tag response.should be_rjs response.should be_feed response.should send_email See rdocs for Spec::Rails::Matchers for more information. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-01-19 13:00 Message: We can't use it as/is because it's all bound to test/unit. Right now there are 2 different implementations in the trunk. Over the next few days I'll clean this all up, doc it, and all will be right w/ the world. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-01-19 10:15 Message: AFAICT assert_select is part of Rails core now. Can't we just use that? It seems like a lot of work to maintain our own. What's really missing now is doco on how to use this. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-12-13 10:43 Message: This is working w/ 1.2.0 and edge(5717) as of rspec rev 1286. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-12-08 22:00 Message: I checked in a preliminary port (rev 1276). It only works w/ 1.1.6 right now, but it works just like assert_select for everything except rjs: response.should_have (for tags w/ x-path like syntax) response.should_have_encoded response.should_have_email response.should_have_feed Remaining TODO: Get it to work w/ 1.2.0 and edge Figure out what to do about rjs (need a name other than should_have_rjs) Clean up the docs ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-22 13:00 Message: Josh - a plugin would be great. Could you use should_have instead of should_select (which doesn't really mean anything in this context): response.should_have "form>input[name=age][type=text]" I'm assuming you've got this implemented on ResponseBody, so there should be no conflict w/ Should#have. ---------------------------------------------------------------------- Comment By: Josh Chisholm (joshchisholm) Date: 2006-11-22 09:48 Message: I implemented a basic response.should_select by mixing in scrAPI. Haven't brought it up to date with rspec 0.72 yet, but I will if someone advises the best way to do so (assuming we don't want a scrAPI dependency in rspec core? - a plugin??). > The third seems to promote really detailed expectations about the HTML, and I think that way lies madness. If I understand correcly the second example implies the form has a child (somewhere unspecified) with certain specified attributes. I don't find this too detailed and if I remember correctly this can be done with a single selector: response.should_select "form>input[name=age][type=text]" This syntax is all I have needed so far. ---------------------------------------------------------------------- Comment By: Wilson Bilkovich (wilson) Date: 2006-11-21 22:43 Message: I like the: repsonse.should_include(:form).with(:action => "blah") version, myself. The third seems to promote really detailed expectations about the HTML, and I think that way lies madness. If someone writes the specs for it, I will code it. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6807&group_id=797 From noreply at rubyforge.org Mon Jan 29 22:21:37 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 29 Jan 2007 22:21:37 -0500 (EST) Subject: [rspec-devel] [ rspec-Feature Requests-5634 ] support custom expectations Message-ID: <20070130032137.183A352433C6@rubyforge.org> Feature Requests item #5634, was opened at 2006-09-05 13:27 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=5634&group_id=797 Category: None Group: None >Status: Closed Priority: 3 Submitted By: David Chelimsky (dchelimsky) >Assigned to: David Chelimsky (dchelimsky) Summary: support custom expectations Initial Comment: Add a simple hook/API/whatever to allow people to easily build their own custom expectations. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-01-30 03:21 Message: Done as of long before 1442! See rdoc for Spec::Expectations::Matchers for more information. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-10-26 16:19 Message: Makes sense ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-10-26 16:00 Message: To clarify that last comment - this would still require monkey patching, but it would officially document a class to monkey patch that we would commit to maintain (in name). ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-10-26 15:56 Message: I prefer not to encourage monkey patching because it binds rspec's structure to specs outside our control. For example, I recently changed Spec::ShouldHelper and Spec::ShouldNegator to Spec::Expectations::Should and Spec::Expectations::Not respectively. This would break anyone's specs if they were monkey patching. I'm more inclined to expose a class specifically intended as a hook: Spec::CustomExpectations and have rspec look to that class to see if its instances respond to the method in question. That make sense? ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-09-08 17:48 Message: What about Ruby's monkeypathing feature? Just add methods to Spec::ShouldHelper and Spec::ShuoldNegator? I think this is just a matter of documentation. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=5634&group_id=797 From noreply at rubyforge.org Mon Jan 29 22:32:18 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 29 Jan 2007 22:32:18 -0500 (EST) Subject: [rspec-devel] [ rspec-Patches-8235 ] Fixes problem with " nil" in failure messages raised from the Not class Message-ID: <20070130033218.A635352433D3@rubyforge.org> Patches item #8235, was opened at 2007-01-29 00:22 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=8235&group_id=797 Category: expectation module Group: None >Status: Closed >Resolution: Accepted Priority: 3 Submitted By: Tobias Grimm (e-tobi) Assigned to: David Chelimsky (dchelimsky) Summary: Fixes problem with "nil" in failure messages raised from the Not class Initial Comment: The failure messages raised from the not class contain a "nil", because the expected values gets not passed as the second argument to default_message(). ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-01-30 03:32 Message: Duplicate of 8236, which was fixed as of rev 1442. ---------------------------------------------------------------------- Comment By: Tobias Grimm (e-tobi) Date: 2007-01-29 09:26 Message: Ok,here it is uncompressed. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-01-29 03:24 Message: For some unknown reason I can't open that file. Would you please upload it uncompressed? Thx ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=8235&group_id=797 From noreply at rubyforge.org Tue Jan 30 02:04:42 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 30 Jan 2007 02:04:42 -0500 (EST) Subject: [rspec-devel] [ rspec-Patches-8303 ] :nil_object option for mocks Message-ID: <20070130070442.95C4652433ED@rubyforge.org> Patches item #8303, was opened at 2007-01-30 07:04 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=8303&group_id=797 Category: mock module Group: None Status: Open Resolution: None Priority: 3 Submitted By: Chris Anderson (jchris) Assigned to: Nobody (None) Summary: :nil_object option for mocks Initial Comment: A nil object returns nil (rather than itself) for any methods which aren't stubbed. This is useful if you are going to send something into views, and don't care how it renders, but don't want errors. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=8303&group_id=797 From noreply at rubyforge.org Tue Jan 30 07:18:04 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 30 Jan 2007 07:18:04 -0500 (EST) Subject: [rspec-devel] [ rspec-Patches-8303 ] :nil_object option for mocks Message-ID: <20070130121804.69BE45243093@rubyforge.org> Patches item #8303, was opened at 2007-01-30 02:04 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=8303&group_id=797 Category: mock module Group: None Status: Open Resolution: None Priority: 3 Submitted By: Chris Anderson (jchris) Assigned to: Nobody (None) Summary: :nil_object option for mocks Initial Comment: A nil object returns nil (rather than itself) for any methods which aren't stubbed. This is useful if you are going to send something into views, and don't care how it renders, but don't want errors. ---------------------------------------------------------------------- >Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-01-30 07:18 Message: The term "null object" refers to a design pattern (google it). There is no "nil object" design pattern. I'm a little concerned that the presence of :null_object and :nil_object may be confusing for users since they sound so similar. One is the implementation of a design pattern, the other is ehm, something else. Can we come up with a less confusing name? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=8303&group_id=797 From noreply at rubyforge.org Tue Jan 30 11:20:57 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 30 Jan 2007 11:20:57 -0500 (EST) Subject: [rspec-devel] [ rspec-Feature Requests-8315 ] File "Go to..." functionality Message-ID: <20070130162057.3E8FA52430C6@rubyforge.org> Feature Requests item #8315, was opened at 2007-01-30 08: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: Open 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. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=8315&group_id=797 From noreply at rubyforge.org Tue Jan 30 12:09:38 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 30 Jan 2007 12:09:38 -0500 (EST) Subject: [rspec-devel] [ rspec-Patches-8303 ] :nil_object option for mocks Message-ID: <20070130170938.3B04852430CF@rubyforge.org> Patches item #8303, was opened at 2007-01-30 07:04 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=8303&group_id=797 Category: mock module Group: None Status: Open Resolution: None Priority: 3 Submitted By: Chris Anderson (jchris) Assigned to: Nobody (None) Summary: :nil_object option for mocks Initial Comment: A nil object returns nil (rather than itself) for any methods which aren't stubbed. This is useful if you are going to send something into views, and don't care how it renders, but don't want errors. ---------------------------------------------------------------------- >Comment By: Chris Anderson (jchris) Date: 2007-01-30 17:09 Message: I've been using nil objects as an implementation in Ruby of the null object pattern for a while now. Both approaches have their uses, depending on the client code. You're right, the RSpec API for the nil object could have a more transparent usage that reflects its status as a variant on the null object pattern. Maybe as an alternative value for :null_object. My first thought would be mock('returns nil for all unstubbed methods', :null_object => :returns_nil) This keeps the surface area of mocks down, and presents the "nil object" as a special case of null object. Thoughts? Should I bring this up on the mailing list? Once we figure out the API, I'll be happy to provide a patch. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-01-30 12:18 Message: The term "null object" refers to a design pattern (google it). There is no "nil object" design pattern. I'm a little concerned that the presence of :null_object and :nil_object may be confusing for users since they sound so similar. One is the implementation of a design pattern, the other is ehm, something else. Can we come up with a less confusing name? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=8303&group_id=797 From noreply at rubyforge.org Tue Jan 30 12:19:59 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 30 Jan 2007 12:19:59 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-8238 ] spec route generation in Rails trunk Message-ID: <20070130172000.8547652430E3@rubyforge.org> Bugs item #8238, was opened at 2007-01-29 01:47 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=8238&group_id=797 Category: rails plugin Group: None >Status: Closed >Resolution: Out of Date Priority: 3 Submitted By: Chris Anderson (jchris) Assigned to: Nobody (None) Summary: spec route generation in Rails trunk Initial Comment: Route-generation in specs is broken as of Rails trunk r6062. With Rails r6061, all specs pass, but in 6062 I get a trace like this every time my controller generates a route: TypeError in 'Requesting /artists/1 using PUT should redirect to the artist' can't convert Fixnum into String (eval):19:in `artist_url' /Users/jchris/ruby/rails/grabbit/config/../app/controllers/artists_controller.rb:59:in `update' /Users/jchris/ruby/rails/grabbit/config/../app/controllers/artists_controller.rb:56:in `update' ./spec/controllers/artists_controller_spec.rb:267:in `do_update' ./spec/controllers/artists_controller_spec.rb:287: The issue affects both RSpec and RSpec on Rails at revision 1359 and 1440. Parallel Test::Unit tests aren't showing any signs of breakage. ---------------------------------------------------------------------- >Comment By: Chris Anderson (jchris) Date: 2007-01-30 17:19 Message: turns out to be an issue with the spec resource generator ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=8238&group_id=797 From noreply at rubyforge.org Tue Jan 30 12:24:11 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 30 Jan 2007 12:24:11 -0500 (EST) Subject: [rspec-devel] [ rspec-Patches-8316 ] to_param should return a stringified key in resource generator's controller spec Message-ID: <20070130172411.A80B252430DE@rubyforge.org> Patches item #8316, was opened at 2007-01-30 17:24 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=8316&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Chris Anderson (jchris) Assigned to: Nobody (None) Summary: to_param should return a stringified key in resource generator's controller spec Initial Comment: Rails expects a string here, raising errors like: TypeError in 'Requesting /venues using POST should create a new venue' can't convert Fixnum into String (eval):19:in `venue_url' when given a Fixnum param. This patch simply adds a few quote marks to the rspec resource generator's controller spec template. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=8316&group_id=797 From noreply at rubyforge.org Tue Jan 30 13:38:39 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 30 Jan 2007 13:38:39 -0500 (EST) Subject: [rspec-devel] [ rspec-Patches-8316 ] to_param should return a stringified key in resource generator's controller spec Message-ID: <20070130183839.40DD75243102@rubyforge.org> Patches item #8316, was opened at 2007-01-30 17:24 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=8316&group_id=797 >Category: rails plugin Group: None >Status: Closed >Resolution: Accepted Priority: 3 Submitted By: Chris Anderson (jchris) >Assigned to: David Chelimsky (dchelimsky) Summary: to_param should return a stringified key in resource generator's controller spec Initial Comment: Rails expects a string here, raising errors like: TypeError in 'Requesting /venues using POST should create a new venue' can't convert Fixnum into String (eval):19:in `venue_url' when given a Fixnum param. This patch simply adds a few quote marks to the rspec resource generator's controller spec template. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-01-30 18:38 Message: Applied in rev 1445 ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=8316&group_id=797 From noreply at rubyforge.org Tue Jan 30 13:43:40 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 30 Jan 2007 13:43:40 -0500 (EST) Subject: [rspec-devel] [ rspec-Patches-8303 ] :nil_object option for mocks Message-ID: <20070130184340.C0A0152430D0@rubyforge.org> Patches item #8303, was opened at 2007-01-30 07:04 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=8303&group_id=797 Category: mock module Group: None Status: Open Resolution: None Priority: 3 Submitted By: Chris Anderson (jchris) Assigned to: Nobody (None) Summary: :nil_object option for mocks Initial Comment: A nil object returns nil (rather than itself) for any methods which aren't stubbed. This is useful if you are going to send something into views, and don't care how it renders, but don't want errors. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-01-30 18:43 Message: Why don't you go ahead and float this on the lists. I like the idea in general, though there's no syntax for it that is standing out for me at the moment. Cheers, David ---------------------------------------------------------------------- Comment By: Chris Anderson (jchris) Date: 2007-01-30 17:09 Message: I've been using nil objects as an implementation in Ruby of the null object pattern for a while now. Both approaches have their uses, depending on the client code. You're right, the RSpec API for the nil object could have a more transparent usage that reflects its status as a variant on the null object pattern. Maybe as an alternative value for :null_object. My first thought would be mock('returns nil for all unstubbed methods', :null_object => :returns_nil) This keeps the surface area of mocks down, and presents the "nil object" as a special case of null object. Thoughts? Should I bring this up on the mailing list? Once we figure out the API, I'll be happy to provide a patch. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-01-30 12:18 Message: The term "null object" refers to a design pattern (google it). There is no "nil object" design pattern. I'm a little concerned that the presence of :null_object and :nil_object may be confusing for users since they sound so similar. One is the implementation of a design pattern, the other is ehm, something else. Can we come up with a less confusing name? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=8303&group_id=797 From noreply at rubyforge.org Tue Jan 30 17:34:29 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 30 Jan 2007 17:34:29 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-8302 ] Strange side effect when mocking a class method Message-ID: <20070130223429.CA37B5243146@rubyforge.org> Bugs item #8302, was opened at 2007-01-30 02:35 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=8302&group_id=797 Category: mock module Group: None >Status: Closed >Resolution: Accepted Priority: 3 Submitted By: Tobias Grimm (e-tobi) >Assigned to: David Chelimsky (dchelimsky) Summary: Strange side effect when mocking a class method Initial Comment: Hi! This one is really driving me mad: class Foo def Foo.bar(arg) end end context "Context" do specify "spec 1" do Foo.should_not_receive(:bar).with(Array.new) end specify "spec 2" do Foo.bar(Array.new) end end Running these specs results in this failure: ArgumentError in 'Context 1 spec 1.2' wrong number of arguments (0 for 1) ./xxx_controller_spec.rb:14:in `bar' ./xxx_controller_spec.rb:14:in `bar' ./xxx_controller_spec.rb:12: Finished in 0.002342 seconds If I comment out the mocking of bar() in spec 1 it works. If I pass a string instead of an empty array in spec 1.2 it works too. I also can add a default value for the arg parameter in bar() and it will work. But in the above constellation, it doesn't work. Maybe there's something going wrong with the define_method() call in the MockHandler class, that puts the original method of the mocked class back in place. This might also be a Ruby bug - I'm not sure. Any ideas? bye, Tobias ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-01-30 22:34 Message: Turns out that this is a problem for instance methods as well - we just never noticed it because typically each spec is dealing with its own instances. Whether or not this is a Ruby bug is hard to say. We had been storing proxied methods in a Hash w/ the method name as a key and then restoring them back to the object. The fix, which inadvertently also fixed bug 7611, was to use alias_method on the way in and out. In other words, based on your example above, when you call: Foo.should_receive(:bar) the MockHandler is now aliasing :bar with :bar__proxied_by_rspec (using alias_method, so it actually makes a copy) and redefining :bar to intercept calls. When the spec is over, the alias is reversed and the munged name is removed. Fixed in rev 1447 ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=8302&group_id=797 From noreply at rubyforge.org Tue Jan 30 17:34:38 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 30 Jan 2007 17:34:38 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-7611 ] Partial Mocks override Subclass methods Message-ID: <20070130223439.0E8135243147@rubyforge.org> Bugs item #7611, was opened at 2007-01-06 00:35 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=7611&group_id=797 >Category: mock module Group: None >Status: Closed >Resolution: Accepted Priority: 3 Submitted By: Brian Takita (btakita) >Assigned to: David Chelimsky (dchelimsky) Summary: Partial Mocks override Subclass methods Initial Comment: Here is a quick error case that is order dependent. The first spec must run first. I'll post a better spec later. require "rubygems" require "spec" class Foo end class Bar < Foo end context "A Partial Mock" do specify "should respect subclasses" do Foo.stub!(:new).and_return(Object.new) end specify "should" do Bar.new.class.should == Bar end end # output .F 1) 'A Partial Mock should' FAILED Foo should == Bar /home/btakita/workspace/scratch/lib/bdd/partial_mock_subclass_bug.rb:17: /home/btakita/workspace/scratch/lib/bdd/partial_mock_subclass_bug.rb:11: Finished in 0.001406 seconds 2 specifications, 1 failure ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-01-30 22:34 Message: Fixed in rev 1447 ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=7611&group_id=797 From noreply at rubyforge.org Tue Jan 30 18:27:51 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 30 Jan 2007 18:27:51 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-8302 ] Strange side effect when mocking a class method Message-ID: <20070130232751.8CABC5243154@rubyforge.org> Bugs item #8302, was opened at 2007-01-30 02:35 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=8302&group_id=797 Category: mock module Group: None Status: Closed Resolution: Accepted Priority: 3 Submitted By: Tobias Grimm (e-tobi) Assigned to: David Chelimsky (dchelimsky) Summary: Strange side effect when mocking a class method Initial Comment: Hi! This one is really driving me mad: class Foo def Foo.bar(arg) end end context "Context" do specify "spec 1" do Foo.should_not_receive(:bar).with(Array.new) end specify "spec 2" do Foo.bar(Array.new) end end Running these specs results in this failure: ArgumentError in 'Context 1 spec 1.2' wrong number of arguments (0 for 1) ./xxx_controller_spec.rb:14:in `bar' ./xxx_controller_spec.rb:14:in `bar' ./xxx_controller_spec.rb:12: Finished in 0.002342 seconds If I comment out the mocking of bar() in spec 1 it works. If I pass a string instead of an empty array in spec 1.2 it works too. I also can add a default value for the arg parameter in bar() and it will work. But in the above constellation, it doesn't work. Maybe there's something going wrong with the define_method() call in the MockHandler class, that puts the original method of the mocked class back in place. This might also be a Ruby bug - I'm not sure. Any ideas? bye, Tobias ---------------------------------------------------------------------- >Comment By: Tobias Grimm (e-tobi) Date: 2007-01-30 23:27 Message: Thanks a million! I've tested the last revision and it works fine now! ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-01-30 22:34 Message: Turns out that this is a problem for instance methods as well - we just never noticed it because typically each spec is dealing with its own instances. Whether or not this is a Ruby bug is hard to say. We had been storing proxied methods in a Hash w/ the method name as a key and then restoring them back to the object. The fix, which inadvertently also fixed bug 7611, was to use alias_method on the way in and out. In other words, based on your example above, when you call: Foo.should_receive(:bar) the MockHandler is now aliasing :bar with :bar__proxied_by_rspec (using alias_method, so it actually makes a copy) and redefining :bar to intercept calls. When the spec is over, the alias is reversed and the munged name is removed. Fixed in rev 1447 ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=8302&group_id=797 From noreply at rubyforge.org Tue Jan 30 18:56:05 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 30 Jan 2007 18:56:05 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-8165 ] Partial Mock Errors when respond_to? is true but the method is not in the object Message-ID: <20070130235605.217E8524314D@rubyforge.org> Bugs item #8165, was opened at 2007-01-26 02:59 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=8165&group_id=797 >Category: mock module Group: None >Status: Closed >Resolution: Accepted Priority: 3 Submitted By: Brian Takita (btakita) >Assigned to: David Chelimsky (dchelimsky) Summary: Partial Mock Errors when respond_to? is true but the method is not in the object Initial Comment: Unfortunately, this happens with ActiveRecord until #define_read_methods is called. dir = File.dirname(__FILE__) require "#{dir}/spec_helper" context "An object where respond_to? is true and does not have method" do specify "should not raise an exception" do obj = Object.new obj.should_receive(:respond_to?).with(:foobar).and_return(true) obj.should_receive(:foobar).and_return(:baz) obj.foobar.should == :baz end end Here is an ActiveRecord case: context "An object where respond_to? is true and does not have method" do specify "should not raise an exception" do obj = Person.new obj.should_receive(:respond_to?).with(:foobar).and_return(true) obj.should_receive(:foobar).and_return(:baz) obj.foobar.should == :baz end end ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-01-30 23:56 Message: The problem was that MockHandler uses :respond_to? to decide whether or not to proxy a method. Since the spec says "respond true to respond_to?(:foobar), the object tells MockHandler "yes, I do respond to :foobar" so MockHandler tries to proxy it. Since the object LIED (because the spec told it to), it threw an error when MockHandler tried to alias the non-existent :foobar method. Fixed in rev 1449. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=8165&group_id=797 From noreply at rubyforge.org Tue Jan 30 19:04:03 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 30 Jan 2007 19:04:03 -0500 (EST) Subject: [rspec-devel] [ rspec-Feature Requests-6178 ] should_return Message-ID: <20070131000403.DFC59524314B@rubyforge.org> Feature Requests item #6178, was opened at 2006-10-16 11:18 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6178&group_id=797 Category: None Group: None Status: Open Priority: 3 Submitted By: David Chelimsky (dchelimsky) Assigned to: David Chelimsky (dchelimsky) Summary: should_return Initial Comment: I'd like to add should_return as an alias for should_equal for lambdas: lambda { expression }.should_return value reads more intuitively than lambda { expression }.should_equal value ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-01-31 00:04 Message: And now it should probably be... lambda { expression }.should return_value(value) Or maybe we should just kill the idea? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-08 22:46 Message: Yes. This was initially submitted a while back. So... lambda { expression }.should_return value reads more intuitively than lambda { expression }.should_eql value or lambda { expression }.should == value ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-08 22:37 Message: I think you mean an alias for should_eql or should == ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6178&group_id=797 From noreply at rubyforge.org Tue Jan 30 19:05:13 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 30 Jan 2007 19:05:13 -0500 (EST) Subject: [rspec-devel] [ rspec-Feature Requests-6651 ] Ability to query whether a spec has failed or not in teardown Message-ID: <20070131000514.0C46A52414DA@rubyforge.org> Feature Requests item #6651, was opened at 2006-11-13 18:39 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6651&group_id=797 Category: None Group: None Status: Open Priority: 3 Submitted By: Aslak Helles?y (aslak_hellesoy) Assigned to: Aslak Helles?y (aslak_hellesoy) Summary: Ability to query whether a spec has failed or not in teardown Initial Comment: I'm using RSpec to drive Watir. When a spec fails, I want to take a screenshot before closing the browser in teardown. (Screenshotting is supported by Watir). Example: teardown do if failed? screenshot_file_name = "#{context_name} #{spec_name}.jpg".gsub!(/\s/, "_") screen_capture(screenshot, true) end @ie.close end 3 new methods that need to be available in teardown: failed? context_name spec_name ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-01-31 00:05 Message: Aslak - did this one got resolved w/ the addition of callbacks? If so, can we kill it? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6651&group_id=797 From noreply at rubyforge.org Tue Jan 30 19:18:02 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 30 Jan 2007 19:18:02 -0500 (EST) Subject: [rspec-devel] [ rspec-Patches-8316 ] to_param should return a stringified key in resource generator's controller spec Message-ID: <20070131001802.9F70B524311B@rubyforge.org> Patches item #8316, was opened at 2007-01-31 01:24 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=8316&group_id=797 Category: rails plugin Group: None Status: Closed Resolution: Accepted Priority: 3 Submitted By: Chris Anderson (jchris) Assigned to: David Chelimsky (dchelimsky) Summary: to_param should return a stringified key in resource generator's controller spec Initial Comment: Rails expects a string here, raising errors like: TypeError in 'Requesting /venues using POST should create a new venue' can't convert Fixnum into String (eval):19:in `venue_url' when given a Fixnum param. This patch simply adds a few quote marks to the rspec resource generator's controller spec template. ---------------------------------------------------------------------- Comment By: Deepak Jois (deepakjois) Date: 2007-01-31 08:18 Message: A similar patch needs to be applied to the view spec generators too.. Index: show_rhtml_spec.rb =================================================================== --- show_rhtml_spec.rb (revision 136) +++ show_rhtml_spec.rb (working copy) @@ -5,7 +5,7 @@ setup do @<%= file_name %> = mock("<%= file_name %>") - @<%= file_name %>.stub!(:to_param).and_return(99) + @<%= file_name %>.stub!(:to_param).and_return("99") @<%= file_name %>.stub!(:errors).and_return(@errors)<% for attribute in attributes -%> @<%= file_name %>.should_receive(:<%= attribute.name %>).and_return(<%= attribute.default_value %>)<% end -%> Index: edit_rhtml_spec.rb =================================================================== --- edit_rhtml_spec.rb (revision 136) +++ edit_rhtml_spec.rb (working copy) @@ -8,7 +8,7 @@ @errors.stub!(:count).and_return(0) @<%= file_name %> = mock("<%= file_name %>") - @<%= file_name %>.stub!(:to_param).and_return(99) + @<%= file_name %>.stub!(:to_param).and_return("99") @<%= file_name %>.stub!(:errors).and_return(@errors)<% for attribute in attributes -%> @<%= file_name %>.should_receive(:<%= attribute.name %>).and_return(<%= attribute.default_value %>)<% end -%> Index: new_rhtml_spec.rb =================================================================== --- new_rhtml_spec.rb (revision 136) +++ new_rhtml_spec.rb (working copy) @@ -8,7 +8,7 @@ @errors.stub!(:count).and_return(0) @<%= file_name %> = mock("<%= file_name %>") - @<%= file_name %>.stub!(:to_param).and_return(99) + @<%= file_name %>.stub!(:to_param).and_return("99") @<%= file_name %>.stub!(:errors).and_return(@errors)<% for attribute in attributes -%> @<%= file_name %>.should_receive(:<%= attribute.name %>).and_return(<%= attribute.default_value %>)<% end -%> ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-01-31 02:38 Message: Applied in rev 1445 ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=8316&group_id=797 From noreply at rubyforge.org Wed Jan 31 05:18:18 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 31 Jan 2007 05:18:18 -0500 (EST) Subject: [rspec-devel] [ rspec-Feature Requests-6651 ] Ability to query whether a spec has failed or not in teardown Message-ID: <20070131101819.508915242DE3@rubyforge.org> Feature Requests item #6651, was opened at 2006-11-13 13:39 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6651&group_id=797 Category: None Group: None Status: Open Priority: 3 Submitted By: Aslak Helles?y (aslak_hellesoy) Assigned to: Aslak Helles?y (aslak_hellesoy) Summary: Ability to query whether a spec has failed or not in teardown Initial Comment: I'm using RSpec to drive Watir. When a spec fails, I want to take a screenshot before closing the browser in teardown. (Screenshotting is supported by Watir). Example: teardown do if failed? screenshot_file_name = "#{context_name} #{spec_name}.jpg".gsub!(/\s/, "_") screen_capture(screenshot, true) end @ie.close end 3 new methods that need to be available in teardown: failed? context_name spec_name ---------------------------------------------------------------------- >Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-01-31 05:18 Message: I never got it resolved because I couldn't easily figure out how to use the callback stuff (no docs). Further, I realised I didn't really need it. I thought I needed it in spec/ui to decide whether or not to take a screenshot (for failing specs), but realized I can always take a screenshot in teardown, regardless of whether the spec failed. Therefore, I'm not sure we need the callback stuff at all in RSpec - it doesn't seem to solve any real problems - at least not that I'm aware of. As far as I am concerned it is a non-feature because it's not documented. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-01-30 19:05 Message: Aslak - did this one got resolved w/ the addition of callbacks? If so, can we kill it? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6651&group_id=797 From noreply at rubyforge.org Wed Jan 31 07:32:27 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 31 Jan 2007 07:32:27 -0500 (EST) Subject: [rspec-devel] [ rspec-Feature Requests-6651 ] Ability to query whether a spec has failed or not in teardown Message-ID: <20070131123227.33C9D5242E14@rubyforge.org> Feature Requests item #6651, was opened at 2006-11-13 18:39 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6651&group_id=797 Category: None Group: None Status: Open Priority: 3 Submitted By: Aslak Helles?y (aslak_hellesoy) Assigned to: Aslak Helles?y (aslak_hellesoy) Summary: Ability to query whether a spec has failed or not in teardown Initial Comment: I'm using RSpec to drive Watir. When a spec fails, I want to take a screenshot before closing the browser in teardown. (Screenshotting is supported by Watir). Example: teardown do if failed? screenshot_file_name = "#{context_name} #{spec_name}.jpg".gsub!(/\s/, "_") screen_capture(screenshot, true) end @ie.close end 3 new methods that need to be available in teardown: failed? context_name spec_name ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-01-31 12:32 Message: It's not doc'd on the website because it's not really an RSpec feature. It's a library that we've forked into RSpec in order to avoid the dependency. There is rdoc in the callback dirs - check it out and see if you find it sufficient or not. That said, Brian, can you please enlighten us as to how to use the before_setup and after_teardown callbacks to solve Aslak's seemingly-former-problem. Thanks, David ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-01-31 10:18 Message: I never got it resolved because I couldn't easily figure out how to use the callback stuff (no docs). Further, I realised I didn't really need it. I thought I needed it in spec/ui to decide whether or not to take a screenshot (for failing specs), but realized I can always take a screenshot in teardown, regardless of whether the spec failed. Therefore, I'm not sure we need the callback stuff at all in RSpec - it doesn't seem to solve any real problems - at least not that I'm aware of. As far as I am concerned it is a non-feature because it's not documented. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-01-31 00:05 Message: Aslak - did this one got resolved w/ the addition of callbacks? If so, can we kill it? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6651&group_id=797 From noreply at rubyforge.org Wed Jan 31 07:51:39 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 31 Jan 2007 07:51:39 -0500 (EST) Subject: [rspec-devel] [ rspec-Patches-8332 ] [PATCH] Update views documentation Message-ID: <20070131125139.C8A455242E16@rubyforge.org> Patches item #8332, was opened at 2007-01-31 12:51 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=8332&group_id=797 Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: Jerry West (jjw) Assigned to: Nobody (None) Summary: [PATCH] Update views documentation Initial Comment: Add section to views documentation (http://rspec.rubyforge.org/documentation/rails/writing/views.html) describing use of flash[:key]. Patch (diff -c) attached. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=8332&group_id=797 From noreply at rubyforge.org Wed Jan 31 15:54:23 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 31 Jan 2007 15:54:23 -0500 (EST) Subject: [rspec-devel] [ rspec-Feature Requests-6515 ] Couple GET and POST phases of forms Message-ID: <20070131205423.F09F25242EAA@rubyforge.org> Feature Requests item #6515, was opened at 2006-11-06 16:28 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6515&group_id=797 Category: rails plugin Group: None >Status: Closed Priority: 3 Submitted By: Jay Levitt (jaylev) >Assigned to: David Chelimsky (dchelimsky) Summary: Couple GET and POST phases of forms Initial Comment: I'd love to be able to do things like this plugin does for standard Rails tests: http://www.jasongarber.com/articles/2006/10/24/easier-testing-of-forms-form_test_helper In a nutshell, it finally closes the loop between "the empty form sent by a get" and "the filled-in form returned on a post". Instead of blindly posting parameters, you're now actually filling in form fields in the tests. Works with hidden fields and everything, too. It'd be nice to see rspec do something like that. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-01-31 20:54 Message: Got one better for you - I just committed a change to rspec on rails so that you can use test/unit assertions in your rails specs. This means that form_test_helper is accessible as/is from your specs - you just need to install the plugin. Cheers, David ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6515&group_id=797