From noreply at rubyforge.org Sun Apr 1 08:12:29 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 1 Apr 2007 08:12:29 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-9282 ] Change to allow running specs from textmate with rspec installed as a rails plugin (and no rspec gem installed) Message-ID: <20070401121229.CBCFF5240AFA@rubyforge.org> Patches item #9282, was opened at 2007-03-14 10:51 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=9282&group_id=797 Category: None Group: None >Status: Closed >Resolution: Accepted Priority: 3 Submitted By: Jonathan Tron (jonathant) >Assigned to: Aslak Helles?y (aslak_hellesoy) Summary: Change to allow running specs from textmate with rspec installed as a rails plugin (and no rspec gem installed) Initial Comment: I changed all require call to use a full path based on File.dirname(__FILE__). I modified the spec_mate.rb of RSpec.tmbundle to look for rspec as a rails plugins (check if ENV['TM_PROJECT_DIRECTORY'] and ENV['TM_PROJECT_DIRECTORY']/vendor/plugins/rspec/lib/rspec.rb are present) and fallback to a simple require 'spec'. ---------------------------------------------------------------------- >Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-04-01 08:12 Message: Fixed in branches/0.9-dev#1671 (with a simpler fix - see attached patch) ---------------------------------------------------------------------- Comment By: Jonathan Tron (jonathant) Date: 2007-03-14 11:58 Message: I tried to use "$:.unshift" method first, but I had some trouble with files not loading correctly (I confess not having searched to far to identified the problem). So I choosed to go the way it is done in rspec_on_rails plugin. If you prefer I think I could have a second look for the "clean" solution by tomorrow. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-03-14 11:17 Message: I like the idea, but your patch modifies a bunch of require statements in RSpec core. Is that really necessary? Wouldn't it be better to use LOAD_PATH and avoid all of these ugly absolute paths everywhere? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=9282&group_id=797 From noreply at rubyforge.org Sun Apr 1 10:04:52 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 1 Apr 2007 10:04:52 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-9375 ] play nice w/ mocha and/or flexmock and/or any other mocking framework Message-ID: <20070401140453.06F805240942@rubyforge.org> Feature Requests item #9375, was opened at 2007-03-19 12:37 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=9375&group_id=797 Category: mock module Group: None >Status: Closed Priority: 3 Submitted By: David Chelimsky (dchelimsky) Assigned to: David Chelimsky (dchelimsky) Summary: play nice w/ mocha and/or flexmock and/or any other mocking framework Initial Comment: Right now you can use rspec w/ other frameworks but you have to go through some hoops. You should be able to do something as simple as require 'mocha' or require 'flexmock' to invoke either. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-04-01 14:04 Message: Added support for using mocha in branches/0.9-dev. Will be released w/ 0.9. To use this feature, you'll do this: Spec::Runner.configure do |config| config.mock_with :mocha end Opening a separate RFE to add support for flexmock ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=9375&group_id=797 From noreply at rubyforge.org Sun Apr 1 10:06:18 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 1 Apr 2007 10:06:18 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-9735 ] support flexmock Message-ID: <20070401140619.0417A52409AD@rubyforge.org> Feature Requests item #9735, was opened at 2007-04-01 14:06 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=9735&group_id=797 Category: runner module Group: None Status: Open Priority: 3 Submitted By: David Chelimsky (dchelimsky) Assigned to: David Chelimsky (dchelimsky) Summary: support flexmock Initial Comment: RSpec-0.9 will support using mocha instead of Spec::Mocks (for those who choose) by doing the following: Spec::Runner.configure do |config| config.mock_with :mocha end We should add the same support for flexmock. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=9735&group_id=797 From noreply at rubyforge.org Sun Apr 1 10:08:07 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 1 Apr 2007 10:08:07 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-6523 ] Run rspec on rails without a db Message-ID: <20070401140807.2689552409AD@rubyforge.org> Feature Requests item #6523, was opened at 2006-11-06 21:07 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6523&group_id=797 Category: None Group: None Status: Open Priority: 3 Submitted By: Paul Pagel (paulwpagel) Assigned to: Nobody (None) Summary: Run rspec on rails without a db Initial Comment: We need to be able to run the specs without the database. We have no model objects in some of our projects, therefore, no use for the db. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-04-01 14:08 Message: Now that we have a cleaner configuration model, we should add a configuration option to do this: Spec::Runner.configure do |config| config.use_database = false end (or something like that) ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-07 01:28 Message: How do I reproduce this missing feature? How would you like it to work exactly? Code please. http://rspec.rubyforge.org/contribute.html ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6523&group_id=797 From noreply at rubyforge.org Sun Apr 1 10:12:39 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 1 Apr 2007 10:12:39 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-6550 ] Mix in several modules and do it in one place only Message-ID: <20070401141239.7FA4C52409AD@rubyforge.org> Feature Requests item #6550, was opened at 2006-11-08 02:01 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6550&group_id=797 >Category: runner module Group: None >Status: Closed Priority: 3 Submitted By: Aslak Helles?y (aslak_hellesoy) >Assigned to: David Chelimsky (dchelimsky) Summary: Mix in several modules and do it in one place only Initial Comment: We need a way to mixin several modules and do it in one place only. Like in the spec_helper.rb file used by spec/rails ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-04-01 14:12 Message: Added to branches/0.9-dev (r1637) ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-03-21 15:02 Message: Actually, how about a rails-style initializer/configurator: Spec.configure do |config| config.mock_with :my_favorite_mock_framework config.include MyHelperMethods config.include MyCustomMatchers #for rails config.use_transactional_fixtures = true end This keeps the interface simple, exposes less structure, and let's rspec delegate these configuration options to different parts of the system as necessary. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-03-15 19:05 Message: We have a need to add this soon. Here's what I'm thinking: #in spec_helper.rb module Spec module Config mock_with :my_favorite_mock_framework include MyHelperMethods include MyCustomMatchers end end Everything defined or declared here would impact all specs. We'd make it work the same for Spec::Rails. Sound reasonable? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6550&group_id=797 From noreply at rubyforge.org Sun Apr 1 10:18:38 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 1 Apr 2007 10:18:38 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-8241 ] "no id given" if controller method does not exist Message-ID: <20070401141838.5108B5240AFA@rubyforge.org> Bugs item #8241, was opened at 2007-01-29 03: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: Closed >Resolution: Accepted Priority: 1 Submitted By: Fran?ois Beausoleil (fbos) Assigned to: David Chelimsky (dchelimsky) >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 ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-04-01 14:18 Message: This was fixed when we removed sugar from branches/0.9-dev ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-02-02 12:03 Message: This is a conflict between RSpec's use of method_missing and Rails' use of the same. This will go away in 0.9 when we remove the syntax sugar, at which point you'll get the message you'll expect: No action responded to create I'll leave this open for tracking, but setting it to postponed. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=8241&group_id=797 From noreply at rubyforge.org Sun Apr 1 10:22:15 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 1 Apr 2007 10:22:15 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-9737 ] --colour doesn't work with --drb if defined in spec.opts Message-ID: <20070401142215.399BD5240AFA@rubyforge.org> Bugs item #9737, was opened at 2007-04-01 14:22 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=9737&group_id=797 Category: runner module Group: None Status: Open Resolution: None Priority: 3 Submitted By: David Chelimsky (dchelimsky) Assigned to: Nobody (None) Summary: --colour doesn't work with --drb if defined in spec.opts Initial Comment: You can do this: ./script/spec spec --drb --colour but if you do this: ./script/spec spec -O spec/spec.opts w/ this in spec.opts --drb --colour no dice, amigo. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=9737&group_id=797 From noreply at rubyforge.org Sun Apr 1 10:25:30 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 1 Apr 2007 10:25:30 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-9649 ] Parital mocks don't work if object loaded from fixture, and referenced via association Message-ID: <20070401142530.A190D5240AFA@rubyforge.org> Bugs item #9649, was opened at 2007-03-28 19:44 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=9649&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: Parital mocks don't work if object loaded from fixture, and referenced via association Initial Comment: Hello, The following code will not function properly: spec/fixtures/pages.yml ---------- first: id: 1 type: LockedPage name: the first default page spec/fixtures/questions.yml ---------- first: id: 1 type: LockedQuestion name: the first default question container_id: 1 container_type: LockedPage spec/models/locked_question_spec.rb ---------- context "LockedQuestion#document_session, being linked to a Page that has a Document Session" do fixtures :questions, :pages setup do @question = questions(:first) @page = pages(:first) @page.stub!(:document_session).and_return("the document session") @question.page.should == @page #=> true end specify "should return the Page's Document Session" do @question.document_session.should == "the document session" #=> fails with 'undefined method' end end I would kludge something together by just assigning an unlocked page to the question, but the "Locked" that prefaces these models is a subclass that denies any modifications. Thanks for your help. -Chris ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-04-01 14:25 Message: What's 'undefined method' getting called on? Question or Page? Can you post the backtrace? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=9649&group_id=797 From noreply at rubyforge.org Sun Apr 1 10:27:41 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 1 Apr 2007 10:27:41 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-9311 ] Controller Specs do not play nicely with Markaby and Rxml Message-ID: <20070401142741.0E9FC52409AD@rubyforge.org> Bugs item #9311, was opened at 2007-03-15 21:48 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=9311&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Brian Takita (btakita) Assigned to: Nobody (None) Summary: Controller Specs do not play nicely with Markaby and Rxml Initial Comment: Look in rails/runner/context/controller.rb line 18. If render is called without a block and views are not integrated, ActionView::Base#find_template_extension_for is stubbed to return 'rhtml'. Unfortunately, rails caches this result. When I run a view spec, e.g. render 'foo/bar' and bar is a markaby file (bar.mab), rails uses the cached extension (rhtml) when @@cache_template_extensions is set to true, which it is by default. See ActionView::Base#pick_template_extension ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-04-01 14:27 Message: Brian - we made a change a while back so that cache_template_extensions is turned off by default (when running rspec examples). This can be found in branches/0.9-dev. I *think* that should have solved this problem, yes? If so, please close this. Thanks ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=9311&group_id=797 From noreply at rubyforge.org Sun Apr 1 10:41:47 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 1 Apr 2007 10:41:47 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-9737 ] --colour doesn't work with --drb if defined in spec.opts Message-ID: <20070401144147.3C6445240948@rubyforge.org> Bugs item #9737, was opened at 2007-04-01 14:22 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=9737&group_id=797 Category: runner module Group: None >Status: Closed >Resolution: Rejected Priority: 3 Submitted By: David Chelimsky (dchelimsky) Assigned to: Nobody (None) Summary: --colour doesn't work with --drb if defined in spec.opts Initial Comment: You can do this: ./script/spec spec --drb --colour but if you do this: ./script/spec spec -O spec/spec.opts w/ this in spec.opts --drb --colour no dice, amigo. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-04-01 14:41 Message: Actually - this is only a problem when running w/ rspec_autotest, so nevermind. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=9737&group_id=797 From noreply at rubyforge.org Sun Apr 1 11:24:12 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 1 Apr 2007 11:24:12 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-9649 ] Parital mocks don't work if object loaded from fixture, and referenced via association Message-ID: <20070401152413.01A0B5240956@rubyforge.org> Bugs item #9649, was opened at 2007-03-28 15:44 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=9649&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: Parital mocks don't work if object loaded from fixture, and referenced via association Initial Comment: Hello, The following code will not function properly: spec/fixtures/pages.yml ---------- first: id: 1 type: LockedPage name: the first default page spec/fixtures/questions.yml ---------- first: id: 1 type: LockedQuestion name: the first default question container_id: 1 container_type: LockedPage spec/models/locked_question_spec.rb ---------- context "LockedQuestion#document_session, being linked to a Page that has a Document Session" do fixtures :questions, :pages setup do @question = questions(:first) @page = pages(:first) @page.stub!(:document_session).and_return("the document session") @question.page.should == @page #=> true end specify "should return the Page's Document Session" do @question.document_session.should == "the document session" #=> fails with 'undefined method' end end I would kludge something together by just assigning an unlocked page to the question, but the "Locked" that prefaces these models is a subclass that denies any modifications. Thanks for your help. -Chris ---------------------------------------------------------------------- >Comment By: Chris Hoffman (hoffman_c) Date: 2007-04-01 11:24 Message: Hello, I have created a rails project with the models and spec that reveal the problem. Please let me know if you need additional information. Also, you were indeed correct that the above example would fail for a different reason (if not taking into account the Question model's delegation). I apologize for the confusion. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-01 10:25 Message: What's 'undefined method' getting called on? Question or Page? Can you post the backtrace? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=9649&group_id=797 From noreply at rubyforge.org Sun Apr 1 15:24:49 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 1 Apr 2007 15:24:49 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-8103 ] RSpec not installing spec script correctly Message-ID: <20070401192449.256AD5240B1B@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: Closed >Resolution: Accepted 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 ---------------------------------------------------------------------- >Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-04-01 15:24 Message: Fixed in branches/0.9-dev ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-03-20 04:57 Message: The reason why I'm asking is that rubygems generates files with #!/usr/bin/env ruby in the header - it's not RSpec. I need to know what Rubygems version you are using, and what the path of the said file is (so I can determine whether this is a file made by the RSpec team or the Rubygems program. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-03-20 03:19 Message: Are you talking about the rubygems-generated wrapper script? What's the path of the script you're talking abouth (after installation and in our sources). ---------------------------------------------------------------------- Comment By: Scott Taylor (smtlaissezfaire) Date: 2007-03-20 02:36 Message: What is the best way to get around this? I have a little script which searches the $PATH environment variable for a given name, hence: euclid% find_file_in_path ruby /opt/local/bin /usr/local/bin /usr/bin euclid% find_file_in_path spec /opt/local/bin Would something like this be useful to use? How about for the windows folks? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=8103&group_id=797 From noreply at rubyforge.org Sun Apr 1 17:07:02 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 1 Apr 2007 17:07:02 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-9421 ] --line doesn't work with behaviours that use class names Message-ID: <20070401210702.9C1155240B5B@rubyforge.org> Bugs item #9421, was opened at 2007-03-21 06:11 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=9421&group_id=797 Category: runner module Group: None Status: Open Resolution: None Priority: 4 Submitted By: Aslak Helles?y (aslak_hellesoy) Assigned to: David Chelimsky (dchelimsky) Summary: --line doesn't work with behaviours that use class names Initial Comment: To reproduce, do: ruby bin/spec spec/spec/dsl/behaviour_spec.rb -l 22 Finished in 1.4e-05 seconds 0 examples, 0 failures This is because SpecParser always looks for quotes - it has to be smarter ---------------------------------------------------------------------- >Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-04-01 17:07 Message: Didn't you just fix this? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=9421&group_id=797 From noreply at rubyforge.org Mon Apr 2 03:31:37 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 2 Apr 2007 03:31:37 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-9282 ] Change to allow running specs from textmate with rspec installed as a rails plugin (and no rspec gem installed) Message-ID: <20070402073137.5D8D2A970002@rubyforge.org> Patches item #9282, was opened at 14/03/2007 15:51 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=9282&group_id=797 Category: None Group: None Status: Closed Resolution: Accepted Priority: 3 Submitted By: Jonathan Tron (jonathant) Assigned to: Aslak Helles?y (aslak_hellesoy) Summary: Change to allow running specs from textmate with rspec installed as a rails plugin (and no rspec gem installed) Initial Comment: I changed all require call to use a full path based on File.dirname(__FILE__). I modified the spec_mate.rb of RSpec.tmbundle to look for rspec as a rails plugins (check if ENV['TM_PROJECT_DIRECTORY'] and ENV['TM_PROJECT_DIRECTORY']/vendor/plugins/rspec/lib/rspec.rb are present) and fallback to a simple require 'spec'. ---------------------------------------------------------------------- Comment By: Jonathan Tron (jonathant) Date: 02/04/2007 09:31 Message: Wohh great... thanks for taking the time to do it. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 01/04/2007 14:12 Message: Fixed in branches/0.9-dev#1671 (with a simpler fix - see attached patch) ---------------------------------------------------------------------- Comment By: Jonathan Tron (jonathant) Date: 14/03/2007 16:58 Message: I tried to use "$:.unshift" method first, but I had some trouble with files not loading correctly (I confess not having searched to far to identified the problem). So I choosed to go the way it is done in rspec_on_rails plugin. If you prefer I think I could have a second look for the "clean" solution by tomorrow. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 14/03/2007 16:17 Message: I like the idea, but your patch modifies a bunch of require statements in RSpec core. Is that really necessary? Wouldn't it be better to use LOAD_PATH and avoid all of these ugly absolute paths everywhere? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=9282&group_id=797 From noreply at rubyforge.org Mon Apr 2 06:46:03 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 2 Apr 2007 06:46:03 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-9265 ] [Documentation] These are NOT deprecated. See Spec::Matchers should not be red Message-ID: <20070402104603.58A4B5240BD0@rubyforge.org> Bugs item #9265, was opened at 2007-03-13 19:37 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=9265&group_id=797 Category: expectation module Group: None >Status: Closed >Resolution: Rejected Priority: 3 Submitted By: Brian Takita (btakita) Assigned to: Nobody (None) Summary: [Documentation] These are NOT deprecated. See Spec::Matchers should not be red Initial Comment: It is confusing to see "These are NOT deprecated. See Spec::Matchers" in red text because it looks like it is being deprecated. Perhaps it should be green? ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-04-02 10:46 Message: I'm going to close this - this will not be an issue for long. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-03-21 14:44 Message: I tried changing it to green, but then it gets lost. In a page full of red messages, I want people to see this one so they don't think that the non-deprecated messages are deprecated - and the NOT brings it out for me. Any other suggestions? I'm all for doing something that will make this as clear as possible. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=9265&group_id=797 From noreply at rubyforge.org Mon Apr 2 07:19:56 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 2 Apr 2007 07:19:56 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-9649 ] Parital mocks don't work if object loaded from fixture, and referenced via association Message-ID: <20070402111956.B8C9B5240BD0@rubyforge.org> Bugs item #9649, was opened at 2007-03-28 15:44 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=9649&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: Parital mocks don't work if object loaded from fixture, and referenced via association Initial Comment: Hello, The following code will not function properly: spec/fixtures/pages.yml ---------- first: id: 1 type: LockedPage name: the first default page spec/fixtures/questions.yml ---------- first: id: 1 type: LockedQuestion name: the first default question container_id: 1 container_type: LockedPage spec/models/locked_question_spec.rb ---------- context "LockedQuestion#document_session, being linked to a Page that has a Document Session" do fixtures :questions, :pages setup do @question = questions(:first) @page = pages(:first) @page.stub!(:document_session).and_return("the document session") @question.page.should == @page #=> true end specify "should return the Page's Document Session" do @question.document_session.should == "the document session" #=> fails with 'undefined method' end end I would kludge something together by just assigning an unlocked page to the question, but the "Locked" that prefaces these models is a subclass that denies any modifications. Thanks for your help. -Chris ---------------------------------------------------------------------- >Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-04-02 07:19 Message: Can you confirm that you're not getting the same problem when you use Test::Unit? What are your versions of everything? ---------------------------------------------------------------------- Comment By: Chris Hoffman (hoffman_c) Date: 2007-04-01 11:24 Message: Hello, I have created a rails project with the models and spec that reveal the problem. Please let me know if you need additional information. Also, you were indeed correct that the above example would fail for a different reason (if not taking into account the Question model's delegation). I apologize for the confusion. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-01 10:25 Message: What's 'undefined method' getting called on? Question or Page? Can you post the backtrace? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=9649&group_id=797 From noreply at rubyforge.org Mon Apr 2 07:44:17 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 2 Apr 2007 07:44:17 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-9649 ] Parital mocks don't work if object loaded from fixture, and referenced via association Message-ID: <20070402114417.C2F2B5240BE9@rubyforge.org> Bugs item #9649, was opened at 2007-03-28 15:44 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=9649&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: Parital mocks don't work if object loaded from fixture, and referenced via association Initial Comment: Hello, The following code will not function properly: spec/fixtures/pages.yml ---------- first: id: 1 type: LockedPage name: the first default page spec/fixtures/questions.yml ---------- first: id: 1 type: LockedQuestion name: the first default question container_id: 1 container_type: LockedPage spec/models/locked_question_spec.rb ---------- context "LockedQuestion#document_session, being linked to a Page that has a Document Session" do fixtures :questions, :pages setup do @question = questions(:first) @page = pages(:first) @page.stub!(:document_session).and_return("the document session") @question.page.should == @page #=> true end specify "should return the Page's Document Session" do @question.document_session.should == "the document session" #=> fails with 'undefined method' end end I would kludge something together by just assigning an unlocked page to the question, but the "Locked" that prefaces these models is a subclass that denies any modifications. Thanks for your help. -Chris ---------------------------------------------------------------------- >Comment By: Chris Hoffman (hoffman_c) Date: 2007-04-02 07:44 Message: I am not sure how to do partial mocks with Test::Unit. As far as versions, I have the following: rspec 0.8.2 rails 1.1.2 Is the attached rails application not giving you an error when you run rake spec:models? ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-04-02 07:19 Message: Can you confirm that you're not getting the same problem when you use Test::Unit? What are your versions of everything? ---------------------------------------------------------------------- Comment By: Chris Hoffman (hoffman_c) Date: 2007-04-01 11:24 Message: Hello, I have created a rails project with the models and spec that reveal the problem. Please let me know if you need additional information. Also, you were indeed correct that the above example would fail for a different reason (if not taking into account the Question model's delegation). I apologize for the confusion. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-01 10:25 Message: What's 'undefined method' getting called on? Question or Page? Can you post the backtrace? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=9649&group_id=797 From noreply at rubyforge.org Mon Apr 2 10:11:50 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 2 Apr 2007 10:11:50 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-9605 ] Patch for ER 9472, shared behaviour Message-ID: <20070402141150.B9E1E5240C9F@rubyforge.org> Patches item #9605, was opened at 2007-03-26 22:08 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=9605&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Bob Cotton (bcotton) Assigned to: Nobody (None) Summary: Patch for ER 9472, shared behaviour Initial Comment: I chose behaves_as, as the inclusion method. I don't like the use of the global, behavior_runner, in Behavior to find shared behaviors. Putting the collection on Spec::Runner seemed just as bad. Had to move some methods on module Spec::DSL::BehaviourEval::ModuleMethods from private to protected to faciliate copying things from one EvalModule to another. There are many combinations of include, setup/teardown, context_setup/context_teardown and inherit that are not covered in the shared_behavior spec. Let me know if you want more. Might be a good place for shared behaviors! -Bob ---------------------------------------------------------------------- >Comment By: Bob Cotton (bcotton) Date: 2007-04-02 08:11 Message: Newest version of the patch attached. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-03-28 05:11 Message: I haven't had time to look into this in detail, but it looks interesting. Right now we're trying to get 0.9 out the door, and we're reluctant to add new features before 0.9 is released. Let's revisit this post 0.9 ---------------------------------------------------------------------- Comment By: Bob Cotton (bcotton) Date: 2007-03-27 06:12 Message: Missed the checkbox. Sorry. ---------------------------------------------------------------------- Comment By: Bob Cotton (bcotton) Date: 2007-03-27 06:11 Message: One more thing, rcov is at 100%, but I can't get pre_commit to run. It either runs out of memory, or the stack is too deep. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-03-26 22:16 Message: File please. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-03-26 22:15 Message: Hi Bob - I'll take a look at this tomorrow. Thanks. FYI - the problem you had running pre_commit was due to something we were trying to fix w/ 1.8.6. I reverted the spectask and you can run pre_commit now. ---------------------------------------------------------------------- Comment By: Bob Cotton (bcotton) Date: 2007-03-26 22:10 Message: One more thing, rcov is at 100%, but I can't get pre_commit to run. It either runs out of memory, or the stack is too deep. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=9605&group_id=797 From noreply at rubyforge.org Mon Apr 2 10:23:54 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 2 Apr 2007 10:23:54 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-9649 ] Parital mocks don't work if object loaded from fixture, and referenced via association Message-ID: <20070402142354.50F215240BE9@rubyforge.org> Bugs item #9649, was opened at 2007-03-28 15:44 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=9649&group_id=797 Category: mock module Group: None >Status: Closed >Resolution: Rejected Priority: 3 Submitted By: Chris Hoffman (hoffman_c) >Assigned to: Aslak Helles?y (aslak_hellesoy) Summary: Parital mocks don't work if object loaded from fixture, and referenced via association Initial Comment: Hello, The following code will not function properly: spec/fixtures/pages.yml ---------- first: id: 1 type: LockedPage name: the first default page spec/fixtures/questions.yml ---------- first: id: 1 type: LockedQuestion name: the first default question container_id: 1 container_type: LockedPage spec/models/locked_question_spec.rb ---------- context "LockedQuestion#document_session, being linked to a Page that has a Document Session" do fixtures :questions, :pages setup do @question = questions(:first) @page = pages(:first) @page.stub!(:document_session).and_return("the document session") @question.page.should == @page #=> true end specify "should return the Page's Document Session" do @question.document_session.should == "the document session" #=> fails with 'undefined method' end end I would kludge something together by just assigning an unlocked page to the question, but the "Locked" that prefaces these models is a subclass that denies any modifications. Thanks for your help. -Chris ---------------------------------------------------------------------- >Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-04-02 10:23 Message: Your Rails version is one year old, and the oldest Rails version RSpec is tested against is 1.1.6 (8 months old). It's too much work for us to ensure things work against old Railses, so I'm closing this bug. Feel free to reopen this bug if it still applies to Rails 1.1.6 or 1.2.x. (In the near future we will probably drop support for 1.1.6 though). ---------------------------------------------------------------------- Comment By: Chris Hoffman (hoffman_c) Date: 2007-04-02 07:44 Message: I am not sure how to do partial mocks with Test::Unit. As far as versions, I have the following: rspec 0.8.2 rails 1.1.2 Is the attached rails application not giving you an error when you run rake spec:models? ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-04-02 07:19 Message: Can you confirm that you're not getting the same problem when you use Test::Unit? What are your versions of everything? ---------------------------------------------------------------------- Comment By: Chris Hoffman (hoffman_c) Date: 2007-04-01 11:24 Message: Hello, I have created a rails project with the models and spec that reveal the problem. Please let me know if you need additional information. Also, you were indeed correct that the above example would fail for a different reason (if not taking into account the Question model's delegation). I apologize for the confusion. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-01 10:25 Message: What's 'undefined method' getting called on? Question or Page? Can you post the backtrace? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=9649&group_id=797 From noreply at rubyforge.org Mon Apr 2 10:24:32 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 2 Apr 2007 10:24:32 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-7636 ] drbspec not managing db connections appropriately Message-ID: <20070402142432.9F0B35240BE9@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: Closed >Resolution: Out of Date Priority: 3 Submitted By: Chris Anderson (jchris) >Assigned to: Aslak Helles?y (aslak_hellesoy) 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-02-08 10:23 Message: Chris - is this still giving you grief w/ the current trunk and using --drb? ---------------------------------------------------------------------- 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 Mon Apr 2 10:27:03 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 2 Apr 2007 10:27:03 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-8155 ] rspec clashing with rubyclr Message-ID: <20070402142703.83A6A5240CA6@rubyforge.org> Bugs item #8155, was opened at 2007-01-25 17: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: Aslak Helles?y (aslak_hellesoy) Date: 2007-04-02 10:27 Message: Does this still apply against the branches/0.9-dev/rspec code? ---------------------------------------------------------------------- Comment By: Kevin Williams (kevwil) Date: 2007-01-26 15: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 18: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 Mon Apr 2 10:59:20 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 2 Apr 2007 10:59:20 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-9760 ] rspec generators incompatible with changes to edge rails Message-ID: <20070402145920.95F6F5240CA3@rubyforge.org> Bugs item #9760, was opened at 2007-04-02 14:59 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=9760&group_id=797 Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: David Chelimsky (dchelimsky) Assigned to: Nobody (None) Summary: rspec generators incompatible with changes to edge rails Initial Comment: rails rev 6499 rspec rev 1672 (branches/0.9-dev) Stand in example_rails_app and run: RSPEC_RAILS_VERSION=edge rake rspec:pre_commit and you'll get the following errors: ==================================== controller specs ==================================== 'PurchasesController#route_for should map { :controller => 'purchases', :action => 'edit', :id => 1 } to /purchases/1;edit' FAILED expected "/purchases/1;edit", got "/purchases/1/edit" (using ==) ./spec/controllers/purchases_controller_spec.rb:19: ==================================== (that is because the mapping nown goes to /purchases/1/edit, as it probably should have all along) ==================================== ==================================== view specs ==================================== 1) '/purchases/edit.rhtml should render edit form' FAILED Expected at least 1 elements, found 0. is not true. ./spec/views/purchases/edit_rhtml_spec.rb:20: 2) '/purchases/index.rhtml should render list of purchases' FAILED 2. is not true. ./spec/views/purchases/index_rhtml_spec.rb:29: 3) '/purchases/new.rhtml should render new form' FAILED Expected at least 1 elements, found 0. is not true. ./spec/views/purchases/new_rhtml_spec.rb:20: 4) '/purchases/show.rhtml should render attributes in

' FAILED expected /9\.99/, got "" ./spec/views/purchases/show_rhtml_spec.rb:22: ==================================== It turns out the generated .rhtml files are all empty - probably related to rails switching from .rhtml to .erb ==================================== And we're also getting this deprecation warning: DEPRECATION WARNING: template_root is deprecated and will be removed from Rails 2.0 (use view_paths instead) See http://www.rubyonrails.org/deprecation for details. (called from template_root= at ./vendor/rails/edge/actionpack/lib/action_controller/base.rb:360) ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=9760&group_id=797 From noreply at rubyforge.org Mon Apr 2 10:59:43 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 2 Apr 2007 10:59:43 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-9760 ] rspec generators incompatible with changes to edge rails Message-ID: <20070402145943.510BE5240CA3@rubyforge.org> Bugs item #9760, was opened at 2007-04-02 14:59 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=9760&group_id=797 Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: David Chelimsky (dchelimsky) Assigned to: Nobody (None) Summary: rspec generators incompatible with changes to edge rails Initial Comment: rails rev 6499 rspec rev 1672 (branches/0.9-dev) Stand in example_rails_app and run: RSPEC_RAILS_VERSION=edge rake rspec:pre_commit and you'll get the following errors: ==================================== controller specs ==================================== 'PurchasesController#route_for should map { :controller => 'purchases', :action => 'edit', :id => 1 } to /purchases/1;edit' FAILED expected "/purchases/1;edit", got "/purchases/1/edit" (using ==) ./spec/controllers/purchases_controller_spec.rb:19: ==================================== (that is because the mapping nown goes to /purchases/1/edit, as it probably should have all along) ==================================== ==================================== view specs ==================================== 1) '/purchases/edit.rhtml should render edit form' FAILED Expected at least 1 elements, found 0. is not true. ./spec/views/purchases/edit_rhtml_spec.rb:20: 2) '/purchases/index.rhtml should render list of purchases' FAILED 2. is not true. ./spec/views/purchases/index_rhtml_spec.rb:29: 3) '/purchases/new.rhtml should render new form' FAILED Expected at least 1 elements, found 0. is not true. ./spec/views/purchases/new_rhtml_spec.rb:20: 4) '/purchases/show.rhtml should render attributes in

' FAILED expected /9\.99/, got "" ./spec/views/purchases/show_rhtml_spec.rb:22: ==================================== It turns out the generated .rhtml files are all empty - probably related to rails switching from .rhtml to .erb ==================================== And we're also getting this deprecation warning: DEPRECATION WARNING: template_root is deprecated and will be removed from Rails 2.0 (use view_paths instead) See http://www.rubyonrails.org/deprecation for details. (called from template_root= at ./vendor/rails/edge/actionpack/lib/action_controller/base.rb:360) ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=9760&group_id=797 From noreply at rubyforge.org Mon Apr 2 13:59:24 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 2 Apr 2007 13:59:24 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-9649 ] Parital mocks don't work if object loaded from fixture, and referenced via association Message-ID: <20070402175924.F09825240CBA@rubyforge.org> Bugs item #9649, was opened at 2007-03-28 15:44 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=9649&group_id=797 Category: mock module Group: None >Status: Open Resolution: Rejected Priority: 3 Submitted By: Chris Hoffman (hoffman_c) Assigned to: Aslak Helles?y (aslak_hellesoy) Summary: Parital mocks don't work if object loaded from fixture, and referenced via association Initial Comment: Hello, The following code will not function properly: spec/fixtures/pages.yml ---------- first: id: 1 type: LockedPage name: the first default page spec/fixtures/questions.yml ---------- first: id: 1 type: LockedQuestion name: the first default question container_id: 1 container_type: LockedPage spec/models/locked_question_spec.rb ---------- context "LockedQuestion#document_session, being linked to a Page that has a Document Session" do fixtures :questions, :pages setup do @question = questions(:first) @page = pages(:first) @page.stub!(:document_session).and_return("the document session") @question.page.should == @page #=> true end specify "should return the Page's Document Session" do @question.document_session.should == "the document session" #=> fails with 'undefined method' end end I would kludge something together by just assigning an unlocked page to the question, but the "Locked" that prefaces these models is a subclass that denies any modifications. Thanks for your help. -Chris ---------------------------------------------------------------------- >Comment By: Chris Hoffman (hoffman_c) Date: 2007-04-02 13:59 Message: Hello, I just ran the project I attached on rails 1.2, and it exhibited the same results. If you run into problems getting that project running, it may be due to an undefined method 'gem' in config/boot.rb; if you change this to 'require_gem', you should be up and running. Please let me know if you need additional information. Just as a recommendation, it would be superb to have rspec, rails, and even ruby version fields in this tracker, so that people like myself are forced to make this explicit. Thanks for your help. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-04-02 10:23 Message: Your Rails version is one year old, and the oldest Rails version RSpec is tested against is 1.1.6 (8 months old). It's too much work for us to ensure things work against old Railses, so I'm closing this bug. Feel free to reopen this bug if it still applies to Rails 1.1.6 or 1.2.x. (In the near future we will probably drop support for 1.1.6 though). ---------------------------------------------------------------------- Comment By: Chris Hoffman (hoffman_c) Date: 2007-04-02 07:44 Message: I am not sure how to do partial mocks with Test::Unit. As far as versions, I have the following: rspec 0.8.2 rails 1.1.2 Is the attached rails application not giving you an error when you run rake spec:models? ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-04-02 07:19 Message: Can you confirm that you're not getting the same problem when you use Test::Unit? What are your versions of everything? ---------------------------------------------------------------------- Comment By: Chris Hoffman (hoffman_c) Date: 2007-04-01 11:24 Message: Hello, I have created a rails project with the models and spec that reveal the problem. Please let me know if you need additional information. Also, you were indeed correct that the above example would fail for a different reason (if not taking into account the Question model's delegation). I apologize for the confusion. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-01 10:25 Message: What's 'undefined method' getting called on? Question or Page? Can you post the backtrace? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=9649&group_id=797 From noreply at rubyforge.org Mon Apr 2 14:40:49 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 2 Apr 2007 14:40:49 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-9760 ] rspec generators incompatible with changes to edge rails Message-ID: <20070402184049.E615F5240CAA@rubyforge.org> Bugs item #9760, was opened at 2007-04-02 14:59 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=9760&group_id=797 Category: rails plugin Group: None >Status: Closed >Resolution: Accepted Priority: 3 Submitted By: David Chelimsky (dchelimsky) >Assigned to: David Chelimsky (dchelimsky) Summary: rspec generators incompatible with changes to edge rails Initial Comment: rails rev 6499 rspec rev 1672 (branches/0.9-dev) Stand in example_rails_app and run: RSPEC_RAILS_VERSION=edge rake rspec:pre_commit and you'll get the following errors: ==================================== controller specs ==================================== 'PurchasesController#route_for should map { :controller => 'purchases', :action => 'edit', :id => 1 } to /purchases/1;edit' FAILED expected "/purchases/1;edit", got "/purchases/1/edit" (using ==) ./spec/controllers/purchases_controller_spec.rb:19: ==================================== (that is because the mapping nown goes to /purchases/1/edit, as it probably should have all along) ==================================== ==================================== view specs ==================================== 1) '/purchases/edit.rhtml should render edit form' FAILED Expected at least 1 elements, found 0. is not true. ./spec/views/purchases/edit_rhtml_spec.rb:20: 2) '/purchases/index.rhtml should render list of purchases' FAILED 2. is not true. ./spec/views/purchases/index_rhtml_spec.rb:29: 3) '/purchases/new.rhtml should render new form' FAILED Expected at least 1 elements, found 0. is not true. ./spec/views/purchases/new_rhtml_spec.rb:20: 4) '/purchases/show.rhtml should render attributes in

' FAILED expected /9\.99/, got "" ./spec/views/purchases/show_rhtml_spec.rb:22: ==================================== It turns out the generated .rhtml files are all empty - probably related to rails switching from .rhtml to .erb ==================================== And we're also getting this deprecation warning: DEPRECATION WARNING: template_root is deprecated and will be removed from Rails 2.0 (use view_paths instead) See http://www.rubyonrails.org/deprecation for details. (called from template_root= at ./vendor/rails/edge/actionpack/lib/action_controller/base.rb:360) ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-04-02 18:40 Message: Fixed in branches/0.9-dev (rev 1674) ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=9760&group_id=797 From noreply at rubyforge.org Mon Apr 2 14:47:57 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 2 Apr 2007 14:47:57 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-9421 ] --line doesn't work with behaviours that use class names Message-ID: <20070402184757.188F55240AB0@rubyforge.org> Bugs item #9421, was opened at 2007-03-21 10:11 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=9421&group_id=797 Category: runner module Group: None Status: Open Resolution: None Priority: 4 Submitted By: Aslak Helles?y (aslak_hellesoy) Assigned to: David Chelimsky (dchelimsky) Summary: --line doesn't work with behaviours that use class names Initial Comment: To reproduce, do: ruby bin/spec spec/spec/dsl/behaviour_spec.rb -l 22 Finished in 1.4e-05 seconds 0 examples, 0 failures This is because SpecParser always looks for quotes - it has to be smarter ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-04-02 18:47 Message: The problem is now with modules: module Spec module DSL describe Behaviour do this produces a behaviour description of "Spec::DSL::Behaviour" but the parser is only looking for "Behaviour" in progress.... ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-04-01 21:07 Message: Didn't you just fix this? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=9421&group_id=797 From noreply at rubyforge.org Mon Apr 2 15:22:37 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 2 Apr 2007 15:22:37 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-9421 ] --line doesn't work with behaviours that use class names Message-ID: <20070402192237.6F6F15240CB4@rubyforge.org> Bugs item #9421, was opened at 2007-03-21 10:11 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=9421&group_id=797 Category: runner module Group: None >Status: Closed >Resolution: Accepted Priority: 4 Submitted By: Aslak Helles?y (aslak_hellesoy) Assigned to: David Chelimsky (dchelimsky) Summary: --line doesn't work with behaviours that use class names Initial Comment: To reproduce, do: ruby bin/spec spec/spec/dsl/behaviour_spec.rb -l 22 Finished in 1.4e-05 seconds 0 examples, 0 failures This is because SpecParser always looks for quotes - it has to be smarter ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-04-02 19:22 Message: Fixed in branches/0.9-dev (rev 1675) ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-02 18:47 Message: The problem is now with modules: module Spec module DSL describe Behaviour do this produces a behaviour description of "Spec::DSL::Behaviour" but the parser is only looking for "Behaviour" in progress.... ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-04-01 21:07 Message: Didn't you just fix this? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=9421&group_id=797 From noreply at rubyforge.org Mon Apr 2 16:52:40 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 2 Apr 2007 16:52:40 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-9649 ] Parital mocks don't work if object loaded from fixture, and referenced via association Message-ID: <20070402205240.A9FB95240B6E@rubyforge.org> Bugs item #9649, was opened at 2007-03-28 15:44 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=9649&group_id=797 Category: mock module Group: None Status: Open Resolution: Rejected Priority: 3 Submitted By: Chris Hoffman (hoffman_c) Assigned to: Aslak Helles?y (aslak_hellesoy) Summary: Parital mocks don't work if object loaded from fixture, and referenced via association Initial Comment: Hello, The following code will not function properly: spec/fixtures/pages.yml ---------- first: id: 1 type: LockedPage name: the first default page spec/fixtures/questions.yml ---------- first: id: 1 type: LockedQuestion name: the first default question container_id: 1 container_type: LockedPage spec/models/locked_question_spec.rb ---------- context "LockedQuestion#document_session, being linked to a Page that has a Document Session" do fixtures :questions, :pages setup do @question = questions(:first) @page = pages(:first) @page.stub!(:document_session).and_return("the document session") @question.page.should == @page #=> true end specify "should return the Page's Document Session" do @question.document_session.should == "the document session" #=> fails with 'undefined method' end end I would kludge something together by just assigning an unlocked page to the question, but the "Locked" that prefaces these models is a subclass that denies any modifications. Thanks for your help. -Chris ---------------------------------------------------------------------- >Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-04-02 16:52 Message: I was able to reproduce your error. Looking further, it look like @page and @document.page is not the same instance, which explains why the spec is failing: require File.dirname(__FILE__) + '/../spec_helper' context "LockedQuestion#document_session, being linked to a Page that has a Document Session" do fixtures :questions, :pages setup do @question = questions(:first) @page = pages(:first) @page.stub!(:document_session).and_return("the document session") # This will work #@question.page.stub!(:document_session).and_return("the document session") end specify "should return the Page's Document Session" do @question.page.should == @page #=> true @question.page.should equal(@page) #=> fails, which explains why the next one fails too - the stub! is on the wrong object @question.page.document_session.should == "the document session" #=> fails with 'undefined method' end end This seems to be related to Rails not giving you the *same* (equal) page instance - just a similar (==) one. ---------------------------------------------------------------------- Comment By: Chris Hoffman (hoffman_c) Date: 2007-04-02 13:59 Message: Hello, I just ran the project I attached on rails 1.2, and it exhibited the same results. If you run into problems getting that project running, it may be due to an undefined method 'gem' in config/boot.rb; if you change this to 'require_gem', you should be up and running. Please let me know if you need additional information. Just as a recommendation, it would be superb to have rspec, rails, and even ruby version fields in this tracker, so that people like myself are forced to make this explicit. Thanks for your help. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-04-02 10:23 Message: Your Rails version is one year old, and the oldest Rails version RSpec is tested against is 1.1.6 (8 months old). It's too much work for us to ensure things work against old Railses, so I'm closing this bug. Feel free to reopen this bug if it still applies to Rails 1.1.6 or 1.2.x. (In the near future we will probably drop support for 1.1.6 though). ---------------------------------------------------------------------- Comment By: Chris Hoffman (hoffman_c) Date: 2007-04-02 07:44 Message: I am not sure how to do partial mocks with Test::Unit. As far as versions, I have the following: rspec 0.8.2 rails 1.1.2 Is the attached rails application not giving you an error when you run rake spec:models? ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-04-02 07:19 Message: Can you confirm that you're not getting the same problem when you use Test::Unit? What are your versions of everything? ---------------------------------------------------------------------- Comment By: Chris Hoffman (hoffman_c) Date: 2007-04-01 11:24 Message: Hello, I have created a rails project with the models and spec that reveal the problem. Please let me know if you need additional information. Also, you were indeed correct that the above example would fail for a different reason (if not taking into account the Question model's delegation). I apologize for the confusion. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-01 10:25 Message: What's 'undefined method' getting called on? Question or Page? Can you post the backtrace? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=9649&group_id=797 From noreply at rubyforge.org Mon Apr 2 16:59:07 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 2 Apr 2007 16:59:07 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-9767 ] rspec_on_rails hoses Message-ID: <20070402205907.6E9635240B6E@rubyforge.org> Bugs item #9767, was opened at 2007-04-02 20:59 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=9767&group_id=797 Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: Jonathan Terhorst (terhorst) Assigned to: Nobody (None) Summary: rspec_on_rails hoses Initial Comment: This was already mentioned on rspec-users but I never saw any mention of it. The plugin currently overwrites the rescue_action method of a tested controller: lib/spec/rails/runner/context/controller.rb:183: @controller_class.send(:define_method, :rescue_action) { |e| raise e } This is bad for several reasons. First, it's not very OO. Second, many people are using this method to implement exception handling (there's even a nice plugin for this) and this behavior breaks that. I am happy to code up a test and patch but first I need a better understanding of what this line was intended to accomplish--it seems pointless, so I must be missing something. As it stands, I commented it out and everything appears to work fine ... ? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=9767&group_id=797 From noreply at rubyforge.org Mon Apr 2 17:02:30 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 2 Apr 2007 17:02:30 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-6591 ] rails_dpec like functionality in RSpec.tmbundle Message-ID: <20070402210230.AA2315240AB0@rubyforge.org> Feature Requests item #6591, was opened at 2006-11-09 20:53 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6591&group_id=797 Category: None Group: None >Status: Closed Priority: 3 Submitted By: Aslak Helles?y (aslak_hellesoy) Assigned to: Aslak Helles?y (aslak_hellesoy) Summary: rails_dpec like functionality in RSpec.tmbundle Initial Comment: For Rails development, it would be great to be able to run specs via DRb, to connect to rails_spec_server. I think the rails_spec script ought to be made a first-class RSpec core bin script: drbspec. Then it could be reused from commandline, editors/ides and other clients. Also see: http://www.artima.com/forums/flat.jsp?forum=123&thread=144337 ---------------------------------------------------------------------- >Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-04-02 17:02 Message: Fixed long ago. Just use the --drb in the TM RSPEC_OPTS settings ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-09 21:09 Message: Let's not forget to update the spec/rails doco when we do this ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6591&group_id=797 From noreply at rubyforge.org Mon Apr 2 19:05:33 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 2 Apr 2007 19:05:33 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-9649 ] Parital mocks don't work if object loaded from fixture, and referenced via association Message-ID: <20070402230533.55C925240B7E@rubyforge.org> Bugs item #9649, was opened at 2007-03-28 15:44 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=9649&group_id=797 Category: mock module Group: None Status: Open Resolution: Rejected Priority: 3 Submitted By: Chris Hoffman (hoffman_c) Assigned to: Aslak Helles?y (aslak_hellesoy) Summary: Parital mocks don't work if object loaded from fixture, and referenced via association Initial Comment: Hello, The following code will not function properly: spec/fixtures/pages.yml ---------- first: id: 1 type: LockedPage name: the first default page spec/fixtures/questions.yml ---------- first: id: 1 type: LockedQuestion name: the first default question container_id: 1 container_type: LockedPage spec/models/locked_question_spec.rb ---------- context "LockedQuestion#document_session, being linked to a Page that has a Document Session" do fixtures :questions, :pages setup do @question = questions(:first) @page = pages(:first) @page.stub!(:document_session).and_return("the document session") @question.page.should == @page #=> true end specify "should return the Page's Document Session" do @question.document_session.should == "the document session" #=> fails with 'undefined method' end end I would kludge something together by just assigning an unlocked page to the question, but the "Locked" that prefaces these models is a subclass that denies any modifications. Thanks for your help. -Chris ---------------------------------------------------------------------- >Comment By: Chris Hoffman (hoffman_c) Date: 2007-04-02 19:05 Message: Oh, okay, that makes sense. Thanks for looking into this issue for me. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-04-02 16:52 Message: I was able to reproduce your error. Looking further, it look like @page and @document.page is not the same instance, which explains why the spec is failing: require File.dirname(__FILE__) + '/../spec_helper' context "LockedQuestion#document_session, being linked to a Page that has a Document Session" do fixtures :questions, :pages setup do @question = questions(:first) @page = pages(:first) @page.stub!(:document_session).and_return("the document session") # This will work #@question.page.stub!(:document_session).and_return("the document session") end specify "should return the Page's Document Session" do @question.page.should == @page #=> true @question.page.should equal(@page) #=> fails, which explains why the next one fails too - the stub! is on the wrong object @question.page.document_session.should == "the document session" #=> fails with 'undefined method' end end This seems to be related to Rails not giving you the *same* (equal) page instance - just a similar (==) one. ---------------------------------------------------------------------- Comment By: Chris Hoffman (hoffman_c) Date: 2007-04-02 13:59 Message: Hello, I just ran the project I attached on rails 1.2, and it exhibited the same results. If you run into problems getting that project running, it may be due to an undefined method 'gem' in config/boot.rb; if you change this to 'require_gem', you should be up and running. Please let me know if you need additional information. Just as a recommendation, it would be superb to have rspec, rails, and even ruby version fields in this tracker, so that people like myself are forced to make this explicit. Thanks for your help. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-04-02 10:23 Message: Your Rails version is one year old, and the oldest Rails version RSpec is tested against is 1.1.6 (8 months old). It's too much work for us to ensure things work against old Railses, so I'm closing this bug. Feel free to reopen this bug if it still applies to Rails 1.1.6 or 1.2.x. (In the near future we will probably drop support for 1.1.6 though). ---------------------------------------------------------------------- Comment By: Chris Hoffman (hoffman_c) Date: 2007-04-02 07:44 Message: I am not sure how to do partial mocks with Test::Unit. As far as versions, I have the following: rspec 0.8.2 rails 1.1.2 Is the attached rails application not giving you an error when you run rake spec:models? ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-04-02 07:19 Message: Can you confirm that you're not getting the same problem when you use Test::Unit? What are your versions of everything? ---------------------------------------------------------------------- Comment By: Chris Hoffman (hoffman_c) Date: 2007-04-01 11:24 Message: Hello, I have created a rails project with the models and spec that reveal the problem. Please let me know if you need additional information. Also, you were indeed correct that the above example would fail for a different reason (if not taking into account the Question model's delegation). I apologize for the confusion. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-01 10:25 Message: What's 'undefined method' getting called on? Question or Page? Can you post the backtrace? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=9649&group_id=797 From noreply at rubyforge.org Mon Apr 2 22:01:20 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 2 Apr 2007 22:01:20 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-9649 ] Parital mocks don't work if object loaded from fixture, and referenced via association Message-ID: <20070403020120.79DDD5240CC5@rubyforge.org> Bugs item #9649, was opened at 2007-03-28 19:44 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=9649&group_id=797 Category: mock module Group: None Status: Open Resolution: Rejected Priority: 3 Submitted By: Chris Hoffman (hoffman_c) Assigned to: Aslak Helles?y (aslak_hellesoy) Summary: Parital mocks don't work if object loaded from fixture, and referenced via association Initial Comment: Hello, The following code will not function properly: spec/fixtures/pages.yml ---------- first: id: 1 type: LockedPage name: the first default page spec/fixtures/questions.yml ---------- first: id: 1 type: LockedQuestion name: the first default question container_id: 1 container_type: LockedPage spec/models/locked_question_spec.rb ---------- context "LockedQuestion#document_session, being linked to a Page that has a Document Session" do fixtures :questions, :pages setup do @question = questions(:first) @page = pages(:first) @page.stub!(:document_session).and_return("the document session") @question.page.should == @page #=> true end specify "should return the Page's Document Session" do @question.document_session.should == "the document session" #=> fails with 'undefined method' end end I would kludge something together by just assigning an unlocked page to the question, but the "Locked" that prefaces these models is a subclass that denies any modifications. Thanks for your help. -Chris ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-04-03 02:01 Message: Can we close this then? ---------------------------------------------------------------------- Comment By: Chris Hoffman (hoffman_c) Date: 2007-04-02 23:05 Message: Oh, okay, that makes sense. Thanks for looking into this issue for me. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-04-02 20:52 Message: I was able to reproduce your error. Looking further, it look like @page and @document.page is not the same instance, which explains why the spec is failing: require File.dirname(__FILE__) + '/../spec_helper' context "LockedQuestion#document_session, being linked to a Page that has a Document Session" do fixtures :questions, :pages setup do @question = questions(:first) @page = pages(:first) @page.stub!(:document_session).and_return("the document session") # This will work #@question.page.stub!(:document_session).and_return("the document session") end specify "should return the Page's Document Session" do @question.page.should == @page #=> true @question.page.should equal(@page) #=> fails, which explains why the next one fails too - the stub! is on the wrong object @question.page.document_session.should == "the document session" #=> fails with 'undefined method' end end This seems to be related to Rails not giving you the *same* (equal) page instance - just a similar (==) one. ---------------------------------------------------------------------- Comment By: Chris Hoffman (hoffman_c) Date: 2007-04-02 17:59 Message: Hello, I just ran the project I attached on rails 1.2, and it exhibited the same results. If you run into problems getting that project running, it may be due to an undefined method 'gem' in config/boot.rb; if you change this to 'require_gem', you should be up and running. Please let me know if you need additional information. Just as a recommendation, it would be superb to have rspec, rails, and even ruby version fields in this tracker, so that people like myself are forced to make this explicit. Thanks for your help. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-04-02 14:23 Message: Your Rails version is one year old, and the oldest Rails version RSpec is tested against is 1.1.6 (8 months old). It's too much work for us to ensure things work against old Railses, so I'm closing this bug. Feel free to reopen this bug if it still applies to Rails 1.1.6 or 1.2.x. (In the near future we will probably drop support for 1.1.6 though). ---------------------------------------------------------------------- Comment By: Chris Hoffman (hoffman_c) Date: 2007-04-02 11:44 Message: I am not sure how to do partial mocks with Test::Unit. As far as versions, I have the following: rspec 0.8.2 rails 1.1.2 Is the attached rails application not giving you an error when you run rake spec:models? ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-04-02 11:19 Message: Can you confirm that you're not getting the same problem when you use Test::Unit? What are your versions of everything? ---------------------------------------------------------------------- Comment By: Chris Hoffman (hoffman_c) Date: 2007-04-01 15:24 Message: Hello, I have created a rails project with the models and spec that reveal the problem. Please let me know if you need additional information. Also, you were indeed correct that the above example would fail for a different reason (if not taking into account the Question model's delegation). I apologize for the confusion. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-01 14:25 Message: What's 'undefined method' getting called on? Question or Page? Can you post the backtrace? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=9649&group_id=797 From noreply at rubyforge.org Mon Apr 2 22:16:03 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 2 Apr 2007 22:16:03 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-9767 ] rspec_on_rails hoses Message-ID: <20070403021603.2E1125240CC8@rubyforge.org> Bugs item #9767, was opened at 2007-04-02 20:59 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=9767&group_id=797 Category: rails plugin Group: None >Status: Closed >Resolution: Accepted Priority: 3 Submitted By: Jonathan Terhorst (terhorst) >Assigned to: David Chelimsky (dchelimsky) Summary: rspec_on_rails hoses Initial Comment: This was already mentioned on rspec-users but I never saw any mention of it. The plugin currently overwrites the rescue_action method of a tested controller: lib/spec/rails/runner/context/controller.rb:183: @controller_class.send(:define_method, :rescue_action) { |e| raise e } This is bad for several reasons. First, it's not very OO. Second, many people are using this method to implement exception handling (there's even a nice plugin for this) and this behavior breaks that. I am happy to code up a test and patch but first I need a better understanding of what this line was intended to accomplish--it seems pointless, so I must be missing something. As it stands, I commented it out and everything appears to work fine ... ? ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-04-03 02:16 Message: Fixed in trunk and branches/0.9-dev (rev 1678), so it will be included in both 0.8.3 and 0.9 forward. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=9767&group_id=797 From noreply at rubyforge.org Mon Apr 2 22:20:19 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 2 Apr 2007 22:20:19 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-9260 ] IvarProxy does not act like a hash Message-ID: <20070403022019.973235240CCB@rubyforge.org> Bugs item #9260, was opened at 2007-03-13 17:08 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=9260&group_id=797 >Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: Brian Takita (btakita) Assigned to: Nobody (None) Summary: IvarProxy does not act like a hash Initial Comment: undefined method `delete' for # This happened in a Helper Spec. Here is the code to reproduce this. mab = Markaby::Builder.new(assigns_hash, self) ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-04-03 02:20 Message: Brian, can you please submit a failing example? ---------------------------------------------------------------------- Comment By: Brian Takita (btakita) Date: 2007-03-13 17:13 Message: Here is a fix I used without specs (my specs pass now): class Spec::Rails::Expectations::IvarProxy def delete(name) @object.send(:remove_instance_variable, "@#{name}") if @object.instance_variables.include?("@#{name}") end def each @object.instance_variables do |var| yield @object.instance_variable_get(var) end end end ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=9260&group_id=797 From noreply at rubyforge.org Tue Apr 3 00:02:39 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 3 Apr 2007 00:02:39 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-7795 ] form_tag renders action=" /view_spec" in view specs Message-ID: <20070403040239.E8B015240CD6@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: Closed >Resolution: Accepted Priority: 3 Submitted By: David Chelimsky (dchelimsky) >Assigned to: David Chelimsky (dchelimsky) >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:
...
---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-04-03 04:02 Message: Fixed in branches/0.9-dev (rev 1679) ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=7795&group_id=797 From noreply at rubyforge.org Tue Apr 3 02:42:54 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 3 Apr 2007 02:42:54 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-9649 ] Parital mocks don't work if object loaded from fixture, and referenced via association Message-ID: <20070403064254.F0C875240CE4@rubyforge.org> Bugs item #9649, was opened at 2007-03-28 15:44 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=9649&group_id=797 Category: mock module Group: None >Status: Closed Resolution: Rejected Priority: 3 Submitted By: Chris Hoffman (hoffman_c) Assigned to: Aslak Helles?y (aslak_hellesoy) Summary: Parital mocks don't work if object loaded from fixture, and referenced via association Initial Comment: Hello, The following code will not function properly: spec/fixtures/pages.yml ---------- first: id: 1 type: LockedPage name: the first default page spec/fixtures/questions.yml ---------- first: id: 1 type: LockedQuestion name: the first default question container_id: 1 container_type: LockedPage spec/models/locked_question_spec.rb ---------- context "LockedQuestion#document_session, being linked to a Page that has a Document Session" do fixtures :questions, :pages setup do @question = questions(:first) @page = pages(:first) @page.stub!(:document_session).and_return("the document session") @question.page.should == @page #=> true end specify "should return the Page's Document Session" do @question.document_session.should == "the document session" #=> fails with 'undefined method' end end I would kludge something together by just assigning an unlocked page to the question, but the "Locked" that prefaces these models is a subclass that denies any modifications. Thanks for your help. -Chris ---------------------------------------------------------------------- >Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-04-03 02:42 Message: Not a bug ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-02 22:01 Message: Can we close this then? ---------------------------------------------------------------------- Comment By: Chris Hoffman (hoffman_c) Date: 2007-04-02 19:05 Message: Oh, okay, that makes sense. Thanks for looking into this issue for me. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-04-02 16:52 Message: I was able to reproduce your error. Looking further, it look like @page and @document.page is not the same instance, which explains why the spec is failing: require File.dirname(__FILE__) + '/../spec_helper' context "LockedQuestion#document_session, being linked to a Page that has a Document Session" do fixtures :questions, :pages setup do @question = questions(:first) @page = pages(:first) @page.stub!(:document_session).and_return("the document session") # This will work #@question.page.stub!(:document_session).and_return("the document session") end specify "should return the Page's Document Session" do @question.page.should == @page #=> true @question.page.should equal(@page) #=> fails, which explains why the next one fails too - the stub! is on the wrong object @question.page.document_session.should == "the document session" #=> fails with 'undefined method' end end This seems to be related to Rails not giving you the *same* (equal) page instance - just a similar (==) one. ---------------------------------------------------------------------- Comment By: Chris Hoffman (hoffman_c) Date: 2007-04-02 13:59 Message: Hello, I just ran the project I attached on rails 1.2, and it exhibited the same results. If you run into problems getting that project running, it may be due to an undefined method 'gem' in config/boot.rb; if you change this to 'require_gem', you should be up and running. Please let me know if you need additional information. Just as a recommendation, it would be superb to have rspec, rails, and even ruby version fields in this tracker, so that people like myself are forced to make this explicit. Thanks for your help. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-04-02 10:23 Message: Your Rails version is one year old, and the oldest Rails version RSpec is tested against is 1.1.6 (8 months old). It's too much work for us to ensure things work against old Railses, so I'm closing this bug. Feel free to reopen this bug if it still applies to Rails 1.1.6 or 1.2.x. (In the near future we will probably drop support for 1.1.6 though). ---------------------------------------------------------------------- Comment By: Chris Hoffman (hoffman_c) Date: 2007-04-02 07:44 Message: I am not sure how to do partial mocks with Test::Unit. As far as versions, I have the following: rspec 0.8.2 rails 1.1.2 Is the attached rails application not giving you an error when you run rake spec:models? ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-04-02 07:19 Message: Can you confirm that you're not getting the same problem when you use Test::Unit? What are your versions of everything? ---------------------------------------------------------------------- Comment By: Chris Hoffman (hoffman_c) Date: 2007-04-01 11:24 Message: Hello, I have created a rails project with the models and spec that reveal the problem. Please let me know if you need additional information. Also, you were indeed correct that the above example would fail for a different reason (if not taking into account the Question model's delegation). I apologize for the confusion. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-01 10:25 Message: What's 'undefined method' getting called on? Question or Page? Can you post the backtrace? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=9649&group_id=797 From noreply at rubyforge.org Tue Apr 3 07:40:06 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 3 Apr 2007 07:40:06 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-9649 ] Parital mocks don't work if object loaded from fixture, and referenced via association Message-ID: <20070403114006.BFDCF5240B52@rubyforge.org> Bugs item #9649, was opened at 2007-03-28 15:44 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=9649&group_id=797 Category: mock module Group: None Status: Closed Resolution: Rejected Priority: 3 Submitted By: Chris Hoffman (hoffman_c) Assigned to: Aslak Helles?y (aslak_hellesoy) Summary: Parital mocks don't work if object loaded from fixture, and referenced via association Initial Comment: Hello, The following code will not function properly: spec/fixtures/pages.yml ---------- first: id: 1 type: LockedPage name: the first default page spec/fixtures/questions.yml ---------- first: id: 1 type: LockedQuestion name: the first default question container_id: 1 container_type: LockedPage spec/models/locked_question_spec.rb ---------- context "LockedQuestion#document_session, being linked to a Page that has a Document Session" do fixtures :questions, :pages setup do @question = questions(:first) @page = pages(:first) @page.stub!(:document_session).and_return("the document session") @question.page.should == @page #=> true end specify "should return the Page's Document Session" do @question.document_session.should == "the document session" #=> fails with 'undefined method' end end I would kludge something together by just assigning an unlocked page to the question, but the "Locked" that prefaces these models is a subclass that denies any modifications. Thanks for your help. -Chris ---------------------------------------------------------------------- >Comment By: Chris Hoffman (hoffman_c) Date: 2007-04-03 07:40 Message: Oh yeah, sure, I should've done so. I thought the resolution was the state. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-04-03 02:42 Message: Not a bug ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-02 22:01 Message: Can we close this then? ---------------------------------------------------------------------- Comment By: Chris Hoffman (hoffman_c) Date: 2007-04-02 19:05 Message: Oh, okay, that makes sense. Thanks for looking into this issue for me. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-04-02 16:52 Message: I was able to reproduce your error. Looking further, it look like @page and @document.page is not the same instance, which explains why the spec is failing: require File.dirname(__FILE__) + '/../spec_helper' context "LockedQuestion#document_session, being linked to a Page that has a Document Session" do fixtures :questions, :pages setup do @question = questions(:first) @page = pages(:first) @page.stub!(:document_session).and_return("the document session") # This will work #@question.page.stub!(:document_session).and_return("the document session") end specify "should return the Page's Document Session" do @question.page.should == @page #=> true @question.page.should equal(@page) #=> fails, which explains why the next one fails too - the stub! is on the wrong object @question.page.document_session.should == "the document session" #=> fails with 'undefined method' end end This seems to be related to Rails not giving you the *same* (equal) page instance - just a similar (==) one. ---------------------------------------------------------------------- Comment By: Chris Hoffman (hoffman_c) Date: 2007-04-02 13:59 Message: Hello, I just ran the project I attached on rails 1.2, and it exhibited the same results. If you run into problems getting that project running, it may be due to an undefined method 'gem' in config/boot.rb; if you change this to 'require_gem', you should be up and running. Please let me know if you need additional information. Just as a recommendation, it would be superb to have rspec, rails, and even ruby version fields in this tracker, so that people like myself are forced to make this explicit. Thanks for your help. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-04-02 10:23 Message: Your Rails version is one year old, and the oldest Rails version RSpec is tested against is 1.1.6 (8 months old). It's too much work for us to ensure things work against old Railses, so I'm closing this bug. Feel free to reopen this bug if it still applies to Rails 1.1.6 or 1.2.x. (In the near future we will probably drop support for 1.1.6 though). ---------------------------------------------------------------------- Comment By: Chris Hoffman (hoffman_c) Date: 2007-04-02 07:44 Message: I am not sure how to do partial mocks with Test::Unit. As far as versions, I have the following: rspec 0.8.2 rails 1.1.2 Is the attached rails application not giving you an error when you run rake spec:models? ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-04-02 07:19 Message: Can you confirm that you're not getting the same problem when you use Test::Unit? What are your versions of everything? ---------------------------------------------------------------------- Comment By: Chris Hoffman (hoffman_c) Date: 2007-04-01 11:24 Message: Hello, I have created a rails project with the models and spec that reveal the problem. Please let me know if you need additional information. Also, you were indeed correct that the above example would fail for a different reason (if not taking into account the Question model's delegation). I apologize for the confusion. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-01 10:25 Message: What's 'undefined method' getting called on? Question or Page? Can you post the backtrace? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=9649&group_id=797 From noreply at rubyforge.org Tue Apr 3 08:36:05 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 3 Apr 2007 08:36:05 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-9472 ] Provide way to extract specify/it into includable module Message-ID: <20070403123605.CEDC25240AE3@rubyforge.org> Feature Requests item #9472, was opened at 2007-03-22 16:12 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=9472&group_id=797 Category: expectation module Group: None Status: Open Priority: 3 Submitted By: Bob Cotton (bcotton) Assigned to: Nobody (None) Summary: Provide way to extract specify/it into includable module Initial Comment: Based on the conversation here http://rubyforge.org/pipermail/rspec-users/2007-March/000993.html provide the ability to extract specify/it into a module that may be included into a context/describe For example: describe AllEditions, :shared => true do it "should" do end end describe LargeEdition do include AllEditions it "should also" do end end ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-04-03 12:36 Message: So the concern that we've had about this sort of sharing is that it wouldn't lead to cleaner specs, but would, in fact, end up making things more complex. Let's take the stack example. describe "All Stacks", :shared => true do it "should return the top item when you send it #top" do OK - right away we've got a problem. Somehow, this example needs to reference a Stack instance and say something about it: describe "All Stacks", :shared => true do it "should return the top item when you send it #top" do @stack.top.should == ??????? What's it going to equal? Where's it going to come from? Perhaps this: describe "All Stacks", :shared => true do it "should return the top item when you send it #top" do @stack.top.should == @last_added end end describe "An non-empty, non-full Stack" do it_should_behave_as "All Stacks" def setup @stack = Stack.new @stack.push "1" @stack.push @last_added = "2" end end Now this would pass, but there's this unfortunate binding between the shared behavoiur and its user. As things grow more complex, these will end up in different files (or one really big file) and you'll have to go chasing around to understand what any one thing is doing. Now there is a case in which I see a real use for this that would minimize this binding and provide some benefit - and that is defining a duck type - sort of like a java interface without the interface class. So you could do this: describe "Enumerable", :shared => true do it "should respond to #each" do enumerable.should respond_to(:each) end end describe "A Stack" do it_should_behave_as "Enumerable" def setup @stack = Stack.new end def enumerable @stack end end So now we've defined an interface from the examples instead of from a class from which Stack must derive. This is what duck typing is all about! But we still have an odd binding here - the "A Stack" behaviour has to implement #enumerable. That makes me uncomfortable. So I was batting this around w/ Dan North and he suggested something that would end up looking like this: act_as_enumerable = act_as %w { each } describe Stack do it "should act as enumerable" do Stack.new.should act_as_enumerable end end Actually - his suggestion was quack_like :) quack_like_enumerable = quack_like %w { each } describe Stack do it "should quack like enumerable" do Stack.new.should quack_like_enumerable end end One way or another, I think that we'll want to add something like that because it is a very simple way to solve the behaves_as problem. So then my question is what other use cases are there for :shared => true? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-03-27 01:24 Message: I need to think about how to word some things. Why don't you go ahead and give it your best shot and I'll tweak what I think needs tweaking. OK? Thanks Bob - a lot of people have been waiting for a feature like this. Cheers, David ---------------------------------------------------------------------- Comment By: Bob Cotton (bcotton) Date: 2007-03-27 01:01 Message: Thoughs on the wording for including shared behavior, before I write the doc and submit the patch? ---------------------------------------------------------------------- Comment By: Bob Cotton (bcotton) Date: 2007-03-25 13:36 Message: Yes, I'll be doing the work on 0.9. No BDD pie necessary, not being that familar with the code base, just wanted to make sure I wasn't missing anything. Before I can define behavior, I want to make sure I've got all the right classes. Don't worry, there will be specs! Thanks for the followup ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-03-24 23:33 Message: Following up - I guess there's nothing wrong w/ talking about design a LITTLE first. How about a collection on Spec::Runner with methods to interact with it right on the module. Something like: Spec::Runner.add_shared_behaviour(behaviour) Spec::Runner.find_shared_behaviour(:name) This way you don't have to expose anything and those methods can handle the management of the collection. Thoughts? Feel free to throw a BDD pie in my face instead of answering. Cheers, David ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-03-24 23:24 Message: Hi Bob - I assume you're working in the 0.9 branch, yes? If not, please do. As for your questions - this is BDD! Write some specs! If we have any issues w/ the design, we'll talk about it later. Cool? ---------------------------------------------------------------------- Comment By: Bob Cotton (bcotton) Date: 2007-03-24 22:29 Message: I'm about to start implementing this. A couple of questions: 1. I suppose the only way to locate a shared 'describe' would be through its description 2. I'll need to add an attr_reader for :examples to Spec::DSL::Behavior::ModuleMethods so I can grab all shared Examples and add them to the current Behavior just before running. 3. I'll need to add either an attr_reader for :behaviors or a find method to Spec::Runner::BehaviorRunner so I can lookup behaviors by descritpion. Thoughts? ---------------------------------------------------------------------- Comment By: Bob Cotton (bcotton) Date: 2007-03-22 18:45 Message: Very nice. it_should_behave_as Brainstorming with a co-worker: behaving_as behaves_like sharing acts_like an_example_of shares_behavior_with shares_behavior_of same_as same_behavior_as just_like equivalent_to it_doppelgangers ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-03-22 16:23 Message: I like this idea in general. I know we've been resistant to add any sort of example (spec) sharing, but perhaps now is the time. We can't really just say describe AllEditions because Ruby would treat that as a constant and not be able to find it. Also, include implies a module - this is a bit different. So I'm thinking something like this: describe "AllEditions", :shared => true do it "should do something" do end end describe LargeEdition do it_should_behave_as "AllEditions" it "should also do something else" do end end That reads kinda nice, ay? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=9472&group_id=797 From noreply at rubyforge.org Tue Apr 3 11:16:28 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 3 Apr 2007 11:16:28 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-9786 ] infer controller and helper names from the described type Message-ID: <20070403151628.670275240CFD@rubyforge.org> Feature Requests item #9786, was opened at 2007-04-03 15:16 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=9786&group_id=797 Category: rails plugin Group: None Status: Open Priority: 3 Submitted By: David Chelimsky (dchelimsky) Assigned to: Nobody (None) Summary: infer controller and helper names from the described type Initial Comment: Now that we can do this: describe SomeThingController do it seems a shame to require this: controller_name :some_thing Controller Behavoiurs could be smart enough to see if a type is passed to #describe, and if it is a subclass of ActionController::Base, in which case it doesn't need to require controller_name Same goes for Helper Behaviours. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=9786&group_id=797 From noreply at rubyforge.org Tue Apr 3 13:50:19 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 3 Apr 2007 13:50:19 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-9789 ] Make HtmlFormatter#extra_failure_content take the failure as a arg Message-ID: <20070403175020.797FE5240AE3@rubyforge.org> Feature Requests item #9789, was opened at 2007-04-03 13:50 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=9789&group_id=797 Category: expectation module Group: None Status: Open Priority: 3 Submitted By: Mike Harris (gfunk911) Assigned to: Nobody (None) Summary: Make HtmlFormatter#extra_failure_content take the failure as a arg Initial Comment: It would be helpful if HtmlFormatter#extra_failure_content could take the failure as an arg, so it could produce content based on the failure. If the change was made to have rspec only pass the failure if the arity of failure is 1, it would also preserve existing behavior. I would be happy to code this and submit a patch if that would be helpful. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=9789&group_id=797 From noreply at rubyforge.org Tue Apr 3 14:06:03 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 3 Apr 2007 14:06:03 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-9789 ] Make HtmlFormatter#extra_failure_content take the failure as a arg Message-ID: <20070403180604.08C3E5240BF0@rubyforge.org> Feature Requests item #9789, was opened at 2007-04-03 13:50 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=9789&group_id=797 Category: expectation module Group: None Status: Open Priority: 3 Submitted By: Mike Harris (gfunk911) Assigned to: Nobody (None) Summary: Make HtmlFormatter#extra_failure_content take the failure as a arg Initial Comment: It would be helpful if HtmlFormatter#extra_failure_content could take the failure as an arg, so it could produce content based on the failure. If the change was made to have rspec only pass the failure if the arity of failure is 1, it would also preserve existing behavior. I would be happy to code this and submit a patch if that would be helpful. ---------------------------------------------------------------------- >Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-04-03 14:06 Message: Please make a patch (no need to ask permission first ;-) Out of curiosity - what kind of extension are you making that needs this feature? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=9789&group_id=797 From noreply at rubyforge.org Tue Apr 3 14:21:48 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 3 Apr 2007 14:21:48 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-9789 ] Make HtmlFormatter#extra_failure_content take the failure as a arg Message-ID: <20070403182148.9C6E05240CD3@rubyforge.org> Feature Requests item #9789, was opened at 2007-04-03 13:50 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=9789&group_id=797 Category: expectation module Group: None Status: Open Priority: 3 Submitted By: Mike Harris (gfunk911) Assigned to: Nobody (None) Summary: Make HtmlFormatter#extra_failure_content take the failure as a arg Initial Comment: It would be helpful if HtmlFormatter#extra_failure_content could take the failure as an arg, so it could produce content based on the failure. If the change was made to have rspec only pass the failure if the arity of failure is 1, it would also preserve existing behavior. I would be happy to code this and submit a patch if that would be helpful. ---------------------------------------------------------------------- >Comment By: Mike Harris (gfunk911) Date: 2007-04-03 14:21 Message: I'm running my specs with two formatters attached (specdoc and html). I have html content for certain failures that I only want to display in the html format. I just monkeypatched in the changes that I wanted, but I thought it could be a feature that others would find useful. I'll get that patch ready and submit it. Thanks. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-04-03 14:06 Message: Please make a patch (no need to ask permission first ;-) Out of curiosity - what kind of extension are you making that needs this feature? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=9789&group_id=797 From noreply at rubyforge.org Tue Apr 3 23:48:55 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 3 Apr 2007 23:48:55 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-9786 ] infer controller and helper names from the described type Message-ID: <20070404034855.407925240BE8@rubyforge.org> Feature Requests item #9786, was opened at 2007-04-03 15:16 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=9786&group_id=797 Category: rails plugin Group: None >Status: Closed Priority: 3 Submitted By: David Chelimsky (dchelimsky) >Assigned to: David Chelimsky (dchelimsky) Summary: infer controller and helper names from the described type Initial Comment: Now that we can do this: describe SomeThingController do it seems a shame to require this: controller_name :some_thing Controller Behavoiurs could be smart enough to see if a type is passed to #describe, and if it is a subclass of ActionController::Base, in which case it doesn't need to require controller_name Same goes for Helper Behaviours. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-04-04 03:48 Message: Added in branches/0.9-dev (rev 1685) ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=9786&group_id=797 From noreply at rubyforge.org Wed Apr 4 00:51:21 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 4 Apr 2007 00:51:21 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-9304 ] should_all < predicate> Message-ID: <20070404045121.6E2095240BE8@rubyforge.org> Feature Requests item #9304, was opened at 2007-03-15 14:58 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=9304&group_id=797 Category: expectation module Group: None Status: Open >Priority: 2 Submitted By: Chris Hoffman (hoffman_c) Assigned to: Nobody (None) Summary: should_all <predicate> Initial Comment: Hello, In order to check the properties of each element in a collection, one must presently do the following (as far as I can tell): mycollection = [2,3,5,7] mycollection.each { |num| num.should_be_prime } I suggest an improvement that would significantly increase the readability of these statement types: mycollection.should_all be_prime Keep up the good work! This software has made me into a better programmer. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-04-04 04:51 Message: Actually, you're original idea would be more flexible, though I think #should_each would be more ruby-ish: (1..10).should_each be < 11 While it does look pretty sweet, I'm not 100% sold on the real value of this yet. We've just taken great pains to un-pollute Object so I'm hesitant to add anything else to it. There are also some questions that come up like whether to add #should_each_not, or whether to fail on the first iteration that fails or collect them all. This could get quite a bit more complicated. All of that said, you can add this to your spec_helper and get the functionality you're looking for in the mean time. class Object def should_each(*args) each {|item| item.should(*args)} end end Cheers, David ---------------------------------------------------------------------- Comment By: Chris Hoffman (hoffman_c) Date: 2007-03-15 15:14 Message: Sure, that will work; I'm not intimate with your code base, so whatever you think is best as far as implementation would be great. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-03-15 15:11 Message: How about: mycollection.should all_be_prime Then we don't further pollute Object. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=9304&group_id=797 From noreply at rubyforge.org Wed Apr 4 05:45:46 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 4 Apr 2007 05:45:46 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-9295 ] rake spec should run anything in the spec directory (not just rspec's standard dirs) Message-ID: <20070404094546.E05715240957@rubyforge.org> Feature Requests item #9295, was opened at 2007-03-14 22:20 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=9295&group_id=797 Category: rails plugin Group: None >Status: Closed Priority: 3 Submitted By: David Chelimsky (dchelimsky) >Assigned to: Aslak Helles?y (aslak_hellesoy) Summary: rake spec should run anything in the spec directory (not just rspec's standard dirs) Initial Comment: >From email from Bob Martin: Recommend you add this to rspec.rake desc "Run all specs in spec directory" Spec::Rake::SpecTask.new(:all_specs => "db:test:prepare") do |t| t.spec_opts = ['--options', "\#{RAILS_ROOT}/spec/spec.opts\"] t.spec_files = FileList['spec/**/*_spec.rb'] end Perhaps this should BE the 'spec' task. ---------------------------------------------------------------------- >Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-04-04 05:45 Message: Fixed on branches/0.9-dev#1689 The convention for spec locations is not to put them under app as you suggest, but under the spec directory. spec/models, spec/controllers etc. As for wishing to add everything under app to the autoloader path, this sounds like a general Rails RFE. ---------------------------------------------------------------------- Comment By: Robert Martin (unclebob) Date: 2007-03-15 10:42 Message: I've only build one real rails app at this point. But before it got very large, I was creating subdirectories in the 'app/models' and 'app/specs' directory. I can't imaging that this isn't common practice. So my vote is for the default rake task to hunt out every subdirectory under spec, and execute any spec it finds. I also wish that every subdirectory under 'app' was automatically added to the rails autoloader path. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-03-14 22:32 Message: I added the task (rev 1602), but I'm not sure about making it the default. As we add more types of specs for stories and browser tests, I think this will become problematic. I do see some benefit in a task that runs the model/view/controller/helper specs in a single batch (rather than 4 separate batches, each w/ their own reload time). Should we make the default do that? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=9295&group_id=797 From noreply at rubyforge.org Wed Apr 4 05:49:57 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 4 Apr 2007 05:49:57 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-6523 ] Run rspec on rails without a db Message-ID: <20070404094957.E43BE5240957@rubyforge.org> Feature Requests item #6523, was opened at 2006-11-06 16:07 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6523&group_id=797 Category: None Group: None >Status: Closed Priority: 3 Submitted By: Paul Pagel (paulwpagel) >Assigned to: Aslak Helles?y (aslak_hellesoy) Summary: Run rspec on rails without a db Initial Comment: We need to be able to run the specs without the database. We have no model objects in some of our projects, therefore, no use for the db. ---------------------------------------------------------------------- >Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-04-04 05:49 Message: Fixed in /branches/0.9-dev#1689 If you remove config/database.yml from your Rails project, the various spec:* rake tasks will no longer depend on db:test:prepare. Further, you should tell Rails not to use AR in your config/environment.rb file ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-01 10:08 Message: Now that we have a cleaner configuration model, we should add a configuration option to do this: Spec::Runner.configure do |config| config.use_database = false end (or something like that) ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-06 20:28 Message: How do I reproduce this missing feature? How would you like it to work exactly? Code please. http://rspec.rubyforge.org/contribute.html ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6523&group_id=797 From aslak.hellesoy at gmail.com Wed Apr 4 12:33:01 2007 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Wed, 4 Apr 2007 18:33:01 +0200 Subject: [rspec-devel] ANN: RSpec 0.9.0 beta-1 available for download. Message-ID: <8d961d900704040933i6917b8dey25be2d1f4372a42b@mail.gmail.com> We'd like to get some feedback on RSpec 0.9 before we start pushing out releases via Rubyforge's gem server and update the website. We have therefore made the first beta of 0.9 available - both prepackaged and tagged in subversion (see below). RSpec 0.9 introduces a new API for expectations, which essentially means that your underscores go away (there has been other discussions on the lists about this). In addition to this, you can say describe/it instead of context/specify. We believe this will lead to even more readable - and well-written specs. (context/specify will still be supported for a while). == Translator == In order to ease the transition from 0.8 to 0.9, we have included a tool to translate your 0.8 style specs to 0.9 style. After installing the 0.9 gem, you should run: spec_translator path_to_my_spec_dir path_to_my_translated_spec_dir (or alternatively, if you have your code under version control and can do a revert if things go wrong:) spec_translator path_to_my_spec_dir path_to_my_spec_dir (This will translate your specs in-place) == Where to get it == RSpec core is available here: * http://rspec.rubyforge.org/rspec-0.9.0.gem * http://rspec.rubyforge.org/rspec-0.9.0.tgz * http://rspec.rubyforge.org/rspec-0.9.0.zip * http://rspec.rubyforge.org/RSpec-0.9.0.tmbundle.tgz == Rails users == For those of you who want to install 0.9 beta as plugins, the svn URLs are: * svn://rubyforge.org/var/svn/rspec/tags/REL_0_9_0_BETA_1/rspec * svn://rubyforge.org/var/svn/rspec/tags/REL_0_9_0_BETA_1/rspec_on_rails (Don't forget to do do a "script generate rspec" to update your local files) Cheers, Aslak From mtrier at eminentconsultinggroup.com Wed Apr 4 12:53:47 2007 From: mtrier at eminentconsultinggroup.com (Michael Trier) Date: Wed, 4 Apr 2007 12:53:47 -0400 Subject: [rspec-devel] [rspec-users] ANN: RSpec 0.9.0 beta-1 available for download. In-Reply-To: <8d961d900704040933i6917b8dey25be2d1f4372a42b@mail.gmail.com> References: <8d961d900704040933i6917b8dey25be2d1f4372a42b@mail.gmail.com> Message-ID: <9F9AF820-B756-4E1B-B5C1-44EEC828918F@eminentconsultinggroup.com> Thanks Aslak, David, and the rest of the team. Nice work. Michael On Apr 4, 2007, at 12:33 PM, aslak hellesoy wrote: > We'd like to get some feedback on RSpec 0.9 before we start pushing > out releases via Rubyforge's gem server and update the website. We > have therefore made the first beta of 0.9 available - both prepackaged > and tagged in subversion (see below). > > RSpec 0.9 introduces a new API for expectations, which essentially > means that your underscores go away (there has been other discussions > on the lists about this). In addition to this, you can say describe/it > instead of context/specify. We believe this will lead to even more > readable - and well-written specs. (context/specify will still be > supported for a while). > > == Translator == > In order to ease the transition from 0.8 to 0.9, we have included a > tool to translate your 0.8 style specs to 0.9 style. After installing > the 0.9 gem, you should run: > > spec_translator path_to_my_spec_dir path_to_my_translated_spec_dir > > (or alternatively, if you have your code under version control and can > do a revert if things go wrong:) > > spec_translator path_to_my_spec_dir path_to_my_spec_dir > > (This will translate your specs in-place) > > == Where to get it == > > RSpec core is available here: > > * http://rspec.rubyforge.org/rspec-0.9.0.gem > * http://rspec.rubyforge.org/rspec-0.9.0.tgz > * http://rspec.rubyforge.org/rspec-0.9.0.zip > * http://rspec.rubyforge.org/RSpec-0.9.0.tmbundle.tgz > > == Rails users == > For those of you who want to install 0.9 beta as plugins, the svn > URLs are: > * svn://rubyforge.org/var/svn/rspec/tags/REL_0_9_0_BETA_1/rspec > * svn://rubyforge.org/var/svn/rspec/tags/REL_0_9_0_BETA_1/ > rspec_on_rails > > (Don't forget to do do a "script generate rspec" to update your > local files) > > Cheers, > Aslak > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users From dchelimsky at gmail.com Wed Apr 4 14:16:50 2007 From: dchelimsky at gmail.com (David Chelimsky) Date: Wed, 4 Apr 2007 13:16:50 -0500 Subject: [rspec-devel] ANN: RSpec 0.9.0 beta-1 available for download. In-Reply-To: <8d961d900704040933i6917b8dey25be2d1f4372a42b@mail.gmail.com> References: <8d961d900704040933i6917b8dey25be2d1f4372a42b@mail.gmail.com> Message-ID: <57c63afe0704041116g37b8a562n70a8b1977e3de6dc@mail.gmail.com> On 4/4/07, aslak hellesoy wrote: > We'd like to get some feedback on RSpec 0.9 before we start pushing > out releases via Rubyforge's gem server and update the website. We > have therefore made the first beta of 0.9 available - both prepackaged > and tagged in subversion (see below). > > RSpec 0.9 introduces a new API for expectations, which essentially > means that your underscores go away (there has been other discussions > on the lists about this). In addition to this, you can say describe/it > instead of context/specify. We believe this will lead to even more > readable - and well-written specs. (context/specify will still be > supported for a while). > > == Translator == > In order to ease the transition from 0.8 to 0.9, we have included a > tool to translate your 0.8 style specs to 0.9 style. After installing > the 0.9 gem, you should run: > > spec_translator path_to_my_spec_dir path_to_my_translated_spec_dir > > (or alternatively, if you have your code under version control and can > do a revert if things go wrong:) > > spec_translator path_to_my_spec_dir path_to_my_spec_dir > > (This will translate your specs in-place) > > == Where to get it == > > RSpec core is available here: > > * http://rspec.rubyforge.org/rspec-0.9.0.gem > * http://rspec.rubyforge.org/rspec-0.9.0.tgz > * http://rspec.rubyforge.org/rspec-0.9.0.zip > * http://rspec.rubyforge.org/RSpec-0.9.0.tmbundle.tgz > > == Rails users == > For those of you who want to install 0.9 beta as plugins, the svn URLs are: > * svn://rubyforge.org/var/svn/rspec/tags/REL_0_9_0_BETA_1/rspec > * svn://rubyforge.org/var/svn/rspec/tags/REL_0_9_0_BETA_1/rspec_on_rails > > (Don't forget to do do a "script generate rspec" to update your local files) Since we haven't updated the website yet you can't see the change log w/o downloading it - here's some of what it has to say: * Sugar FREE! * Fixed [#6523] Run rspec on rails without a db * Fixed [#9295] rake spec should run anything in the spec directory (not just rspec's standard dirs) * Added [#9786] infer controller and helper names from the described type * Fixed [#7795] form_tag renders action='/view_spec' in view specs * Fixed [#9767] rspec_on_rails should not define rescue_action on controllers * Fixed [#9421] --line doesn't work with behaviours that use class names * Fixed [#9760] rspec generators incompatible with changes to edge rails * Added [#9786] infer controller and helper names from the described type * Applied a simplified version of [#9282] Change to allow running specs from textmate with rspec installed as a rails plugin (and no rspec gem installed) * Applied [#9700] Make Spec::DSL::Example#name public / Add a --timeout switch. A great way to prevent specs from getting slow. * In Rails, script/generate rspec will generate a spec.opts file that optimises faster/more efficient running of specs. * Added [#9522] support using rspec's expectations with test/unit * Moved rspec_on_rails up to the project root, simplifying the download url * Fixed [#8103] RSpec not installing spec script correctly. * The --spec option is replaced by the --example option. * The --loadby option no longer supports a file argument. Use --example file_name instead. * The --example option can now take a file name as an argument. The file should contain example names. * New --failures option which will write out a file that can later be used with --example. * Internal classes are named Behaviour/Example (rather than Context/Specification). * You can now use mocha by saying config.mock_with :mocha in a spec_helper * before_context_eval is replaced by before_eval. * Applied [#9509] allow spaced options in spec.opts * Applied [#9510] Added File for Ruby 1.8.6 * Applied [#9511] Clarification to README file in spec/ * Moved all of the Spec::Rails specs down to the plugins directory - now you can run the specs after you install. * Updated RSpec.tmbundle to the 0.9 syntax and replaced context/specify with describe/it. * Applied [#9232] ActionController::Base#render is sometimes protected (patch from Dan Manges) * Added --reverse option, allowing contexts/specs to be run in reverse order. * Added --loadby option, allowing better control over load order for spec files. mtime and file.txt supported. * Implemented [#8696] --order option (see --reverse and --loadby) * Added describe/it as aliases for context/specify - suggestion from Dan North. * Applied [#7637] [PATCH] add skip-migration option to rspec_resource generator * Added [#9167] string.should have_tag * Changed script/rails_spec_server to script/spec_server and added script/spec (w/ path to vendor/plugins/rspec) * Fixed [#8897] Error when mixing controller spec with/without integrated views and using template system other than rhtml * Updated sample app specs to 0.9 syntax * Updated generated specs to 0.9 syntax * Applied [#8994] trunk: generated names for be_ specs (Multiple patches from Yurii Rashkovskii) I've been blogging about some of the new features, and will continue to do so. Aslak and Dave also blog about rspec features from time to time so check their blogs out as well: http://blog.davidchelimsky.net/ http://blog.aslakhellesoy.com/ http://blog.daveastels.com/ Cheers, David > > Cheers, > Aslak > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From dchelimsky at gmail.com Wed Apr 4 14:34:32 2007 From: dchelimsky at gmail.com (David Chelimsky) Date: Wed, 4 Apr 2007 13:34:32 -0500 Subject: [rspec-devel] moving 0.9 to trunk Message-ID: <57c63afe0704041134j4ab00784ne58a838fcf00efe3@mail.gmail.com> Heads up for those of you who have been using trunk or branches/0.9-dev: I'm going to be moving them around in the next day or so. What is now in trunk will move to branches/0.8-maintenance, and what is now in branches/0.9-dev will move to trunk. I'll email shortly before and after this happens, but I figured I'd give you some advanced warning. David From noreply at rubyforge.org Wed Apr 4 14:48:14 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 4 Apr 2007 14:48:14 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-9841 ] RSpec 0.9.0 (rspec_on_rails) rake task doesn't work for all spec:models/controllers/etc Message-ID: <20070404184814.DCEB25240C40@rubyforge.org> Bugs item #9841, was opened at 2007-04-04 14:48 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=9841&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Chad Humphries (spicycode) Assigned to: Nobody (None) Summary: RSpec 0.9.0 (rspec_on_rails) rake task doesn't work for all spec:models/controllers/etc Initial Comment: rspec_on_rails/tasks/rspec.rake Task was: [:models, :controllers, :views, :helpers].each do |sub| desc "Run the specs under spec/#{sub}" Spec::Rake::SpecTask.new(sub => spec_prereq) do |t| t.spec_opts = ['--options', "\#{RAILS_ROOT}/spec/spec.opts\"] t.spec_files = FileList['spec/#{sub}/**/*_spec.rb'] end end Should be: [:models, :controllers, :views, :helpers].each do |sub| desc "Run the specs under spec/#{sub}" Spec::Rake::SpecTask.new(sub => spec_prereq) do |t| t.spec_opts = ['--options', "\#{RAILS_ROOT}/spec/spec.opts\"] t.spec_files = FileList["spec/#{sub}/**/*_spec.rb"] end end ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=9841&group_id=797 From noreply at rubyforge.org Wed Apr 4 14:59:25 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 4 Apr 2007 14:59:25 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-9842 ] Cannot run specs due to fixture error Message-ID: <20070404185925.A6C2E5240BE6@rubyforge.org> Bugs item #9842, was opened at 2007-04-04 14:59 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=9842&group_id=797 Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: Chad Humphries (spicycode) Assigned to: Nobody (None) Summary: Cannot run specs due to fixture error Initial Comment: New EdgeRails Project with 0.9.0 RSpec + RSpec On Rails Frozen in vendor/plugins project_here/vendor/plugins/rspec_on_rails/lib/spec/rails/dsl/behaviour/base.rb:32:in `configure': undefined method `fixtures' for # The model spec has no reference of fixtures in it, the spec_helper is vanilla/the default, and the app actually contacts no fixtures. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=9842&group_id=797 From noreply at rubyforge.org Wed Apr 4 15:04:12 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 4 Apr 2007 15:04:12 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-9841 ] RSpec 0.9.0 (rspec_on_rails) rake task doesn't work for all spec:models/controllers/etc Message-ID: <20070404190412.7138E5240CC4@rubyforge.org> Bugs item #9841, was opened at 2007-04-04 18:48 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=9841&group_id=797 >Category: rails plugin Group: None >Status: Closed >Resolution: Accepted Priority: 3 Submitted By: Chad Humphries (spicycode) >Assigned to: David Chelimsky (dchelimsky) Summary: RSpec 0.9.0 (rspec_on_rails) rake task doesn't work for all spec:models/controllers/etc Initial Comment: rspec_on_rails/tasks/rspec.rake Task was: [:models, :controllers, :views, :helpers].each do |sub| desc "Run the specs under spec/#{sub}" Spec::Rake::SpecTask.new(sub => spec_prereq) do |t| t.spec_opts = ['--options', "\#{RAILS_ROOT}/spec/spec.opts\"] t.spec_files = FileList['spec/#{sub}/**/*_spec.rb'] end end Should be: [:models, :controllers, :views, :helpers].each do |sub| desc "Run the specs under spec/#{sub}" Spec::Rake::SpecTask.new(sub => spec_prereq) do |t| t.spec_opts = ['--options', "\#{RAILS_ROOT}/spec/spec.opts\"] t.spec_files = FileList["spec/#{sub}/**/*_spec.rb"] end end ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-04-04 19:04 Message: Fixed in branches/0.9-dev #1696 Thanks for the fix Chad. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=9841&group_id=797 From noreply at rubyforge.org Wed Apr 4 15:17:11 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 4 Apr 2007 15:17:11 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-9842 ] Cannot run specs due to fixture error Message-ID: <20070404191711.1E0D05240BE6@rubyforge.org> Bugs item #9842, was opened at 2007-04-04 18:59 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=9842&group_id=797 Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: Chad Humphries (spicycode) Assigned to: Nobody (None) Summary: Cannot run specs due to fixture error Initial Comment: New EdgeRails Project with 0.9.0 RSpec + RSpec On Rails Frozen in vendor/plugins project_here/vendor/plugins/rspec_on_rails/lib/spec/rails/dsl/behaviour/base.rb:32:in `configure': undefined method `fixtures' for # The model spec has no reference of fixtures in it, the spec_helper is vanilla/the default, and the app actually contacts no fixtures. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-04-04 19:17 Message: how are you running the example? what command? from what directory? on what platform? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=9842&group_id=797 From noreply at rubyforge.org Wed Apr 4 15:19:40 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 4 Apr 2007 15:19:40 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-9607 ] Rails 2.0 render issue Message-ID: <20070404191940.74DEC5240BE6@rubyforge.org> Bugs item #9607, was opened at 2007-03-27 07:19 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=9607&group_id=797 Category: rails plugin Group: None >Status: Closed >Resolution: Out of Date Priority: 3 Submitted By: Zach Inglis (zachinglis) >Assigned to: David Chelimsky (dchelimsky) Summary: Rails 2.0 render issue Initial Comment: rspec gives the code: render 'controller/action' which is not allowed in Rails 2.0 and will give you an error. It should render: render :controller => "controller", :action => "action" ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-04-04 19:19 Message: I'm not quite sure what this is talking about. The generated specs are run against rails edge and 1.1.6 through 1.2.3 and there are no problems. I'm going to close this assuming that it's an obsolete issue, but if you can provide us with a specific example that's failing we'll be glad to look at it again. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-03-30 06:01 Message: Is Rails 2.0 the same as http://svn.rubyonrails.org/rails/trunk/ ? If not, what's the svn URL? ---------------------------------------------------------------------- Comment By: Scott Taylor (smtlaissezfaire) Date: 2007-03-30 05:31 Message: Is this in one of the generators? ---------------------------------------------------------------------- Comment By: Zach Inglis (zachinglis) Date: 2007-03-30 05:26 Message: Anyone? ---------------------------------------------------------------------- Comment By: Zach Inglis (zachinglis) Date: 2007-03-27 07:25 Message: err, actually the substitute code gives me an error. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=9607&group_id=797 From noreply at rubyforge.org Wed Apr 4 15:24:18 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 4 Apr 2007 15:24:18 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-9842 ] Cannot run specs due to fixture error Message-ID: <20070404192418.280695240AE4@rubyforge.org> Bugs item #9842, was opened at 2007-04-04 14:59 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=9842&group_id=797 Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: Chad Humphries (spicycode) Assigned to: Nobody (None) Summary: Cannot run specs due to fixture error Initial Comment: New EdgeRails Project with 0.9.0 RSpec + RSpec On Rails Frozen in vendor/plugins project_here/vendor/plugins/rspec_on_rails/lib/spec/rails/dsl/behaviour/base.rb:32:in `configure': undefined method `fixtures' for # The model spec has no reference of fixtures in it, the spec_helper is vanilla/the default, and the app actually contacts no fixtures. ---------------------------------------------------------------------- >Comment By: Chad Humphries (spicycode) Date: 2007-04-04 15:24 Message: - OSX 10.4.9 (Intel) - Ruby 1.8.6 - EdgeRails - Rspec/RspecOnRails/SpecUi 0.9.0 as a svn:external plugin Running the spec using either script/spec spec/models/model_spec.rb or via rake spec/rake spec:models ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-04 15:17 Message: how are you running the example? what command? from what directory? on what platform? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=9842&group_id=797 From noreply at rubyforge.org Wed Apr 4 15:27:43 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 4 Apr 2007 15:27:43 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-9842 ] Cannot run specs due to fixture error Message-ID: <20070404192743.4EF3B5240AE4@rubyforge.org> Bugs item #9842, was opened at 2007-04-04 14:59 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=9842&group_id=797 Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: Chad Humphries (spicycode) Assigned to: Nobody (None) Summary: Cannot run specs due to fixture error Initial Comment: New EdgeRails Project with 0.9.0 RSpec + RSpec On Rails Frozen in vendor/plugins project_here/vendor/plugins/rspec_on_rails/lib/spec/rails/dsl/behaviour/base.rb:32:in `configure': undefined method `fixtures' for # The model spec has no reference of fixtures in it, the spec_helper is vanilla/the default, and the app actually contacts no fixtures. ---------------------------------------------------------------------- >Comment By: Chad Humphries (spicycode) Date: 2007-04-04 15:27 Message: Commenting out line 32 of spec/rails/dsl/behaviour resolves it, but not sure why at the moment. # fixtures global_fixtures if global_fixtures ---------------------------------------------------------------------- Comment By: Chad Humphries (spicycode) Date: 2007-04-04 15:24 Message: - OSX 10.4.9 (Intel) - Ruby 1.8.6 - EdgeRails - Rspec/RspecOnRails/SpecUi 0.9.0 as a svn:external plugin Running the spec using either script/spec spec/models/model_spec.rb or via rake spec/rake spec:models ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-04 15:17 Message: how are you running the example? what command? from what directory? on what platform? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=9842&group_id=797 From noreply at rubyforge.org Wed Apr 4 15:34:54 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 4 Apr 2007 15:34:54 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-9842 ] Cannot run specs due to fixture error Message-ID: <20070404193454.AB9BD5240C0F@rubyforge.org> Bugs item #9842, was opened at 2007-04-04 18:59 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=9842&group_id=797 Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: Chad Humphries (spicycode) Assigned to: Nobody (None) Summary: Cannot run specs due to fixture error Initial Comment: New EdgeRails Project with 0.9.0 RSpec + RSpec On Rails Frozen in vendor/plugins project_here/vendor/plugins/rspec_on_rails/lib/spec/rails/dsl/behaviour/base.rb:32:in `configure': undefined method `fixtures' for # The model spec has no reference of fixtures in it, the spec_helper is vanilla/the default, and the app actually contacts no fixtures. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-04-04 19:34 Message: I haven't installed 1.8.6 and that may be part of the problem on my end. Would you please uncomment the line and run: script/spec spec/models -b and show us the backtrace? Thanks ---------------------------------------------------------------------- Comment By: Chad Humphries (spicycode) Date: 2007-04-04 19:27 Message: Commenting out line 32 of spec/rails/dsl/behaviour resolves it, but not sure why at the moment. # fixtures global_fixtures if global_fixtures ---------------------------------------------------------------------- Comment By: Chad Humphries (spicycode) Date: 2007-04-04 19:24 Message: - OSX 10.4.9 (Intel) - Ruby 1.8.6 - EdgeRails - Rspec/RspecOnRails/SpecUi 0.9.0 as a svn:external plugin Running the spec using either script/spec spec/models/model_spec.rb or via rake spec/rake spec:models ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-04 19:17 Message: how are you running the example? what command? from what directory? on what platform? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=9842&group_id=797 From noreply at rubyforge.org Wed Apr 4 15:38:22 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 4 Apr 2007 15:38:22 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-9842 ] Cannot run specs due to fixture error Message-ID: <20070404193822.AB3E25240C40@rubyforge.org> Bugs item #9842, was opened at 2007-04-04 14:59 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=9842&group_id=797 Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: Chad Humphries (spicycode) Assigned to: Nobody (None) Summary: Cannot run specs due to fixture error Initial Comment: New EdgeRails Project with 0.9.0 RSpec + RSpec On Rails Frozen in vendor/plugins project_here/vendor/plugins/rspec_on_rails/lib/spec/rails/dsl/behaviour/base.rb:32:in `configure': undefined method `fixtures' for # The model spec has no reference of fixtures in it, the spec_helper is vanilla/the default, and the app actually contacts no fixtures. ---------------------------------------------------------------------- >Comment By: Chad Humphries (spicycode) Date: 2007-04-04 15:38 Message: ~ script/spec spec/models -b ~/test_project/vendor/plugins/rspec_on_rails/lib/spec/rails/dsl/behaviour/base.rb:32:in `configure': undefined method `fixtures' for # (NoMethodError) from ~/test_project/vendor/plugins/rspec/lib/spec/dsl/behaviour_eval.rb:46:in `send' from ~/test_project/vendor/plugins/rspec/lib/spec/dsl/behaviour_eval.rb:46:in `method_missing' from ~/test_project/vendor/plugins/rspec/lib/spec/dsl/behaviour.rb:91:in `send' from ~/test_project/vendor/plugins/rspec/lib/spec/dsl/behaviour.rb:91:in `method_missing' from ~/test_project/vendor/plugins/rspec_on_rails/lib/spec/rails/dsl/behaviour/model.rb:12:in `before_eval' from ~/test_project/vendor/plugins/rspec/lib/spec/dsl/behaviour.rb:25:in `initialize' from ~/test_project/vendor/plugins/rspec_on_rails/lib/spec/rails/dsl/behaviour_factory.rb:36:in `new' from ~/test_project/vendor/plugins/rspec_on_rails/lib/spec/rails/dsl/behaviour_factory.rb:36:in `create' from ~/test_project/vendor/plugins/rspec_on_rails/lib/spec/rails/extensions/kernel.rb:4:in `describe' from ./spec/models/account_spec.rb:3 from ~/test_project/vendor/plugins/rspec/lib/spec/runner/behaviour_runner.rb:81:in `load' from ~/test_project/vendor/plugins/rspec/lib/spec/runner/behaviour_runner.rb:81:in `load_specs' from ~/test_project/vendor/plugins/rspec/lib/spec/runner/behaviour_runner.rb:80:in `each' from ~/test_project/vendor/plugins/rspec/lib/spec/runner/behaviour_runner.rb:80:in `load_specs' from ~/test_project/vendor/plugins/rspec/lib/spec/runner/behaviour_runner.rb:22:in `run' from ~/test_project/vendor/plugins/rspec/lib/spec/runner/command_line.rb:17:in `run' from script/spec:4 ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-04 15:34 Message: I haven't installed 1.8.6 and that may be part of the problem on my end. Would you please uncomment the line and run: script/spec spec/models -b and show us the backtrace? Thanks ---------------------------------------------------------------------- Comment By: Chad Humphries (spicycode) Date: 2007-04-04 15:27 Message: Commenting out line 32 of spec/rails/dsl/behaviour resolves it, but not sure why at the moment. # fixtures global_fixtures if global_fixtures ---------------------------------------------------------------------- Comment By: Chad Humphries (spicycode) Date: 2007-04-04 15:24 Message: - OSX 10.4.9 (Intel) - Ruby 1.8.6 - EdgeRails - Rspec/RspecOnRails/SpecUi 0.9.0 as a svn:external plugin Running the spec using either script/spec spec/models/model_spec.rb or via rake spec/rake spec:models ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-04 15:17 Message: how are you running the example? what command? from what directory? on what platform? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=9842&group_id=797 From noreply at rubyforge.org Wed Apr 4 15:54:33 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 4 Apr 2007 15:54:33 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-9842 ] Cannot run specs due to fixture error Message-ID: <20070404195433.A11D05240AE4@rubyforge.org> Bugs item #9842, was opened at 2007-04-04 18:59 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=9842&group_id=797 Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: Chad Humphries (spicycode) Assigned to: Nobody (None) Summary: Cannot run specs due to fixture error Initial Comment: New EdgeRails Project with 0.9.0 RSpec + RSpec On Rails Frozen in vendor/plugins project_here/vendor/plugins/rspec_on_rails/lib/spec/rails/dsl/behaviour/base.rb:32:in `configure': undefined method `fixtures' for # The model spec has no reference of fixtures in it, the spec_helper is vanilla/the default, and the app actually contacts no fixtures. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-04-04 19:54 Message: This is really bizarre. I'm able to run model specs w/ no fixtures against 1.8.6 (using multiruby - man, that rocks!) with no problem. Would you mind terribly zipping up your project and attaching it to this RFE? If you don't want it public, just email it to me directly. Thanks, David ---------------------------------------------------------------------- Comment By: Chad Humphries (spicycode) Date: 2007-04-04 19:38 Message: ~ script/spec spec/models -b ~/test_project/vendor/plugins/rspec_on_rails/lib/spec/rails/dsl/behaviour/base.rb:32:in `configure': undefined method `fixtures' for # (NoMethodError) from ~/test_project/vendor/plugins/rspec/lib/spec/dsl/behaviour_eval.rb:46:in `send' from ~/test_project/vendor/plugins/rspec/lib/spec/dsl/behaviour_eval.rb:46:in `method_missing' from ~/test_project/vendor/plugins/rspec/lib/spec/dsl/behaviour.rb:91:in `send' from ~/test_project/vendor/plugins/rspec/lib/spec/dsl/behaviour.rb:91:in `method_missing' from ~/test_project/vendor/plugins/rspec_on_rails/lib/spec/rails/dsl/behaviour/model.rb:12:in `before_eval' from ~/test_project/vendor/plugins/rspec/lib/spec/dsl/behaviour.rb:25:in `initialize' from ~/test_project/vendor/plugins/rspec_on_rails/lib/spec/rails/dsl/behaviour_factory.rb:36:in `new' from ~/test_project/vendor/plugins/rspec_on_rails/lib/spec/rails/dsl/behaviour_factory.rb:36:in `create' from ~/test_project/vendor/plugins/rspec_on_rails/lib/spec/rails/extensions/kernel.rb:4:in `describe' from ./spec/models/account_spec.rb:3 from ~/test_project/vendor/plugins/rspec/lib/spec/runner/behaviour_runner.rb:81:in `load' from ~/test_project/vendor/plugins/rspec/lib/spec/runner/behaviour_runner.rb:81:in `load_specs' from ~/test_project/vendor/plugins/rspec/lib/spec/runner/behaviour_runner.rb:80:in `each' from ~/test_project/vendor/plugins/rspec/lib/spec/runner/behaviour_runner.rb:80:in `load_specs' from ~/test_project/vendor/plugins/rspec/lib/spec/runner/behaviour_runner.rb:22:in `run' from ~/test_project/vendor/plugins/rspec/lib/spec/runner/command_line.rb:17:in `run' from script/spec:4 ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-04 19:34 Message: I haven't installed 1.8.6 and that may be part of the problem on my end. Would you please uncomment the line and run: script/spec spec/models -b and show us the backtrace? Thanks ---------------------------------------------------------------------- Comment By: Chad Humphries (spicycode) Date: 2007-04-04 19:27 Message: Commenting out line 32 of spec/rails/dsl/behaviour resolves it, but not sure why at the moment. # fixtures global_fixtures if global_fixtures ---------------------------------------------------------------------- Comment By: Chad Humphries (spicycode) Date: 2007-04-04 19:24 Message: - OSX 10.4.9 (Intel) - Ruby 1.8.6 - EdgeRails - Rspec/RspecOnRails/SpecUi 0.9.0 as a svn:external plugin Running the spec using either script/spec spec/models/model_spec.rb or via rake spec/rake spec:models ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-04 19:17 Message: how are you running the example? what command? from what directory? on what platform? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=9842&group_id=797 From noreply at rubyforge.org Thu Apr 5 00:16:10 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 5 Apr 2007 00:16:10 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-9852 ] Patch for RSpec's Website using Webgen 0.4.2 Message-ID: <20070405041611.40F085240CCE@rubyforge.org> Patches item #9852, was opened at 2007-04-05 04:16 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=9852&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Scott Taylor (smtlaissezfaire) Assigned to: Nobody (None) Summary: Patch for RSpec's Website using Webgen 0.4.2 Initial Comment: We can now use the 0.4.2 version of webgen to generate the docs. The main patch is of the new content parser in doc/plugin/syntax.rb Several other little things have changed, including: 1. the main template file, which now uses block: instead of content: 2. the css file 3. the other plugin for webgen 4. the meta.info files have all been deleted. They are now consolidated into metainfo.yaml in the doc/ directory, with several small changes to work w/ webgen 042 5. a slight change to config.yaml, which uses the new ContentParser in syntax.rb 6. a change to the README so that webgen 0.3.8 is no longer referenced. Diffing the old and new output/ directories seems to give only changes generated by the new version of webgen, and slight changes in how html tags are output. The only noticable difference is that some pre tags aren't surrounded by paragraph tags. You can see the difference in the spacing under the heading "Example Controller Specs" on the page documentation/rails/writing/controllers.html ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=9852&group_id=797 From mailing_lists at railsnewbie.com Thu Apr 5 00:27:49 2007 From: mailing_lists at railsnewbie.com (Scott Taylor) Date: Thu, 5 Apr 2007 00:27:49 -0400 Subject: [rspec-devel] ANN: RSpec 0.9.0 beta-1 available for download. In-Reply-To: <57c63afe0704041116g37b8a562n70a8b1977e3de6dc@mail.gmail.com> References: <8d961d900704040933i6917b8dey25be2d1f4372a42b@mail.gmail.com> <57c63afe0704041116g37b8a562n70a8b1977e3de6dc@mail.gmail.com> Message-ID: <6964BFC6-16B2-45CD-A78E-35809FABE855@railsnewbie.com> Wow. You guys are super productive. Good job! So when can I officially become a junior developer? Scott On Apr 4, 2007, at 2:16 PM, David Chelimsky wrote: > On 4/4/07, aslak hellesoy wrote: >> We'd like to get some feedback on RSpec 0.9 before we start pushing >> out releases via Rubyforge's gem server and update the website. We >> have therefore made the first beta of 0.9 available - both >> prepackaged >> and tagged in subversion (see below). >> >> RSpec 0.9 introduces a new API for expectations, which essentially >> means that your underscores go away (there has been other discussions >> on the lists about this). In addition to this, you can say >> describe/it >> instead of context/specify. We believe this will lead to even more >> readable - and well-written specs. (context/specify will still be >> supported for a while). >> >> == Translator == >> In order to ease the transition from 0.8 to 0.9, we have included a >> tool to translate your 0.8 style specs to 0.9 style. After installing >> the 0.9 gem, you should run: >> >> spec_translator path_to_my_spec_dir path_to_my_translated_spec_dir >> >> (or alternatively, if you have your code under version control and >> can >> do a revert if things go wrong:) >> >> spec_translator path_to_my_spec_dir path_to_my_spec_dir >> >> (This will translate your specs in-place) >> >> == Where to get it == >> >> RSpec core is available here: >> >> * http://rspec.rubyforge.org/rspec-0.9.0.gem >> * http://rspec.rubyforge.org/rspec-0.9.0.tgz >> * http://rspec.rubyforge.org/rspec-0.9.0.zip >> * http://rspec.rubyforge.org/RSpec-0.9.0.tmbundle.tgz >> >> == Rails users == >> For those of you who want to install 0.9 beta as plugins, the svn >> URLs are: >> * svn://rubyforge.org/var/svn/rspec/tags/REL_0_9_0_BETA_1/rspec >> * svn://rubyforge.org/var/svn/rspec/tags/REL_0_9_0_BETA_1/ >> rspec_on_rails >> >> (Don't forget to do do a "script generate rspec" to update your >> local files) > > Since we haven't updated the website yet you can't see the change log > w/o downloading it - here's some of what it has to say: > > * Sugar FREE! > * Fixed [#6523] Run rspec on rails without a db > * Fixed [#9295] rake spec should run anything in the spec directory > (not just rspec's standard dirs) > * Added [#9786] infer controller and helper names from the > described type > * Fixed [#7795] form_tag renders action='/view_spec' in view specs > * Fixed [#9767] rspec_on_rails should not define rescue_action on > controllers > * Fixed [#9421] --line doesn't work with behaviours that use class > names > * Fixed [#9760] rspec generators incompatible with changes to edge > rails > * Added [#9786] infer controller and helper names from the > described type > * Applied a simplified version of [#9282] Change to allow running > specs from textmate with rspec installed as a rails plugin (and no > rspec gem installed) > * Applied [#9700] Make Spec::DSL::Example#name public / Add a > --timeout switch. A great way to prevent specs from getting slow. > * In Rails, script/generate rspec will generate a spec.opts file that > optimises faster/more efficient running of specs. > * Added [#9522] support using rspec's expectations with test/unit > * Moved rspec_on_rails up to the project root, simplifying the > download url > * Fixed [#8103] RSpec not installing spec script correctly. > * The --spec option is replaced by the --example option. > * The --loadby option no longer supports a file argument. Use > --example file_name instead. > * The --example option can now take a file name as an argument. The > file should contain example names. > * New --failures option which will write out a file that can later be > used with --example. > * Internal classes are named Behaviour/Example (rather than > Context/Specification). > * You can now use mocha by saying config.mock_with :mocha in a > spec_helper > * before_context_eval is replaced by before_eval. > * Applied [#9509] allow spaced options in spec.opts > * Applied [#9510] Added File for Ruby 1.8.6 > * Applied [#9511] Clarification to README file in spec/ > * Moved all of the Spec::Rails specs down to the plugins directory - > now you can run the specs after you install. > * Updated RSpec.tmbundle to the 0.9 syntax and replaced > context/specify with describe/it. > * Applied [#9232] ActionController::Base#render is sometimes protected > (patch from Dan Manges) > * Added --reverse option, allowing contexts/specs to be run in > reverse order. > * Added --loadby option, allowing better control over load order for > spec files. mtime and file.txt supported. > * Implemented [#8696] --order option (see --reverse and --loadby) > * Added describe/it as aliases for context/specify - suggestion > from Dan North. > * Applied [#7637] [PATCH] add skip-migration option to > rspec_resource generator > * Added [#9167] string.should have_tag > * Changed script/rails_spec_server to script/spec_server and added > script/spec (w/ path to vendor/plugins/rspec) > * Fixed [#8897] Error when mixing controller spec with/without > integrated views and using template system other than rhtml > * Updated sample app specs to 0.9 syntax > * Updated generated specs to 0.9 syntax > * Applied [#8994] trunk: generated names for be_ specs (Multiple > patches from Yurii Rashkovskii) > > I've been blogging about some of the new features, and will continue > to do so. Aslak and Dave also blog about rspec features from time to > time so check their blogs out as well: > > http://blog.davidchelimsky.net/ > http://blog.aslakhellesoy.com/ > http://blog.daveastels.com/ > > Cheers, > David > >> >> Cheers, >> Aslak >> _______________________________________________ >> rspec-devel mailing list >> rspec-devel at rubyforge.org >> http://rubyforge.org/mailman/listinfo/rspec-devel >> > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel From noreply at rubyforge.org Thu Apr 5 06:41:01 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 5 Apr 2007 06:41:01 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-9852 ] Patch for RSpec's Website using Webgen 0.4.2 Message-ID: <20070405104101.3FDA45240950@rubyforge.org> Patches item #9852, was opened at 2007-04-05 04:16 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=9852&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Scott Taylor (smtlaissezfaire) >Assigned to: David Chelimsky (dchelimsky) Summary: Patch for RSpec's Website using Webgen 0.4.2 Initial Comment: We can now use the 0.4.2 version of webgen to generate the docs. The main patch is of the new content parser in doc/plugin/syntax.rb Several other little things have changed, including: 1. the main template file, which now uses block: instead of content: 2. the css file 3. the other plugin for webgen 4. the meta.info files have all been deleted. They are now consolidated into metainfo.yaml in the doc/ directory, with several small changes to work w/ webgen 042 5. a slight change to config.yaml, which uses the new ContentParser in syntax.rb 6. a change to the README so that webgen 0.3.8 is no longer referenced. Diffing the old and new output/ directories seems to give only changes generated by the new version of webgen, and slight changes in how html tags are output. The only noticable difference is that some pre tags aren't surrounded by paragraph tags. You can see the difference in the spacing under the heading "Example Controller Specs" on the page documentation/rails/writing/controllers.html ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=9852&group_id=797 From noreply at rubyforge.org Thu Apr 5 07:11:09 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 5 Apr 2007 07:11:09 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-9852 ] Patch for RSpec's Website using Webgen 0.4.2 Message-ID: <20070405111109.392C8524097D@rubyforge.org> Patches item #9852, was opened at 2007-04-05 04:16 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=9852&group_id=797 Category: None Group: None >Status: Closed >Resolution: Accepted Priority: 3 Submitted By: Scott Taylor (smtlaissezfaire) Assigned to: David Chelimsky (dchelimsky) Summary: Patch for RSpec's Website using Webgen 0.4.2 Initial Comment: We can now use the 0.4.2 version of webgen to generate the docs. The main patch is of the new content parser in doc/plugin/syntax.rb Several other little things have changed, including: 1. the main template file, which now uses block: instead of content: 2. the css file 3. the other plugin for webgen 4. the meta.info files have all been deleted. They are now consolidated into metainfo.yaml in the doc/ directory, with several small changes to work w/ webgen 042 5. a slight change to config.yaml, which uses the new ContentParser in syntax.rb 6. a change to the README so that webgen 0.3.8 is no longer referenced. Diffing the old and new output/ directories seems to give only changes generated by the new version of webgen, and slight changes in how html tags are output. The only noticable difference is that some pre tags aren't surrounded by paragraph tags. You can see the difference in the spacing under the heading "Example Controller Specs" on the page documentation/rails/writing/controllers.html ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-04-05 11:11 Message: Applied to branches/0.9-dev #1697 Nice patch Scott. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=9852&group_id=797 From noreply at rubyforge.org Thu Apr 5 14:44:29 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 5 Apr 2007 14:44:29 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-9882 ] 0.9 Beta 1 - translator bugs Message-ID: <20070405184429.94AD452409A1@rubyforge.org> Bugs item #9882, was opened at 2007-04-05 18:44 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=9882&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: David Chelimsky (dchelimsky) Assigned to: Nobody (None) Summary: 0.9 Beta 1 - translator bugs Initial Comment: >From email from Wincent Colaiuta to the rspec users list: The included translator did a pretty good job on a fairly large project ("svn diff" on the working copy after the translation yielded over 3,000 lines of diffs) with only a few minor issues for which I'll paste in samples. (Tried to post this to the RubyForge issue tracker but I can't stay logged in long enough to open the ticket because of an invisible anonymous proxy in place thanks to my ISP...) Whitespace between specs and comments eaten: - lambda { @instance.foo = foo }.should_raise NoMethodError # no writer defined + lambda { @instance.foo = foo }.should raise_error (NoMethodError)# no writer defined Incorrect parentheses around method invocations with parameters: - AndPredicate.new('foo').should_eql AndPredicate.new('foo') + AndPredicate.new('foo').should eql(AndPredicate.new)('foo') Unnecessary parens: - Node.subclass('FooNode').should_not_be_nil + Node.subclass('FooNode').should_not be_nil() Missing parentheses, yields "parenthesize argument(s) for future version" warnings when running specs: - lambda { sequence.parse ('bar') }.should_throw :ZeroWidthParseSuccess + lambda { sequence.parse('bar') }.should throw_symbol :ZeroWidthParseSuccess Another example: - @parslet.should_eql @parslet.clone + @parslet.should eql @parslet.clone Another case of misplaced parens: - @parslet.should_not_eql lambda { nil }.to_parseable + @parslet.should_not eql(lambda){ nil }.to_parseable Another: - results.should_be_kind_of SimpleASTLanguage::Identifier + results.should be_kind_of(SimpleASTLanguage)::Identifier Apart from that, no major issues. All specs continued to pass after 0.90, and the updated TextMate bundle works brilliantly. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=9882&group_id=797 From noreply at rubyforge.org Thu Apr 5 19:03:27 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 5 Apr 2007 19:03:27 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-9882 ] 0.9 Beta 1 - translator bugs Message-ID: <20070405230327.A5C2B5240A3E@rubyforge.org> Bugs item #9882, was opened at 2007-04-05 18:44 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=9882&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: David Chelimsky (dchelimsky) Assigned to: Nobody (None) Summary: 0.9 Beta 1 - translator bugs Initial Comment: >From email from Wincent Colaiuta to the rspec users list: The included translator did a pretty good job on a fairly large project ("svn diff" on the working copy after the translation yielded over 3,000 lines of diffs) with only a few minor issues for which I'll paste in samples. (Tried to post this to the RubyForge issue tracker but I can't stay logged in long enough to open the ticket because of an invisible anonymous proxy in place thanks to my ISP...) Whitespace between specs and comments eaten: - lambda { @instance.foo = foo }.should_raise NoMethodError # no writer defined + lambda { @instance.foo = foo }.should raise_error (NoMethodError)# no writer defined Incorrect parentheses around method invocations with parameters: - AndPredicate.new('foo').should_eql AndPredicate.new('foo') + AndPredicate.new('foo').should eql(AndPredicate.new)('foo') Unnecessary parens: - Node.subclass('FooNode').should_not_be_nil + Node.subclass('FooNode').should_not be_nil() Missing parentheses, yields "parenthesize argument(s) for future version" warnings when running specs: - lambda { sequence.parse ('bar') }.should_throw :ZeroWidthParseSuccess + lambda { sequence.parse('bar') }.should throw_symbol :ZeroWidthParseSuccess Another example: - @parslet.should_eql @parslet.clone + @parslet.should eql @parslet.clone Another case of misplaced parens: - @parslet.should_not_eql lambda { nil }.to_parseable + @parslet.should_not eql(lambda){ nil }.to_parseable Another: - results.should_be_kind_of SimpleASTLanguage::Identifier + results.should be_kind_of(SimpleASTLanguage)::Identifier Apart from that, no major issues. All specs continued to pass after 0.90, and the updated TextMate bundle works brilliantly. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-04-05 23:03 Message: Addressed all but the "whitespace before comment" issue in rev 1702 of branches/0.9-dev. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=9882&group_id=797 From dchelimsky at gmail.com Thu Apr 5 20:40:44 2007 From: dchelimsky at gmail.com (David Chelimsky) Date: Thu, 5 Apr 2007 19:40:44 -0500 Subject: [rspec-devel] moving 0.9 to trunk Message-ID: <57c63afe0704051740o46ae174bib303be3851db698a@mail.gmail.com> Trunksters: I'm in the process of moving 0.9 to trunk so things might be a bit weird for a few minutes if you're updating. I'll email when I'm done. David From dchelimsky at gmail.com Thu Apr 5 21:17:44 2007 From: dchelimsky at gmail.com (David Chelimsky) Date: Thu, 5 Apr 2007 20:17:44 -0500 Subject: [rspec-devel] trunk is now ... trunk Message-ID: <57c63afe0704051817w2f1f61eco5888527a9b371536@mail.gmail.com> All, If you're following 0.9 development, it has been moved to the trunk. What was in the trunk was 0.8 maintenance, which has been moved to branches/0.8-maintenance. We had originally planned an 0.8.3 release, but have decided to just press forward with 0.9, hence the beta release yesterday. Cheers, David From noreply at rubyforge.org Fri Apr 6 14:31:21 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 6 Apr 2007 14:31:21 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-9472 ] Provide way to extract specify/it into includable module Message-ID: <20070406183121.6DCE05240A45@rubyforge.org> Feature Requests item #9472, was opened at 2007-03-22 10:12 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=9472&group_id=797 Category: expectation module Group: None Status: Open Priority: 3 Submitted By: Bob Cotton (bcotton) Assigned to: Nobody (None) Summary: Provide way to extract specify/it into includable module Initial Comment: Based on the conversation here http://rubyforge.org/pipermail/rspec-users/2007-March/000993.html provide the ability to extract specify/it into a module that may be included into a context/describe For example: describe AllEditions, :shared => true do it "should" do end end describe LargeEdition do include AllEditions it "should also" do end end ---------------------------------------------------------------------- >Comment By: Bob Cotton (bcotton) Date: 2007-04-06 12:31 Message: > Date: 2007-04-03 06:36 > Sender: David Chelimsky > So the concern that we've had about this sort of sharing is that > it wouldn't lead to cleaner specs, but would, in fact, end up > making things more complex. Let's take the stack example. > > describe "All Stacks", :shared => true do > it "should return the top item when you send it #top" > do > > OK - right away we've got a problem. Somehow, this example needs > to reference a Stack instance and say something about it: > > describe "All Stacks", :shared => true do > it "should return the top item when you send it #top" > do > @stack.top.should == ??????? Sharing of instance variables, especially instance variables that are the target of the spec was exactly what I need from spec sharing. > What's it going to equal? Where's it going to come from? Perhaps > this: > > describe "All Stacks", :shared => true do > it "should return the top item when you send it #top" > do > @stack.top.should == @last_added > end > end > > describe "An non-empty, non-full Stack" do > it_should_behave_as "All Stacks" > > def setup > @stack = Stack.new > @stack.push "1" > @stack.push @last_added = "2" > end > end > > Now this would pass, but there's this unfortunate binding between > the shared behavoiur and its user. As things grow more complex, > these will end up in different files (or one really big file) > and you'll have to go chasing around to understand what any one > thing is doing. I agree that the possibility for this complexity exists, but it's really no worse than included modules with helper methods that are referencing instance vars created in setup or ruby modules that depend on instance vars or methods present on the including class. > So then my question is what other use cases are there for :shared > => true? Most of our use for rspec is for acceptance/function testing. We have several editions of our product. We need a way to parameterize the creation of each edition, then run some specs over each of them. My first thought was to extend 'describe' to accept a list of modules, then create a new Behavior for each one: describe "All Editions", LargeEditionFactory, SmallEditionFactory do end This would create a Beahviour for each module, include the module on the Behavior, then add it to the list. All of the included modules would respond to the same methods, specifically a method to create the correct edition. Then you suggested shared behaviours. Which does the same thing, except the non-shared behavior would be responsible for the creation of the edition. But the shared behaviors would still have to have knowledge of the instance of the edition from the non-shared behaviour. That's our use case. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-03 06:36 Message: So the concern that we've had about this sort of sharing is that it wouldn't lead to cleaner specs, but would, in fact, end up making things more complex. Let's take the stack example. describe "All Stacks", :shared => true do it "should return the top item when you send it #top" do OK - right away we've got a problem. Somehow, this example needs to reference a Stack instance and say something about it: describe "All Stacks", :shared => true do it "should return the top item when you send it #top" do @stack.top.should == ??????? What's it going to equal? Where's it going to come from? Perhaps this: describe "All Stacks", :shared => true do it "should return the top item when you send it #top" do @stack.top.should == @last_added end end describe "An non-empty, non-full Stack" do it_should_behave_as "All Stacks" def setup @stack = Stack.new @stack.push "1" @stack.push @last_added = "2" end end Now this would pass, but there's this unfortunate binding between the shared behavoiur and its user. As things grow more complex, these will end up in different files (or one really big file) and you'll have to go chasing around to understand what any one thing is doing. Now there is a case in which I see a real use for this that would minimize this binding and provide some benefit - and that is defining a duck type - sort of like a java interface without the interface class. So you could do this: describe "Enumerable", :shared => true do it "should respond to #each" do enumerable.should respond_to(:each) end end describe "A Stack" do it_should_behave_as "Enumerable" def setup @stack = Stack.new end def enumerable @stack end end So now we've defined an interface from the examples instead of from a class from which Stack must derive. This is what duck typing is all about! But we still have an odd binding here - the "A Stack" behaviour has to implement #enumerable. That makes me uncomfortable. So I was batting this around w/ Dan North and he suggested something that would end up looking like this: act_as_enumerable = act_as %w { each } describe Stack do it "should act as enumerable" do Stack.new.should act_as_enumerable end end Actually - his suggestion was quack_like :) quack_like_enumerable = quack_like %w { each } describe Stack do it "should quack like enumerable" do Stack.new.should quack_like_enumerable end end One way or another, I think that we'll want to add something like that because it is a very simple way to solve the behaves_as problem. So then my question is what other use cases are there for :shared => true? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-03-26 19:24 Message: I need to think about how to word some things. Why don't you go ahead and give it your best shot and I'll tweak what I think needs tweaking. OK? Thanks Bob - a lot of people have been waiting for a feature like this. Cheers, David ---------------------------------------------------------------------- Comment By: Bob Cotton (bcotton) Date: 2007-03-26 19:01 Message: Thoughs on the wording for including shared behavior, before I write the doc and submit the patch? ---------------------------------------------------------------------- Comment By: Bob Cotton (bcotton) Date: 2007-03-25 07:36 Message: Yes, I'll be doing the work on 0.9. No BDD pie necessary, not being that familar with the code base, just wanted to make sure I wasn't missing anything. Before I can define behavior, I want to make sure I've got all the right classes. Don't worry, there will be specs! Thanks for the followup ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-03-24 17:33 Message: Following up - I guess there's nothing wrong w/ talking about design a LITTLE first. How about a collection on Spec::Runner with methods to interact with it right on the module. Something like: Spec::Runner.add_shared_behaviour(behaviour) Spec::Runner.find_shared_behaviour(:name) This way you don't have to expose anything and those methods can handle the management of the collection. Thoughts? Feel free to throw a BDD pie in my face instead of answering. Cheers, David ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-03-24 17:24 Message: Hi Bob - I assume you're working in the 0.9 branch, yes? If not, please do. As for your questions - this is BDD! Write some specs! If we have any issues w/ the design, we'll talk about it later. Cool? ---------------------------------------------------------------------- Comment By: Bob Cotton (bcotton) Date: 2007-03-24 16:29 Message: I'm about to start implementing this. A couple of questions: 1. I suppose the only way to locate a shared 'describe' would be through its description 2. I'll need to add an attr_reader for :examples to Spec::DSL::Behavior::ModuleMethods so I can grab all shared Examples and add them to the current Behavior just before running. 3. I'll need to add either an attr_reader for :behaviors or a find method to Spec::Runner::BehaviorRunner so I can lookup behaviors by descritpion. Thoughts? ---------------------------------------------------------------------- Comment By: Bob Cotton (bcotton) Date: 2007-03-22 12:45 Message: Very nice. it_should_behave_as Brainstorming with a co-worker: behaving_as behaves_like sharing acts_like an_example_of shares_behavior_with shares_behavior_of same_as same_behavior_as just_like equivalent_to it_doppelgangers ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-03-22 10:23 Message: I like this idea in general. I know we've been resistant to add any sort of example (spec) sharing, but perhaps now is the time. We can't really just say describe AllEditions because Ruby would treat that as a constant and not be able to find it. Also, include implies a module - this is a bit different. So I'm thinking something like this: describe "AllEditions", :shared => true do it "should do something" do end end describe LargeEdition do it_should_behave_as "AllEditions" it "should also do something else" do end end That reads kinda nice, ay? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=9472&group_id=797 From noreply at rubyforge.org Fri Apr 6 19:40:16 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 6 Apr 2007 19:40:16 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-9916 ] translator may fail converting boolean expectations Message-ID: <20070406234016.761885240A52@rubyforge.org> Bugs item #9916, was opened at 2007-04-06 16:40 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=9916&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: steve ross (cwd) Assigned to: Nobody (None) Summary: translator may fail converting boolean expectations Initial Comment: was: foo.should_be(true) converted to: foo.should be(true) which fails. Expected: foo.should ==(true) ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=9916&group_id=797 From noreply at rubyforge.org Fri Apr 6 23:48:32 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 6 Apr 2007 23:48:32 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-9919 ] Small Webgen updates Message-ID: <20070407034832.E66025240A70@rubyforge.org> Patches item #9919, was opened at 2007-04-07 03:48 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=9919&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Scott Taylor (smtlaissezfaire) Assigned to: Nobody (None) Summary: Small Webgen updates Initial Comment: I've updated the stylesheet so that there is a little bit of space between h2 headers and the ruby tags in the docs. I've also updated the rake file so that it only throws an error when using an older version of webgen (> 0.4.2) I had to modify the spec command in the rakefile to a timeout of '2' since one of the specs was timing out. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=9919&group_id=797 From noreply at rubyforge.org Sat Apr 7 00:49:09 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sat, 7 Apr 2007 00:49:09 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-9921 ] 0.9: true.should be(true) fails Message-ID: <20070407044909.BCF635240A29@rubyforge.org> Bugs item #9921, was opened at 2007-04-07 04:49 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=9921&group_id=797 Category: expectation module Group: None Status: Open Resolution: None Priority: 3 Submitted By: David Chelimsky (dchelimsky) Assigned to: David Chelimsky (dchelimsky) Summary: 0.9: true.should be(true) fails Initial Comment: In previous versions be(value) was a synonym for equal(value), but this is no longer supported. It should be! ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=9921&group_id=797 From noreply at rubyforge.org Sat Apr 7 00:50:33 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sat, 7 Apr 2007 00:50:33 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-9916 ] translator may fail converting boolean expectations Message-ID: <20070407045033.35D2C5240A1F@rubyforge.org> Bugs item #9916, was opened at 2007-04-06 23:40 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=9916&group_id=797 Category: None Group: None >Status: Closed >Resolution: Rejected Priority: 3 Submitted By: steve ross (cwd) Assigned to: Nobody (None) Summary: translator may fail converting boolean expectations Initial Comment: was: foo.should_be(true) converted to: foo.should be(true) which fails. Expected: foo.should ==(true) ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-04-07 04:50 Message: I think this is an RSpec bug (related to be(value)), not a translator bug. I've raised http://rubyforge.org/tracker/index.php?func=detail&aid=9921&group_id=797&atid=3149 and am closing this one. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=9916&group_id=797 From noreply at rubyforge.org Sat Apr 7 00:52:53 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sat, 7 Apr 2007 00:52:53 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-9921 ] 0.9: true.should be(true) fails Message-ID: <20070407045253.9B8BA5240A1F@rubyforge.org> Bugs item #9921, was opened at 2007-04-07 04:49 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=9921&group_id=797 Category: expectation module Group: None >Status: Closed >Resolution: Accepted Priority: 3 Submitted By: David Chelimsky (dchelimsky) Assigned to: David Chelimsky (dchelimsky) Summary: 0.9: true.should be(true) fails Initial Comment: In previous versions be(value) was a synonym for equal(value), but this is no longer supported. It should be! ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-04-07 04:52 Message: Fixed in trunk (rev 1709) ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=9921&group_id=797 From noreply at rubyforge.org Sat Apr 7 01:10:15 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sat, 7 Apr 2007 01:10:15 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-9919 ] Small Webgen updates Message-ID: <20070407051015.8F5D15240A1F@rubyforge.org> Patches item #9919, was opened at 2007-04-07 03:48 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=9919&group_id=797 Category: None Group: None >Status: Closed >Resolution: Accepted Priority: 3 Submitted By: Scott Taylor (smtlaissezfaire) >Assigned to: David Chelimsky (dchelimsky) Summary: Small Webgen updates Initial Comment: I've updated the stylesheet so that there is a little bit of space between h2 headers and the ruby tags in the docs. I've also updated the rake file so that it only throws an error when using an older version of webgen (> 0.4.2) I had to modify the spec command in the rakefile to a timeout of '2' since one of the specs was timing out. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-04-07 05:10 Message: Applied to trunk (rev 1710) Please don't forget to submit separate patches for separate concerns. Even though these were each 1 liners, there are really three completely different patches here. We need that separation for two reasons. One is documentation (looking at the title of this patch only tells part of the story). The second reason is that binding multiple patches into one means that we need to either accept them all, reject them all, or do extra work to pick and choose. Keep 'em coming, but please keep 'em separate. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=9919&group_id=797 From noreply at rubyforge.org Sat Apr 7 06:34:46 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sat, 7 Apr 2007 06:34:46 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-9925 ] Changed ".rhtml" to "template" in REST spec generator Message-ID: <20070407103446.30C485240A52@rubyforge.org> Patches item #9925, was opened at 2007-04-07 10:34 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=9925&group_id=797 Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: Scott Taylor (smtlaissezfaire) Assigned to: Nobody (None) Summary: Changed ".rhtml" to "template" in REST spec generator Initial Comment: The typical REST generated specs include something like the followingL it "should render index.rhtml" do do_get response.should render_template('index') end Rails claims that they are moving away from .rhtml as the appropriate suffix of an erb template file. They are chainging it to .erb for the future. Also, some users of rspec are using markaby or other templating systems. This patch changes those .rhtmls to "should render index template", and so on. (as a side note: Sorry for the last three patches in one. My internet access has been quite funky as of late, and couldn't bear to download trunk 2 additional times. I'll stay away from that.) ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=9925&group_id=797 From noreply at rubyforge.org Sat Apr 7 07:49:16 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sat, 7 Apr 2007 07:49:16 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-9926 ] Rakefile - RSPEC_DEPS constant as an Array of Hashes instead of an Array of Arrays Message-ID: <20070407114918.24B1B5240A96@rubyforge.org> Patches item #9926, was opened at 2007-04-07 11:49 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=9926&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Scott Taylor (smtlaissezfaire) Assigned to: Nobody (None) Summary: Rakefile - RSPEC_DEPS constant as an Array of Hashes instead of an Array of Arrays Initial Comment: Small change to the rakefile to make it a little bit more readable ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=9926&group_id=797 From noreply at rubyforge.org Sun Apr 8 09:11:04 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 8 Apr 2007 09:11:04 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-9925 ] Changed ".rhtml" to "template" in REST spec generator Message-ID: <20070408131105.2048652409C1@rubyforge.org> Patches item #9925, was opened at 2007-04-07 10:34 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=9925&group_id=797 Category: rails plugin Group: None >Status: Closed >Resolution: Accepted Priority: 3 Submitted By: Scott Taylor (smtlaissezfaire) >Assigned to: David Chelimsky (dchelimsky) >Summary: Changed ".rhtml" to "template" in REST spec generator Initial Comment: The typical REST generated specs include something like the followingL it "should render index.rhtml" do do_get response.should render_template('index') end Rails claims that they are moving away from .rhtml as the appropriate suffix of an erb template file. They are chainging it to .erb for the future. Also, some users of rspec are using markaby or other templating systems. This patch changes those .rhtmls to "should render index template", and so on. (as a side note: Sorry for the last three patches in one. My internet access has been quite funky as of late, and couldn't bear to download trunk 2 additional times. I'll stay away from that.) ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-04-08 13:11 Message: Applied to trunk rev 1724. FYI - the generator pays attention to the rails version and generates .rhtml files for published rails versions through 1.2.3 and .erb for edge. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=9925&group_id=797 From noreply at rubyforge.org Sun Apr 8 09:29:30 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 8 Apr 2007 09:29:30 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-9926 ] Rakefile - RSPEC_DEPS constant as an Array of Hashes instead of an Array of Arrays Message-ID: <20070408132930.52C5A5240A41@rubyforge.org> Patches item #9926, was opened at 2007-04-07 11:49 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=9926&group_id=797 Category: None Group: None >Status: Closed >Resolution: Accepted Priority: 3 Submitted By: Scott Taylor (smtlaissezfaire) >Assigned to: David Chelimsky (dchelimsky) Summary: Rakefile - RSPEC_DEPS constant as an Array of Hashes instead of an Array of Arrays Initial Comment: Small change to the rakefile to make it a little bit more readable ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-04-08 13:29 Message: Nice. Applied to trunk rev 1725. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=9926&group_id=797 From noreply at rubyforge.org Sun Apr 8 09:47:20 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 8 Apr 2007 09:47:20 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-9678 ] Custom runner command line switch, and multi-threaded runner Message-ID: <20070408134720.D843A5240A7A@rubyforge.org> Patches item #9678, was opened at 2007-03-29 15:22 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=9678&group_id=797 >Category: runner module Group: None >Status: Closed >Resolution: Accepted Priority: 3 Submitted By: Bob Cotton (bcotton) >Assigned to: David Chelimsky (dchelimsky) Summary: Custom runner command line switch, and multi-threaded runner Initial Comment: Here's a better patch, with the multi-threaded runner in the examples dir ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-04-08 13:47 Message: Applied to trunk rev Great patch! Please patch from trunk or branch root (this was patched from branches and the referenced 0.9-dev branch doesn't exist any longer). Thanks ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=9678&group_id=797 From noreply at rubyforge.org Sun Apr 8 10:01:54 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 8 Apr 2007 10:01:54 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-9132 ] Rakefile spec:doc can fail without preparing database Message-ID: <20070408140154.CD7BB5240A75@rubyforge.org> Patches item #9132, was opened at 2007-03-08 19:08 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=9132&group_id=797 Category: rails plugin Group: None >Status: Closed >Resolution: Accepted Priority: 3 Submitted By: steve ross (cwd) >Assigned to: David Chelimsky (dchelimsky) Summary: Rakefile spec:doc can fail without preparing database Initial Comment: Two issues addressed in this patch to rspec.rake: 1. specs fail because database is not prepared when running spec:doc 2. added task spec:appdoc so only specs for the app are run - not for plugins N.b.: It might be better to name these spec:doc (just the application) and spec:doc_all (for everything) but I left that alone because I didn't want to break existing functionality. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-04-08 14:01 Message: Applied to trunk rev 1727. FYI - I added the db:test:prepare prereq (thanks) and a separate spec:plugin_doc task to handle plugins (the spec:doc task was changed already to run everything under ./spec and not plugins). ---------------------------------------------------------------------- Comment By: steve ross (cwd) Date: 2007-03-10 16:16 Message: Ok, now the patch :) ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-03-10 14:13 Message: Please submit the patch ;) ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=9132&group_id=797 From noreply at rubyforge.org Sun Apr 8 10:39:42 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 8 Apr 2007 10:39:42 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-9598 ] Change to Object.path2class to resolve conflicts with namespaced controllers Message-ID: <20070408143942.19AD05240A92@rubyforge.org> Patches item #9598, was opened at 2007-03-26 20:10 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=9598&group_id=797 Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: bruno bornsztein (bborn) Assigned to: Nobody (None) Summary: Change to Object.path2class to resolve conflicts with namespaced controllers Initial Comment: The RSpec on Rails plugin adds a path2class method to Object, which is intended to get a class from a string; however the existing implementation failed when using namespaced classes, for example: def self.path2class(klassname) klassname.split('::').inject(Object) { |k,n| k.const_get n } end "TenantsController".inject(Object) { |k,n| k.const_get n } => TenantsController "Admin::TenantsController".inject(Object) { |k,n| k.const_get n } => TenantsController This is a problem if you have two controllers with the same name in different namespaces. The solution uses Rails' Inflector.constantize instead: def self.path2class(klassname) klassname.constantize end "TenantsController".constantize => TenantsController "Admin::TenantsController".constantize => Admin::TenantsController This yields the expected result. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-04-08 14:39 Message: Applying this patch causes other failures when run against trunk rev 1727 (output below). Please be sure all specs are passing and resubmit. ============================================= rake spec:plugins 1) 'Given a controller spec running in isolation mode a spec in a context without controller_name set should fail with a useful warning' FAILED example block expected # but raised # ./vendor/plugins/rspec_on_rails/spec/rails/runner/controller_spec_spec.rb:83 2) 'Given a controller spec running in integration mode a spec in a context without controller_name set should fail with a useful warning' FAILED example block expected # but raised # ./vendor/plugins/rspec_on_rails/spec/rails/runner/controller_spec_spec.rb:83 ---------------------------------------------------------------------- Comment By: bruno bornsztein (bborn) Date: 2007-03-26 20:12 Message: Sorry... forgot to check the box when attaching files. ---------------------------------------------------------------------- Comment By: bruno bornsztein (bborn) Date: 2007-03-26 20:11 Message: Here's a spec. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=9598&group_id=797 From noreply at rubyforge.org Sun Apr 8 10:50:02 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 8 Apr 2007 10:50:02 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-9458 ] The rspec_resource generator does not take into account class nesting Message-ID: <20070408145002.65E225240A8A@rubyforge.org> Patches item #9458, was opened at 2007-03-22 08:49 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=9458&group_id=797 Category: rails plugin Group: None >Status: Closed >Resolution: Accepted Priority: 3 Submitted By: Steve Tendon (progfrog) >Assigned to: David Chelimsky (dchelimsky) Summary: The rspec_resource generator does not take into account class nesting Initial Comment: The rspec_resource generator will not generate the correct require paths if you generate with a module. For example: ?./script/generate rspec_resource 'railfrog/content' will put: require File.dirname(__FILE__) + '/../spec_helper' in the generated controller, while it should generate: require File.dirname(__FILE__) + '<%= '/..' * class_nesting_depth %>/../spec_helper' Similar problems in the generated views. This patch corrects the genertor templates accordingly. ==== This contribution comes from the Pond http://railfrog.com/ Croak! Croak! --progfrog ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-04-08 14:50 Message: Applied to trunk rev 1728. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=9458&group_id=797 From noreply at rubyforge.org Sun Apr 8 12:00:10 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 8 Apr 2007 12:00:10 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-9958 ] Rakefile change to use MySQL Message-ID: <20070408160010.8C11D5240A8B@rubyforge.org> Patches item #9958, was opened at 2007-04-08 16:00 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=9958&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Scott Taylor (smtlaissezfaire) Assigned to: Nobody (None) Summary: Rakefile change to use MySQL Initial Comment: As it stands right now, sqlite3 is unusable with pre_commit_rails. This has been talked about in the mailing list, so I won't add anything more. As it stands right now, one of two things must occur: 1. rails versions 1.2.1 and lower must be dropped in order to use sqlite3 2. -OR- sqlite should be dropped for the time being. This patch does not fix the problem. All this patch does is add two additional rake tasks: 1. setup_mysql: (copying config/database.mysql.yml to config/database.yml) 2. pre_commit_with_mysql: run pre_commit, with the setup_for_mysql task as a dependency. This patch is mainly to address the annoyance I feel everytime I try to submit a patch. I always forget to copy that mysql file. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=9958&group_id=797 From noreply at rubyforge.org Sun Apr 8 15:59:03 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 8 Apr 2007 15:59:03 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-9958 ] Rakefile change to use MySQL Message-ID: <20070408195903.190EE5240A7D@rubyforge.org> Patches item #9958, was opened at 2007-04-08 16:00 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=9958&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Scott Taylor (smtlaissezfaire) Assigned to: Nobody (None) Summary: Rakefile change to use MySQL Initial Comment: As it stands right now, sqlite3 is unusable with pre_commit_rails. This has been talked about in the mailing list, so I won't add anything more. As it stands right now, one of two things must occur: 1. rails versions 1.2.1 and lower must be dropped in order to use sqlite3 2. -OR- sqlite should be dropped for the time being. This patch does not fix the problem. All this patch does is add two additional rake tasks: 1. setup_mysql: (copying config/database.mysql.yml to config/database.yml) 2. pre_commit_with_mysql: run pre_commit, with the setup_for_mysql task as a dependency. This patch is mainly to address the annoyance I feel everytime I try to submit a patch. I always forget to copy that mysql file. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-04-08 19:59 Message: There is already rspec:generate_mysql_config (so we don't need setup_mysql). Not sure yet whether to add pre_commit_with_mysql or just start limiting what we're supporting. Aslak? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=9958&group_id=797 From noreply at rubyforge.org Sun Apr 8 16:47:42 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 8 Apr 2007 16:47:42 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-9958 ] Rakefile change to use MySQL Message-ID: <20070408204743.18DD65240A7D@rubyforge.org> Patches item #9958, was opened at 2007-04-08 16:00 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=9958&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Scott Taylor (smtlaissezfaire) Assigned to: Nobody (None) Summary: Rakefile change to use MySQL Initial Comment: As it stands right now, sqlite3 is unusable with pre_commit_rails. This has been talked about in the mailing list, so I won't add anything more. As it stands right now, one of two things must occur: 1. rails versions 1.2.1 and lower must be dropped in order to use sqlite3 2. -OR- sqlite should be dropped for the time being. This patch does not fix the problem. All this patch does is add two additional rake tasks: 1. setup_mysql: (copying config/database.mysql.yml to config/database.yml) 2. pre_commit_with_mysql: run pre_commit, with the setup_for_mysql task as a dependency. This patch is mainly to address the annoyance I feel everytime I try to submit a patch. I always forget to copy that mysql file. ---------------------------------------------------------------------- >Comment By: Scott Taylor (smtlaissezfaire) Date: 2007-04-08 20:47 Message: I didn't realize there was such a task! I would normally just say that we should hook up mysql to work by default, but others may be using a different database. I think it would be nice if we could have something like: rake pre_commit_sqlite rake pre_commit_mysql etc. I know this is what rails does for their unit tests. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-08 19:59 Message: There is already rspec:generate_mysql_config (so we don't need setup_mysql). Not sure yet whether to add pre_commit_with_mysql or just start limiting what we're supporting. Aslak? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=9958&group_id=797 From mailing_lists at railsnewbie.com Sun Apr 8 17:05:59 2007 From: mailing_lists at railsnewbie.com (Scott Taylor) Date: Sun, 8 Apr 2007 17:05:59 -0400 Subject: [rspec-devel] [ rspec-Feature Requests-9786 ] infer controller and helper names from the described type In-Reply-To: <20070404034855.407925240BE8@rubyforge.org> References: <20070404034855.407925240BE8@rubyforge.org> Message-ID: <68C8746D-8500-4751-969A-1F72F9920815@railsnewbie.com> I'm not specifying the controller name in one of my controller specs and am getting this: 1) 'POST /users/1/terms/1 - UPDATE should be successful' FAILED You have to declare the controller name in controller specs. For example: context "The ExampleController" do controller_name "example" #invokes the ExampleController end I've got trunk checked out in my plugins directory. Do you know why I'd have this problem? Scott On Apr 3, 2007, at 11:48 PM, wrote: > Feature Requests item #9786, was opened at 2007-04-03 15:16 > You can respond by visiting: > http://rubyforge.org/tracker/? > func=detail&atid=3152&aid=9786&group_id=797 > > Category: rails plugin > Group: None >> Status: Closed > Priority: 3 > Submitted By: David Chelimsky (dchelimsky) >> Assigned to: David Chelimsky (dchelimsky) > Summary: infer controller and helper names from the described type > > Initial Comment: > Now that we can do this: > > describe SomeThingController do > > it seems a shame to require this: > > controller_name :some_thing > > Controller Behavoiurs could be smart enough to see if a type is > passed to #describe, and if it is a subclass of > ActionController::Base, in which case it doesn't need to require > controller_name > > Same goes for Helper Behaviours. > > ---------------------------------------------------------------------- > >> Comment By: David Chelimsky (dchelimsky) > Date: 2007-04-04 03:48 > > Message: > Added in branches/0.9-dev (rev 1685) > > ---------------------------------------------------------------------- > > You can respond by visiting: > http://rubyforge.org/tracker/? > func=detail&atid=3152&aid=9786&group_id=797 > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel From dchelimsky at gmail.com Sun Apr 8 17:26:22 2007 From: dchelimsky at gmail.com (David Chelimsky) Date: Sun, 8 Apr 2007 16:26:22 -0500 Subject: [rspec-devel] [ rspec-Feature Requests-9786 ] infer controller and helper names from the described type In-Reply-To: <68C8746D-8500-4751-969A-1F72F9920815@railsnewbie.com> References: <20070404034855.407925240BE8@rubyforge.org> <68C8746D-8500-4751-969A-1F72F9920815@railsnewbie.com> Message-ID: <57c63afe0704081426w613cd41fq175987d62a6bb782@mail.gmail.com> You have to use the type directly: describe TheExampleController do etc On 4/8/07, Scott Taylor wrote: > > I'm not specifying the controller name in one of my controller specs > and am getting this: > > 1) > 'POST /users/1/terms/1 - UPDATE should be successful' FAILED > You have to declare the controller name in controller specs. For > example: > context "The ExampleController" do > controller_name "example" #invokes the ExampleController > end > > I've got trunk checked out in my plugins directory. Do you know why > I'd have this problem? > > Scott > > > > On Apr 3, 2007, at 11:48 PM, > wrote: > > > Feature Requests item #9786, was opened at 2007-04-03 15:16 > > You can respond by visiting: > > http://rubyforge.org/tracker/? > > func=detail&atid=3152&aid=9786&group_id=797 > > > > Category: rails plugin > > Group: None > >> Status: Closed > > Priority: 3 > > Submitted By: David Chelimsky (dchelimsky) > >> Assigned to: David Chelimsky (dchelimsky) > > Summary: infer controller and helper names from the described type > > > > Initial Comment: > > Now that we can do this: > > > > describe SomeThingController do > > > > it seems a shame to require this: > > > > controller_name :some_thing > > > > Controller Behavoiurs could be smart enough to see if a type is > > passed to #describe, and if it is a subclass of > > ActionController::Base, in which case it doesn't need to require > > controller_name > > > > Same goes for Helper Behaviours. > > > > ---------------------------------------------------------------------- > > > >> Comment By: David Chelimsky (dchelimsky) > > Date: 2007-04-04 03:48 > > > > Message: > > Added in branches/0.9-dev (rev 1685) > > > > ---------------------------------------------------------------------- > > > > You can respond by visiting: > > http://rubyforge.org/tracker/? > > func=detail&atid=3152&aid=9786&group_id=797 > > _______________________________________________ > > rspec-devel mailing list > > rspec-devel at rubyforge.org > > http://rubyforge.org/mailman/listinfo/rspec-devel > > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From noreply at rubyforge.org Sun Apr 8 17:27:58 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 8 Apr 2007 17:27:58 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-9786 ] infer controller and helper names from the described type Message-ID: <20070408212758.B88665240A78@rubyforge.org> Feature Requests item #9786, was opened at 2007-04-03 15:16 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=9786&group_id=797 Category: rails plugin Group: None Status: Closed Priority: 3 Submitted By: David Chelimsky (dchelimsky) Assigned to: David Chelimsky (dchelimsky) Summary: infer controller and helper names from the described type Initial Comment: Now that we can do this: describe SomeThingController do it seems a shame to require this: controller_name :some_thing Controller Behavoiurs could be smart enough to see if a type is passed to #describe, and if it is a subclass of ActionController::Base, in which case it doesn't need to require controller_name Same goes for Helper Behaviours. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-04-08 21:27 Message: Note - you MUST use the type to make this work: describe SomeType do etc NOT THIS: describe "SomeType" do ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-04 03:48 Message: Added in branches/0.9-dev (rev 1685) ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=9786&group_id=797 From noreply at rubyforge.org Mon Apr 9 01:06:45 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 9 Apr 2007 01:06:45 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-9260 ] IvarProxy does not act like a hash Message-ID: <20070409050645.C8B7C5240AA9@rubyforge.org> Bugs item #9260, was opened at 2007-03-13 10:08 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=9260&group_id=797 Category: rails plugin Group: None >Status: Closed Resolution: None Priority: 3 Submitted By: Brian Takita (btakita) Assigned to: Nobody (None) Summary: IvarProxy does not act like a hash Initial Comment: undefined method `delete' for # This happened in a Helper Spec. Here is the code to reproduce this. mab = Markaby::Builder.new(assigns_hash, self) ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-02 19:20 Message: Brian, can you please submit a failing example? ---------------------------------------------------------------------- Comment By: Brian Takita (btakita) Date: 2007-03-13 10:13 Message: Here is a fix I used without specs (my specs pass now): class Spec::Rails::Expectations::IvarProxy def delete(name) @object.send(:remove_instance_variable, "@#{name}") if @object.instance_variables.include?("@#{name}") end def each @object.instance_variables do |var| yield @object.instance_variable_get(var) end end end ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=9260&group_id=797 From noreply at rubyforge.org Mon Apr 9 01:39:11 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 9 Apr 2007 01:39:11 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-9982 ] `rake spec` for rspec_on_rails does not run tests. Message-ID: <20070409053911.3BC055240AA6@rubyforge.org> Bugs item #9982, was opened at 2007-04-09 05:39 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=9982&group_id=797 Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: Phil O. Despotos (philodespotos) Assigned to: Nobody (None) Summary: `rake spec` for rspec_on_rails does not run tests. Initial Comment: I am running rails edge, revision 6510, and the latest trunk of both rspec and rspec_on_rails checked out earlier today. Unfortunately, I don't get a REVISION_17.. file with rspec, nor do I use SVN, so I'm unsure of the exact revision. It occurs both with and without --drb in spec.opts. The output speaks for itself. I'm not sure how to go about demonstrating this with a spec or some such, and I'm not competent enough to dig through the source. Hopefully this suffices: $ rake spec (in /home/pd/rails/myproject) /usr/local/bin/ruby18 -I"/home/pd/rails/myproject/vendor/plugins/rspec/lib" "/home/pd/rails/myproject/vendor/plugins/rspec/bin/spec" "spec/controllers/sites_controller_spec.rb" "spec/controllers/session_controller_spec.rb" "spec/models/site_spec.rb" "spec/models/user_spec.rb" "spec/models/site_info_spec.rb" "spec/views/sites/edit_erb_spec.rb" "spec/views/sites/index_erb_spec.rb" "spec/views/sites/new_erb_spec.rb" "spec/views/sites/show_erb_spec.rb" --options "/home/pd/rails/myproject/spec/spec.opts" Finished in 7.4e-05 seconds 0 examples, 0 failures $ rake spec:controllers (in /home/pd/rails/myproject) /usr/local/bin/ruby18 -I"/home/pd/rails/myproject/vendor/plugins/rspec/lib" "/home/pd/rails/myproject/vendor/plugins/rspec/bin/spec" "spec/controllers/sites_controller_spec.rb" "spec/controllers/session_controller_spec.rb" --options "/home/pd/rails/myproject/spec/spec.opts" Finished in 7.5e-05 seconds 0 examples, 0 failures $ script/spec spec/models/user_spec.rb ........................ Finished in 2.511908 seconds 24 examples, 0 failures All tests run as expected when running manually. Apologies if this looks awful, there's no preview functionality... ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=9982&group_id=797 From noreply at rubyforge.org Mon Apr 9 01:50:40 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 9 Apr 2007 01:50:40 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-9311 ] Controller Specs do not play nicely with Markaby and Rxml Message-ID: <20070409055040.7DF735240AA9@rubyforge.org> Bugs item #9311, was opened at 2007-03-15 14:48 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=9311&group_id=797 Category: None Group: None >Status: Closed Resolution: None Priority: 3 Submitted By: Brian Takita (btakita) Assigned to: Nobody (None) Summary: Controller Specs do not play nicely with Markaby and Rxml Initial Comment: Look in rails/runner/context/controller.rb line 18. If render is called without a block and views are not integrated, ActionView::Base#find_template_extension_for is stubbed to return 'rhtml'. Unfortunately, rails caches this result. When I run a view spec, e.g. render 'foo/bar' and bar is a markaby file (bar.mab), rails uses the cached extension (rhtml) when @@cache_template_extensions is set to true, which it is by default. See ActionView::Base#pick_template_extension ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-01 07:27 Message: Brian - we made a change a while back so that cache_template_extensions is turned off by default (when running rspec examples). This can be found in branches/0.9-dev. I *think* that should have solved this problem, yes? If so, please close this. Thanks ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=9311&group_id=797 From noreply at rubyforge.org Mon Apr 9 02:29:18 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 9 Apr 2007 02:29:18 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-9983 ] Allow before_setup and after_teardown to be called in BehaviourEval Message-ID: <20070409062918.35FEA5240AA6@rubyforge.org> Feature Requests item #9983, was opened at 2007-04-08 23:29 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=9983&group_id=797 Category: None Group: None Status: Open Priority: 3 Submitted By: Brian Takita (btakita) Assigned to: Nobody (None) Summary: Allow before_setup and after_teardown to be called in BehaviourEval Initial Comment: This would provide a hook for cross cutting. For example: Somebody wants to have setup and/or teardown functionality in a select few Examples. One may want to create a module and define the included method. module Foobar def self.included(mod) mod.before_setup do puts 'my special setup hook' end end end describe MyObject include Foobar end ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=9983&group_id=797 From noreply at rubyforge.org Mon Apr 9 02:36:02 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 9 Apr 2007 02:36:02 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-9984 ] Unmock methods Message-ID: <20070409063602.ADC115240AA6@rubyforge.org> Feature Requests item #9984, was opened at 2007-04-08 23:36 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=9984&group_id=797 Category: None Group: None Status: Open Priority: 3 Submitted By: Brian Takita (btakita) Assigned to: Nobody (None) Summary: Unmock methods Initial Comment: This would apply to partial mocks. Thes use case is: By default, I want a certain object to be mocked because the method that is called is very slow. However, I do want to test it's implementation in a few specs. Currently this works: class ObjectWithLongMethod def long_method 'this takes a long time' end end obj = ObjectWithLongMethod.new obj.stub!(:long_method).and_return('my string') obj.long_method.should == 'my string' obj.stub!(:long_method).and_return &obj.method(:proxied_by_rspec__long_method) obj.long_method.should == 'this takes a long time' ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=9984&group_id=797 From noreply at rubyforge.org Mon Apr 9 06:52:56 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 9 Apr 2007 06:52:56 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-9982 ] `rake spec` for rspec_on_rails does not run tests. Message-ID: <20070409105256.D245E524096C@rubyforge.org> Bugs item #9982, was opened at 2007-04-09 05:39 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=9982&group_id=797 Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: Phil O. Despotos (philodespotos) Assigned to: Nobody (None) Summary: `rake spec` for rspec_on_rails does not run tests. Initial Comment: I am running rails edge, revision 6510, and the latest trunk of both rspec and rspec_on_rails checked out earlier today. Unfortunately, I don't get a REVISION_17.. file with rspec, nor do I use SVN, so I'm unsure of the exact revision. It occurs both with and without --drb in spec.opts. The output speaks for itself. I'm not sure how to go about demonstrating this with a spec or some such, and I'm not competent enough to dig through the source. Hopefully this suffices: $ rake spec (in /home/pd/rails/myproject) /usr/local/bin/ruby18 -I"/home/pd/rails/myproject/vendor/plugins/rspec/lib" "/home/pd/rails/myproject/vendor/plugins/rspec/bin/spec" "spec/controllers/sites_controller_spec.rb" "spec/controllers/session_controller_spec.rb" "spec/models/site_spec.rb" "spec/models/user_spec.rb" "spec/models/site_info_spec.rb" "spec/views/sites/edit_erb_spec.rb" "spec/views/sites/index_erb_spec.rb" "spec/views/sites/new_erb_spec.rb" "spec/views/sites/show_erb_spec.rb" --options "/home/pd/rails/myproject/spec/spec.opts" Finished in 7.4e-05 seconds 0 examples, 0 failures $ rake spec:controllers (in /home/pd/rails/myproject) /usr/local/bin/ruby18 -I"/home/pd/rails/myproject/vendor/plugins/rspec/lib" "/home/pd/rails/myproject/vendor/plugins/rspec/bin/spec" "spec/controllers/sites_controller_spec.rb" "spec/controllers/session_controller_spec.rb" --options "/home/pd/rails/myproject/spec/spec.opts" Finished in 7.5e-05 seconds 0 examples, 0 failures $ script/spec spec/models/user_spec.rb ........................ Finished in 2.511908 seconds 24 examples, 0 failures All tests run as expected when running manually. Apologies if this looks awful, there's no preview functionality... ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-04-09 10:52 Message: Do the examples run the second time you run it? If so, then this is due to the following lines in spec/spec.opts (and is behaving as expected): --failures previous_spec_failures.txt --example previous_spec_failures.txt This causes rspec to only run specs that have just failed. Once they pass, the next run should run them all. Please report back as to whether that is what is going on. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=9982&group_id=797 From noreply at rubyforge.org Mon Apr 9 06:59:38 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 9 Apr 2007 06:59:38 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-9983 ] Allow before_setup and after_teardown to be called in BehaviourEval Message-ID: <20070409105939.0C1E1524096C@rubyforge.org> Feature Requests item #9983, was opened at 2007-04-09 06:29 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=9983&group_id=797 Category: None Group: None Status: Open Priority: 3 Submitted By: Brian Takita (btakita) Assigned to: Nobody (None) Summary: Allow before_setup and after_teardown to be called in BehaviourEval Initial Comment: This would provide a hook for cross cutting. For example: Somebody wants to have setup and/or teardown functionality in a select few Examples. One may want to create a module and define the included method. module Foobar def self.included(mod) mod.before_setup do puts 'my special setup hook' end end end describe MyObject include Foobar end ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-04-09 10:59 Message: Right now you can do the following - would it suffice? # in a central location like spec_helper.rb module SpecialSetups def stuff_to_do_first ... end end Spec::Runner.configure do |config| config.include SpecialSetups end # in a spec file describe SomeObject do setup do stuff_to_do_first # other stuff end ... end This makes things a bit more transparent in the specs and is not really any more verbose if you've got a setup anyhow. WDYT? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=9983&group_id=797 From noreply at rubyforge.org Mon Apr 9 07:06:11 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 9 Apr 2007 07:06:11 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-9984 ] Unmock methods Message-ID: <20070409110612.017F6524098C@rubyforge.org> Feature Requests item #9984, was opened at 2007-04-09 06:36 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=9984&group_id=797 Category: None Group: None Status: Open Priority: 3 Submitted By: Brian Takita (btakita) Assigned to: Nobody (None) Summary: Unmock methods Initial Comment: This would apply to partial mocks. Thes use case is: By default, I want a certain object to be mocked because the method that is called is very slow. However, I do want to test it's implementation in a few specs. Currently this works: class ObjectWithLongMethod def long_method 'this takes a long time' end end obj = ObjectWithLongMethod.new obj.stub!(:long_method).and_return('my string') obj.long_method.should == 'my string' obj.stub!(:long_method).and_return &obj.method(:proxied_by_rspec__long_method) obj.long_method.should == 'this takes a long time' ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-04-09 11:06 Message: Why not put the two calls in separate examples? All of the proxied methods are restored between every example. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=9984&group_id=797 From noreply at rubyforge.org Mon Apr 9 08:07:52 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 9 Apr 2007 08:07:52 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-9982 ] `rake spec` for rspec_on_rails does not run tests. Message-ID: <20070409120752.83DF05240989@rubyforge.org> Bugs item #9982, was opened at 2007-04-09 01:39 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=9982&group_id=797 Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: Phil O. Despotos (philodespotos) Assigned to: Nobody (None) Summary: `rake spec` for rspec_on_rails does not run tests. Initial Comment: I am running rails edge, revision 6510, and the latest trunk of both rspec and rspec_on_rails checked out earlier today. Unfortunately, I don't get a REVISION_17.. file with rspec, nor do I use SVN, so I'm unsure of the exact revision. It occurs both with and without --drb in spec.opts. The output speaks for itself. I'm not sure how to go about demonstrating this with a spec or some such, and I'm not competent enough to dig through the source. Hopefully this suffices: $ rake spec (in /home/pd/rails/myproject) /usr/local/bin/ruby18 -I"/home/pd/rails/myproject/vendor/plugins/rspec/lib" "/home/pd/rails/myproject/vendor/plugins/rspec/bin/spec" "spec/controllers/sites_controller_spec.rb" "spec/controllers/session_controller_spec.rb" "spec/models/site_spec.rb" "spec/models/user_spec.rb" "spec/models/site_info_spec.rb" "spec/views/sites/edit_erb_spec.rb" "spec/views/sites/index_erb_spec.rb" "spec/views/sites/new_erb_spec.rb" "spec/views/sites/show_erb_spec.rb" --options "/home/pd/rails/myproject/spec/spec.opts" Finished in 7.4e-05 seconds 0 examples, 0 failures $ rake spec:controllers (in /home/pd/rails/myproject) /usr/local/bin/ruby18 -I"/home/pd/rails/myproject/vendor/plugins/rspec/lib" "/home/pd/rails/myproject/vendor/plugins/rspec/bin/spec" "spec/controllers/sites_controller_spec.rb" "spec/controllers/session_controller_spec.rb" --options "/home/pd/rails/myproject/spec/spec.opts" Finished in 7.5e-05 seconds 0 examples, 0 failures $ script/spec spec/models/user_spec.rb ........................ Finished in 2.511908 seconds 24 examples, 0 failures All tests run as expected when running manually. Apologies if this looks awful, there's no preview functionality... ---------------------------------------------------------------------- >Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-04-09 08:07 Message: If your options file has --example previous_spec_failures.txt and that file doesn't exist, then RSpec will try to run only the spec with that name. Perhaps you deleted the file? (script/generate rspec should create an empty one for you) The next time you run the specs everything should be restored to normal. I realise this might be confusing, and we'd be happy to consider something more intuitive. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-09 06:52 Message: Do the examples run the second time you run it? If so, then this is due to the following lines in spec/spec.opts (and is behaving as expected): --failures previous_spec_failures.txt --example previous_spec_failures.txt This causes rspec to only run specs that have just failed. Once they pass, the next run should run them all. Please report back as to whether that is what is going on. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=9982&group_id=797 From noreply at rubyforge.org Tue Apr 10 11:55:01 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 10 Apr 2007 11:55:01 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-10010 ] Number executed specs; support --spec-number switch Message-ID: <20070410155501.98F445240AED@rubyforge.org> Feature Requests item #10010, was opened at 2007-04-10 11:55 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10010&group_id=797 Category: runner / command line Group: None Status: Open Priority: 3 Submitted By: Chris Hoffman (hoffman_c) Assigned to: Nobody (None) Summary: Number executed specs; support --spec-number switch Initial Comment: I am not sure if this is at all possible, but I have been thinking about ticket #9287, and it seems like the following might be an easier way to go. If you number all of the specs that are being executed for a particular command, then the user can see which number failed, fix the problem, and run that specific spec again. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10010&group_id=797 From noreply at rubyforge.org Tue Apr 10 12:07:28 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 10 Apr 2007 12:07:28 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-10010 ] Number executed specs; support --spec-number switch Message-ID: <20070410160728.5372A5240A99@rubyforge.org> Feature Requests item #10010, was opened at 2007-04-10 15:55 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10010&group_id=797 Category: runner / command line Group: None Status: Open Priority: 3 Submitted By: Chris Hoffman (hoffman_c) Assigned to: Nobody (None) Summary: Number executed specs; support --spec-number switch Initial Comment: I am not sure if this is at all possible, but I have been thinking about ticket #9287, and it seems like the following might be an easier way to go. If you number all of the specs that are being executed for a particular command, then the user can see which number failed, fix the problem, and run that specific spec again. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-04-10 16:07 Message: I believe your goal is to only run the specs that have just failed until you get them to pass, yes? If so, you can do that now (in 0.9) using the following in spec.opts: --failures previous_spec_failures.txt --example previous_spec_failures.txt now either do this: spec spec -O spec/spec.opts or rake spec (assuming the rake task is set up to read the opts file, which it is now by default) ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10010&group_id=797 From noreply at rubyforge.org Tue Apr 10 12:14:10 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 10 Apr 2007 12:14:10 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-10010 ] Number executed specs; support --spec-number switch Message-ID: <20070410161410.8FEC05240AE8@rubyforge.org> Feature Requests item #10010, was opened at 2007-04-10 11:55 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10010&group_id=797 Category: runner / command line Group: None >Status: Deleted Priority: 3 Submitted By: Chris Hoffman (hoffman_c) Assigned to: Nobody (None) Summary: Number executed specs; support --spec-number switch Initial Comment: I am not sure if this is at all possible, but I have been thinking about ticket #9287, and it seems like the following might be an easier way to go. If you number all of the specs that are being executed for a particular command, then the user can see which number failed, fix the problem, and run that specific spec again. ---------------------------------------------------------------------- >Comment By: Chris Hoffman (hoffman_c) Date: 2007-04-10 12:14 Message: Yeah, I was totally thinking of the solution without thinking about the actual use case. Good catch. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-10 12:07 Message: I believe your goal is to only run the specs that have just failed until you get them to pass, yes? If so, you can do that now (in 0.9) using the following in spec.opts: --failures previous_spec_failures.txt --example previous_spec_failures.txt now either do this: spec spec -O spec/spec.opts or rake spec (assuming the rake task is set up to read the opts file, which it is now by default) ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10010&group_id=797 From noreply at rubyforge.org Wed Apr 11 01:03:48 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 11 Apr 2007 01:03:48 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-9983 ] Allow before_setup and after_teardown to be called in BehaviourEval Message-ID: <20070411050348.1FE9F5240A3A@rubyforge.org> Feature Requests item #9983, was opened at 2007-04-08 23:29 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=9983&group_id=797 Category: None Group: None Status: Open Priority: 3 Submitted By: Brian Takita (btakita) Assigned to: Nobody (None) Summary: Allow before_setup and after_teardown to be called in BehaviourEval Initial Comment: This would provide a hook for cross cutting. For example: Somebody wants to have setup and/or teardown functionality in a select few Examples. One may want to create a module and define the included method. module Foobar def self.included(mod) mod.before_setup do puts 'my special setup hook' end end end describe MyObject include Foobar end ---------------------------------------------------------------------- >Comment By: Brian Takita (btakita) Date: 2007-04-10 22:03 Message: The objection I received, that I agree with, was a lack of cross cutting hooks. There are cases when a library developer would not want to require up to 3 touch points (include, setup, and teardown) to get the added feature set to run. In house, we have a number of helper packages that get applied only certain specs. For example, we have a module that hooks into TestCase that print how long the test took. Sometimes we want to apply to all of our tests, and sometimes we don't. Another example would be if you want some specs to print out the specdocs, but not others. At some level, it would be helpful to allow users to make 'plugins' of some type, rather than have to rely on editing core classes. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-09 03:59 Message: Right now you can do the following - would it suffice? # in a central location like spec_helper.rb module SpecialSetups def stuff_to_do_first ... end end Spec::Runner.configure do |config| config.include SpecialSetups end # in a spec file describe SomeObject do setup do stuff_to_do_first # other stuff end ... end This makes things a bit more transparent in the specs and is not really any more verbose if you've got a setup anyhow. WDYT? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=9983&group_id=797 From noreply at rubyforge.org Wed Apr 11 01:24:56 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 11 Apr 2007 01:24:56 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-9984 ] Unmock methods Message-ID: <20070411052456.BCDA05240A9D@rubyforge.org> Feature Requests item #9984, was opened at 2007-04-08 23:36 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=9984&group_id=797 Category: None Group: None Status: Open Priority: 3 Submitted By: Brian Takita (btakita) Assigned to: Nobody (None) Summary: Unmock methods Initial Comment: This would apply to partial mocks. Thes use case is: By default, I want a certain object to be mocked because the method that is called is very slow. However, I do want to test it's implementation in a few specs. Currently this works: class ObjectWithLongMethod def long_method 'this takes a long time' end end obj = ObjectWithLongMethod.new obj.stub!(:long_method).and_return('my string') obj.long_method.should == 'my string' obj.stub!(:long_method).and_return &obj.method(:proxied_by_rspec__long_method) obj.long_method.should == 'this takes a long time' ---------------------------------------------------------------------- >Comment By: Brian Takita (btakita) Date: 2007-04-10 22:24 Message: We have a project where the developers found it preferable to mock the object by default because there where only a few specs that used the real implementation. Its like a negative space. I'll ask the developer who requested this to chime in. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-09 04:06 Message: Why not put the two calls in separate examples? All of the proxied methods are restored between every example. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=9984&group_id=797 From noreply at rubyforge.org Wed Apr 11 01:45:40 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 11 Apr 2007 01:45:40 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-9984 ] Unmock methods Message-ID: <20070411054540.B587D5240A9D@rubyforge.org> Feature Requests item #9984, was opened at 2007-04-09 06:36 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=9984&group_id=797 Category: None Group: None Status: Open Priority: 3 Submitted By: Brian Takita (btakita) Assigned to: Nobody (None) Summary: Unmock methods Initial Comment: This would apply to partial mocks. Thes use case is: By default, I want a certain object to be mocked because the method that is called is very slow. However, I do want to test it's implementation in a few specs. Currently this works: class ObjectWithLongMethod def long_method 'this takes a long time' end end obj = ObjectWithLongMethod.new obj.stub!(:long_method).and_return('my string') obj.long_method.should == 'my string' obj.stub!(:long_method).and_return &obj.method(:proxied_by_rspec__long_method) obj.long_method.should == 'this takes a long time' ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-04-11 05:45 Message: Do you mean "stub the object"? Please do ask the dev to chime in. Thx ---------------------------------------------------------------------- Comment By: Brian Takita (btakita) Date: 2007-04-11 05:24 Message: We have a project where the developers found it preferable to mock the object by default because there where only a few specs that used the real implementation. Its like a negative space. I'll ask the developer who requested this to chime in. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-09 11:06 Message: Why not put the two calls in separate examples? All of the proxied methods are restored between every example. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=9984&group_id=797 From noreply at rubyforge.org Wed Apr 11 01:48:41 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 11 Apr 2007 01:48:41 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-9983 ] Allow before_setup and after_teardown to be called in BehaviourEval Message-ID: <20070411054841.D651A5240A9D@rubyforge.org> Feature Requests item #9983, was opened at 2007-04-09 06:29 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=9983&group_id=797 Category: None Group: None Status: Open Priority: 3 Submitted By: Brian Takita (btakita) Assigned to: Nobody (None) Summary: Allow before_setup and after_teardown to be called in BehaviourEval Initial Comment: This would provide a hook for cross cutting. For example: Somebody wants to have setup and/or teardown functionality in a select few Examples. One may want to create a module and define the included method. module Foobar def self.included(mod) mod.before_setup do puts 'my special setup hook' end end end describe MyObject include Foobar end ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-04-11 05:48 Message: Brian - what you say makes sense to me. Thanks for the explanation. RSpec currently supports a context_setup that happens once before all of the examples in a given context. So when is the hook supposed to get run? Before each example? Once before all examples? Would we want to have 4 hooks? before_context_setup, before_setup, and their teardown counterparts? On a side note, I'm planning to change setup so it takes an arg: def setup(scope=:each, &block) This will default to :each, but you can supply :all .... describe Thing do setup :all { ... } setup :each { ... } ... end So "setup :all" would replace context_setup (we'd leave context_setup for backwards compatibility). This might actually simplify this hook question because we could say: before_setup :each or before_setup :all WDYT? ---------------------------------------------------------------------- Comment By: Brian Takita (btakita) Date: 2007-04-11 05:03 Message: The objection I received, that I agree with, was a lack of cross cutting hooks. There are cases when a library developer would not want to require up to 3 touch points (include, setup, and teardown) to get the added feature set to run. In house, we have a number of helper packages that get applied only certain specs. For example, we have a module that hooks into TestCase that print how long the test took. Sometimes we want to apply to all of our tests, and sometimes we don't. Another example would be if you want some specs to print out the specdocs, but not others. At some level, it would be helpful to allow users to make 'plugins' of some type, rather than have to rely on editing core classes. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-09 10:59 Message: Right now you can do the following - would it suffice? # in a central location like spec_helper.rb module SpecialSetups def stuff_to_do_first ... end end Spec::Runner.configure do |config| config.include SpecialSetups end # in a spec file describe SomeObject do setup do stuff_to_do_first # other stuff end ... end This makes things a bit more transparent in the specs and is not really any more verbose if you've got a setup anyhow. WDYT? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=9983&group_id=797 From noreply at rubyforge.org Wed Apr 11 07:35:25 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 11 Apr 2007 07:35:25 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-9260 ] IvarProxy does not act like a hash Message-ID: <20070411113525.7BC13A970001@rubyforge.org> Bugs item #9260, was opened at 2007-03-13 13:08 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=9260&group_id=797 Category: rails plugin Group: None Status: Closed Resolution: None Priority: 3 Submitted By: Brian Takita (btakita) Assigned to: Nobody (None) Summary: IvarProxy does not act like a hash Initial Comment: undefined method `delete' for # This happened in a Helper Spec. Here is the code to reproduce this. mab = Markaby::Builder.new(assigns_hash, self) ---------------------------------------------------------------------- >Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-04-11 07:35 Message: I noticed this was closed without: * Mentioning why it was closed * Updating the CHANGELOG It looks like it was fixed in r1736. I have updated the CHANGELOG. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-02 22:20 Message: Brian, can you please submit a failing example? ---------------------------------------------------------------------- Comment By: Brian Takita (btakita) Date: 2007-03-13 13:13 Message: Here is a fix I used without specs (my specs pass now): class Spec::Rails::Expectations::IvarProxy def delete(name) @object.send(:remove_instance_variable, "@#{name}") if @object.instance_variables.include?("@#{name}") end def each @object.instance_variables do |var| yield @object.instance_variable_get(var) end end end ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=9260&group_id=797 From noreply at rubyforge.org Wed Apr 11 08:35:32 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 11 Apr 2007 08:35:32 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-9631 ] Custom Behaviour Runner Message-ID: <20070411123532.801585240995@rubyforge.org> Feature Requests item #9631, was opened at 2007-03-27 22:03 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=9631&group_id=797 >Category: runner module Group: None >Status: Closed Priority: 3 Submitted By: Bob Cotton (bcotton) >Assigned to: David Chelimsky (dchelimsky) Summary: Custom Behaviour Runner Initial Comment: Command line switch for custom behaviour runner. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-04-11 12:35 Message: This was fixed w/ patch [#9678], which was applied to r1726. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-03-28 07:01 Message: I'm also at a project where we do that (except we're using Watir). Our suite takes close to half an hour, so I'd be *very* interested in this. Is this something you can/want to share? ---------------------------------------------------------------------- Comment By: Bob Cotton (bcotton) Date: 2007-03-28 02:17 Message: We use rspec mostly for acceptance testing, driving selenium. Slow, Slow, Slow. It's for a multi-threaded runner. -Bob ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-03-27 23:45 Message: Interesting feature. Could you elaborate a little on the need for custom runners? I'm not sceptical - just curious. What does *your* custom runner do differently? (I assume you have one) ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=9631&group_id=797 From dchelimsky at gmail.com Wed Apr 11 08:49:11 2007 From: dchelimsky at gmail.com (David Chelimsky) Date: Wed, 11 Apr 2007 07:49:11 -0500 Subject: [rspec-devel] names for setup and teardown methods Message-ID: <57c63afe0704110549x2c2a42f6l641e0c59e9de0afb@mail.gmail.com> We're going to rename context_setup and context_teardown because they no longer read well when using "describe/id". There are two ideas floating around about this. The first: setup :each #default - works like setup does now setup :all #replaces context_setup teardown :each #default - works like teardown does now teardown :all #replaces context teardown The second uses "before" and "after" in the same way: before :each #default - works like setup does now before :all #replaces context_setup after :each #default - works like teardown does now after :all #replaces context teardown In both cases, the default is :each, so you can just say "setup do" or "before do" instead of "setup :each do" or "before :each do". == Examples describe Thing do setup :all { ... } setup :each { ... } it "should do something" { ... } it "should do something else" { ... } teardown :each { ... } teardown :all { ... } end describe Thing do before :all { ... } before :each { ... } it "should do something" { ... } it "should do something else" { ... } after :each { ... } after :all { ... } end describe Thing do before { ... } # works like before :each it "should do something" { ... } it "should do something else" { ... } after { ... } # works like after :each end One other thing that occurs to me is that "before :each" really means "before each example" - so perhaps it should be "before :each_example" and "before :all_examples" (or :each and :each_example could both be supported, etc). WDYT? From deanwampler at gmail.com Wed Apr 11 13:56:20 2007 From: deanwampler at gmail.com (Dean Wampler) Date: Wed, 11 Apr 2007 12:56:20 -0500 Subject: [rspec-devel] names for setup and teardown methods In-Reply-To: <57c63afe0704110549x2c2a42f6l641e0c59e9de0afb@mail.gmail.com> References: <57c63afe0704110549x2c2a42f6l641e0c59e9de0afb@mail.gmail.com> Message-ID: <6cf2a94f0704111056s591105bfm92e32c5e88fb2dc4@mail.gmail.com> Setup and teardown are more approachable to converts from Test::Unit, but "before :all" and "after :each" read better, IMHO. "all_examples" might cause people to ask "what examples?" I'm not sure most people will think of the "it blocks" as examples. Still, you could just accept any symbol that begins with "each" and "all", so people can invent their own name ;) dean On 4/11/07, David Chelimsky wrote: > We're going to rename context_setup and context_teardown because they > no longer read well when using "describe/id". There are two ideas > floating around about this. The first: > > setup :each #default - works like setup does now > setup :all #replaces context_setup > teardown :each #default - works like teardown does now > teardown :all #replaces context teardown > > The second uses "before" and "after" in the same way: > > before :each #default - works like setup does now > before :all #replaces context_setup > after :each #default - works like teardown does now > after :all #replaces context teardown > > In both cases, the default is :each, so you can just say "setup do" or > "before do" instead of "setup :each do" or "before :each do". > > == Examples > > describe Thing do > setup :all { ... } > setup :each { ... } > it "should do something" { ... } > it "should do something else" { ... } > teardown :each { ... } > teardown :all { ... } > end > > describe Thing do > before :all { ... } > before :each { ... } > it "should do something" { ... } > it "should do something else" { ... } > after :each { ... } > after :all { ... } > end > > describe Thing do > before { ... } # works like before :each > it "should do something" { ... } > it "should do something else" { ... } > after { ... } # works like after :each > end > > One other thing that occurs to me is that "before :each" really means > "before each example" - so perhaps it should be "before :each_example" > and "before :all_examples" (or :each and :each_example could both be > supported, etc). > > WDYT? > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > -- Dean Wampler http://www.objectmentor.com http://www.aspectprogramming.com http://www.contract4j.org From noreply at rubyforge.org Wed Apr 11 17:48:04 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 11 Apr 2007 17:48:04 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-9842 ] Cannot run specs due to fixture error Message-ID: <20070411214804.85F355240ABC@rubyforge.org> Bugs item #9842, was opened at 2007-04-04 14:59 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=9842&group_id=797 Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: Chad Humphries (spicycode) Assigned to: Nobody (None) Summary: Cannot run specs due to fixture error Initial Comment: New EdgeRails Project with 0.9.0 RSpec + RSpec On Rails Frozen in vendor/plugins project_here/vendor/plugins/rspec_on_rails/lib/spec/rails/dsl/behaviour/base.rb:32:in `configure': undefined method `fixtures' for # The model spec has no reference of fixtures in it, the spec_helper is vanilla/the default, and the app actually contacts no fixtures. ---------------------------------------------------------------------- Comment By: Chad Humphries (spicycode) Date: 2007-04-11 17:48 Message: I'm trying to get a good sample project carved out, or at least a working sample to send over together. I just experienced this again today on two of our other projects when attemping to convert to 0.9.0. They made use of fixtures and they all fail with the same error below. One is on postgres, one mysql, both using Ruby 1.8.6 on OSX. /vendor/plugins/rspec_on_rails/lib/spec/rails/dsl/behaviour/base.rb:32:in `configure': undefined method `fixtures' for # (NoMethodError) from project/vendor/plugins/rspec/lib/spec/dsl/behaviour_eval.rb:46:in `send' from project/vendor/plugins/rspec/lib/spec/dsl/behaviour_eval.rb:46:in `method_missing' from project/vendor/plugins/rspec/lib/spec/dsl/behaviour.rb:91:in `send' from project/vendor/plugins/rspec/lib/spec/dsl/behaviour.rb:91:in `method_missing' from project/vendor/plugins/rspec_on_rails/lib/spec/rails/dsl/behaviour/model.rb:12:in `before_eval' from project/vendor/plugins/rspec/lib/spec/dsl/behaviour.rb:25:in `initialize' from project/vendor/plugins/rspec_on_rails/lib/spec/rails/dsl/behaviour_factory.rb:36:in `new' from project/vendor/plugins/rspec_on_rails/lib/spec/rails/dsl/behaviour_factory.rb:36:in `create' ... 16 levels... from project/vendor/plugins/rspec/lib/spec/runner/option_parser.rb:236:in `parse' from project/vendor/plugins/rspec/lib/spec/runner/option_parser.rb:14:in `create_behaviour_runner' from project/vendor/plugins/rspec/lib/spec/runner/command_line.rb:14:in `run' from project/vendor/plugins/rspec/bin/spec:3 ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-04 15:54 Message: This is really bizarre. I'm able to run model specs w/ no fixtures against 1.8.6 (using multiruby - man, that rocks!) with no problem. Would you mind terribly zipping up your project and attaching it to this RFE? If you don't want it public, just email it to me directly. Thanks, David ---------------------------------------------------------------------- Comment By: Chad Humphries (spicycode) Date: 2007-04-04 15:38 Message: ~ script/spec spec/models -b ~/test_project/vendor/plugins/rspec_on_rails/lib/spec/rails/dsl/behaviour/base.rb:32:in `configure': undefined method `fixtures' for # (NoMethodError) from ~/test_project/vendor/plugins/rspec/lib/spec/dsl/behaviour_eval.rb:46:in `send' from ~/test_project/vendor/plugins/rspec/lib/spec/dsl/behaviour_eval.rb:46:in `method_missing' from ~/test_project/vendor/plugins/rspec/lib/spec/dsl/behaviour.rb:91:in `send' from ~/test_project/vendor/plugins/rspec/lib/spec/dsl/behaviour.rb:91:in `method_missing' from ~/test_project/vendor/plugins/rspec_on_rails/lib/spec/rails/dsl/behaviour/model.rb:12:in `before_eval' from ~/test_project/vendor/plugins/rspec/lib/spec/dsl/behaviour.rb:25:in `initialize' from ~/test_project/vendor/plugins/rspec_on_rails/lib/spec/rails/dsl/behaviour_factory.rb:36:in `new' from ~/test_project/vendor/plugins/rspec_on_rails/lib/spec/rails/dsl/behaviour_factory.rb:36:in `create' from ~/test_project/vendor/plugins/rspec_on_rails/lib/spec/rails/extensions/kernel.rb:4:in `describe' from ./spec/models/account_spec.rb:3 from ~/test_project/vendor/plugins/rspec/lib/spec/runner/behaviour_runner.rb:81:in `load' from ~/test_project/vendor/plugins/rspec/lib/spec/runner/behaviour_runner.rb:81:in `load_specs' from ~/test_project/vendor/plugins/rspec/lib/spec/runner/behaviour_runner.rb:80:in `each' from ~/test_project/vendor/plugins/rspec/lib/spec/runner/behaviour_runner.rb:80:in `load_specs' from ~/test_project/vendor/plugins/rspec/lib/spec/runner/behaviour_runner.rb:22:in `run' from ~/test_project/vendor/plugins/rspec/lib/spec/runner/command_line.rb:17:in `run' from script/spec:4 ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-04 15:34 Message: I haven't installed 1.8.6 and that may be part of the problem on my end. Would you please uncomment the line and run: script/spec spec/models -b and show us the backtrace? Thanks ---------------------------------------------------------------------- Comment By: Chad Humphries (spicycode) Date: 2007-04-04 15:27 Message: Commenting out line 32 of spec/rails/dsl/behaviour resolves it, but not sure why at the moment. # fixtures global_fixtures if global_fixtures ---------------------------------------------------------------------- Comment By: Chad Humphries (spicycode) Date: 2007-04-04 15:24 Message: - OSX 10.4.9 (Intel) - Ruby 1.8.6 - EdgeRails - Rspec/RspecOnRails/SpecUi 0.9.0 as a svn:external plugin Running the spec using either script/spec spec/models/model_spec.rb or via rake spec/rake spec:models ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-04 15:17 Message: how are you running the example? what command? from what directory? on what platform? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=9842&group_id=797 From noreply at rubyforge.org Wed Apr 11 19:57:51 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 11 Apr 2007 19:57:51 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-9842 ] Cannot run specs due to fixture error Message-ID: <20070411235751.57EA75240AE8@rubyforge.org> Bugs item #9842, was opened at 2007-04-04 14:59 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=9842&group_id=797 Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: Chad Humphries (spicycode) Assigned to: Nobody (None) Summary: Cannot run specs due to fixture error Initial Comment: New EdgeRails Project with 0.9.0 RSpec + RSpec On Rails Frozen in vendor/plugins project_here/vendor/plugins/rspec_on_rails/lib/spec/rails/dsl/behaviour/base.rb:32:in `configure': undefined method `fixtures' for # The model spec has no reference of fixtures in it, the spec_helper is vanilla/the default, and the app actually contacts no fixtures. ---------------------------------------------------------------------- >Comment By: Chad Humphries (spicycode) Date: 2007-04-11 19:57 Message: One other thing of note, this happens on rails 1.2.3, and edge with the 1.2.3 frozen or as a gem. No rspec gem is installed (soley used through the vendor/plugins/rspec provided script/rspec and rake tasks). It's like none of the testcase methods are available even though the i can see the inherit method call that should be providing them. ---------------------------------------------------------------------- Comment By: Chad Humphries (spicycode) Date: 2007-04-11 17:48 Message: I'm trying to get a good sample project carved out, or at least a working sample to send over together. I just experienced this again today on two of our other projects when attemping to convert to 0.9.0. They made use of fixtures and they all fail with the same error below. One is on postgres, one mysql, both using Ruby 1.8.6 on OSX. /vendor/plugins/rspec_on_rails/lib/spec/rails/dsl/behaviour/base.rb:32:in `configure': undefined method `fixtures' for # (NoMethodError) from project/vendor/plugins/rspec/lib/spec/dsl/behaviour_eval.rb:46:in `send' from project/vendor/plugins/rspec/lib/spec/dsl/behaviour_eval.rb:46:in `method_missing' from project/vendor/plugins/rspec/lib/spec/dsl/behaviour.rb:91:in `send' from project/vendor/plugins/rspec/lib/spec/dsl/behaviour.rb:91:in `method_missing' from project/vendor/plugins/rspec_on_rails/lib/spec/rails/dsl/behaviour/model.rb:12:in `before_eval' from project/vendor/plugins/rspec/lib/spec/dsl/behaviour.rb:25:in `initialize' from project/vendor/plugins/rspec_on_rails/lib/spec/rails/dsl/behaviour_factory.rb:36:in `new' from project/vendor/plugins/rspec_on_rails/lib/spec/rails/dsl/behaviour_factory.rb:36:in `create' ... 16 levels... from project/vendor/plugins/rspec/lib/spec/runner/option_parser.rb:236:in `parse' from project/vendor/plugins/rspec/lib/spec/runner/option_parser.rb:14:in `create_behaviour_runner' from project/vendor/plugins/rspec/lib/spec/runner/command_line.rb:14:in `run' from project/vendor/plugins/rspec/bin/spec:3 ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-04 15:54 Message: This is really bizarre. I'm able to run model specs w/ no fixtures against 1.8.6 (using multiruby - man, that rocks!) with no problem. Would you mind terribly zipping up your project and attaching it to this RFE? If you don't want it public, just email it to me directly. Thanks, David ---------------------------------------------------------------------- Comment By: Chad Humphries (spicycode) Date: 2007-04-04 15:38 Message: ~ script/spec spec/models -b ~/test_project/vendor/plugins/rspec_on_rails/lib/spec/rails/dsl/behaviour/base.rb:32:in `configure': undefined method `fixtures' for # (NoMethodError) from ~/test_project/vendor/plugins/rspec/lib/spec/dsl/behaviour_eval.rb:46:in `send' from ~/test_project/vendor/plugins/rspec/lib/spec/dsl/behaviour_eval.rb:46:in `method_missing' from ~/test_project/vendor/plugins/rspec/lib/spec/dsl/behaviour.rb:91:in `send' from ~/test_project/vendor/plugins/rspec/lib/spec/dsl/behaviour.rb:91:in `method_missing' from ~/test_project/vendor/plugins/rspec_on_rails/lib/spec/rails/dsl/behaviour/model.rb:12:in `before_eval' from ~/test_project/vendor/plugins/rspec/lib/spec/dsl/behaviour.rb:25:in `initialize' from ~/test_project/vendor/plugins/rspec_on_rails/lib/spec/rails/dsl/behaviour_factory.rb:36:in `new' from ~/test_project/vendor/plugins/rspec_on_rails/lib/spec/rails/dsl/behaviour_factory.rb:36:in `create' from ~/test_project/vendor/plugins/rspec_on_rails/lib/spec/rails/extensions/kernel.rb:4:in `describe' from ./spec/models/account_spec.rb:3 from ~/test_project/vendor/plugins/rspec/lib/spec/runner/behaviour_runner.rb:81:in `load' from ~/test_project/vendor/plugins/rspec/lib/spec/runner/behaviour_runner.rb:81:in `load_specs' from ~/test_project/vendor/plugins/rspec/lib/spec/runner/behaviour_runner.rb:80:in `each' from ~/test_project/vendor/plugins/rspec/lib/spec/runner/behaviour_runner.rb:80:in `load_specs' from ~/test_project/vendor/plugins/rspec/lib/spec/runner/behaviour_runner.rb:22:in `run' from ~/test_project/vendor/plugins/rspec/lib/spec/runner/command_line.rb:17:in `run' from script/spec:4 ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-04 15:34 Message: I haven't installed 1.8.6 and that may be part of the problem on my end. Would you please uncomment the line and run: script/spec spec/models -b and show us the backtrace? Thanks ---------------------------------------------------------------------- Comment By: Chad Humphries (spicycode) Date: 2007-04-04 15:27 Message: Commenting out line 32 of spec/rails/dsl/behaviour resolves it, but not sure why at the moment. # fixtures global_fixtures if global_fixtures ---------------------------------------------------------------------- Comment By: Chad Humphries (spicycode) Date: 2007-04-04 15:24 Message: - OSX 10.4.9 (Intel) - Ruby 1.8.6 - EdgeRails - Rspec/RspecOnRails/SpecUi 0.9.0 as a svn:external plugin Running the spec using either script/spec spec/models/model_spec.rb or via rake spec/rake spec:models ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-04 15:17 Message: how are you running the example? what command? from what directory? on what platform? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=9842&group_id=797 From noreply at rubyforge.org Thu Apr 12 01:18:42 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 12 Apr 2007 01:18:42 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-9735 ] support flexmock Message-ID: <20070412051842.54C5E5240B3F@rubyforge.org> Feature Requests item #9735, was opened at 2007-04-01 14:06 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=9735&group_id=797 Category: runner module Group: None >Status: Closed Priority: 3 Submitted By: David Chelimsky (dchelimsky) Assigned to: David Chelimsky (dchelimsky) Summary: support flexmock Initial Comment: RSpec-0.9 will support using mocha instead of Spec::Mocks (for those who choose) by doing the following: Spec::Runner.configure do |config| config.mock_with :mocha end We should add the same support for flexmock. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-04-12 05:18 Message: Thanks to Jim Weirich for putting this together for us, we can now use flexmock as well. This required some changes to flexmock which have not been released yet, but will be shortly. Once Jim releases the new version of flexmock, you'll be able to say: Spec::Runner.configure do |config| config.mock_with :flexmock end ... and off you go. Added to trunk r1750 ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=9735&group_id=797 From noreply at rubyforge.org Thu Apr 12 03:19:11 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 12 Apr 2007 03:19:11 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-9983 ] Allow before_setup and after_teardown to be called in BehaviourEval Message-ID: <20070412071911.B7D445240B3F@rubyforge.org> Feature Requests item #9983, was opened at 2007-04-08 23:29 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=9983&group_id=797 Category: None Group: None Status: Open Priority: 3 Submitted By: Brian Takita (btakita) Assigned to: Nobody (None) Summary: Allow before_setup and after_teardown to be called in BehaviourEval Initial Comment: This would provide a hook for cross cutting. For example: Somebody wants to have setup and/or teardown functionality in a select few Examples. One may want to create a module and define the included method. module Foobar def self.included(mod) mod.before_setup do puts 'my special setup hook' end end end describe MyObject include Foobar end ---------------------------------------------------------------------- >Comment By: Brian Takita (btakita) Date: 2007-04-12 00:19 Message: Great. This would get run before each example. I think we both agree that before_setup provides value. That would bring 4 hooks. Actually there are also the global before_setup hooks. Maybe there should be global before_context_setup hooks too? Your idea with the setup methods arguments looks good. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-10 22:48 Message: Brian - what you say makes sense to me. Thanks for the explanation. RSpec currently supports a context_setup that happens once before all of the examples in a given context. So when is the hook supposed to get run? Before each example? Once before all examples? Would we want to have 4 hooks? before_context_setup, before_setup, and their teardown counterparts? On a side note, I'm planning to change setup so it takes an arg: def setup(scope=:each, &block) This will default to :each, but you can supply :all .... describe Thing do setup :all { ... } setup :each { ... } ... end So "setup :all" would replace context_setup (we'd leave context_setup for backwards compatibility). This might actually simplify this hook question because we could say: before_setup :each or before_setup :all WDYT? ---------------------------------------------------------------------- Comment By: Brian Takita (btakita) Date: 2007-04-10 22:03 Message: The objection I received, that I agree with, was a lack of cross cutting hooks. There are cases when a library developer would not want to require up to 3 touch points (include, setup, and teardown) to get the added feature set to run. In house, we have a number of helper packages that get applied only certain specs. For example, we have a module that hooks into TestCase that print how long the test took. Sometimes we want to apply to all of our tests, and sometimes we don't. Another example would be if you want some specs to print out the specdocs, but not others. At some level, it would be helpful to allow users to make 'plugins' of some type, rather than have to rely on editing core classes. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-09 03:59 Message: Right now you can do the following - would it suffice? # in a central location like spec_helper.rb module SpecialSetups def stuff_to_do_first ... end end Spec::Runner.configure do |config| config.include SpecialSetups end # in a spec file describe SomeObject do setup do stuff_to_do_first # other stuff end ... end This makes things a bit more transparent in the specs and is not really any more verbose if you've got a setup anyhow. WDYT? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=9983&group_id=797 From noreply at rubyforge.org Thu Apr 12 05:37:07 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 12 Apr 2007 05:37:07 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-9983 ] Allow before_setup and after_teardown to be called in BehaviourEval Message-ID: <20070412093707.A44255240A6B@rubyforge.org> Feature Requests item #9983, was opened at 2007-04-09 02:29 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=9983&group_id=797 Category: None Group: None Status: Open Priority: 3 Submitted By: Brian Takita (btakita) Assigned to: Nobody (None) Summary: Allow before_setup and after_teardown to be called in BehaviourEval Initial Comment: This would provide a hook for cross cutting. For example: Somebody wants to have setup and/or teardown functionality in a select few Examples. One may want to create a module and define the included method. module Foobar def self.included(mod) mod.before_setup do puts 'my special setup hook' end end end describe MyObject include Foobar end ---------------------------------------------------------------------- >Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-04-12 05:37 Message: Contexts are gone, and so are specify (ok, they are around a little bit longer for compatibility). We should come up with names that make sense with the new API. The following has been suggested in various emails and chats: before(what=:each) # you can also pass :all after(what=:each) # you can also pass :all ---------------------------------------------------------------------- Comment By: Brian Takita (btakita) Date: 2007-04-12 03:19 Message: Great. This would get run before each example. I think we both agree that before_setup provides value. That would bring 4 hooks. Actually there are also the global before_setup hooks. Maybe there should be global before_context_setup hooks too? Your idea with the setup methods arguments looks good. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-11 01:48 Message: Brian - what you say makes sense to me. Thanks for the explanation. RSpec currently supports a context_setup that happens once before all of the examples in a given context. So when is the hook supposed to get run? Before each example? Once before all examples? Would we want to have 4 hooks? before_context_setup, before_setup, and their teardown counterparts? On a side note, I'm planning to change setup so it takes an arg: def setup(scope=:each, &block) This will default to :each, but you can supply :all .... describe Thing do setup :all { ... } setup :each { ... } ... end So "setup :all" would replace context_setup (we'd leave context_setup for backwards compatibility). This might actually simplify this hook question because we could say: before_setup :each or before_setup :all WDYT? ---------------------------------------------------------------------- Comment By: Brian Takita (btakita) Date: 2007-04-11 01:03 Message: The objection I received, that I agree with, was a lack of cross cutting hooks. There are cases when a library developer would not want to require up to 3 touch points (include, setup, and teardown) to get the added feature set to run. In house, we have a number of helper packages that get applied only certain specs. For example, we have a module that hooks into TestCase that print how long the test took. Sometimes we want to apply to all of our tests, and sometimes we don't. Another example would be if you want some specs to print out the specdocs, but not others. At some level, it would be helpful to allow users to make 'plugins' of some type, rather than have to rely on editing core classes. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-09 06:59 Message: Right now you can do the following - would it suffice? # in a central location like spec_helper.rb module SpecialSetups def stuff_to_do_first ... end end Spec::Runner.configure do |config| config.include SpecialSetups end # in a spec file describe SomeObject do setup do stuff_to_do_first # other stuff end ... end This makes things a bit more transparent in the specs and is not really any more verbose if you've got a setup anyhow. WDYT? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=9983&group_id=797 From bob.cotton at rallydev.com Thu Apr 12 07:39:46 2007 From: bob.cotton at rallydev.com (Bob Cotton) Date: Thu, 12 Apr 2007 05:39:46 -0600 Subject: [rspec-devel] [ rspec-Feature Requests-9983 ] Allow before_setup and after_teardown to be called in BehaviourEval In-Reply-To: <20070412093707.A44255240A6B@rubyforge.org> (noreply@rubyforge.org's message of "Thu, 12 Apr 2007 05:37:07 -0400 (EDT)") References: <20070412093707.A44255240A6B@rubyforge.org> Message-ID: >>Comment By: Aslak Helles?y (aslak_hellesoy) > Contexts are gone, and so are specify (ok, they are around a little > bit longer for compatibility). So is the rspec project going to change it's name, now that specs are gone? - Bob From noreply at rubyforge.org Thu Apr 12 08:30:20 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 12 Apr 2007 08:30:20 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-9983 ] Allow before_setup and after_teardown to be called in BehaviourEval Message-ID: <20070412123021.10C425240A73@rubyforge.org> Feature Requests item #9983, was opened at 2007-04-09 06:29 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=9983&group_id=797 Category: None Group: None Status: Open Priority: 3 Submitted By: Brian Takita (btakita) Assigned to: Nobody (None) Summary: Allow before_setup and after_teardown to be called in BehaviourEval Initial Comment: This would provide a hook for cross cutting. For example: Somebody wants to have setup and/or teardown functionality in a select few Examples. One may want to create a module and define the included method. module Foobar def self.included(mod) mod.before_setup do puts 'my special setup hook' end end end describe MyObject include Foobar end ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-04-12 12:30 Message: before and after (:each or :all) have been implemented now. These are there for use within examples. The other methods are still around as aliases to avoid compatibility problems, so you don't have to change existing specs (yet). Looking through the code, we do have before_setup and after_teardown hooks in Example (formerly Specification). I think you actually added these, Brian. So we need to do two things: - Come up w/ better names given the new API. - Add these to Behaviour so that they are accessible (right now I don't think anybody is using them). ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-04-12 09:37 Message: Contexts are gone, and so are specify (ok, they are around a little bit longer for compatibility). We should come up with names that make sense with the new API. The following has been suggested in various emails and chats: before(what=:each) # you can also pass :all after(what=:each) # you can also pass :all ---------------------------------------------------------------------- Comment By: Brian Takita (btakita) Date: 2007-04-12 07:19 Message: Great. This would get run before each example. I think we both agree that before_setup provides value. That would bring 4 hooks. Actually there are also the global before_setup hooks. Maybe there should be global before_context_setup hooks too? Your idea with the setup methods arguments looks good. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-11 05:48 Message: Brian - what you say makes sense to me. Thanks for the explanation. RSpec currently supports a context_setup that happens once before all of the examples in a given context. So when is the hook supposed to get run? Before each example? Once before all examples? Would we want to have 4 hooks? before_context_setup, before_setup, and their teardown counterparts? On a side note, I'm planning to change setup so it takes an arg: def setup(scope=:each, &block) This will default to :each, but you can supply :all .... describe Thing do setup :all { ... } setup :each { ... } ... end So "setup :all" would replace context_setup (we'd leave context_setup for backwards compatibility). This might actually simplify this hook question because we could say: before_setup :each or before_setup :all WDYT? ---------------------------------------------------------------------- Comment By: Brian Takita (btakita) Date: 2007-04-11 05:03 Message: The objection I received, that I agree with, was a lack of cross cutting hooks. There are cases when a library developer would not want to require up to 3 touch points (include, setup, and teardown) to get the added feature set to run. In house, we have a number of helper packages that get applied only certain specs. For example, we have a module that hooks into TestCase that print how long the test took. Sometimes we want to apply to all of our tests, and sometimes we don't. Another example would be if you want some specs to print out the specdocs, but not others. At some level, it would be helpful to allow users to make 'plugins' of some type, rather than have to rely on editing core classes. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-09 10:59 Message: Right now you can do the following - would it suffice? # in a central location like spec_helper.rb module SpecialSetups def stuff_to_do_first ... end end Spec::Runner.configure do |config| config.include SpecialSetups end # in a spec file describe SomeObject do setup do stuff_to_do_first # other stuff end ... end This makes things a bit more transparent in the specs and is not really any more verbose if you've got a setup anyhow. WDYT? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=9983&group_id=797 From dchelimsky at gmail.com Thu Apr 12 14:21:30 2007 From: dchelimsky at gmail.com (David Chelimsky) Date: Thu, 12 Apr 2007 13:21:30 -0500 Subject: [rspec-devel] RSpec part of two (count 'em, two) GSoC projects Message-ID: <57c63afe0704121121j39de5931l6ca47bcebdeca55d@mail.gmail.com> Here is the list of Ruby related projects accepted for GSoC. It includes two very similar projects (seemingly the same project, really, but I'm not saying anything ;) ) using RSpec to build a spec suite for implementations of the Ruby language: http://code.google.com/soc/ruby/about.html I'm, personally, very excited about the implications of this. Thanks to all of you who use, talk about and contribute to RSpec! Cheers, David (on behalf the RSpec Development Team) From aslak.hellesoy at gmail.com Thu Apr 12 15:15:27 2007 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Thu, 12 Apr 2007 21:15:27 +0200 Subject: [rspec-devel] RSpec part of two (count 'em, two) GSoC projects In-Reply-To: <57c63afe0704121121j39de5931l6ca47bcebdeca55d@mail.gmail.com> References: <57c63afe0704121121j39de5931l6ca47bcebdeca55d@mail.gmail.com> Message-ID: <8d961d900704121215rd37773al623c8dfb3bb7aad0@mail.gmail.com> On 4/12/07, David Chelimsky wrote: > Here is the list of Ruby related projects accepted for GSoC. It > includes two very similar projects (seemingly the same project, > really, but I'm not saying anything ;) ) using RSpec to build a spec > suite for implementations of the Ruby language: > > http://code.google.com/soc/ruby/about.html > Isn't it quite symptomatic that the two RSpec GSoC projects are essentially the same? I guess Ruby is really in need of a test suite. As late as yesterday I stumbled across a subtle bug in JRuby's handling of equality in hashes: http://jira.codehaus.org/browse/JRUBY-807 Aslak > I'm, personally, very excited about the implications of this. Thanks > to all of you who use, talk about and contribute to RSpec! > > Cheers, > David (on behalf the RSpec Development Team) > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From noreply at rubyforge.org Thu Apr 12 21:14:02 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 12 Apr 2007 21:14:02 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-10076 ] Invalid svn repository path on http://rspec.rubyforge.org/documentation/rails/install.html Message-ID: <20070413011403.00AAD5240B77@rubyforge.org> Bugs item #10076, was opened at 2007-04-13 01:14 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10076&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Esad Hajdarevic (esad) Assigned to: Nobody (None) Summary: Invalid svn repository path on http://rspec.rubyforge.org/documentation/rails/install.html Initial Comment: The documentation points the user to install rspec_on_rails from svn://rubyforge.org/var/svn/rspec/trunk/rspec_on_rails/vendor/plugins/rspec_on_rails which has changed to svn://rubyforge.org/var/svn/rspec/trunk/rspec_on_rails ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10076&group_id=797 From noreply at rubyforge.org Thu Apr 12 21:27:11 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 12 Apr 2007 21:27:11 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-10076 ] Invalid svn repository path on http://rspec.rubyforge.org/documentation/rails/install.html Message-ID: <20070413012711.2E6015240ADD@rubyforge.org> Bugs item #10076, was opened at 2007-04-12 21:14 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10076&group_id=797 Category: None Group: None >Status: Closed >Resolution: Accepted Priority: 3 Submitted By: Esad Hajdarevic (esad) >Assigned to: Aslak Helles?y (aslak_hellesoy) Summary: Invalid svn repository path on http://rspec.rubyforge.org/documentation/rails/install.html Initial Comment: The documentation points the user to install rspec_on_rails from svn://rubyforge.org/var/svn/rspec/trunk/rspec_on_rails/vendor/plugins/rspec_on_rails which has changed to svn://rubyforge.org/var/svn/rspec/trunk/rspec_on_rails ---------------------------------------------------------------------- >Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-04-12 21:27 Message: The documentation is changed in svn and will get to the website when we make the next release. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10076&group_id=797 From noreply at rubyforge.org Fri Apr 13 16:31:40 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 13 Apr 2007 16:31:40 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-9842 ] Cannot run specs due to fixture error Message-ID: <20070413203140.4D59D5240BC7@rubyforge.org> Bugs item #9842, was opened at 2007-04-04 14:59 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=9842&group_id=797 Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: Chad Humphries (spicycode) Assigned to: Nobody (None) Summary: Cannot run specs due to fixture error Initial Comment: New EdgeRails Project with 0.9.0 RSpec + RSpec On Rails Frozen in vendor/plugins project_here/vendor/plugins/rspec_on_rails/lib/spec/rails/dsl/behaviour/base.rb:32:in `configure': undefined method `fixtures' for # The model spec has no reference of fixtures in it, the spec_helper is vanilla/the default, and the app actually contacts no fixtures. ---------------------------------------------------------------------- >Comment By: Chad Humphries (spicycode) Date: 2007-04-13 16:31 Message: Found the cause, was a machine specific bug. ---------------------------------------------------------------------- Comment By: Chad Humphries (spicycode) Date: 2007-04-11 19:57 Message: One other thing of note, this happens on rails 1.2.3, and edge with the 1.2.3 frozen or as a gem. No rspec gem is installed (soley used through the vendor/plugins/rspec provided script/rspec and rake tasks). It's like none of the testcase methods are available even though the i can see the inherit method call that should be providing them. ---------------------------------------------------------------------- Comment By: Chad Humphries (spicycode) Date: 2007-04-11 17:48 Message: I'm trying to get a good sample project carved out, or at least a working sample to send over together. I just experienced this again today on two of our other projects when attemping to convert to 0.9.0. They made use of fixtures and they all fail with the same error below. One is on postgres, one mysql, both using Ruby 1.8.6 on OSX. /vendor/plugins/rspec_on_rails/lib/spec/rails/dsl/behaviour/base.rb:32:in `configure': undefined method `fixtures' for # (NoMethodError) from project/vendor/plugins/rspec/lib/spec/dsl/behaviour_eval.rb:46:in `send' from project/vendor/plugins/rspec/lib/spec/dsl/behaviour_eval.rb:46:in `method_missing' from project/vendor/plugins/rspec/lib/spec/dsl/behaviour.rb:91:in `send' from project/vendor/plugins/rspec/lib/spec/dsl/behaviour.rb:91:in `method_missing' from project/vendor/plugins/rspec_on_rails/lib/spec/rails/dsl/behaviour/model.rb:12:in `before_eval' from project/vendor/plugins/rspec/lib/spec/dsl/behaviour.rb:25:in `initialize' from project/vendor/plugins/rspec_on_rails/lib/spec/rails/dsl/behaviour_factory.rb:36:in `new' from project/vendor/plugins/rspec_on_rails/lib/spec/rails/dsl/behaviour_factory.rb:36:in `create' ... 16 levels... from project/vendor/plugins/rspec/lib/spec/runner/option_parser.rb:236:in `parse' from project/vendor/plugins/rspec/lib/spec/runner/option_parser.rb:14:in `create_behaviour_runner' from project/vendor/plugins/rspec/lib/spec/runner/command_line.rb:14:in `run' from project/vendor/plugins/rspec/bin/spec:3 ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-04 15:54 Message: This is really bizarre. I'm able to run model specs w/ no fixtures against 1.8.6 (using multiruby - man, that rocks!) with no problem. Would you mind terribly zipping up your project and attaching it to this RFE? If you don't want it public, just email it to me directly. Thanks, David ---------------------------------------------------------------------- Comment By: Chad Humphries (spicycode) Date: 2007-04-04 15:38 Message: ~ script/spec spec/models -b ~/test_project/vendor/plugins/rspec_on_rails/lib/spec/rails/dsl/behaviour/base.rb:32:in `configure': undefined method `fixtures' for # (NoMethodError) from ~/test_project/vendor/plugins/rspec/lib/spec/dsl/behaviour_eval.rb:46:in `send' from ~/test_project/vendor/plugins/rspec/lib/spec/dsl/behaviour_eval.rb:46:in `method_missing' from ~/test_project/vendor/plugins/rspec/lib/spec/dsl/behaviour.rb:91:in `send' from ~/test_project/vendor/plugins/rspec/lib/spec/dsl/behaviour.rb:91:in `method_missing' from ~/test_project/vendor/plugins/rspec_on_rails/lib/spec/rails/dsl/behaviour/model.rb:12:in `before_eval' from ~/test_project/vendor/plugins/rspec/lib/spec/dsl/behaviour.rb:25:in `initialize' from ~/test_project/vendor/plugins/rspec_on_rails/lib/spec/rails/dsl/behaviour_factory.rb:36:in `new' from ~/test_project/vendor/plugins/rspec_on_rails/lib/spec/rails/dsl/behaviour_factory.rb:36:in `create' from ~/test_project/vendor/plugins/rspec_on_rails/lib/spec/rails/extensions/kernel.rb:4:in `describe' from ./spec/models/account_spec.rb:3 from ~/test_project/vendor/plugins/rspec/lib/spec/runner/behaviour_runner.rb:81:in `load' from ~/test_project/vendor/plugins/rspec/lib/spec/runner/behaviour_runner.rb:81:in `load_specs' from ~/test_project/vendor/plugins/rspec/lib/spec/runner/behaviour_runner.rb:80:in `each' from ~/test_project/vendor/plugins/rspec/lib/spec/runner/behaviour_runner.rb:80:in `load_specs' from ~/test_project/vendor/plugins/rspec/lib/spec/runner/behaviour_runner.rb:22:in `run' from ~/test_project/vendor/plugins/rspec/lib/spec/runner/command_line.rb:17:in `run' from script/spec:4 ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-04 15:34 Message: I haven't installed 1.8.6 and that may be part of the problem on my end. Would you please uncomment the line and run: script/spec spec/models -b and show us the backtrace? Thanks ---------------------------------------------------------------------- Comment By: Chad Humphries (spicycode) Date: 2007-04-04 15:27 Message: Commenting out line 32 of spec/rails/dsl/behaviour resolves it, but not sure why at the moment. # fixtures global_fixtures if global_fixtures ---------------------------------------------------------------------- Comment By: Chad Humphries (spicycode) Date: 2007-04-04 15:24 Message: - OSX 10.4.9 (Intel) - Ruby 1.8.6 - EdgeRails - Rspec/RspecOnRails/SpecUi 0.9.0 as a svn:external plugin Running the spec using either script/spec spec/models/model_spec.rb or via rake spec/rake spec:models ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-04 15:17 Message: how are you running the example? what command? from what directory? on what platform? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=9842&group_id=797 From noreply at rubyforge.org Fri Apr 13 16:32:06 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 13 Apr 2007 16:32:06 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-9842 ] Cannot run specs due to fixture error Message-ID: <20070413203206.48E3B5240CC4@rubyforge.org> Bugs item #9842, was opened at 2007-04-04 14:59 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=9842&group_id=797 Category: rails plugin Group: None >Status: Closed Resolution: None Priority: 3 Submitted By: Chad Humphries (spicycode) Assigned to: Nobody (None) Summary: Cannot run specs due to fixture error Initial Comment: New EdgeRails Project with 0.9.0 RSpec + RSpec On Rails Frozen in vendor/plugins project_here/vendor/plugins/rspec_on_rails/lib/spec/rails/dsl/behaviour/base.rb:32:in `configure': undefined method `fixtures' for # The model spec has no reference of fixtures in it, the spec_helper is vanilla/the default, and the app actually contacts no fixtures. ---------------------------------------------------------------------- Comment By: Chad Humphries (spicycode) Date: 2007-04-13 16:31 Message: Found the cause, was a machine specific bug. ---------------------------------------------------------------------- Comment By: Chad Humphries (spicycode) Date: 2007-04-11 19:57 Message: One other thing of note, this happens on rails 1.2.3, and edge with the 1.2.3 frozen or as a gem. No rspec gem is installed (soley used through the vendor/plugins/rspec provided script/rspec and rake tasks). It's like none of the testcase methods are available even though the i can see the inherit method call that should be providing them. ---------------------------------------------------------------------- Comment By: Chad Humphries (spicycode) Date: 2007-04-11 17:48 Message: I'm trying to get a good sample project carved out, or at least a working sample to send over together. I just experienced this again today on two of our other projects when attemping to convert to 0.9.0. They made use of fixtures and they all fail with the same error below. One is on postgres, one mysql, both using Ruby 1.8.6 on OSX. /vendor/plugins/rspec_on_rails/lib/spec/rails/dsl/behaviour/base.rb:32:in `configure': undefined method `fixtures' for # (NoMethodError) from project/vendor/plugins/rspec/lib/spec/dsl/behaviour_eval.rb:46:in `send' from project/vendor/plugins/rspec/lib/spec/dsl/behaviour_eval.rb:46:in `method_missing' from project/vendor/plugins/rspec/lib/spec/dsl/behaviour.rb:91:in `send' from project/vendor/plugins/rspec/lib/spec/dsl/behaviour.rb:91:in `method_missing' from project/vendor/plugins/rspec_on_rails/lib/spec/rails/dsl/behaviour/model.rb:12:in `before_eval' from project/vendor/plugins/rspec/lib/spec/dsl/behaviour.rb:25:in `initialize' from project/vendor/plugins/rspec_on_rails/lib/spec/rails/dsl/behaviour_factory.rb:36:in `new' from project/vendor/plugins/rspec_on_rails/lib/spec/rails/dsl/behaviour_factory.rb:36:in `create' ... 16 levels... from project/vendor/plugins/rspec/lib/spec/runner/option_parser.rb:236:in `parse' from project/vendor/plugins/rspec/lib/spec/runner/option_parser.rb:14:in `create_behaviour_runner' from project/vendor/plugins/rspec/lib/spec/runner/command_line.rb:14:in `run' from project/vendor/plugins/rspec/bin/spec:3 ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-04 15:54 Message: This is really bizarre. I'm able to run model specs w/ no fixtures against 1.8.6 (using multiruby - man, that rocks!) with no problem. Would you mind terribly zipping up your project and attaching it to this RFE? If you don't want it public, just email it to me directly. Thanks, David ---------------------------------------------------------------------- Comment By: Chad Humphries (spicycode) Date: 2007-04-04 15:38 Message: ~ script/spec spec/models -b ~/test_project/vendor/plugins/rspec_on_rails/lib/spec/rails/dsl/behaviour/base.rb:32:in `configure': undefined method `fixtures' for # (NoMethodError) from ~/test_project/vendor/plugins/rspec/lib/spec/dsl/behaviour_eval.rb:46:in `send' from ~/test_project/vendor/plugins/rspec/lib/spec/dsl/behaviour_eval.rb:46:in `method_missing' from ~/test_project/vendor/plugins/rspec/lib/spec/dsl/behaviour.rb:91:in `send' from ~/test_project/vendor/plugins/rspec/lib/spec/dsl/behaviour.rb:91:in `method_missing' from ~/test_project/vendor/plugins/rspec_on_rails/lib/spec/rails/dsl/behaviour/model.rb:12:in `before_eval' from ~/test_project/vendor/plugins/rspec/lib/spec/dsl/behaviour.rb:25:in `initialize' from ~/test_project/vendor/plugins/rspec_on_rails/lib/spec/rails/dsl/behaviour_factory.rb:36:in `new' from ~/test_project/vendor/plugins/rspec_on_rails/lib/spec/rails/dsl/behaviour_factory.rb:36:in `create' from ~/test_project/vendor/plugins/rspec_on_rails/lib/spec/rails/extensions/kernel.rb:4:in `describe' from ./spec/models/account_spec.rb:3 from ~/test_project/vendor/plugins/rspec/lib/spec/runner/behaviour_runner.rb:81:in `load' from ~/test_project/vendor/plugins/rspec/lib/spec/runner/behaviour_runner.rb:81:in `load_specs' from ~/test_project/vendor/plugins/rspec/lib/spec/runner/behaviour_runner.rb:80:in `each' from ~/test_project/vendor/plugins/rspec/lib/spec/runner/behaviour_runner.rb:80:in `load_specs' from ~/test_project/vendor/plugins/rspec/lib/spec/runner/behaviour_runner.rb:22:in `run' from ~/test_project/vendor/plugins/rspec/lib/spec/runner/command_line.rb:17:in `run' from script/spec:4 ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-04 15:34 Message: I haven't installed 1.8.6 and that may be part of the problem on my end. Would you please uncomment the line and run: script/spec spec/models -b and show us the backtrace? Thanks ---------------------------------------------------------------------- Comment By: Chad Humphries (spicycode) Date: 2007-04-04 15:27 Message: Commenting out line 32 of spec/rails/dsl/behaviour resolves it, but not sure why at the moment. # fixtures global_fixtures if global_fixtures ---------------------------------------------------------------------- Comment By: Chad Humphries (spicycode) Date: 2007-04-04 15:24 Message: - OSX 10.4.9 (Intel) - Ruby 1.8.6 - EdgeRails - Rspec/RspecOnRails/SpecUi 0.9.0 as a svn:external plugin Running the spec using either script/spec spec/models/model_spec.rb or via rake spec/rake spec:models ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-04 15:17 Message: how are you running the example? what command? from what directory? on what platform? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=9842&group_id=797 From noreply at rubyforge.org Fri Apr 13 19:17:01 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 13 Apr 2007 19:17:01 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-10097 ] Let rcov_verify allow greater coverages via configuration Message-ID: <20070413231701.933D55240C1C@rubyforge.org> Feature Requests item #10097, was opened at 2007-04-13 19:17 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10097&group_id=797 Category: None Group: None Status: Open Priority: 3 Submitted By: Chad Humphries (spicycode) Assigned to: Nobody (None) Summary: Let rcov_verify allow greater coverages via configuration Initial Comment: I've attached a patch we use in most of our projects that allows simple configuration of the rcov_verify task. This leaves the default behaviour regarding thresholds, but allows for setting @require_exact_threshold = false to allow for overages. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10097&group_id=797 From undees at gmail.com Fri Apr 13 20:23:06 2007 From: undees at gmail.com (Ian Dees) Date: Fri, 13 Apr 2007 17:23:06 -0700 Subject: [rspec-devel] Removing context/specify: what will "it do" to spec names? Message-ID: Quoth Aslak: > Contexts are gone, and so are specify (ok, they are around a little bit longer for compatibility). context / specify are going to be deleted entirely? I thought they were just going to be preserved as an alternative to describe / it. I don't mind converting scripts, but what will this do to autogenerated spec names? For example: context "Foo" specify do @foo.bar.should == :baz end end would become: describe "Foo" it do @foo.bar.should == :baz end end "it do?" Doesn't feel right to me. From noreply at rubyforge.org Sat Apr 14 00:27:34 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sat, 14 Apr 2007 00:27:34 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-9984 ] Unmock methods Message-ID: <20070414042734.3D2855240CD0@rubyforge.org> Feature Requests item #9984, was opened at 2007-04-08 23:36 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=9984&group_id=797 Category: None Group: None Status: Open Priority: 3 Submitted By: Brian Takita (btakita) Assigned to: Nobody (None) Summary: Unmock methods Initial Comment: This would apply to partial mocks. Thes use case is: By default, I want a certain object to be mocked because the method that is called is very slow. However, I do want to test it's implementation in a few specs. Currently this works: class ObjectWithLongMethod def long_method 'this takes a long time' end end obj = ObjectWithLongMethod.new obj.stub!(:long_method).and_return('my string') obj.long_method.should == 'my string' obj.stub!(:long_method).and_return &obj.method(:proxied_by_rspec__long_method) obj.long_method.should == 'this takes a long time' ---------------------------------------------------------------------- >Comment By: Brian Takita (btakita) Date: 2007-04-13 21:27 Message: Here's Nathan's response: In response to - why not put the two calls in separate examples? I can't really speak to what 'example' means here, so I'll assume it's equivalent to 'context'. The answer is, well, that we have ~500-600 contexts.. and this is not the only thing that needs to be stubbed in general. Let me turn my actual example into a play problem. I have three expensive services, each of which needs to be mocked most of the time. Each service has a couple of contexts/specs that test that service in particular. There are around 500 contexts in all. IF I DO IT VIA EXPLICIT CONTEXT SWITCHING: Well, I've just duplicated my mocking calls 500 times. Furthermore, if I happen to find a fourth service to stub in a similar fashion, I have 500 contexts to add this stub to. Not great. IF I DO IT VIA STUB/UNSTUB: The idea would be that I have a global standard set of stubbings using before_setup. Having unstub would allow a developer to remove mocking from a particular area for a particular context or spec, which would make it really easy to add stubs to the global set. OTHER OPTIONS: Well, if you make sure that every context/spec has a common include/setup, you can make that include method take an argument to say "well, don't actually stub this service". Trouble with this approach is that any context that doesn't use this include/setup won't benefit from any stubs at all. Part of the benefit of using a single global area for your default stubs is that you no longer have to think about your stubs for test cases that don't play with them. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-10 22:45 Message: Do you mean "stub the object"? Please do ask the dev to chime in. Thx ---------------------------------------------------------------------- Comment By: Brian Takita (btakita) Date: 2007-04-10 22:24 Message: We have a project where the developers found it preferable to mock the object by default because there where only a few specs that used the real implementation. Its like a negative space. I'll ask the developer who requested this to chime in. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-09 04:06 Message: Why not put the two calls in separate examples? All of the proxied methods are restored between every example. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=9984&group_id=797 From nicksieger at gmail.com Sat Apr 14 00:41:28 2007 From: nicksieger at gmail.com (Nick Sieger) Date: Fri, 13 Apr 2007 23:41:28 -0500 Subject: [rspec-devel] No more spec_started in BaseTextFormatter Message-ID: Hi, David removed this method in 1640: | r1640 | dchelimsky | 2007-03-21 20:05:20 -0500 (Wed, 21 Mar 2007) | 3 lines | | removed example_started from reporter and formatters. | It wasn't buying us anything and it was costing us extra binding between examples | and the reporter I'll defer to you since you had a good reason for jettisoning it, but let me plead my case -- I was using this in ci_reporter in order to measure the duration of individual specs/examples. Any suggestions for a workaround or way to achieve the same effect in the meantime? /Nick From dchelimsky at gmail.com Sat Apr 14 01:02:56 2007 From: dchelimsky at gmail.com (David Chelimsky) Date: Sat, 14 Apr 2007 00:02:56 -0500 Subject: [rspec-devel] Removing context/specify: what will "it do" to spec names? In-Reply-To: References: Message-ID: <57c63afe0704132202s672d120dk128903d727405210@mail.gmail.com> On 4/13/07, Ian Dees wrote: > Quoth Aslak: > > > Contexts are gone, and so are specify (ok, they are around a little bit longer for compatibility). > > context / specify are going to be deleted entirely? I thought they > were just going to be preserved as an alternative to describe / it. > > I don't mind converting scripts, but what will this do to > autogenerated spec names? For example: > > context "Foo" > specify do > @foo.bar.should == :baz > end > end > > would become: > > describe "Foo" > it do > @foo.bar.should == :baz > end > end > > "it do?" Doesn't feel right to me. It don't? Seriously - we'll probably keep specify around unless somebody comes up w/ a better word that "it". > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From dchelimsky at gmail.com Sat Apr 14 01:07:07 2007 From: dchelimsky at gmail.com (David Chelimsky) Date: Sat, 14 Apr 2007 00:07:07 -0500 Subject: [rspec-devel] No more spec_started in BaseTextFormatter In-Reply-To: References: Message-ID: <57c63afe0704132207h26d1769bq82e52f55d0efda79@mail.gmail.com> On 4/13/07, Nick Sieger wrote: > Hi, > > David removed this method in 1640: > > | r1640 | dchelimsky | 2007-03-21 20:05:20 -0500 (Wed, 21 Mar 2007) | 3 lines > | > | removed example_started from reporter and formatters. > | It wasn't buying us anything and it was costing us extra binding > between examples > | and the reporter > > I'll defer to you since you had a good reason for jettisoning it, but > let me plead my case -- I was using this in ci_reporter in order to > measure the duration of individual specs/examples. > > Any suggestions for a workaround or way to achieve the same effect in > the meantime? Sorry - there's nothing right now. I really didn't think anyone was using this - I know RSpec wasn't in any of its formatters. There's an RFE for adding hooks before setting up and after tearing down each behaviour and/or example. Would that do the trick for you? If not, go ahead and add a new RFE to reinstate spec_started. > > /Nick > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From nicksieger at gmail.com Sat Apr 14 22:55:43 2007 From: nicksieger at gmail.com (Nick Sieger) Date: Sat, 14 Apr 2007 21:55:43 -0500 Subject: [rspec-devel] No more spec_started in BaseTextFormatter In-Reply-To: <57c63afe0704132207h26d1769bq82e52f55d0efda79@mail.gmail.com> References: <57c63afe0704132207h26d1769bq82e52f55d0efda79@mail.gmail.com> Message-ID: On 4/14/07, David Chelimsky wrote: > Sorry - there's nothing right now. I really didn't think anyone was > using this - I know RSpec wasn't in any of its formatters. There's an > RFE for adding hooks before setting up and after tearing down each > behaviour and/or example. Would that do the trick for you? If not, go > ahead and add a new RFE to reinstate spec_started. I think before setup and after teardown hooks for behaviour and example should suffice for my purposes. I'll look for the RFE, add a comment, and watch it. Thanks, /Nick From nicksieger at gmail.com Sat Apr 14 23:02:45 2007 From: nicksieger at gmail.com (Nick Sieger) Date: Sat, 14 Apr 2007 22:02:45 -0500 Subject: [rspec-devel] No more spec_started in BaseTextFormatter In-Reply-To: References: <57c63afe0704132207h26d1769bq82e52f55d0efda79@mail.gmail.com> Message-ID: On 4/14/07, Nick Sieger wrote: > On 4/14/07, David Chelimsky wrote: > > Sorry - there's nothing right now. I really didn't think anyone was > > using this - I know RSpec wasn't in any of its formatters. There's an > > RFE for adding hooks before setting up and after tearing down each > > behaviour and/or example. Would that do the trick for you? If not, go > > ahead and add a new RFE to reinstate spec_started. > > I think before setup and after teardown hooks for behaviour and > example should suffice for my purposes. I'll look for the RFE, add a > comment, and watch it. > Now, after looking, I don't see to which RFE you're referring. If you can find it, that would be great, otherwise if you could let me know, I can file a new one. /Nick From dchelimsky at gmail.com Sat Apr 14 23:15:25 2007 From: dchelimsky at gmail.com (David Chelimsky) Date: Sat, 14 Apr 2007 22:15:25 -0500 Subject: [rspec-devel] No more spec_started in BaseTextFormatter In-Reply-To: References: <57c63afe0704132207h26d1769bq82e52f55d0efda79@mail.gmail.com> Message-ID: <57c63afe0704142015k2ab9f684r67d36ac8b081137b@mail.gmail.com> On 4/14/07, Nick Sieger wrote: > On 4/14/07, Nick Sieger wrote: > > On 4/14/07, David Chelimsky wrote: > > > Sorry - there's nothing right now. I really didn't think anyone was > > > using this - I know RSpec wasn't in any of its formatters. There's an > > > RFE for adding hooks before setting up and after tearing down each > > > behaviour and/or example. Would that do the trick for you? If not, go > > > ahead and add a new RFE to reinstate spec_started. > > > > I think before setup and after teardown hooks for behaviour and > > example should suffice for my purposes. I'll look for the RFE, add a > > comment, and watch it. > > > > Now, after looking, I don't see to which RFE you're referring. If you > can find it, that would be great, otherwise if you could let me know, > I can file a new one. http://rubyforge.org/tracker/?func=detail&group_id=797&aid=9983&atid=3152 > > /Nick > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From dchelimsky at gmail.com Mon Apr 16 05:29:12 2007 From: dchelimsky at gmail.com (David Chelimsky) Date: Mon, 16 Apr 2007 04:29:12 -0500 Subject: [rspec-devel] Fwd: ANN: FlexMock 0.6.0 Released In-Reply-To: References: Message-ID: <57c63afe0704160229m160ae077l679f24501d122708@mail.gmail.com> FYI - Jim Weirich just released an rspec-compatible version of FlexMock. For those of you using trunk, you can now use either FlexMock, Mocha, or RSpec's built-in mocking framework by saying: Spec::Runner.configure do |config| config.mock_with :flexmock # or :mocha or :rspec (default) end The choice is yours. Mock in peace. Cheers, David ---------- Forwarded message ---------- From: Jim Weirich Date: Apr 15, 2007 9:34 PM Subject: ANN: FlexMock 0.6.0 Released To: ruby-talk ML = FlexMock 0.6.0 Released FlexMock is a flexible mocking library for use in unit testing and behavior specification in Ruby. Version 0.6.0 introduces a number of API enhancements to make testing with mocks even easier than before. == New in 0.6.0 * Better integration with Test::Unit (no need to explicitly include FlexMock::TestCase). * Integration with RSpec (version 0.9.0 or later of RSpec is required). * The +flexmock+ method will now create both regular mocks and partial mocks. flexmock() # => a full mock flexmock(person) # => a partial mock based on person (+flexstub+ is still included for backwards compatibility). * Quick and simple mocks my now be created using an expectation hash. For example: flexmock(:foo => 10, :bar => "Hello") will create a mock with two methods, :foo and :bar,defined. :foo will return 10 when invoked, and :bar will return "Hello". * The +should_receive+ method will now allow multiple methods (with the same constraints) be defined in a single call. For example, the following declares that both :read and :write need to be called at least one time each on the mock object. flexmock.should_receive(:read, :write).at_least.once * +should_recieve+ now will allow expectation hashes as arguments. This is similar to the list of methods, but allows each defined method to have its own return value. flexmock.should_receive(:name => "John", :age => 32) * In addition to using a block for defining constrains, constraints may now be applied directly to the return value of +new_instances+. Combined with the expectation hashes supported by +should_receive+, simple mocking scenarios have become much more succinct. For example: flexmock(Person).new_instances.should_receive(:name => "John", :age => 32) * Improved implementation, allowing for more flexible use and greater consistency between full mock and partial mocks. * Version 0.6.0 also includes a fix for an incompatibility with some older versions of RCov. The FlexMock Rakefile now includes a RCov task (and we have 100% code coverage). == What is FlexMock? FlexMock is a flexible framework for creating mock object for testing. When running unit tests, it is often desirable to use isolate the objects being tested from the "real world" by having them interact with simplified test objects. Sometimes these test objects simply return values when called, other times they verify that certain methods were called with particular arguments in a particular order. FlexMock makes creating these test objects easy. === Features * Easy integration with both Test::Unit and RSpec. Mocks created with the flexmock method are automatically verified at the end of the test or example. * A fluent interface that allows mock behavior to be specified very easily. * A "record mode" where an existing implementation can record its interaction with a mock for later validation against a new implementation. * Easy mocking of individual methods in existing, non-mock objects. * The ability to cause classes to instantiate test instances (instead of real instances) for the duration of a test. === Example Suppose you had a Dog object that wagged a tail when it was happy. Something like this: class Dog def initialize(a_tail) @tail = a_tail end def happy @tail.wag end end To test the +Dog+ class without a real +Tail+ object (perhaps because real +Tail+ objects activate servos in some robotic equipment), you can do something like this: require 'test/unit' require 'flexmock/test_unit' class TestDog < Test::Unit::TestCase def test_dog_wags_tail_when_happy tail = flexmock("tail") tail.should_receive(:wag).once dog = Dog.new(tail) dog.happy end end FlexMock will automatically verify that the mocked tail object received the message +wag+ exactly one time. If it doesn't, the test will not pass. See the FlexMock documentation at http://flexmock.rubyforge.org for details on specifying arguments and return values on mocked methods, as well as a simple technique for mocking tail objects when the Dog class creates the tail objects directly. == Availability You can make sure you have the latest version with a quick RubyGems command: gem install flexmock (you may need root/admin privileges) Otherwise, you can get it from the more traditional places: Download:: http://rubyforge.org/project/showfiles.php?group_id=170 You will find documentation at: http://flexmock.rubyforge.org. -- Jim Weirich -- Posted via http://www.ruby-forum.com/. From noreply at rubyforge.org Mon Apr 16 06:16:26 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 16 Apr 2007 06:16:26 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-9984 ] Unmock methods Message-ID: <20070416101626.CD55852409DA@rubyforge.org> Feature Requests item #9984, was opened at 2007-04-09 06:36 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=9984&group_id=797 >Category: mock module Group: None >Status: Closed Priority: 3 Submitted By: Brian Takita (btakita) >Assigned to: David Chelimsky (dchelimsky) Summary: Unmock methods Initial Comment: This would apply to partial mocks. Thes use case is: By default, I want a certain object to be mocked because the method that is called is very slow. However, I do want to test it's implementation in a few specs. Currently this works: class ObjectWithLongMethod def long_method 'this takes a long time' end end obj = ObjectWithLongMethod.new obj.stub!(:long_method).and_return('my string') obj.long_method.should == 'my string' obj.stub!(:long_method).and_return &obj.method(:proxied_by_rspec__long_method) obj.long_method.should == 'this takes a long time' ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-04-16 10:16 Message: Thanks for the thorough response. My instinct is that a dynamic mocking library is not the right place for the solution to this problem. I'd rather see a solution that would let you bypass the stub external to the mock framework. For example: =================== # already supported module SetupHelper def do_not_stub_long_method @do_not_stub_long_method = true end end Spec::Runner.configure { |config| config.include SetupHelper } =================== # not yet supported Spec::Runner::Example.before_setup do @obj = ObjectWithLongMethod.new end Spec::Runner::Example.after_setup do unless @do_not_stub_long_method @obj.stub!(:long_method).and_return('stub value') end end =================== describe ThingThatUsesObjectWithLongMethod do it "should access the stub" do ... end end describe ObjectWithLongMethod do setup do do_not_stub_long_method end it "should access the original method" do ... end end There is already an RFE to support before_setup and after_teardown (http://rubyforge.org/tracker/index.php?func=detail&aid=9983&group_id=797&atid=3152), and we've discussed adding after_setup and before_teardown as well. In my view, this is a very flexible approach, and I'm much more comfortable with this sort of solution rather than making the mocking framework any more complex than it already is. I'm rejecting this one, but I'm going to prioritize [#9983], so you should have a solution to your problem soon. ---------------------------------------------------------------------- Comment By: Brian Takita (btakita) Date: 2007-04-14 04:27 Message: Here's Nathan's response: In response to - why not put the two calls in separate examples? I can't really speak to what 'example' means here, so I'll assume it's equivalent to 'context'. The answer is, well, that we have ~500-600 contexts.. and this is not the only thing that needs to be stubbed in general. Let me turn my actual example into a play problem. I have three expensive services, each of which needs to be mocked most of the time. Each service has a couple of contexts/specs that test that service in particular. There are around 500 contexts in all. IF I DO IT VIA EXPLICIT CONTEXT SWITCHING: Well, I've just duplicated my mocking calls 500 times. Furthermore, if I happen to find a fourth service to stub in a similar fashion, I have 500 contexts to add this stub to. Not great. IF I DO IT VIA STUB/UNSTUB: The idea would be that I have a global standard set of stubbings using before_setup. Having unstub would allow a developer to remove mocking from a particular area for a particular context or spec, which would make it really easy to add stubs to the global set. OTHER OPTIONS: Well, if you make sure that every context/spec has a common include/setup, you can make that include method take an argument to say "well, don't actually stub this service". Trouble with this approach is that any context that doesn't use this include/setup won't benefit from any stubs at all. Part of the benefit of using a single global area for your default stubs is that you no longer have to think about your stubs for test cases that don't play with them. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-11 05:45 Message: Do you mean "stub the object"? Please do ask the dev to chime in. Thx ---------------------------------------------------------------------- Comment By: Brian Takita (btakita) Date: 2007-04-11 05:24 Message: We have a project where the developers found it preferable to mock the object by default because there where only a few specs that used the real implementation. Its like a negative space. I'll ask the developer who requested this to chime in. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-09 11:06 Message: Why not put the two calls in separate examples? All of the proxied methods are restored between every example. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=9984&group_id=797 From noreply at rubyforge.org Mon Apr 16 06:30:59 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 16 Apr 2007 06:30:59 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-10133 ] custom predicate matchers Message-ID: <20070416103059.22CCE5240943@rubyforge.org> Feature Requests item #10133, was opened at 2007-04-16 10:30 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10133&group_id=797 Category: expectation module Group: None Status: Open Priority: 3 Submitted By: David Chelimsky (dchelimsky) Assigned to: David Chelimsky (dchelimsky) Summary: custom predicate matchers Initial Comment: RSpec <= 0.8 let you do this: obj.should_predicate For example: obj.should_exist which would pass if obj.exist? returns true. In RSpec 0.9, there is no underscore-less parallel: obj.should exist This was excluded deliberately because when RSpec does not find the #exist method there are more than one reason that it might be missing: it could be a helper method that hasn't been written yet OR it could be a predicate on obj that hasn't been written yet. I still think this is the correct decision, however, the following would support easy creation of custom predicate matchers: Spec::Runner.configure do |config| config.predicate_matchers :exist end and/or describe Thing do predicate_matchers :exist it "should exist" do Thing.new.should exist end end ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10133&group_id=797 From dchelimsky at gmail.com Mon Apr 16 08:35:58 2007 From: dchelimsky at gmail.com (David Chelimsky) Date: Mon, 16 Apr 2007 07:35:58 -0500 Subject: [rspec-devel] No more spec_started in BaseTextFormatter In-Reply-To: <57c63afe0704142015k2ab9f684r67d36ac8b081137b@mail.gmail.com> References: <57c63afe0704132207h26d1769bq82e52f55d0efda79@mail.gmail.com> <57c63afe0704142015k2ab9f684r67d36ac8b081137b@mail.gmail.com> Message-ID: <57c63afe0704160535y8d9d8e6wcc3fab2589d039d6@mail.gmail.com> On 4/14/07, David Chelimsky wrote: > On 4/14/07, Nick Sieger wrote: > > On 4/14/07, Nick Sieger wrote: > > > On 4/14/07, David Chelimsky wrote: > > > > Sorry - there's nothing right now. I really didn't think anyone was > > > > using this - I know RSpec wasn't in any of its formatters. There's an > > > > RFE for adding hooks before setting up and after tearing down each > > > > behaviour and/or example. Would that do the trick for you? If not, go > > > > ahead and add a new RFE to reinstate spec_started. > > > > > > I think before setup and after teardown hooks for behaviour and > > > example should suffice for my purposes. I'll look for the RFE, add a > > > comment, and watch it. > > > > > > > Now, after looking, I don't see to which RFE you're referring. If you > > can find it, that would be great, otherwise if you could let me know, > > I can file a new one. > > http://rubyforge.org/tracker/?func=detail&group_id=797&aid=9983&atid=3152 Actually - that RFE is really for a different concept - a place to put global setup and teardown code as opposed to a notification when an example has started. I've just reinstated example_started in Reporter and BaseTextFormatter in trunk. Sorry for the inconvenience. Cheers, David From dchelimsky at gmail.com Mon Apr 16 10:07:29 2007 From: dchelimsky at gmail.com (David Chelimsky) Date: Mon, 16 Apr 2007 09:07:29 -0500 Subject: [rspec-devel] before before and after after Message-ID: <57c63afe0704160707q7de1ed20j2b2400881085a17f@mail.gmail.com> Hi all, There are currently a number of ways to extend RSpec that are documented inconsistently and work in sometimes conflicting and/or confusing ways. I'd like to resolve that. The recent addition of Spec::Runner.configure is part of that resolution. The thing I want to tackle now is the stuff that happens before and after each example. Currently (in trunk), things are executed in the following order: describe Thing do before(:all) do #happens first, but only once within this "describe" block end before(:each) do #happens before each example within this "describe" block end it "should ..." do #this is the example end after(:each) do #happens after each example within this "describe" block end after(:all) do #happens last, but only once within this "describe" block end end In addition to this, there have been requests to support global "before" and "after". Here's where I'd like to end up: Spec::DSL::Example.before(:first) do # before "before(:all)" and "before(:each)" end Spec::DSL::Example.before(:last) do # after "before(:all)" and "before(:each)", but before the example end Spec::DSL::Example.after(:first) do # before "after(:each)" and "after(:all)", but after the example end Spec::DSL::Example.after(:last) do # after "after(:each)" and "after(:all)" end So the over all order for every example (a.k.a. specify) would be: before(:first) before(:all) #once per "describe" before(:each) before(:last) example after(:first) after(:each) after(:all) #once per "describe" after(:last) I'm certainly open to other suggestions - this is merely a proposal. In most cases you wouldn't use all of these. In fact, you may not use any of them if you prefer the Object Mother approach (helper methods that create the state you want to start with). But this would give you a lot of choice at both global and granular levels. WDYT? Too confusing? Too limiting? Just right? Thanks, David From mtrier at eminentconsultinggroup.com Mon Apr 16 10:24:53 2007 From: mtrier at eminentconsultinggroup.com (Michael Trier) Date: Mon, 16 Apr 2007 10:24:53 -0400 Subject: [rspec-devel] [rspec-users] before before and after after In-Reply-To: <57c63afe0704160707q7de1ed20j2b2400881085a17f@mail.gmail.com> References: <57c63afe0704160707q7de1ed20j2b2400881085a17f@mail.gmail.com> Message-ID: <7810AB1E-6D5D-41A3-8CAD-4C28C4985802@eminentconsultinggroup.com> > Hi all, > > There are currently a number of ways to extend RSpec that are > documented inconsistently and work in sometimes conflicting and/or > confusing ways. I'd like to resolve that. The recent addition of > Spec::Runner.configure is part of that resolution. > > The thing I want to tackle now is the stuff that happens before and > after each example. Currently (in trunk), things are executed in the > following order: > > describe Thing do > before(:all) do > #happens first, but only once within this "describe" block > end > before(:each) do > #happens before each example within this "describe" block > end > it "should ..." do > #this is the example > end > after(:each) do > #happens after each example within this "describe" block > end > after(:all) do > #happens last, but only once within this "describe" block > end > end > > In addition to this, there have been requests to support global > "before" and "after". Here's where I'd like to end up: > > Spec::DSL::Example.before(:first) do > # before "before(:all)" and "before(:each)" > end > > Spec::DSL::Example.before(:last) do > # after "before(:all)" and "before(:each)", but before the example > end > > Spec::DSL::Example.after(:first) do > # before "after(:each)" and "after(:all)", but after the example > end > > Spec::DSL::Example.after(:last) do > # after "after(:each)" and "after(:all)" > end > > So the over all order for every example (a.k.a. specify) would be: > > before(:first) > before(:all) #once per "describe" > before(:each) > before(:last) > example > after(:first) > after(:each) > after(:all) #once per "describe" > after(:last) > > I'm certainly open to other suggestions - this is merely a proposal. > In most cases you wouldn't use all of these. In fact, you may not use > any of them if you prefer the Object Mother approach (helper methods > that create the state you want to start with). But this would give you > a lot of choice at both global and granular levels. > > WDYT? Too confusing? Too limiting? Just right? It sounds good to me, although I can't see a situation where I would need before(:last) or after(:first), just the outerlying ones (before (:first) and after(:last). Michael From noreply at rubyforge.org Mon Apr 16 13:50:08 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 16 Apr 2007 13:50:08 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-9735 ] support flexmock Message-ID: <20070416175008.50DA75240B28@rubyforge.org> Feature Requests item #9735, was opened at 2007-04-01 10:06 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=9735&group_id=797 Category: runner module Group: None >Status: Open Priority: 3 Submitted By: David Chelimsky (dchelimsky) Assigned to: David Chelimsky (dchelimsky) Summary: support flexmock Initial Comment: RSpec-0.9 will support using mocha instead of Spec::Mocks (for those who choose) by doing the following: Spec::Runner.configure do |config| config.mock_with :mocha end We should add the same support for flexmock. ---------------------------------------------------------------------- >Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-04-16 13:50 Message: Autoverification is broken. If you comment out the msg invocation in mocking_with_flexmock.rb the spec is passing, but it shouldn't be. This is on RSpec trunk (r1778) and Flexmock 0.6.0. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-12 01:18 Message: Thanks to Jim Weirich for putting this together for us, we can now use flexmock as well. This required some changes to flexmock which have not been released yet, but will be shortly. Once Jim releases the new version of flexmock, you'll be able to say: Spec::Runner.configure do |config| config.mock_with :flexmock end ... and off you go. Added to trunk r1750 ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=9735&group_id=797 From noreply at rubyforge.org Mon Apr 16 14:43:05 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 16 Apr 2007 14:43:05 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-9735 ] support flexmock Message-ID: <20070416184306.09C595240AAD@rubyforge.org> Feature Requests item #9735, was opened at 2007-04-01 14:06 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=9735&group_id=797 Category: runner module Group: None Status: Open Priority: 3 Submitted By: David Chelimsky (dchelimsky) Assigned to: David Chelimsky (dchelimsky) Summary: support flexmock Initial Comment: RSpec-0.9 will support using mocha instead of Spec::Mocks (for those who choose) by doing the following: Spec::Runner.configure do |config| config.mock_with :mocha end We should add the same support for flexmock. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-04-16 18:43 Message: Damn. I'll work w/ Jim to get this working. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-04-16 17:50 Message: Autoverification is broken. If you comment out the msg invocation in mocking_with_flexmock.rb the spec is passing, but it shouldn't be. This is on RSpec trunk (r1778) and Flexmock 0.6.0. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-12 05:18 Message: Thanks to Jim Weirich for putting this together for us, we can now use flexmock as well. This required some changes to flexmock which have not been released yet, but will be shortly. Once Jim releases the new version of flexmock, you'll be able to say: Spec::Runner.configure do |config| config.mock_with :flexmock end ... and off you go. Added to trunk r1750 ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=9735&group_id=797 From noreply at rubyforge.org Mon Apr 16 15:07:27 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 16 Apr 2007 15:07:27 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-9735 ] support flexmock Message-ID: <20070416190727.2FFD35240B27@rubyforge.org> Feature Requests item #9735, was opened at 2007-04-01 14:06 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=9735&group_id=797 Category: runner module Group: None >Status: Closed Priority: 3 Submitted By: David Chelimsky (dchelimsky) Assigned to: David Chelimsky (dchelimsky) Summary: support flexmock Initial Comment: RSpec-0.9 will support using mocha instead of Spec::Mocks (for those who choose) by doing the following: Spec::Runner.configure do |config| config.mock_with :mocha end We should add the same support for flexmock. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-04-16 19:07 Message: Our example was not following flexmock's API. We didn't have .once in the expectation: mock.should_receive(:msg).with('arg').once I fixed the example and I'm closing this. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-16 18:43 Message: Damn. I'll work w/ Jim to get this working. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-04-16 17:50 Message: Autoverification is broken. If you comment out the msg invocation in mocking_with_flexmock.rb the spec is passing, but it shouldn't be. This is on RSpec trunk (r1778) and Flexmock 0.6.0. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-12 05:18 Message: Thanks to Jim Weirich for putting this together for us, we can now use flexmock as well. This required some changes to flexmock which have not been released yet, but will be shortly. Once Jim releases the new version of flexmock, you'll be able to say: Spec::Runner.configure do |config| config.mock_with :flexmock end ... and off you go. Added to trunk r1750 ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=9735&group_id=797 From aslak.hellesoy at gmail.com Mon Apr 16 18:39:17 2007 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Tue, 17 Apr 2007 00:39:17 +0200 Subject: [rspec-devel] [rspec-users] before before and after after In-Reply-To: <57c63afe0704160707q7de1ed20j2b2400881085a17f@mail.gmail.com> References: <57c63afe0704160707q7de1ed20j2b2400881085a17f@mail.gmail.com> Message-ID: <8d961d900704161539n5ccda496o11171c097d4a44b@mail.gmail.com> Dave and I have just had a lengthy chat about this and I think we've come up with a pretty elegant solution for an API. It's inspired from the filter chaining mechanism in Rails. Essentially you can specify several before and after blocks. This is actually already supported in RSpec. What we need is a mechanism that allows users to have more fine grained control of the order in which these blocks are executed, and we're thinking of supporting this with 4 basic methods: #prepend_before(where=:each, &proc) #append_before(where=:each, &proc) #prepend_after(where=:each, &proc) #append_after(where=:each, &proc) Further, #before will be an alias for #append_before and #after will be an alias for #prepend_after. This allows users to just write before{..} and after{..} if they don't care about the order. This means that globally specified #before blocks (typically in a spec_helper.rb via Spec::Runner#configure, which usually gets loaded before everything else) will be executed before any #before blocks in individual specs. The opposite will be the case for #after blocks. However, for those of you who wish to execute a #before block *before* the global #before block, you can use #prepend_before in the specs that want to do this. Finally, the #before(:all) blocks will be executed before #prepend_before(:each) blocks - the +where+ argument trumps the prepend/append. None of this is implemented yet, so please chime in soon if you have any comments about this. Aslak On 4/16/07, David Chelimsky wrote: > Hi all, > > There are currently a number of ways to extend RSpec that are > documented inconsistently and work in sometimes conflicting and/or > confusing ways. I'd like to resolve that. The recent addition of > Spec::Runner.configure is part of that resolution. > > The thing I want to tackle now is the stuff that happens before and > after each example. Currently (in trunk), things are executed in the > following order: > > describe Thing do > before(:all) do > #happens first, but only once within this "describe" block > end > before(:each) do > #happens before each example within this "describe" block > end > it "should ..." do > #this is the example > end > after(:each) do > #happens after each example within this "describe" block > end > after(:all) do > #happens last, but only once within this "describe" block > end > end > > In addition to this, there have been requests to support global > "before" and "after". Here's where I'd like to end up: > > Spec::DSL::Example.before(:first) do > # before "before(:all)" and "before(:each)" > end > > Spec::DSL::Example.before(:last) do > # after "before(:all)" and "before(:each)", but before the example > end > > Spec::DSL::Example.after(:first) do > # before "after(:each)" and "after(:all)", but after the example > end > > Spec::DSL::Example.after(:last) do > # after "after(:each)" and "after(:all)" > end > > So the over all order for every example (a.k.a. specify) would be: > > before(:first) > before(:all) #once per "describe" > before(:each) > before(:last) > example > after(:first) > after(:each) > after(:all) #once per "describe" > after(:last) > > I'm certainly open to other suggestions - this is merely a proposal. > In most cases you wouldn't use all of these. In fact, you may not use > any of them if you prefer the Object Mother approach (helper methods > that create the state you want to start with). But this would give you > a lot of choice at both global and granular levels. > > WDYT? Too confusing? Too limiting? Just right? > > Thanks, > David > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users > From noreply at rubyforge.org Mon Apr 16 21:02:12 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 16 Apr 2007 21:02:12 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-8155 ] rspec clashing with rubyclr Message-ID: <20070417010212.0C3095240B14@rubyforge.org> Bugs item #8155, was opened at 2007-01-25 17: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: Closed >Resolution: Out of Date 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: Aslak Helles?y (aslak_hellesoy) Date: 2007-04-16 21:02 Message: Didn't hear back, so I'm closing this. Please reopen this if you still care. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-04-02 10:27 Message: Does this still apply against the branches/0.9-dev/rspec code? ---------------------------------------------------------------------- Comment By: Kevin Williams (kevwil) Date: 2007-01-26 15: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 18: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 Mon Apr 16 21:03:16 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 16 Apr 2007 21:03:16 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-9982 ] `rake spec` for rspec_on_rails does not run tests. Message-ID: <20070417010316.6EA085240B14@rubyforge.org> Bugs item #9982, was opened at 2007-04-09 01:39 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=9982&group_id=797 Category: rails plugin Group: None >Status: Closed >Resolution: Out of Date Priority: 3 Submitted By: Phil O. Despotos (philodespotos) Assigned to: Nobody (None) Summary: `rake spec` for rspec_on_rails does not run tests. Initial Comment: I am running rails edge, revision 6510, and the latest trunk of both rspec and rspec_on_rails checked out earlier today. Unfortunately, I don't get a REVISION_17.. file with rspec, nor do I use SVN, so I'm unsure of the exact revision. It occurs both with and without --drb in spec.opts. The output speaks for itself. I'm not sure how to go about demonstrating this with a spec or some such, and I'm not competent enough to dig through the source. Hopefully this suffices: $ rake spec (in /home/pd/rails/myproject) /usr/local/bin/ruby18 -I"/home/pd/rails/myproject/vendor/plugins/rspec/lib" "/home/pd/rails/myproject/vendor/plugins/rspec/bin/spec" "spec/controllers/sites_controller_spec.rb" "spec/controllers/session_controller_spec.rb" "spec/models/site_spec.rb" "spec/models/user_spec.rb" "spec/models/site_info_spec.rb" "spec/views/sites/edit_erb_spec.rb" "spec/views/sites/index_erb_spec.rb" "spec/views/sites/new_erb_spec.rb" "spec/views/sites/show_erb_spec.rb" --options "/home/pd/rails/myproject/spec/spec.opts" Finished in 7.4e-05 seconds 0 examples, 0 failures $ rake spec:controllers (in /home/pd/rails/myproject) /usr/local/bin/ruby18 -I"/home/pd/rails/myproject/vendor/plugins/rspec/lib" "/home/pd/rails/myproject/vendor/plugins/rspec/bin/spec" "spec/controllers/sites_controller_spec.rb" "spec/controllers/session_controller_spec.rb" --options "/home/pd/rails/myproject/spec/spec.opts" Finished in 7.5e-05 seconds 0 examples, 0 failures $ script/spec spec/models/user_spec.rb ........................ Finished in 2.511908 seconds 24 examples, 0 failures All tests run as expected when running manually. Apologies if this looks awful, there's no preview functionality... ---------------------------------------------------------------------- >Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-04-16 21:03 Message: Didn't hear back, so I'm closing this. Please reopen this if you still care. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-04-09 08:07 Message: If your options file has --example previous_spec_failures.txt and that file doesn't exist, then RSpec will try to run only the spec with that name. Perhaps you deleted the file? (script/generate rspec should create an empty one for you) The next time you run the specs everything should be restored to normal. I realise this might be confusing, and we'd be happy to consider something more intuitive. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-09 06:52 Message: Do the examples run the second time you run it? If so, then this is due to the following lines in spec/spec.opts (and is behaving as expected): --failures previous_spec_failures.txt --example previous_spec_failures.txt This causes rspec to only run specs that have just failed. Once they pass, the next run should run them all. Please report back as to whether that is what is going on. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=9982&group_id=797 From noreply at rubyforge.org Mon Apr 16 21:08:19 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 16 Apr 2007 21:08:19 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-7145 ] Hint for subversion users Message-ID: <20070417010819.DC5B35240B46@rubyforge.org> Bugs item #7145, was opened at 2006-12-07 04:28 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=7145&group_id=797 Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: Stefan Saasen (attachr) Assigned to: Nobody (None) Summary: Hint for subversion users Initial Comment: Hi, the revision based version information used in vendor/plugins/rspec/lib/spec/rails/version.rb causes trouble if subversion is used to manage the rails application. If svn:keywords is set to "Revision" on version.rb the Revision is updated to the local revision. This causes the rspec on rails plugin to fail. Maybe you can add a hint to the documentation to either disable svn:keywords (Revision) on version.rb or to manually change the REV constant to the original revision (1201 for the 0.7.4 plugin). best regards stefan saasen ---------------------------------------------------------------------- >Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-04-16 21:08 Message: I don't understand this. We have set the svn:keywords to "Revision" as you mentioned - in RSpec's own svn. I'm assuming you have installed RSpec as a plugin with svn:externals. Are you saying that RSpec's version.rb is updated with *your* repository's revision instead of *RSpec's* revision? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=7145&group_id=797 From noreply at rubyforge.org Mon Apr 16 21:09:45 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 16 Apr 2007 21:09:45 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-5800 ] Make QuickRef.pdf part of the website Message-ID: <20070417010945.9EE6D5240B31@rubyforge.org> Feature Requests item #5800, was opened at 2006-09-18 17:48 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=5800&group_id=797 Category: None Group: None Status: Open Priority: 3 Submitted By: Aslak Helles?y (aslak_hellesoy) Assigned to: Nobody (None) Summary: Make QuickRef.pdf part of the website Initial Comment: The pdf must be moved to doc/src, a link must be created somewhere and we must make sure it's copied over to doc/output as part of the build ---------------------------------------------------------------------- >Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-04-16 21:09 Message: Actually, I think we should remove it since we don't have the source so we can update it. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=5800&group_id=797 From noreply at rubyforge.org Mon Apr 16 21:11:54 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 16 Apr 2007 21:11:54 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-6441 ] Enable rcov in rspec.rake Message-ID: <20070417011154.C3D015240B31@rubyforge.org> Feature Requests item #6441, was opened at 2006-11-01 14:38 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6441&group_id=797 Category: rails plugin Group: None >Status: Closed Priority: 3 Submitted By: Aslak Helles?y (aslak_hellesoy) >Assigned to: Aslak Helles?y (aslak_hellesoy) Summary: Enable rcov in rspec.rake Initial Comment: It would be nice if people got RCov configured out of the box when they install RSpec on Rails. People should be able to do: rake spec RCOV=true And then automatically have rcov enabled. This should use rcov's --aggregate so that several runs (models, controllers) can be aggregated into one report. ---------------------------------------------------------------------- >Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-04-16 21:11 Message: This is supported now that we have spec.opts and --aggregate is no longer needed since everything runs in the same run. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6441&group_id=797 From noreply at rubyforge.org Mon Apr 16 21:14:41 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 16 Apr 2007 21:14:41 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-8698 ] --snippet option Message-ID: <20070417011441.60D1D5240B31@rubyforge.org> Feature Requests item #8698, was opened at 2007-02-16 07:49 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=8698&group_id=797 Category: runner module Group: None >Status: Closed Priority: 3 Submitted By: Aslak Helles?y (aslak_hellesoy) Assigned to: Aslak Helles?y (aslak_hellesoy) Summary: --snippet option Initial Comment: It would be extremely helpful if RSpec's output would include a snippet of the code that caused a spec to fail. Example: 1) Spec::Expectations::ExpectationNotMetError in 'A stack (in general) should remove the top item when sent 'pop'' "b" should equal "d" 28. specify "should remove the top item when sent 'pop'" do 29. @stack.pop.should_equal "c" 30. @stack.pop.should_equal "d" 31. end C:\dev\applications\ruby\lib\ruby\gems\1.8\gems\rspec-0.6.4\examples\stack_spec.rb:30:in `should remove the top item whe n sent 'pop'' It would also be nice if the formatting of the snippet could be pluggable so that we could have it syntax highlighted in the HTML reports. ---------------------------------------------------------------------- >Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-04-16 21:14 Message: Implemented. Not as --snippet - you won't get it it the standard output, but the html reporter gives it by default. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=8698&group_id=797 From noreply at rubyforge.org Tue Apr 17 01:07:56 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 17 Apr 2007 01:07:56 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-10158 ] --failures and --drb don't work together (trunk 1781) Message-ID: <20070417050756.1B5CD5240C8A@rubyforge.org> Bugs item #10158, was opened at 2007-04-17 05:07 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10158&group_id=797 Category: runner module Group: None Status: Open Resolution: None Priority: 3 Submitted By: David Chelimsky (dchelimsky) Assigned to: Nobody (None) Summary: --failures and --drb don't work together (trunk 1781) Initial Comment: this is true whether in spec.opts or directly on the command line: script/spec spec --drb --failures failures.txt --example failures.txt --drb works, but all examples get run every time whether passing or failing ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10158&group_id=797 From noreply at rubyforge.org Tue Apr 17 01:32:03 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 17 Apr 2007 01:32:03 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-10158 ] --failures and --drb don't work together (trunk 1781) Message-ID: <20070417053203.42EBA5240C91@rubyforge.org> Bugs item #10158, was opened at 2007-04-17 05:07 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10158&group_id=797 Category: runner module Group: None Status: Open Resolution: None Priority: 3 Submitted By: David Chelimsky (dchelimsky) Assigned to: Nobody (None) Summary: --failures and --drb don't work together (trunk 1781) Initial Comment: this is true whether in spec.opts or directly on the command line: script/spec spec --drb --failures failures.txt --example failures.txt --drb works, but all examples get run every time whether passing or failing ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-04-17 05:32 Message: >From IRC conversation w/ abcde: "If I use -X/--drb after any other options it'll do the option parsing twice. Also the creation of the failures file is using at_exit which I assume doesnt work in a drb env" ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10158&group_id=797 From noreply at rubyforge.org Tue Apr 17 02:13:38 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 17 Apr 2007 02:13:38 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-10158 ] --failures and --drb don't work together (trunk 1781) Message-ID: <20070417061338.57C935240B51@rubyforge.org> Bugs item #10158, was opened at 2007-04-17 05:07 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10158&group_id=797 Category: runner module Group: None >Status: Closed >Resolution: Accepted Priority: 3 Submitted By: David Chelimsky (dchelimsky) >Assigned to: David Chelimsky (dchelimsky) Summary: --failures and --drb don't work together (trunk 1781) Initial Comment: this is true whether in spec.opts or directly on the command line: script/spec spec --drb --failures failures.txt --example failures.txt --drb works, but all examples get run every time whether passing or failing ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-04-17 06:13 Message: fixed in trunk rev1782 - thanks to abcde for pointing me to the problem ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-17 05:32 Message: >From IRC conversation w/ abcde: "If I use -X/--drb after any other options it'll do the option parsing twice. Also the creation of the failures file is using at_exit which I assume doesnt work in a drb env" ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10158&group_id=797 From noreply at rubyforge.org Tue Apr 17 04:48:05 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 17 Apr 2007 04:48:05 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-7145 ] Hint for subversion users Message-ID: <20070417084805.A5306524099F@rubyforge.org> Bugs item #7145, was opened at 2006-12-07 10:28 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=7145&group_id=797 Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: Stefan Saasen (attachr) Assigned to: Nobody (None) Summary: Hint for subversion users Initial Comment: Hi, the revision based version information used in vendor/plugins/rspec/lib/spec/rails/version.rb causes trouble if subversion is used to manage the rails application. If svn:keywords is set to "Revision" on version.rb the Revision is updated to the local revision. This causes the rspec on rails plugin to fail. Maybe you can add a hint to the documentation to either disable svn:keywords (Revision) on version.rb or to manually change the REV constant to the original revision (1201 for the 0.7.4 plugin). best regards stefan saasen ---------------------------------------------------------------------- >Comment By: Stefan Saasen (attachr) Date: 2007-04-17 10:48 Message: No, the problem only occurs if the plugin is installed without using svn:externals. The problem is as soon as you install the plugin and the rails project (including all the plugins) is managed using Subversion the RSpec Revision will be replaced. For example: version.rb in RSPec has Revision 15xx After installing the plugin the Revision number is set to whatever is used for the version.rb file in the Rails project. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-04-17 03:08 Message: I don't understand this. We have set the svn:keywords to "Revision" as you mentioned - in RSpec's own svn. I'm assuming you have installed RSpec as a plugin with svn:externals. Are you saying that RSpec's version.rb is updated with *your* repository's revision instead of *RSpec's* revision? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=7145&group_id=797 From noreply at rubyforge.org Tue Apr 17 11:48:09 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 17 Apr 2007 11:48:09 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-9958 ] Rakefile change to use MySQL Message-ID: <20070417154809.6A27C5240B56@rubyforge.org> Patches item #9958, was opened at 2007-04-08 16:00 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=9958&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Scott Taylor (smtlaissezfaire) Assigned to: Nobody (None) Summary: Rakefile change to use MySQL Initial Comment: As it stands right now, sqlite3 is unusable with pre_commit_rails. This has been talked about in the mailing list, so I won't add anything more. As it stands right now, one of two things must occur: 1. rails versions 1.2.1 and lower must be dropped in order to use sqlite3 2. -OR- sqlite should be dropped for the time being. This patch does not fix the problem. All this patch does is add two additional rake tasks: 1. setup_mysql: (copying config/database.mysql.yml to config/database.yml) 2. pre_commit_with_mysql: run pre_commit, with the setup_for_mysql task as a dependency. This patch is mainly to address the annoyance I feel everytime I try to submit a patch. I always forget to copy that mysql file. ---------------------------------------------------------------------- >Comment By: Scott Taylor (smtlaissezfaire) Date: 2007-04-17 15:48 Message: You should reject this one. ---------------------------------------------------------------------- Comment By: Scott Taylor (smtlaissezfaire) Date: 2007-04-08 20:47 Message: I didn't realize there was such a task! I would normally just say that we should hook up mysql to work by default, but others may be using a different database. I think it would be nice if we could have something like: rake pre_commit_sqlite rake pre_commit_mysql etc. I know this is what rails does for their unit tests. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-08 19:59 Message: There is already rspec:generate_mysql_config (so we don't need setup_mysql). Not sure yet whether to add pre_commit_with_mysql or just start limiting what we're supporting. Aslak? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=9958&group_id=797 From noreply at rubyforge.org Tue Apr 17 11:49:21 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 17 Apr 2007 11:49:21 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-5800 ] Make QuickRef.pdf part of the website Message-ID: <20070417154921.340415240B36@rubyforge.org> Feature Requests item #5800, was opened at 2006-09-18 21:48 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=5800&group_id=797 Category: None Group: None Status: Open Priority: 3 Submitted By: Aslak Helles?y (aslak_hellesoy) Assigned to: Nobody (None) Summary: Make QuickRef.pdf part of the website Initial Comment: The pdf must be moved to doc/src, a link must be created somewhere and we must make sure it's copied over to doc/output as part of the build ---------------------------------------------------------------------- Comment By: Scott Taylor (smtlaissezfaire) Date: 2007-04-17 15:49 Message: Yeah - the synatax on that pdf is really outdated. If you don't have the source just delete it and close the ticket. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-04-17 01:09 Message: Actually, I think we should remove it since we don't have the source so we can update it. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=5800&group_id=797 From noreply at rubyforge.org Tue Apr 17 12:01:59 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 17 Apr 2007 12:01:59 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-9958 ] Rakefile change to use MySQL Message-ID: <20070417160200.022265240A95@rubyforge.org> Patches item #9958, was opened at 2007-04-08 16:00 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=9958&group_id=797 Category: None Group: None >Status: Closed >Resolution: Rejected Priority: 3 Submitted By: Scott Taylor (smtlaissezfaire) Assigned to: Nobody (None) Summary: Rakefile change to use MySQL Initial Comment: As it stands right now, sqlite3 is unusable with pre_commit_rails. This has been talked about in the mailing list, so I won't add anything more. As it stands right now, one of two things must occur: 1. rails versions 1.2.1 and lower must be dropped in order to use sqlite3 2. -OR- sqlite should be dropped for the time being. This patch does not fix the problem. All this patch does is add two additional rake tasks: 1. setup_mysql: (copying config/database.mysql.yml to config/database.yml) 2. pre_commit_with_mysql: run pre_commit, with the setup_for_mysql task as a dependency. This patch is mainly to address the annoyance I feel everytime I try to submit a patch. I always forget to copy that mysql file. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-04-17 16:01 Message: OK. Thanks. ---------------------------------------------------------------------- Comment By: Scott Taylor (smtlaissezfaire) Date: 2007-04-17 15:48 Message: You should reject this one. ---------------------------------------------------------------------- Comment By: Scott Taylor (smtlaissezfaire) Date: 2007-04-08 20:47 Message: I didn't realize there was such a task! I would normally just say that we should hook up mysql to work by default, but others may be using a different database. I think it would be nice if we could have something like: rake pre_commit_sqlite rake pre_commit_mysql etc. I know this is what rails does for their unit tests. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-08 19:59 Message: There is already rspec:generate_mysql_config (so we don't need setup_mysql). Not sure yet whether to add pre_commit_with_mysql or just start limiting what we're supporting. Aslak? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=9958&group_id=797 From dan at tastapod.com Wed Apr 18 09:34:56 2007 From: dan at tastapod.com (Dan North) Date: Wed, 18 Apr 2007 14:34:56 +0100 Subject: [rspec-devel] [rspec-users] before before and after after In-Reply-To: <8d961d900704161539n5ccda496o11171c097d4a44b@mail.gmail.com> References: <57c63afe0704160707q7de1ed20j2b2400881085a17f@mail.gmail.com> <8d961d900704161539n5ccda496o11171c097d4a44b@mail.gmail.com> Message-ID: <46261E80.40308@tastapod.com> Sounds like the right mix of easy things easy and hard things possible. +1 from me. aslak hellesoy wrote: > Dave and I have just had a lengthy chat about this and I think we've > come up with a pretty elegant solution for an API. It's inspired from > the filter chaining mechanism in Rails. > > Essentially you can specify several before and after blocks. This is > actually already supported in RSpec. > What we need is a mechanism that allows users to have more fine > grained control of the order in which > these blocks are executed, and we're thinking of supporting this with > 4 basic methods: > > #prepend_before(where=:each, &proc) > #append_before(where=:each, &proc) > #prepend_after(where=:each, &proc) > #append_after(where=:each, &proc) > > Further, #before will be an alias for #append_before and #after will > be an alias for #prepend_after. > This allows users to just write before{..} and after{..} if they don't > care about the order. > > This means that globally specified #before blocks (typically in a > spec_helper.rb via Spec::Runner#configure, which usually gets loaded > before everything else) > will be executed before any #before blocks in individual specs. The > opposite will be the case for #after blocks. > > However, for those of you who wish to execute a #before block *before* > the global #before block, you can use #prepend_before > in the specs that want to do this. > > Finally, the #before(:all) blocks will be executed before > #prepend_before(:each) blocks - the +where+ argument trumps the > prepend/append. > > None of this is implemented yet, so please chime in soon if you have > any comments about this. > > Aslak > > > On 4/16/07, David Chelimsky wrote: > >> Hi all, >> >> There are currently a number of ways to extend RSpec that are >> documented inconsistently and work in sometimes conflicting and/or >> confusing ways. I'd like to resolve that. The recent addition of >> Spec::Runner.configure is part of that resolution. >> >> The thing I want to tackle now is the stuff that happens before and >> after each example. Currently (in trunk), things are executed in the >> following order: >> >> describe Thing do >> before(:all) do >> #happens first, but only once within this "describe" block >> end >> before(:each) do >> #happens before each example within this "describe" block >> end >> it "should ..." do >> #this is the example >> end >> after(:each) do >> #happens after each example within this "describe" block >> end >> after(:all) do >> #happens last, but only once within this "describe" block >> end >> end >> >> In addition to this, there have been requests to support global >> "before" and "after". Here's where I'd like to end up: >> >> Spec::DSL::Example.before(:first) do >> # before "before(:all)" and "before(:each)" >> end >> >> Spec::DSL::Example.before(:last) do >> # after "before(:all)" and "before(:each)", but before the example >> end >> >> Spec::DSL::Example.after(:first) do >> # before "after(:each)" and "after(:all)", but after the example >> end >> >> Spec::DSL::Example.after(:last) do >> # after "after(:each)" and "after(:all)" >> end >> >> So the over all order for every example (a.k.a. specify) would be: >> >> before(:first) >> before(:all) #once per "describe" >> before(:each) >> before(:last) >> example >> after(:first) >> after(:each) >> after(:all) #once per "describe" >> after(:last) >> >> I'm certainly open to other suggestions - this is merely a proposal. >> In most cases you wouldn't use all of these. In fact, you may not use >> any of them if you prefer the Object Mother approach (helper methods >> that create the state you want to start with). But this would give you >> a lot of choice at both global and granular levels. >> >> WDYT? Too confusing? Too limiting? Just right? >> >> Thanks, >> David >> _______________________________________________ >> rspec-users mailing list >> rspec-users at rubyforge.org >> http://rubyforge.org/mailman/listinfo/rspec-users >> >> > _______________________________________________ > 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/20070418/e12c22d3/attachment.html From matt at aimonetti.net Wed Apr 11 22:55:05 2007 From: matt at aimonetti.net (Matt Aimonetti) Date: Wed, 11 Apr 2007 19:55:05 -0700 Subject: [rspec-devel] names for setup and teardown methods In-Reply-To: <6cf2a94f0704111056s591105bfm92e32c5e88fb2dc4@mail.gmail.com> References: <57c63afe0704110549x2c2a42f6l641e0c59e9de0afb@mail.gmail.com> <6cf2a94f0704111056s591105bfm92e32c5e88fb2dc4@mail.gmail.com> Message-ID: I fully agree with Dean and prefer the "before :each", "after :all" option, it reads better and is easier to understand for newbies. -Matt On 4/11/07, Dean Wampler wrote: > > Setup and teardown are more approachable to converts from Test::Unit, > but "before :all" and "after :each" read better, IMHO. > > "all_examples" might cause people to ask "what examples?" I'm not sure > most people will think of the "it blocks" as examples. Still, you > could just accept any symbol that begins with "each" and "all", so > people can invent their own name ;) > > dean > > > On 4/11/07, David Chelimsky wrote: > > We're going to rename context_setup and context_teardown because they > > no longer read well when using "describe/id". There are two ideas > > floating around about this. The first: > > > > setup :each #default - works like setup does now > > setup :all #replaces context_setup > > teardown :each #default - works like teardown does now > > teardown :all #replaces context teardown > > > > The second uses "before" and "after" in the same way: > > > > before :each #default - works like setup does now > > before :all #replaces context_setup > > after :each #default - works like teardown does now > > after :all #replaces context teardown > > > > In both cases, the default is :each, so you can just say "setup do" or > > "before do" instead of "setup :each do" or "before :each do". > > > > == Examples > > > > describe Thing do > > setup :all { ... } > > setup :each { ... } > > it "should do something" { ... } > > it "should do something else" { ... } > > teardown :each { ... } > > teardown :all { ... } > > end > > > > describe Thing do > > before :all { ... } > > before :each { ... } > > it "should do something" { ... } > > it "should do something else" { ... } > > after :each { ... } > > after :all { ... } > > end > > > > describe Thing do > > before { ... } # works like before :each > > it "should do something" { ... } > > it "should do something else" { ... } > > after { ... } # works like after :each > > end > > > > One other thing that occurs to me is that "before :each" really means > > "before each example" - so perhaps it should be "before :each_example" > > and "before :all_examples" (or :each and :each_example could both be > > supported, etc). > > > > WDYT? > > _______________________________________________ > > rspec-devel mailing list > > rspec-devel at rubyforge.org > > http://rubyforge.org/mailman/listinfo/rspec-devel > > > > > -- > Dean Wampler > http://www.objectmentor.com > http://www.aspectprogramming.com > http://www.contract4j.org > _______________________________________________ > 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/20070411/494d47fa/attachment.html From matthew.heidemann at gmail.com Wed Apr 18 19:20:36 2007 From: matthew.heidemann at gmail.com (Matthew Heidemann) Date: Wed, 18 Apr 2007 16:20:36 -0700 Subject: [rspec-devel] names for setup and teardown methods In-Reply-To: References: <57c63afe0704110549x2c2a42f6l641e0c59e9de0afb@mail.gmail.com> <6cf2a94f0704111056s591105bfm92e32c5e88fb2dc4@mail.gmail.com> Message-ID: <306e36aa0704181620m23edba0bn9ae388ca007402be@mail.gmail.com> I personally like before :each_example. The first time I read it I said, "before :each what?". I think once people run the spec and see 1 example 0 failures, they know that the 'it do' is an example On 4/11/07, Matt Aimonetti wrote: > > I fully agree with Dean and prefer the "before :each", "after :all" > option, it reads better and is easier to understand for newbies. > > -Matt > > On 4/11/07, Dean Wampler wrote: > > > > Setup and teardown are more approachable to converts from Test::Unit, > > but "before :all" and "after :each" read better, IMHO. > > > > "all_examples" might cause people to ask "what examples?" I'm not sure > > most people will think of the "it blocks" as examples. Still, you > > could just accept any symbol that begins with "each" and "all", so > > people can invent their own name ;) > > > > dean > > > > > > On 4/11/07, David Chelimsky wrote: > > > We're going to rename context_setup and context_teardown because they > > > no longer read well when using "describe/id". There are two ideas > > > floating around about this. The first: > > > > > > setup :each #default - works like setup does now > > > setup :all #replaces context_setup > > > teardown :each #default - works like teardown does now > > > teardown :all #replaces context teardown > > > > > > The second uses "before" and "after" in the same way: > > > > > > before :each #default - works like setup does now > > > before :all #replaces context_setup > > > after :each #default - works like teardown does now > > > after :all #replaces context teardown > > > > > > In both cases, the default is :each, so you can just say "setup do" or > > > "before do" instead of "setup :each do" or "before :each do". > > > > > > == Examples > > > > > > describe Thing do > > > setup :all { ... } > > > setup :each { ... } > > > it "should do something" { ... } > > > it "should do something else" { ... } > > > teardown :each { ... } > > > teardown :all { ... } > > > end > > > > > > describe Thing do > > > before :all { ... } > > > before :each { ... } > > > it "should do something" { ... } > > > it "should do something else" { ... } > > > after :each { ... } > > > after :all { ... } > > > end > > > > > > describe Thing do > > > before { ... } # works like before :each > > > it "should do something" { ... } > > > it "should do something else" { ... } > > > after { ... } # works like after :each > > > end > > > > > > One other thing that occurs to me is that "before :each" really means > > > "before each example" - so perhaps it should be "before :each_example" > > > and "before :all_examples" (or :each and :each_example could both be > > > supported, etc). > > > > > > WDYT? > > > _______________________________________________ > > > rspec-devel mailing list > > > rspec-devel at rubyforge.org > > > http://rubyforge.org/mailman/listinfo/rspec-devel > > > > > > > > > -- > > Dean Wampler > > http://www.objectmentor.com > > http://www.aspectprogramming.com > > http://www.contract4j.org > > _______________________________________________ > > 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/20070418/5d923c1e/attachment-0001.html From matttemp at gmail.com Thu Apr 19 00:02:37 2007 From: matttemp at gmail.com (Matt Aimonetti) Date: Wed, 18 Apr 2007 21:02:37 -0700 Subject: [rspec-devel] model.should be_valid Message-ID: You might have missed this post http://opensoul.org/2007/4/18/rspec-model-should-be_valid from Brandon Keepers suggesting to improve the be_valid matcher. It might be good to think about adding that to a future release. Matt -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20070418/b54441f6/attachment.html From noreply at rubyforge.org Thu Apr 19 21:17:03 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 19 Apr 2007 21:17:03 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-10245 ] Patch to HTML escape the behavior name when using HTML Formatter Message-ID: <20070420011703.C9CDF5240C3E@rubyforge.org> Patches item #10245, was opened at 2007-04-19 18:17 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=10245&group_id=797 Category: runner module Group: None Status: Open Resolution: None Priority: 3 Submitted By: Josh Knowles (joshknowles) Assigned to: Nobody (None) Summary: Patch to HTML escape the behavior name when using HTML Formatter Initial Comment: This small patch HTML escapes the behavior name when using the HTML formatter. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=10245&group_id=797 From aslak.hellesoy at gmail.com Fri Apr 20 04:15:54 2007 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Fri, 20 Apr 2007 10:15:54 +0200 Subject: [rspec-devel] Version numbers Message-ID: <8d961d900704200115j4a0ef777t3b974e5a8dce5ecb@mail.gmail.com> Everybody, When you ask a question, please don't forget to mention what versions of software you're running - for example: * OS X 10.4.9 * Ruby 1.8.6 * RSpec 1.8.2 or RSpec trunk r1643 * Spec::Rails 1.8.2 or Spec::Rails tag r1234... * Rails 1.2.3 or Rails edge r5645 * Whatever other relevant software. Because, you see, without this information it's like solving 1 equation (your question) with 5 unknown variables (the versions). And I think you all know that that is a tough challenge. Please *repeat* this information in new threads - we don't remember from time to time who's using what - nor do we telepathically know when you decide to upgrade or downgrade something. Cheers, Aslak From noreply at rubyforge.org Fri Apr 20 11:47:11 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 20 Apr 2007 11:47:11 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-10260 ] Spec::Mocks::Mock#inspect returns way too much data Message-ID: <20070420154711.2577E52409BA@rubyforge.org> Bugs item #10260, was opened at 2007-04-20 11:47 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10260&group_id=797 Category: runner module Group: None Status: Open Resolution: None Priority: 3 Submitted By: Fran?ois Beausoleil (fbos) Assigned to: Nobody (None) Summary: Spec::Mocks::Mock#inspect returns way too much data Initial Comment: Hi! This is the failure I get: 1) Spec::Mocks::MockExpectationError in 'A POST to /v1/mongrel/heap/free?observed_at=... &data=241 should create a measurement' Measurement expected :new with ({:node=>#, @method_block=nil>], @expectations=[], @target=#, @error_generator=#>, @options={:null_object=>false, :auto_verify=>true}, @messages_received=[]>, @options={}>, :observed_at=>Fri Apr 20 15:37:37 UTC 2007, :feature=>nil}) /home/francois/src/florian/hibiscus/app/controllers/observations_controller.rb:14:in `create_v1' ./spec/controllers/observations_controller_spec.rb:67:in `do_post' ./spec/controllers/observations_controller_spec.rb:77: My expectation is (@node and @category are mocks): Measurement.should_receive(:new).with( :node => @node, :category => @category, :feature => nil, :observed_at => Time.xmlschema(@time), :numerical_data => 241.to_f ).and_return(measurement = mock("observation", :save => true)) Implementing #inspect on Spec::Mocks::Mock to return a bit less data: def inspect "\#<#{self.class.name} #{object_id.to_s(16)} ...>" end results in the following message instead: 1) Spec::Mocks::MockExpectationError in 'A POST to /v1/mongrel/heap/free?observed_at=... &data=241 should create a measurement' Measurement expected :new with ({:node=>#, :observed_at=>Fri Apr 20 15:41:46 UTC 2007, :category=>#, :feature=>nil, :numerical_data=>241.0}) but received it with ({:node=>#, :textual_data=>nil, :category=>#, :observed_at=>Fri Apr 20 15:41:46 UTC 2007, :feature=>nil}) Ah, so my problem is with :textual_data... Interesting ! Bye ! Fran?ois Beausoleil ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10260&group_id=797 From noreply at rubyforge.org Fri Apr 20 12:12:58 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 20 Apr 2007 12:12:58 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-10262 ] Better Helper testing of Erb evaluation block helpers Message-ID: <20070420161259.288DF5240A1C@rubyforge.org> Feature Requests item #10262, was opened at 2007-04-20 18:12 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10262&group_id=797 Category: None Group: None Status: Open Priority: 3 Submitted By: Simon Nicholls (simon_nicholls) Assigned to: Nobody (None) Summary: Better Helper testing of Erb evaluation block helpers Initial Comment: I'd like to easily test helpers which in views would be called like this: <% helper_method "foo" do %> bar <% end %> Erb eval blocks instead of Erb output blocks. Including ActionView::Helpers::TextHelper in HelperBehaviourHelpers would help if you can add that, as it's generally useful. I can then do something like this in the spec: describe ApplicationHelper, "testing Erb eval helper" do before do @result = ERB.new("<% helper_method 'foo' do %>bar<% end %>").result(binding) end it "should work anyway but could be nicer" do @result.should == "foo..bar" end end Works well enough, but can you think of a nicer way? I also tried a more direct, method calling style, but it needs explicit concat usage in the block: _erbout = '' panel('foo') { concat("bar", binding) } @result = _erbout Well, it works, but the block fudging and sneaky _erbout use is a bit naff ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10262&group_id=797 From antti.tarvainen at iki.fi Fri Apr 20 12:23:57 2007 From: antti.tarvainen at iki.fi (Antti Tarvainen) Date: Fri, 20 Apr 2007 18:23:57 +0200 Subject: [rspec-devel] Setting rspec up for contribution Message-ID: <5b89e3bd0704200923y6a791637i18c6b17b85978134@mail.gmail.com> Hello, rspec developers. I checked out rspec trunk to look at the code and perhaps to contribute something in the future. It took me some time to get to the point where "rake pre_commit" works, as it wasn't entirely obvious from the beginning. So, to benefit others, here are the necessary steps (or at least what I did): svn co svn://rubyforge.org/var/svn/rspec/trunk cd trunk rake install_dependencies cd example_rails_app export RSPEC_RAILS_VERSION=edge rake rspec:generate_mysql_config mysql -u root < db/mysql_setup.sql cd .. rake pre_commit Perhaps some instructions like this should be added to trunk/README or trunk/doc/src/contribute.page? Antti T. From dchelimsky at gmail.com Fri Apr 20 12:37:39 2007 From: dchelimsky at gmail.com (David Chelimsky) Date: Fri, 20 Apr 2007 11:37:39 -0500 Subject: [rspec-devel] Setting rspec up for contribution In-Reply-To: <5b89e3bd0704200923y6a791637i18c6b17b85978134@mail.gmail.com> References: <5b89e3bd0704200923y6a791637i18c6b17b85978134@mail.gmail.com> Message-ID: <57c63afe0704200937q309c615di312e81d209112cfc@mail.gmail.com> On 4/20/07, Antti Tarvainen wrote: > Hello, rspec developers. > > > I checked out rspec trunk to look at the code and perhaps to > contribute something in the future. It took me some time to get to the > point where "rake pre_commit" works, as it wasn't entirely obvious > from the beginning. So, to benefit others, here are the necessary > steps (or at least what I did): > > > svn co svn://rubyforge.org/var/svn/rspec/trunk > cd trunk > rake install_dependencies > cd example_rails_app > export RSPEC_RAILS_VERSION=edge > rake rspec:generate_mysql_config > mysql -u root < db/mysql_setup.sql > cd .. > rake pre_commit Thanks Antti - I added this to rspec/README in trunk rev 1786. Cheers, David > > > Perhaps some instructions like this should be added to trunk/README or > trunk/doc/src/contribute.page? > > > Antti T. > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From antti.tarvainen at iki.fi Fri Apr 20 12:39:23 2007 From: antti.tarvainen at iki.fi (Antti Tarvainen) Date: Fri, 20 Apr 2007 18:39:23 +0200 Subject: [rspec-devel] Setting rspec up for contribution In-Reply-To: <5b89e3bd0704200923y6a791637i18c6b17b85978134@mail.gmail.com> References: <5b89e3bd0704200923y6a791637i18c6b17b85978134@mail.gmail.com> Message-ID: <5b89e3bd0704200939o63bf4f34haeadeb7955106105@mail.gmail.com> Continuing my previous post: > I checked out rspec trunk to look at the code and perhaps to > contribute something in the future. It took me some time to get to the > point where "rake pre_commit" works, as it wasn't entirely obvious > from the beginning. [...] Also, rspec_on_rails pre_commit against edge rails (r6542) fails. Was this expected, or did I do something wrong? Tests against older rails versions passed. My environment: * OS X 10.4.9 * Ruby 1.8.6 * RSpec trunk r1785 * Spec::Rails trunk r1785 * Rails Edge r6542 1) 'response.should render_template (in integration mode) should fail on the wrong extension (given rjs)' FAILED expected Spec::Expectations::ExpectationNotMetError with "expected \"render_spec/some_action\", got \"render_spec/some_action.js.rjs\"" but nothing was raised ./vendor/plugins/rspec_on_rails/spec/rails/matchers/render_spec.rb:46: 2) 'response.should render_template (in integration mode) should match an rjs template' FAILED expected "render_spec/some_action.js.rjs", got "render_spec/some_action" ./vendor/plugins/rspec_on_rails/spec/rails/matchers/render_spec.rb:33: 3) 'response.should render_template (in isolation mode) should fail on the wrong extension (given rjs)' FAILED expected Spec::Expectations::ExpectationNotMetError with "expected \"render_spec/some_action\", got \"render_spec/some_action.js.rjs\"" but nothing was raised ./vendor/plugins/rspec_on_rails/spec/rails/matchers/render_spec.rb:46: 4) 'response.should render_template (in isolation mode) should match an rjs template' FAILED expected "render_spec/some_action.js.rjs", got "render_spec/some_action" ./vendor/plugins/rspec_on_rails/spec/rails/matchers/render_spec.rb:33: Finished in 0.745171 seconds 178 examples, 4 failures Antti T. From noreply at rubyforge.org Fri Apr 20 12:40:56 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 20 Apr 2007 12:40:56 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-10263 ] mock "leak" when setting an expectation in a block passed to mock#should_receive Message-ID: <20070420164056.3700A5240A2E@rubyforge.org> Bugs item #10263, was opened at 2007-04-20 16:40 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10263&group_id=797 Category: mock module Group: None Status: Open Resolution: None Priority: 3 Submitted By: David Chelimsky (dchelimsky) Assigned to: Nobody (None) Summary: mock "leak" when setting an expectation in a block passed to mock#should_receive Initial Comment: The following failing examples should tell the story: describe "Mock" do before do @mock = mock("test mock") end specify "when one example has an expectation (non-mock) inside the block passed to the mock" do @mock.should_receive(:msg) do |b| b.should be_true #this call exposes the problem end @mock.msg(false) rescue nil end specify "then the next example should behave as expected instead of saying" do @mock.should_receive(:foobar) @mock.foobar @mock.rspec_verify begin @mock.foobar rescue => e e.message.should == "Mock 'test mock' received unexpected message :foobar with (no args)" end end end ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10263&group_id=797 From dchelimsky at gmail.com Fri Apr 20 12:45:15 2007 From: dchelimsky at gmail.com (David Chelimsky) Date: Fri, 20 Apr 2007 11:45:15 -0500 Subject: [rspec-devel] Setting rspec up for contribution In-Reply-To: <5b89e3bd0704200939o63bf4f34haeadeb7955106105@mail.gmail.com> References: <5b89e3bd0704200923y6a791637i18c6b17b85978134@mail.gmail.com> <5b89e3bd0704200939o63bf4f34haeadeb7955106105@mail.gmail.com> Message-ID: <57c63afe0704200945v3c069f14xd9a9af6d9ab21798@mail.gmail.com> On 4/20/07, Antti Tarvainen wrote: > Continuing my previous post: > > I checked out rspec trunk to look at the code and perhaps to > > contribute something in the future. It took me some time to get to the > > point where "rake pre_commit" works, as it wasn't entirely obvious > > from the beginning. [...] > > Also, rspec_on_rails pre_commit against edge rails (r6542) fails. Was > this expected, or did I do something wrong? You did nothing wrong. We make absolutely no commitment that examples are going to pass against edge rails. Edge rails changes whenever it changes and we don't have the resources to chase down every rpsec-breaking change immediately. We do run the examples against edge so that we can see things that we need to change, but we deliberately ignore failures against edge rails in terms of passing/failing the pre_commit as not to impede progress. That said, we usually try to get these things fixed fairly quickly. If you would like to take a stab at getting these examples to pass against edge rails, that would be a great first contribution. Cheers, David > Tests against older rails > versions passed. > > My environment: > * OS X 10.4.9 > * Ruby 1.8.6 > * RSpec trunk r1785 > * Spec::Rails trunk r1785 > * Rails Edge r6542 > > > 1) > 'response.should render_template (in integration mode) should fail on > the wrong extension (given rjs)' FAILED > expected Spec::Expectations::ExpectationNotMetError with "expected > \"render_spec/some_action\", got \"render_spec/some_action.js.rjs\"" > but nothing was raised > ./vendor/plugins/rspec_on_rails/spec/rails/matchers/render_spec.rb:46: > > 2) > 'response.should render_template (in integration mode) should match an > rjs template' FAILED > expected "render_spec/some_action.js.rjs", got "render_spec/some_action" > ./vendor/plugins/rspec_on_rails/spec/rails/matchers/render_spec.rb:33: > > 3) > 'response.should render_template (in isolation mode) should fail on > the wrong extension (given rjs)' FAILED > expected Spec::Expectations::ExpectationNotMetError with "expected > \"render_spec/some_action\", got \"render_spec/some_action.js.rjs\"" > but nothing was raised > ./vendor/plugins/rspec_on_rails/spec/rails/matchers/render_spec.rb:46: > > 4) > 'response.should render_template (in isolation mode) should match an > rjs template' FAILED > expected "render_spec/some_action.js.rjs", got "render_spec/some_action" > ./vendor/plugins/rspec_on_rails/spec/rails/matchers/render_spec.rb:33: > > Finished in 0.745171 seconds > > 178 examples, 4 failures > > > Antti T. > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From noreply at rubyforge.org Fri Apr 20 13:13:18 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 20 Apr 2007 13:13:18 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-10262 ] Better Helper testing of Erb evaluation block helpers Message-ID: <20070420171318.586E75240A2B@rubyforge.org> Feature Requests item #10262, was opened at 2007-04-20 16:12 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10262&group_id=797 Category: None Group: None Status: Open Priority: 3 Submitted By: Simon Nicholls (simon_nicholls) Assigned to: Nobody (None) Summary: Better Helper testing of Erb evaluation block helpers Initial Comment: I'd like to easily test helpers which in views would be called like this: <% helper_method "foo" do %> bar <% end %> Erb eval blocks instead of Erb output blocks. Including ActionView::Helpers::TextHelper in HelperBehaviourHelpers would help if you can add that, as it's generally useful. I can then do something like this in the spec: describe ApplicationHelper, "testing Erb eval helper" do before do @result = ERB.new("<% helper_method 'foo' do %>bar<% end %>").result(binding) end it "should work anyway but could be nicer" do @result.should == "foo..bar" end end Works well enough, but can you think of a nicer way? I also tried a more direct, method calling style, but it needs explicit concat usage in the block: _erbout = '' panel('foo') { concat("bar", binding) } @result = _erbout Well, it works, but the block fudging and sneaky _erbout use is a bit naff ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-04-20 17:13 Message: How about something like: describe ApplicationHelper, "testing Erb eval helper" do before do @result = eval_erb("<% helper_method 'foo' do %>bar<% end %>") end it "should work anyway but could be nicer" do @result.should == "foo..bar" end end #eval_erb would basically wrap your original suggestion: def eval_erb(text) ERB.new(text).result(binding) end The nice thing about this is that it not only serves your rails app, but you could use it like this: eval_erb("Columbian").should == "really good s**t" :) ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10262&group_id=797 From noreply at rubyforge.org Fri Apr 20 14:07:46 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 20 Apr 2007 14:07:46 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-10262 ] Better Helper testing of Erb evaluation block helpers Message-ID: <20070420180746.2A1F25240A74@rubyforge.org> Feature Requests item #10262, was opened at 2007-04-20 18:12 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10262&group_id=797 Category: None Group: None Status: Open Priority: 3 Submitted By: Simon Nicholls (simon_nicholls) Assigned to: Nobody (None) Summary: Better Helper testing of Erb evaluation block helpers Initial Comment: I'd like to easily test helpers which in views would be called like this: <% helper_method "foo" do %> bar <% end %> Erb eval blocks instead of Erb output blocks. Including ActionView::Helpers::TextHelper in HelperBehaviourHelpers would help if you can add that, as it's generally useful. I can then do something like this in the spec: describe ApplicationHelper, "testing Erb eval helper" do before do @result = ERB.new("<% helper_method 'foo' do %>bar<% end %>").result(binding) end it "should work anyway but could be nicer" do @result.should == "foo..bar" end end Works well enough, but can you think of a nicer way? I also tried a more direct, method calling style, but it needs explicit concat usage in the block: _erbout = '' panel('foo') { concat("bar", binding) } @result = _erbout Well, it works, but the block fudging and sneaky _erbout use is a bit naff ---------------------------------------------------------------------- >Comment By: Simon Nicholls (simon_nicholls) Date: 2007-04-20 20:07 Message: Hehe! That's actually pretty nice when factored out! ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-20 19:13 Message: How about something like: describe ApplicationHelper, "testing Erb eval helper" do before do @result = eval_erb("<% helper_method 'foo' do %>bar<% end %>") end it "should work anyway but could be nicer" do @result.should == "foo..bar" end end #eval_erb would basically wrap your original suggestion: def eval_erb(text) ERB.new(text).result(binding) end The nice thing about this is that it not only serves your rails app, but you could use it like this: eval_erb("Columbian").should == "really good s**t" :) ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10262&group_id=797 From noreply at rubyforge.org Fri Apr 20 14:28:33 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 20 Apr 2007 14:28:33 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-10262 ] Better Helper testing of Erb evaluation block helpers Message-ID: <20070420182834.0CDF65240A2B@rubyforge.org> Feature Requests item #10262, was opened at 2007-04-20 16:12 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10262&group_id=797 >Category: rails plugin Group: None Status: Open Priority: 3 Submitted By: Simon Nicholls (simon_nicholls) >Assigned to: David Chelimsky (dchelimsky) Summary: Better Helper testing of Erb evaluation block helpers Initial Comment: I'd like to easily test helpers which in views would be called like this: <% helper_method "foo" do %> bar <% end %> Erb eval blocks instead of Erb output blocks. Including ActionView::Helpers::TextHelper in HelperBehaviourHelpers would help if you can add that, as it's generally useful. I can then do something like this in the spec: describe ApplicationHelper, "testing Erb eval helper" do before do @result = ERB.new("<% helper_method 'foo' do %>bar<% end %>").result(binding) end it "should work anyway but could be nicer" do @result.should == "foo..bar" end end Works well enough, but can you think of a nicer way? I also tried a more direct, method calling style, but it needs explicit concat usage in the block: _erbout = '' panel('foo') { concat("bar", binding) } @result = _erbout Well, it works, but the block fudging and sneaky _erbout use is a bit naff ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-04-20 18:28 Message: Cool. I've got this working but can't commit right now - will shortly. ---------------------------------------------------------------------- Comment By: Simon Nicholls (simon_nicholls) Date: 2007-04-20 18:07 Message: Hehe! That's actually pretty nice when factored out! ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-20 17:13 Message: How about something like: describe ApplicationHelper, "testing Erb eval helper" do before do @result = eval_erb("<% helper_method 'foo' do %>bar<% end %>") end it "should work anyway but could be nicer" do @result.should == "foo..bar" end end #eval_erb would basically wrap your original suggestion: def eval_erb(text) ERB.new(text).result(binding) end The nice thing about this is that it not only serves your rails app, but you could use it like this: eval_erb("Columbian").should == "really good s**t" :) ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10262&group_id=797 From noreply at rubyforge.org Fri Apr 20 14:34:45 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 20 Apr 2007 14:34:45 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-10262 ] Better Helper testing of Erb evaluation block helpers Message-ID: <20070420183445.341E05240A2B@rubyforge.org> Feature Requests item #10262, was opened at 2007-04-20 16:12 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10262&group_id=797 Category: rails plugin Group: None >Status: Closed Priority: 3 Submitted By: Simon Nicholls (simon_nicholls) Assigned to: David Chelimsky (dchelimsky) Summary: Better Helper testing of Erb evaluation block helpers Initial Comment: I'd like to easily test helpers which in views would be called like this: <% helper_method "foo" do %> bar <% end %> Erb eval blocks instead of Erb output blocks. Including ActionView::Helpers::TextHelper in HelperBehaviourHelpers would help if you can add that, as it's generally useful. I can then do something like this in the spec: describe ApplicationHelper, "testing Erb eval helper" do before do @result = ERB.new("<% helper_method 'foo' do %>bar<% end %>").result(binding) end it "should work anyway but could be nicer" do @result.should == "foo..bar" end end Works well enough, but can you think of a nicer way? I also tried a more direct, method calling style, but it needs explicit concat usage in the block: _erbout = '' panel('foo') { concat("bar", binding) } @result = _erbout Well, it works, but the block fudging and sneaky _erbout use is a bit naff ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-04-20 18:34 Message: committed to trunk rev 1787. thanks for the suggestion ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-20 18:28 Message: Cool. I've got this working but can't commit right now - will shortly. ---------------------------------------------------------------------- Comment By: Simon Nicholls (simon_nicholls) Date: 2007-04-20 18:07 Message: Hehe! That's actually pretty nice when factored out! ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-20 17:13 Message: How about something like: describe ApplicationHelper, "testing Erb eval helper" do before do @result = eval_erb("<% helper_method 'foo' do %>bar<% end %>") end it "should work anyway but could be nicer" do @result.should == "foo..bar" end end #eval_erb would basically wrap your original suggestion: def eval_erb(text) ERB.new(text).result(binding) end The nice thing about this is that it not only serves your rails app, but you could use it like this: eval_erb("Columbian").should == "really good s**t" :) ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10262&group_id=797 From noreply at rubyforge.org Fri Apr 20 14:37:33 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 20 Apr 2007 14:37:33 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-10262 ] Better Helper testing of Erb evaluation block helpers Message-ID: <20070420183733.3FEC15240A2B@rubyforge.org> Feature Requests item #10262, was opened at 2007-04-20 18:12 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10262&group_id=797 Category: rails plugin Group: None >Status: Open Priority: 3 Submitted By: Simon Nicholls (simon_nicholls) Assigned to: David Chelimsky (dchelimsky) Summary: Better Helper testing of Erb evaluation block helpers Initial Comment: I'd like to easily test helpers which in views would be called like this: <% helper_method "foo" do %> bar <% end %> Erb eval blocks instead of Erb output blocks. Including ActionView::Helpers::TextHelper in HelperBehaviourHelpers would help if you can add that, as it's generally useful. I can then do something like this in the spec: describe ApplicationHelper, "testing Erb eval helper" do before do @result = ERB.new("<% helper_method 'foo' do %>bar<% end %>").result(binding) end it "should work anyway but could be nicer" do @result.should == "foo..bar" end end Works well enough, but can you think of a nicer way? I also tried a more direct, method calling style, but it needs explicit concat usage in the block: _erbout = '' panel('foo') { concat("bar", binding) } @result = _erbout Well, it works, but the block fudging and sneaky _erbout use is a bit naff ---------------------------------------------------------------------- >Comment By: Simon Nicholls (simon_nicholls) Date: 2007-04-20 20:37 Message: That's great, thanks! Nice to know I'll be partaking of the erb shortly. BTW, I've been trying to get basic support for RSpec into the Netbeans Ruby support: http://wiki.netbeans.org/wiki/view/Ruby Tor has been doing some great work, it's pretty much there. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-20 20:34 Message: committed to trunk rev 1787. thanks for the suggestion ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-20 20:28 Message: Cool. I've got this working but can't commit right now - will shortly. ---------------------------------------------------------------------- Comment By: Simon Nicholls (simon_nicholls) Date: 2007-04-20 20:07 Message: Hehe! That's actually pretty nice when factored out! ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-20 19:13 Message: How about something like: describe ApplicationHelper, "testing Erb eval helper" do before do @result = eval_erb("<% helper_method 'foo' do %>bar<% end %>") end it "should work anyway but could be nicer" do @result.should == "foo..bar" end end #eval_erb would basically wrap your original suggestion: def eval_erb(text) ERB.new(text).result(binding) end The nice thing about this is that it not only serves your rails app, but you could use it like this: eval_erb("Columbian").should == "really good s**t" :) ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10262&group_id=797 From noreply at rubyforge.org Sat Apr 21 23:16:30 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sat, 21 Apr 2007 23:16:30 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-10260 ] Spec::Mocks::Mock#inspect returns way too much data Message-ID: <20070422031630.B19365240A49@rubyforge.org> Bugs item #10260, was opened at 2007-04-20 15:47 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10260&group_id=797 Category: runner module Group: None Status: Open Resolution: None Priority: 3 Submitted By: Fran?ois Beausoleil (fbos) Assigned to: Nobody (None) Summary: Spec::Mocks::Mock#inspect returns way too much data Initial Comment: Hi! This is the failure I get: 1) Spec::Mocks::MockExpectationError in 'A POST to /v1/mongrel/heap/free?observed_at=... &data=241 should create a measurement' Measurement expected :new with ({:node=>#, @method_block=nil>], @expectations=[], @target=#, @error_generator=#>, @options={:null_object=>false, :auto_verify=>true}, @messages_received=[]>, @options={}>, :observed_at=>Fri Apr 20 15:37:37 UTC 2007, :feature=>nil}) /home/francois/src/florian/hibiscus/app/controllers/observations_controller.rb:14:in `create_v1' ./spec/controllers/observations_controller_spec.rb:67:in `do_post' ./spec/controllers/observations_controller_spec.rb:77: My expectation is (@node and @category are mocks): Measurement.should_receive(:new).with( :node => @node, :category => @category, :feature => nil, :observed_at => Time.xmlschema(@time), :numerical_data => 241.to_f ).and_return(measurement = mock("observation", :save => true)) Implementing #inspect on Spec::Mocks::Mock to return a bit less data: def inspect "\#<#{self.class.name} #{object_id.to_s(16)} ...>" end results in the following message instead: 1) Spec::Mocks::MockExpectationError in 'A POST to /v1/mongrel/heap/free?observed_at=... &data=241 should create a measurement' Measurement expected :new with ({:node=>#, :observed_at=>Fri Apr 20 15:41:46 UTC 2007, :category=>#, :feature=>nil, :numerical_data=>241.0}) but received it with ({:node=>#, :textual_data=>nil, :category=>#, :observed_at=>Fri Apr 20 15:41:46 UTC 2007, :feature=>nil}) Ah, so my problem is with :textual_data... Interesting ! Bye ! Fran?ois Beausoleil ---------------------------------------------------------------------- Comment By: Scott Taylor (smtlaissezfaire) Date: 2007-04-22 03:16 Message: One way to output less information on a mock is to use the --diff option (in the spec command or in your spec.opts). Does this help your problem? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10260&group_id=797 From dchelimsky at gmail.com Sun Apr 22 01:33:34 2007 From: dchelimsky at gmail.com (David Chelimsky) Date: Sun, 22 Apr 2007 00:33:34 -0500 Subject: [rspec-devel] discovering rails version Message-ID: <57c63afe0704212233h205f9e15y78e6ecb265f8fe49@mail.gmail.com> Hi all, Edge rails has been using new template extensions (.erb instead of .rhtml), which means that Spec::Rails' generators need to find out what version of rails you are running so it can do the right thing. A couple of weeks ago, Rails::VERSION::STRING was returning 1.2.0 in edge. Ironically, rspec was able to use that information temporarily to distinguish edge from the published versions, since 1.2.0 was retracted when 1.2.1 was released. So I posted a request to rails trac () to change the version number to something larger that 1.2.3 so the generator can ask if Rails::VERSION::STRING <= 1.2.3 to decide what kind of template to generate. As it turns out, a change to the version was committed in the last few days. Unfortunately it was changed to 1.2.3, which means that the real 1.2.3 AND edge (the imposter) are both identifying themselves as 1.2.3, which means that Spec::Rails' generators can't know to do the right thing for edge, which means that rspec:pre_commit fails against edge unless you manually change railties/lib/rails/version.rb to say 1.2.4. I've done this locally, but since we don't commit rails to rspec's svn, if you're doing any work on rspec you'll have to make this change locally to get pre_commit to pass edge rails. So I posted an additional plea (with a patch) to rails trac to make the version 1.2.4, but I understand that the rails team is busy and don't expect this to be fixed very quickly, if at all. So - any suggestions as to a different way of determining the rails version? Thanks, David From aslak.hellesoy at gmail.com Sun Apr 22 07:26:10 2007 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Sun, 22 Apr 2007 13:26:10 +0200 Subject: [rspec-devel] discovering rails version In-Reply-To: <57c63afe0704212233h205f9e15y78e6ecb265f8fe49@mail.gmail.com> References: <57c63afe0704212233h205f9e15y78e6ecb265f8fe49@mail.gmail.com> Message-ID: <8d961d900704220426n7efd197dx7ea3072b03dc7002@mail.gmail.com> On 4/22/07, David Chelimsky wrote: > Hi all, > > Edge rails has been using new template extensions (.erb instead of > .rhtml), which means that Spec::Rails' generators need to find out > what version of rails you are running so it can do the right thing. A > couple of weeks ago, Rails::VERSION::STRING was returning 1.2.0 in > edge. Ironically, rspec was able to use that information temporarily > to distinguish edge from the published versions, since 1.2.0 was > retracted when 1.2.1 was released. > > So I posted a request to rails trac () to change the version number to > something larger that 1.2.3 so the generator can ask if > Rails::VERSION::STRING <= 1.2.3 to decide what kind of template to > generate. > > As it turns out, a change to the version was committed in the last few > days. Unfortunately it was changed to 1.2.3, which means that the real > 1.2.3 AND edge (the imposter) are both identifying themselves as > 1.2.3, which means that Spec::Rails' generators can't know to do the > right thing for edge, which means that rspec:pre_commit fails against > edge unless you manually change railties/lib/rails/version.rb to say > 1.2.4. I've done this locally, but since we don't commit rails to > rspec's svn, if you're doing any work on rspec you'll have to make > this change locally to get pre_commit to pass edge rails. > > So I posted an additional plea (with a patch) to rails trac to make > the version 1.2.4, but I understand that the rails team is busy and > don't expect this to be fixed very quickly, if at all. > > So - any suggestions as to a different way of determining the rails version? > Look at the rev number of the Rails working copy? ruby -e 'puts `svn info`.match(/Revision: (.*)/n)[1]' Aslak > Thanks, > David > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From noreply at rubyforge.org Sun Apr 22 07:34:30 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 22 Apr 2007 07:34:30 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-10260 ] Spec::Mocks::Mock#inspect returns way too much data Message-ID: <20070422113430.2FE505240B46@rubyforge.org> Bugs item #10260, was opened at 2007-04-20 11:47 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10260&group_id=797 Category: runner module Group: None >Status: Closed >Resolution: Accepted Priority: 3 Submitted By: Fran?ois Beausoleil (fbos) Assigned to: Nobody (None) Summary: Spec::Mocks::Mock#inspect returns way too much data Initial Comment: Hi! This is the failure I get: 1) Spec::Mocks::MockExpectationError in 'A POST to /v1/mongrel/heap/free?observed_at=... &data=241 should create a measurement' Measurement expected :new with ({:node=>#, @method_block=nil>], @expectations=[], @target=#, @error_generator=#>, @options={:null_object=>false, :auto_verify=>true}, @messages_received=[]>, @options={}>, :observed_at=>Fri Apr 20 15:37:37 UTC 2007, :feature=>nil}) /home/francois/src/florian/hibiscus/app/controllers/observations_controller.rb:14:in `create_v1' ./spec/controllers/observations_controller_spec.rb:67:in `do_post' ./spec/controllers/observations_controller_spec.rb:77: My expectation is (@node and @category are mocks): Measurement.should_receive(:new).with( :node => @node, :category => @category, :feature => nil, :observed_at => Time.xmlschema(@time), :numerical_data => 241.to_f ).and_return(measurement = mock("observation", :save => true)) Implementing #inspect on Spec::Mocks::Mock to return a bit less data: def inspect "\#<#{self.class.name} #{object_id.to_s(16)} ...>" end results in the following message instead: 1) Spec::Mocks::MockExpectationError in 'A POST to /v1/mongrel/heap/free?observed_at=... &data=241 should create a measurement' Measurement expected :new with ({:node=>#, :observed_at=>Fri Apr 20 15:41:46 UTC 2007, :category=>#, :feature=>nil, :numerical_data=>241.0}) but received it with ({:node=>#, :textual_data=>nil, :category=>#, :observed_at=>Fri Apr 20 15:41:46 UTC 2007, :feature=>nil}) Ah, so my problem is with :textual_data... Interesting ! Bye ! Fran?ois Beausoleil ---------------------------------------------------------------------- >Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-04-22 07:34 Message: Applied in r1795, with minor modifications: * Added the missing spec for this * Used sprintf ---------------------------------------------------------------------- Comment By: Scott Taylor (smtlaissezfaire) Date: 2007-04-21 23:16 Message: One way to output less information on a mock is to use the --diff option (in the spec command or in your spec.opts). Does this help your problem? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10260&group_id=797 From noreply at rubyforge.org Sun Apr 22 08:51:55 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 22 Apr 2007 08:51:55 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-10285 ] DSL for example execution and non-procedural expectation/state testing Message-ID: <20070422125155.B30C45240A50@rubyforge.org> Feature Requests item #10285, was opened at 2007-04-22 14:51 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10285&group_id=797 Category: None Group: None Status: Open Priority: 3 Submitted By: Simon Nicholls (simon_nicholls) Assigned to: Nobody (None) Summary: DSL for example execution and non-procedural expectation/state testing Initial Comment: Currently, taking Rails controller testing as an example, this would work for DRY state based testing: describe SomeController do before do #mocks and stubs allowing @test to be tested get 'test_action' end it "should have good state" do @test.should == "" end #...other state specs end But you can't set mock expectations, as the production code execution is in the setup. This is better for expectation style: describe SomeController do before do #mocks and stubs, allowing @test to have expectations set end after do get 'test_action' end it "should call test" do @test.should_receive(:test) #etc end #...other mock expectations end Having execution after the specs allows for mock expectations, but then state specs will be jumping the gun. On top of creating problems if trying to mock and state test together, it doesn't feel right that the actual production code example run has no clear home of it's own. What I'd like is an optional way to forget ordering of mock expectations and state checking - they are all specs which should be written before running the SUT - and have the execution wrapped in some nice DSL (This would also create a context for further features) describe SomeController do before do #mocks and stubs, allowing @test use in specs end example do get 'test_action' end it "should call test" do @test.should_receive(:test) #etc end it "should have good state" do @test.should == "" end end If "should" and "should_not" state expectations could defer until after the example is run, when mocks are verified, then all would be peachy. DRY specs, and a clear separation of concerns. It seems non-trivial but perhaps possible. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10285&group_id=797 From noreply at rubyforge.org Sun Apr 22 09:49:38 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 22 Apr 2007 09:49:38 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-10285 ] DSL for example execution and non-procedural expectation/state testing Message-ID: <20070422134938.D5E045240A43@rubyforge.org> Feature Requests item #10285, was opened at 2007-04-22 12:51 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10285&group_id=797 Category: None Group: None Status: Open Priority: 3 Submitted By: Simon Nicholls (simon_nicholls) Assigned to: Nobody (None) Summary: DSL for example execution and non-procedural expectation/state testing Initial Comment: Currently, taking Rails controller testing as an example, this would work for DRY state based testing: describe SomeController do before do #mocks and stubs allowing @test to be tested get 'test_action' end it "should have good state" do @test.should == "" end #...other state specs end But you can't set mock expectations, as the production code execution is in the setup. This is better for expectation style: describe SomeController do before do #mocks and stubs, allowing @test to have expectations set end after do get 'test_action' end it "should call test" do @test.should_receive(:test) #etc end #...other mock expectations end Having execution after the specs allows for mock expectations, but then state specs will be jumping the gun. On top of creating problems if trying to mock and state test together, it doesn't feel right that the actual production code example run has no clear home of it's own. What I'd like is an optional way to forget ordering of mock expectations and state checking - they are all specs which should be written before running the SUT - and have the execution wrapped in some nice DSL (This would also create a context for further features) describe SomeController do before do #mocks and stubs, allowing @test use in specs end example do get 'test_action' end it "should call test" do @test.should_receive(:test) #etc end it "should have good state" do @test.should == "" end end If "should" and "should_not" state expectations could defer until after the example is run, when mocks are verified, then all would be peachy. DRY specs, and a clear separation of concerns. It seems non-trivial but perhaps possible. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-04-22 13:49 Message: As Aslak and Dave and I have all stated emphatically, clarity is king in examples in our view, which means a little moisture is OK if it results in better feedback from reading the examples. I think doing this implicitly would be nothing but confusing to anyone reading the specs trying to understand a failure. When did what run? There was a similar suggestion to this either in the tracker or on one of the mailing lists that read more like this: describe SomeController do def event get 'test_action' end it "should call test", before_event do @test.should_receive(:test) #etc end it "should have good state", after_event do @test.should == "" end end I'd be more open to something like that which is more explicit. Actually, how about "during_event" for the mock expectation - then you could have this: it "should call test", during_event do @test.should_receive(:test) #etc end it "should have good state", after_event do @test.should == "" end Now THAT reads really nicely. WDYT? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10285&group_id=797 From noreply at rubyforge.org Sun Apr 22 10:03:29 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 22 Apr 2007 10:03:29 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-8366 ] Structure for library specs in rspec_on_rails Message-ID: <20070422140329.660235240B4A@rubyforge.org> Feature Requests item #8366, was opened at 2007-02-01 17:37 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=8366&group_id=797 Category: rails plugin Group: None >Status: Closed Priority: 3 Submitted By: Ashley Moran (ashley_moran) >Assigned to: David Chelimsky (dchelimsky) Summary: Structure for library specs in rspec_on_rails Initial Comment: I'd like to see a standard folder spec/lib to put specs for code in RAILS_ROOT/lib Also, a spec:libraries rake task, and having the library specs counted in the test LOC in rake stats would be useful Cheers! ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-04-22 14:03 Message: Saying "rake spec" will now run anything in the spec directory. You can easily create your own spec task to go after individual directories (look at the spec tasks in tasks/rspec.rake as examples). ---------------------------------------------------------------------- Comment By: Jerry West (jjw) Date: 2007-02-01 20:08 Message: If there's nothing generated to go in the directory, does it need to be part of the plugin? A user can just create the directory; there's nothing special about it. Having said that, I've created a 'config' directory to spec my environment.rb (etc); so whilst you're adding 'lib' ... ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=8366&group_id=797 From noreply at rubyforge.org Sun Apr 22 12:11:01 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 22 Apr 2007 12:11:01 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-10285 ] DSL for example execution and non-procedural expectation/state testing Message-ID: <20070422161101.E757F524098D@rubyforge.org> Feature Requests item #10285, was opened at 2007-04-22 14:51 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10285&group_id=797 Category: None Group: None Status: Open Priority: 3 Submitted By: Simon Nicholls (simon_nicholls) Assigned to: Nobody (None) Summary: DSL for example execution and non-procedural expectation/state testing Initial Comment: Currently, taking Rails controller testing as an example, this would work for DRY state based testing: describe SomeController do before do #mocks and stubs allowing @test to be tested get 'test_action' end it "should have good state" do @test.should == "" end #...other state specs end But you can't set mock expectations, as the production code execution is in the setup. This is better for expectation style: describe SomeController do before do #mocks and stubs, allowing @test to have expectations set end after do get 'test_action' end it "should call test" do @test.should_receive(:test) #etc end #...other mock expectations end Having execution after the specs allows for mock expectations, but then state specs will be jumping the gun. On top of creating problems if trying to mock and state test together, it doesn't feel right that the actual production code example run has no clear home of it's own. What I'd like is an optional way to forget ordering of mock expectations and state checking - they are all specs which should be written before running the SUT - and have the execution wrapped in some nice DSL (This would also create a context for further features) describe SomeController do before do #mocks and stubs, allowing @test use in specs end example do get 'test_action' end it "should call test" do @test.should_receive(:test) #etc end it "should have good state" do @test.should == "" end end If "should" and "should_not" state expectations could defer until after the example is run, when mocks are verified, then all would be peachy. DRY specs, and a clear separation of concerns. It seems non-trivial but perhaps possible. ---------------------------------------------------------------------- >Comment By: Simon Nicholls (simon_nicholls) Date: 2007-04-22 18:11 Message: Yeah, I'm kind of jumping into the deep end here. Just wanted to throw something out and see what you thought. I'd be pretty happy with something along the lines of the 2nd version actually, as it does capture the spirit of the spec. I have some niggly thoughts in my mind about being able to state a default before/after event to run if not overridden (using new dsl or hanging off some existing dsl), but I can't really say if it's needed. Dude, it's Sunday! Thanks for getting back so quickly! :D ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-22 15:49 Message: As Aslak and Dave and I have all stated emphatically, clarity is king in examples in our view, which means a little moisture is OK if it results in better feedback from reading the examples. I think doing this implicitly would be nothing but confusing to anyone reading the specs trying to understand a failure. When did what run? There was a similar suggestion to this either in the tracker or on one of the mailing lists that read more like this: describe SomeController do def event get 'test_action' end it "should call test", before_event do @test.should_receive(:test) #etc end it "should have good state", after_event do @test.should == "" end end I'd be more open to something like that which is more explicit. Actually, how about "during_event" for the mock expectation - then you could have this: it "should call test", during_event do @test.should_receive(:test) #etc end it "should have good state", after_event do @test.should == "" end Now THAT reads really nicely. WDYT? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10285&group_id=797 From noreply at rubyforge.org Sun Apr 22 12:16:42 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 22 Apr 2007 12:16:42 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-10262 ] Better Helper testing of Erb evaluation block helpers Message-ID: <20070422161642.6C8985240A35@rubyforge.org> Feature Requests item #10262, was opened at 2007-04-20 16:12 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10262&group_id=797 Category: rails plugin Group: None >Status: Closed Priority: 3 Submitted By: Simon Nicholls (simon_nicholls) Assigned to: David Chelimsky (dchelimsky) Summary: Better Helper testing of Erb evaluation block helpers Initial Comment: I'd like to easily test helpers which in views would be called like this: <% helper_method "foo" do %> bar <% end %> Erb eval blocks instead of Erb output blocks. Including ActionView::Helpers::TextHelper in HelperBehaviourHelpers would help if you can add that, as it's generally useful. I can then do something like this in the spec: describe ApplicationHelper, "testing Erb eval helper" do before do @result = ERB.new("<% helper_method 'foo' do %>bar<% end %>").result(binding) end it "should work anyway but could be nicer" do @result.should == "foo..bar" end end Works well enough, but can you think of a nicer way? I also tried a more direct, method calling style, but it needs explicit concat usage in the block: _erbout = '' panel('foo') { concat("bar", binding) } @result = _erbout Well, it works, but the block fudging and sneaky _erbout use is a bit naff ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-04-22 16:16 Message: This should have been closed two messages ago. ---------------------------------------------------------------------- Comment By: Simon Nicholls (simon_nicholls) Date: 2007-04-20 18:37 Message: That's great, thanks! Nice to know I'll be partaking of the erb shortly. BTW, I've been trying to get basic support for RSpec into the Netbeans Ruby support: http://wiki.netbeans.org/wiki/view/Ruby Tor has been doing some great work, it's pretty much there. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-20 18:34 Message: committed to trunk rev 1787. thanks for the suggestion ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-20 18:28 Message: Cool. I've got this working but can't commit right now - will shortly. ---------------------------------------------------------------------- Comment By: Simon Nicholls (simon_nicholls) Date: 2007-04-20 18:07 Message: Hehe! That's actually pretty nice when factored out! ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-20 17:13 Message: How about something like: describe ApplicationHelper, "testing Erb eval helper" do before do @result = eval_erb("<% helper_method 'foo' do %>bar<% end %>") end it "should work anyway but could be nicer" do @result.should == "foo..bar" end end #eval_erb would basically wrap your original suggestion: def eval_erb(text) ERB.new(text).result(binding) end The nice thing about this is that it not only serves your rails app, but you could use it like this: eval_erb("Columbian").should == "really good s**t" :) ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10262&group_id=797 From noreply at rubyforge.org Sun Apr 22 22:41:30 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 22 Apr 2007 22:41:30 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-10297 ] Controller Specs - assigns method does not use the controller's assigns hash Message-ID: <20070423024130.6741F5240B53@rubyforge.org> Bugs item #10297, was opened at 2007-04-22 19:41 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10297&group_id=797 Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: Brian Takita (btakita) Assigned to: Nobody (None) Summary: Controller Specs - assigns method does not use the controller's assigns hash Initial Comment: The assigs method compares against instance variables in the controller. In ActionController, there is an assigns hash. If a key in the assigns hash is set, that object is sent to the view, even though there is no instance variable with that name. See ActionController::Base#add_variables_to_assigns. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10297&group_id=797 From noreply at rubyforge.org Sun Apr 22 22:56:41 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 22 Apr 2007 22:56:41 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-10297 ] Controller Specs - assigns method does not use the controller's assigns hash Message-ID: <20070423025641.3BC7C5240B60@rubyforge.org> Bugs item #10297, was opened at 2007-04-23 02:41 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10297&group_id=797 Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: Brian Takita (btakita) Assigned to: Nobody (None) Summary: Controller Specs - assigns method does not use the controller's assigns hash Initial Comment: The assigs method compares against instance variables in the controller. In ActionController, there is an assigns hash. If a key in the assigns hash is set, that object is sent to the view, even though there is no instance variable with that name. See ActionController::Base#add_variables_to_assigns. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-04-23 02:56 Message: I don't understand the problem. Can you submit an example that is behaving incorrectly? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10297&group_id=797 From noreply at rubyforge.org Mon Apr 23 00:23:19 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 23 Apr 2007 00:23:19 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-10297 ] Controller Specs - assigns method does not use the controller's assigns hash Message-ID: <20070423042319.7F2965240C04@rubyforge.org> Bugs item #10297, was opened at 2007-04-22 19:41 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10297&group_id=797 Category: rails plugin Group: None >Status: Closed Resolution: None Priority: 3 Submitted By: Brian Takita (btakita) Assigned to: Nobody (None) Summary: Controller Specs - assigns method does not use the controller's assigns hash Initial Comment: The assigs method compares against instance variables in the controller. In ActionController, there is an assigns hash. If a key in the assigns hash is set, that object is sent to the view, even though there is no instance variable with that name. See ActionController::Base#add_variables_to_assigns. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-22 19:56 Message: I don't understand the problem. Can you submit an example that is behaving incorrectly? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10297&group_id=797 From noreply at rubyforge.org Mon Apr 23 01:58:13 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 23 Apr 2007 01:58:13 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-10297 ] Controller Specs - assigns method does not use the controller's assigns hash Message-ID: <20070423055813.16A3A5240C79@rubyforge.org> Bugs item #10297, was opened at 2007-04-22 22:41 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10297&group_id=797 Category: rails plugin Group: None Status: Closed Resolution: None Priority: 3 Submitted By: Brian Takita (btakita) Assigned to: Nobody (None) Summary: Controller Specs - assigns method does not use the controller's assigns hash Initial Comment: The assigs method compares against instance variables in the controller. In ActionController, there is an assigns hash. If a key in the assigns hash is set, that object is sent to the view, even though there is no instance variable with that name. See ActionController::Base#add_variables_to_assigns. ---------------------------------------------------------------------- >Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-04-23 01:58 Message: Why was this closed? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-22 22:56 Message: I don't understand the problem. Can you submit an example that is behaving incorrectly? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10297&group_id=797 From noreply at rubyforge.org Mon Apr 23 05:36:45 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 23 Apr 2007 05:36:45 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-8366 ] Structure for library specs in rspec_on_rails Message-ID: <20070423093645.292EC524099C@rubyforge.org> Feature Requests item #8366, was opened at 2007-02-01 17:37 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=8366&group_id=797 Category: rails plugin Group: None Status: Closed Priority: 3 Submitted By: Ashley Moran (ashley_moran) Assigned to: David Chelimsky (dchelimsky) Summary: Structure for library specs in rspec_on_rails Initial Comment: I'd like to see a standard folder spec/lib to put specs for code in RAILS_ROOT/lib Also, a spec:libraries rake task, and having the library specs counted in the test LOC in rake stats would be useful Cheers! ---------------------------------------------------------------------- >Comment By: Ashley Moran (ashley_moran) Date: 2007-04-23 09:36 Message: My thought was simply that seeing as "lib" is part of the rails structure, it'd be nice if rake spec ran specs for those too. I like the idea of a command that tells me my whole application is perfect and has no bugs... ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-22 14:03 Message: Saying "rake spec" will now run anything in the spec directory. You can easily create your own spec task to go after individual directories (look at the spec tasks in tasks/rspec.rake as examples). ---------------------------------------------------------------------- Comment By: Jerry West (jjw) Date: 2007-02-01 20:08 Message: If there's nothing generated to go in the directory, does it need to be part of the plugin? A user can just create the directory; there's nothing special about it. Having said that, I've created a 'config' directory to spec my environment.rb (etc); so whilst you're adding 'lib' ... ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=8366&group_id=797 From noreply at rubyforge.org Mon Apr 23 06:38:32 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 23 Apr 2007 06:38:32 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-8366 ] Structure for library specs in rspec_on_rails Message-ID: <20070423103832.B526A5240A78@rubyforge.org> Feature Requests item #8366, was opened at 2007-02-01 17:37 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=8366&group_id=797 Category: rails plugin Group: None Status: Closed Priority: 3 Submitted By: Ashley Moran (ashley_moran) Assigned to: David Chelimsky (dchelimsky) Summary: Structure for library specs in rspec_on_rails Initial Comment: I'd like to see a standard folder spec/lib to put specs for code in RAILS_ROOT/lib Also, a spec:libraries rake task, and having the library specs counted in the test LOC in rake stats would be useful Cheers! ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-04-23 10:38 Message: 'rake spec' will run spec/lib - that's what I was trying to say. See http://rubyforge.org/tracker/?func=detail&group_id=797&aid=9295&atid=3152 ---------------------------------------------------------------------- Comment By: Ashley Moran (ashley_moran) Date: 2007-04-23 09:36 Message: My thought was simply that seeing as "lib" is part of the rails structure, it'd be nice if rake spec ran specs for those too. I like the idea of a command that tells me my whole application is perfect and has no bugs... ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-22 14:03 Message: Saying "rake spec" will now run anything in the spec directory. You can easily create your own spec task to go after individual directories (look at the spec tasks in tasks/rspec.rake as examples). ---------------------------------------------------------------------- Comment By: Jerry West (jjw) Date: 2007-02-01 20:08 Message: If there's nothing generated to go in the directory, does it need to be part of the plugin? A user can just create the directory; there's nothing special about it. Having said that, I've created a 'config' directory to spec my environment.rb (etc); so whilst you're adding 'lib' ... ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=8366&group_id=797 From noreply at rubyforge.org Mon Apr 23 07:14:01 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 23 Apr 2007 07:14:01 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-8366 ] Structure for library specs in rspec_on_rails Message-ID: <20070423111401.543925240A4E@rubyforge.org> Feature Requests item #8366, was opened at 2007-02-01 17:37 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=8366&group_id=797 Category: rails plugin Group: None Status: Closed Priority: 3 Submitted By: Ashley Moran (ashley_moran) Assigned to: David Chelimsky (dchelimsky) Summary: Structure for library specs in rspec_on_rails Initial Comment: I'd like to see a standard folder spec/lib to put specs for code in RAILS_ROOT/lib Also, a spec:libraries rake task, and having the library specs counted in the test LOC in rake stats would be useful Cheers! ---------------------------------------------------------------------- >Comment By: Ashley Moran (ashley_moran) Date: 2007-04-23 11:14 Message: Aha cool, I got confused there. Cheers! ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-23 10:38 Message: 'rake spec' will run spec/lib - that's what I was trying to say. See http://rubyforge.org/tracker/?func=detail&group_id=797&aid=9295&atid=3152 ---------------------------------------------------------------------- Comment By: Ashley Moran (ashley_moran) Date: 2007-04-23 09:36 Message: My thought was simply that seeing as "lib" is part of the rails structure, it'd be nice if rake spec ran specs for those too. I like the idea of a command that tells me my whole application is perfect and has no bugs... ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-22 14:03 Message: Saying "rake spec" will now run anything in the spec directory. You can easily create your own spec task to go after individual directories (look at the spec tasks in tasks/rspec.rake as examples). ---------------------------------------------------------------------- Comment By: Jerry West (jjw) Date: 2007-02-01 20:08 Message: If there's nothing generated to go in the directory, does it need to be part of the plugin? A user can just create the directory; there's nothing special about it. Having said that, I've created a 'config' directory to spec my environment.rb (etc); so whilst you're adding 'lib' ... ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=8366&group_id=797 From noreply at rubyforge.org Mon Apr 23 08:38:36 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 23 Apr 2007 08:38:36 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-10313 ] pre_commit_rails: doesn't always build correctly Message-ID: <20070423123836.B14D45240A80@rubyforge.org> Bugs item #10313, was opened at 2007-04-23 15:38 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10313&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Antti Tarvainen (tarvaina) Assigned to: Nobody (None) Summary: pre_commit_rails: doesn't always build correctly Initial Comment: First the cause: The PreCommit#silent_sh method is supposed to return the output of the command it runs, but it always returns "". This is easily fixed: Index: pre_commit/lib/pre_commit/pre_commit.rb =================================================================== --- pre_commit/lib/pre_commit/pre_commit.rb (revision 1802) +++ pre_commit/lib/pre_commit/pre_commit.rb (working copy) @@ -20,10 +20,10 @@ def silent_sh(cmd, &block) output = nil IO.popen(cmd) do |io| - io.each_line do |line| + output = io.read + output.each_line do |line| block.call(line) if block end - output = io.read end output end The reason this is a bug report and not a patch is that fixing silent_sh breaks the build. Here is my understanding of what is happening: 1. Rake against Rails Edge fails. (This is ok.) Since it fails, destroy_purchase is not called, and generated rspec_resource files are left in the example_rails_app. 2. Rake starts to build agains Rails 1.2.3, but fails since it cannot create the rspec_resource files again. In the current trunk, the rake task doesn't notice that rspec_resource generation failed (since it doesn't get the output back from silent_sh), and continues the rake task. Thus, the rspec_resources in tests against 1.2.3 are actually created with Rails edge. Attached is a diff of not-very-bdd specs for repeating parts of this. You can run them in trunk root with ruby rspec/bin/spec pre_commit/spec I will look into this myself later today to see if I can patch it. I'll let you know. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10313&group_id=797 From noreply at rubyforge.org Mon Apr 23 11:22:45 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 23 Apr 2007 11:22:45 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-10315 ] Patch to fix pre_commit (bug 10313) Message-ID: <20070423152245.ACF28A97000D@rubyforge.org> Patches item #10315, was opened at 2007-04-23 18:22 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=10315&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Antti Tarvainen (tarvaina) Assigned to: Nobody (None) Summary: Patch to fix pre_commit (bug 10313) Initial Comment: Here's a patch for the bug I reported earlier today. Changes to the running code are: - fixed PreCommit#silent_sh. - ensured destroy_purchase is run every time at the end of PreCommit::RspecOnRails#rspec_pre_commit. I included some specs in the patch for regression testing. Note however that: - The specs are not run as part of the "rake pre_commit". - There is no rake task to run them. - The specs are not very good BDD. This is because pre_commit code didn't have any specs before and it isn't easily specsable in its current form. Instead of investing time to write exhaustive specs for the current implementation, I suggest we refactor the pre_commit code to make it more easily specsable, writing specs along the way. (Move shell-calls to a module of their own, etc.) (I can look into it this week, if you agree.) ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=10315&group_id=797 From dchelimsky at gmail.com Mon Apr 23 17:40:47 2007 From: dchelimsky at gmail.com (David Chelimsky) Date: Mon, 23 Apr 2007 17:40:47 -0400 Subject: [rspec-devel] discovering rails version In-Reply-To: <8d961d900704220426n7efd197dx7ea3072b03dc7002@mail.gmail.com> References: <57c63afe0704212233h205f9e15y78e6ecb265f8fe49@mail.gmail.com> <8d961d900704220426n7efd197dx7ea3072b03dc7002@mail.gmail.com> Message-ID: <57c63afe0704231440l566580a8l6ec392738297c1cc@mail.gmail.com> On 4/22/07, aslak hellesoy wrote: > On 4/22/07, David Chelimsky wrote: > > Hi all, > > > > Edge rails has been using new template extensions (.erb instead of > > .rhtml), which means that Spec::Rails' generators need to find out > > what version of rails you are running so it can do the right thing. A > > couple of weeks ago, Rails::VERSION::STRING was returning 1.2.0 in > > edge. Ironically, rspec was able to use that information temporarily > > to distinguish edge from the published versions, since 1.2.0 was > > retracted when 1.2.1 was released. > > > > So I posted a request to rails trac () to change the version number to > > something larger that 1.2.3 so the generator can ask if > > Rails::VERSION::STRING <= 1.2.3 to decide what kind of template to > > generate. > > > > As it turns out, a change to the version was committed in the last few > > days. Unfortunately it was changed to 1.2.3, which means that the real > > 1.2.3 AND edge (the imposter) are both identifying themselves as > > 1.2.3, which means that Spec::Rails' generators can't know to do the > > right thing for edge, which means that rspec:pre_commit fails against > > edge unless you manually change railties/lib/rails/version.rb to say > > 1.2.4. I've done this locally, but since we don't commit rails to > > rspec's svn, if you're doing any work on rspec you'll have to make > > this change locally to get pre_commit to pass edge rails. > > > > So I posted an additional plea (with a patch) to rails trac to make > > the version 1.2.4, but I understand that the rails team is busy and > > don't expect this to be fixed very quickly, if at all. > > > > So - any suggestions as to a different way of determining the rails version? > > > > Look at the rev number of the Rails working copy? > > ruby -e 'puts `svn info`.match(/Revision: (.*)/n)[1]' That only works for when rails is specifically checked out (not exported) into vendor/rails. Other ideas? > > Aslak > > > 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 > From aslak.hellesoy at gmail.com Mon Apr 23 18:11:11 2007 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Tue, 24 Apr 2007 00:11:11 +0200 Subject: [rspec-devel] discovering rails version In-Reply-To: <57c63afe0704231440l566580a8l6ec392738297c1cc@mail.gmail.com> References: <57c63afe0704212233h205f9e15y78e6ecb265f8fe49@mail.gmail.com> <8d961d900704220426n7efd197dx7ea3072b03dc7002@mail.gmail.com> <57c63afe0704231440l566580a8l6ec392738297c1cc@mail.gmail.com> Message-ID: <8d961d900704231511v18199b49q78e8bd8a9d95fe0d@mail.gmail.com> On 4/23/07, David Chelimsky wrote: > On 4/22/07, aslak hellesoy wrote: > > On 4/22/07, David Chelimsky wrote: > > > Hi all, > > > > > > Edge rails has been using new template extensions (.erb instead of > > > .rhtml), which means that Spec::Rails' generators need to find out > > > what version of rails you are running so it can do the right thing. A > > > couple of weeks ago, Rails::VERSION::STRING was returning 1.2.0 in > > > edge. Ironically, rspec was able to use that information temporarily > > > to distinguish edge from the published versions, since 1.2.0 was > > > retracted when 1.2.1 was released. > > > > > > So I posted a request to rails trac () to change the version number to > > > something larger that 1.2.3 so the generator can ask if > > > Rails::VERSION::STRING <= 1.2.3 to decide what kind of template to > > > generate. > > > > > > As it turns out, a change to the version was committed in the last few > > > days. Unfortunately it was changed to 1.2.3, which means that the real > > > 1.2.3 AND edge (the imposter) are both identifying themselves as > > > 1.2.3, which means that Spec::Rails' generators can't know to do the > > > right thing for edge, which means that rspec:pre_commit fails against > > > edge unless you manually change railties/lib/rails/version.rb to say > > > 1.2.4. I've done this locally, but since we don't commit rails to > > > rspec's svn, if you're doing any work on rspec you'll have to make > > > this change locally to get pre_commit to pass edge rails. > > > > > > So I posted an additional plea (with a patch) to rails trac to make > > > the version 1.2.4, but I understand that the rails team is busy and > > > don't expect this to be fixed very quickly, if at all. > > > > > > So - any suggestions as to a different way of determining the rails version? > > > > > > > Look at the rev number of the Rails working copy? > > > > ruby -e 'puts `svn info`.match(/Revision: (.*)/n)[1]' > > That only works for when rails is specifically checked out (not > exported) into vendor/rails. > I thought the context was Spec::Rails's own build environment. Did you mean we need to detect this in Spec::Rails when used in an arbitrary Rails project? In that case, why not assume the version is whatever Rails::VERSION::STRING says - unless it's specified expplicitly in Spec::Configure (we could add a hook for it) Aslak > Other ideas? > > > > > Aslak > > > > > 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 > > > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From noreply at rubyforge.org Tue Apr 24 01:54:05 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 24 Apr 2007 01:54:05 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-9983 ] Allow before_setup and after_teardown to be called in BehaviourEval Message-ID: <20070424055405.26E5D5240A93@rubyforge.org> Feature Requests item #9983, was opened at 2007-04-08 23:29 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=9983&group_id=797 Category: None Group: None Status: Open Priority: 3 Submitted By: Brian Takita (btakita) Assigned to: Nobody (None) Summary: Allow before_setup and after_teardown to be called in BehaviourEval Initial Comment: This would provide a hook for cross cutting. For example: Somebody wants to have setup and/or teardown functionality in a select few Examples. One may want to create a module and define the included method. module Foobar def self.included(mod) mod.before_setup do puts 'my special setup hook' end end end describe MyObject include Foobar end ---------------------------------------------------------------------- >Comment By: Brian Takita (btakita) Date: 2007-04-23 22:54 Message: It looks like the current callback library may be obsolete in favor of the new implementation in behaviour_eval. Perhaps some common behaviour can be extracted. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-12 05:30 Message: before and after (:each or :all) have been implemented now. These are there for use within examples. The other methods are still around as aliases to avoid compatibility problems, so you don't have to change existing specs (yet). Looking through the code, we do have before_setup and after_teardown hooks in Example (formerly Specification). I think you actually added these, Brian. So we need to do two things: - Come up w/ better names given the new API. - Add these to Behaviour so that they are accessible (right now I don't think anybody is using them). ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-04-12 02:37 Message: Contexts are gone, and so are specify (ok, they are around a little bit longer for compatibility). We should come up with names that make sense with the new API. The following has been suggested in various emails and chats: before(what=:each) # you can also pass :all after(what=:each) # you can also pass :all ---------------------------------------------------------------------- Comment By: Brian Takita (btakita) Date: 2007-04-12 00:19 Message: Great. This would get run before each example. I think we both agree that before_setup provides value. That would bring 4 hooks. Actually there are also the global before_setup hooks. Maybe there should be global before_context_setup hooks too? Your idea with the setup methods arguments looks good. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-10 22:48 Message: Brian - what you say makes sense to me. Thanks for the explanation. RSpec currently supports a context_setup that happens once before all of the examples in a given context. So when is the hook supposed to get run? Before each example? Once before all examples? Would we want to have 4 hooks? before_context_setup, before_setup, and their teardown counterparts? On a side note, I'm planning to change setup so it takes an arg: def setup(scope=:each, &block) This will default to :each, but you can supply :all .... describe Thing do setup :all { ... } setup :each { ... } ... end So "setup :all" would replace context_setup (we'd leave context_setup for backwards compatibility). This might actually simplify this hook question because we could say: before_setup :each or before_setup :all WDYT? ---------------------------------------------------------------------- Comment By: Brian Takita (btakita) Date: 2007-04-10 22:03 Message: The objection I received, that I agree with, was a lack of cross cutting hooks. There are cases when a library developer would not want to require up to 3 touch points (include, setup, and teardown) to get the added feature set to run. In house, we have a number of helper packages that get applied only certain specs. For example, we have a module that hooks into TestCase that print how long the test took. Sometimes we want to apply to all of our tests, and sometimes we don't. Another example would be if you want some specs to print out the specdocs, but not others. At some level, it would be helpful to allow users to make 'plugins' of some type, rather than have to rely on editing core classes. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-09 03:59 Message: Right now you can do the following - would it suffice? # in a central location like spec_helper.rb module SpecialSetups def stuff_to_do_first ... end end Spec::Runner.configure do |config| config.include SpecialSetups end # in a spec file describe SomeObject do setup do stuff_to_do_first # other stuff end ... end This makes things a bit more transparent in the specs and is not really any more verbose if you've got a setup anyhow. WDYT? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=9983&group_id=797 From aslak.hellesoy at gmail.com Tue Apr 24 04:41:13 2007 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Tue, 24 Apr 2007 10:41:13 +0200 Subject: [rspec-devel] Multiple formatters Message-ID: <8d961d900704240141v5c318aaet449db2ab1f83ac7a@mail.gmail.com> Hi all, RSpec supports multiple formatters, but currently you can only use one at a time. I really need to use several at the same time. I'd like to make RSpec handle several --format options. However, that would require some rethinking of how/where output is written - it can't all go to the same stream (file or stdout). So I'm thinking of making --format take a composite argument: --format html:/path/to/index.html --format rdoc:/path/to/index.rdoc --format progress If nothing comes after the format, output is STDOUT, so this would be backwards compatible. If we do this, we could also get rid of --failures - it would just be a special formatter. WDYT? From noreply at rubyforge.org Tue Apr 24 05:54:44 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 24 Apr 2007 05:54:44 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-10333 ] can't load spec tasks from rakefiles with pluginized rspec [r1802] Message-ID: <20070424095444.1C772524094F@rubyforge.org> Bugs item #10333, was opened at 2007-04-24 09:54 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10333&group_id=797 Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: Ian White (ianwhite) Assigned to: Nobody (None) Summary: can't load spec tasks from rakefiles with pluginized rspec [r1802] Initial Comment: When rspec itself is pluginized (a great idea), all of my custom rakefiles which include spec/rake/whatever don't work. The reason is noted in the rspec_on_rails tasks - the plugin libs don't get into the load path at this stage. So everyone could change all of their scripts to check for the presence of the plugin and load the appropriate rspec lib from the right place. But how about adding the rspec/lib to the load paths in a rake task in rspec/tasks? That way, if the rakefile in question is in Rails' purview, it will know about the rspec plugin lib. This works for me: in vendor/plugins/rspec/tasks/load_rspec.rake: $: << File.expand_path(File.join(File.dirname(__FILE__), '../lib')) Sorry if this isn't a bug - I figured that because it broke existing scripts it should be classified as one. Cheers, Ian White ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10333&group_id=797 From noreply at rubyforge.org Tue Apr 24 06:10:56 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 24 Apr 2007 06:10:56 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-10333 ] can't load spec tasks from rakefiles with pluginized rspec [r1802] Message-ID: <20070424101056.51360524094F@rubyforge.org> Bugs item #10333, was opened at 2007-04-24 09:54 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10333&group_id=797 Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: Ian White (ianwhite) Assigned to: Nobody (None) Summary: can't load spec tasks from rakefiles with pluginized rspec [r1802] Initial Comment: When rspec itself is pluginized (a great idea), all of my custom rakefiles which include spec/rake/whatever don't work. The reason is noted in the rspec_on_rails tasks - the plugin libs don't get into the load path at this stage. So everyone could change all of their scripts to check for the presence of the plugin and load the appropriate rspec lib from the right place. But how about adding the rspec/lib to the load paths in a rake task in rspec/tasks? That way, if the rakefile in question is in Rails' purview, it will know about the rspec plugin lib. This works for me: in vendor/plugins/rspec/tasks/load_rspec.rake: $: << File.expand_path(File.join(File.dirname(__FILE__), '../lib')) Sorry if this isn't a bug - I figured that because it broke existing scripts it should be classified as one. Cheers, Ian White ---------------------------------------------------------------------- >Comment By: Ian White (ianwhite) Date: 2007-04-24 10:10 Message: I just tried this approach for running a custom rcov task from RAILS_ROOT/lib/tasks and it didn't work as rails loads lib/tasks before vendor/plugins/**/tasks. So I just had to copy load_rspec into lib.tasks. This could be done when bootstrapping rspec_on_rails. Also, perhaps the following is better, to avoid duplication of the path $: |= [File.expand_path(File.join(File.dirname(__FILE__), '../lib'))] ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10333&group_id=797 From noreply at rubyforge.org Tue Apr 24 06:18:14 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 24 Apr 2007 06:18:14 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-10333 ] can't load spec tasks from rakefiles with pluginized rspec [r1802] Message-ID: <20070424101814.834A7524094F@rubyforge.org> Bugs item #10333, was opened at 2007-04-24 09:54 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10333&group_id=797 Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: Ian White (ianwhite) Assigned to: Nobody (None) Summary: can't load spec tasks from rakefiles with pluginized rspec [r1802] Initial Comment: When rspec itself is pluginized (a great idea), all of my custom rakefiles which include spec/rake/whatever don't work. The reason is noted in the rspec_on_rails tasks - the plugin libs don't get into the load path at this stage. So everyone could change all of their scripts to check for the presence of the plugin and load the appropriate rspec lib from the right place. But how about adding the rspec/lib to the load paths in a rake task in rspec/tasks? That way, if the rakefile in question is in Rails' purview, it will know about the rspec plugin lib. This works for me: in vendor/plugins/rspec/tasks/load_rspec.rake: $: << File.expand_path(File.join(File.dirname(__FILE__), '../lib')) Sorry if this isn't a bug - I figured that because it broke existing scripts it should be classified as one. Cheers, Ian White ---------------------------------------------------------------------- >Comment By: Ian White (ianwhite) Date: 2007-04-24 10:18 Message: Ok, so this works for me in lib/tasks/_load_rspec.rake if File.exist?(rspec_base = File.join(RAILS_ROOT, 'vendor/plugins/rspec')) $: << File.expand_path(File.join(rspec_base, 'lib')) end ---------------------------------------------------------------------- Comment By: Ian White (ianwhite) Date: 2007-04-24 10:10 Message: I just tried this approach for running a custom rcov task from RAILS_ROOT/lib/tasks and it didn't work as rails loads lib/tasks before vendor/plugins/**/tasks. So I just had to copy load_rspec into lib.tasks. This could be done when bootstrapping rspec_on_rails. Also, perhaps the following is better, to avoid duplication of the path $: |= [File.expand_path(File.join(File.dirname(__FILE__), '../lib'))] ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10333&group_id=797 From noreply at rubyforge.org Tue Apr 24 06:27:44 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 24 Apr 2007 06:27:44 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-10333 ] can't load spec tasks from rakefiles with pluginized rspec [r1802] Message-ID: <20070424102744.8858C524094F@rubyforge.org> Bugs item #10333, was opened at 2007-04-24 05:54 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10333&group_id=797 Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: Ian White (ianwhite) Assigned to: Nobody (None) Summary: can't load spec tasks from rakefiles with pluginized rspec [r1802] Initial Comment: When rspec itself is pluginized (a great idea), all of my custom rakefiles which include spec/rake/whatever don't work. The reason is noted in the rspec_on_rails tasks - the plugin libs don't get into the load path at this stage. So everyone could change all of their scripts to check for the presence of the plugin and load the appropriate rspec lib from the right place. But how about adding the rspec/lib to the load paths in a rake task in rspec/tasks? That way, if the rakefile in question is in Rails' purview, it will know about the rspec plugin lib. This works for me: in vendor/plugins/rspec/tasks/load_rspec.rake: $: << File.expand_path(File.join(File.dirname(__FILE__), '../lib')) Sorry if this isn't a bug - I figured that because it broke existing scripts it should be classified as one. Cheers, Ian White ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-04-24 06:27 Message: Before investigating this we need to know the versions of all relevant software, for example: * OS X 10.4.9 * Ruby 1.8.6 * RSpec 1.8.2 or RSpec trunk r1643 * Spec::Rails 1.8.2 or Spec::Rails tag r1234... * Rails 1.2.3 or Rails edge r5645 * Whatever other relevant software. Without this information it's like solving 1 equation (your question) with 5 unknown variables (the versions). ---------------------------------------------------------------------- Comment By: Ian White (ianwhite) Date: 2007-04-24 06:18 Message: Ok, so this works for me in lib/tasks/_load_rspec.rake if File.exist?(rspec_base = File.join(RAILS_ROOT, 'vendor/plugins/rspec')) $: << File.expand_path(File.join(rspec_base, 'lib')) end ---------------------------------------------------------------------- Comment By: Ian White (ianwhite) Date: 2007-04-24 06:10 Message: I just tried this approach for running a custom rcov task from RAILS_ROOT/lib/tasks and it didn't work as rails loads lib/tasks before vendor/plugins/**/tasks. So I just had to copy load_rspec into lib.tasks. This could be done when bootstrapping rspec_on_rails. Also, perhaps the following is better, to avoid duplication of the path $: |= [File.expand_path(File.join(File.dirname(__FILE__), '../lib'))] ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10333&group_id=797 From dchelimsky at gmail.com Tue Apr 24 07:02:33 2007 From: dchelimsky at gmail.com (David Chelimsky) Date: Tue, 24 Apr 2007 07:02:33 -0400 Subject: [rspec-devel] Multiple formatters In-Reply-To: <8d961d900704240141v5c318aaet449db2ab1f83ac7a@mail.gmail.com> References: <8d961d900704240141v5c318aaet449db2ab1f83ac7a@mail.gmail.com> Message-ID: <57c63afe0704240402x4df1bcdaxa66deadc8e9b7fbe@mail.gmail.com> On 4/24/07, aslak hellesoy wrote: > Hi all, > > RSpec supports multiple formatters, but currently you can only use one > at a time. I really need to use several at the same time. > > I'd like to make RSpec handle several --format options. However, that > would require some rethinking of how/where output is written - it > can't all go to the same stream (file or stdout). > > So I'm thinking of making --format take a composite argument: > > --format html:/path/to/index.html --format rdoc:/path/to/index.rdoc > --format progress > > If nothing comes after the format, output is STDOUT, so this would be > backwards compatible. > > If we do this, we could also get rid of --failures - it would just be > a special formatter. > > WDYT? +1 > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From bkeepers at gmail.com Tue Apr 24 16:40:53 2007 From: bkeepers at gmail.com (Brandon Keepers) Date: Tue, 24 Apr 2007 16:40:53 -0400 Subject: [rspec-devel] discovering rails version In-Reply-To: <57c63afe0704212233h205f9e15y78e6ecb265f8fe49@mail.gmail.com> References: <57c63afe0704212233h205f9e15y78e6ecb265f8fe49@mail.gmail.com> Message-ID: On Apr 22, 2007, at 1:33 AM, David Chelimsky wrote: > Hi all, > > Edge rails has been using new template extensions (.erb instead of > .rhtml), which means that Spec::Rails' generators need to find out > what version of rails you are running so it can do the right thing. A > couple of weeks ago, Rails::VERSION::STRING was returning 1.2.0 in > edge. Ironically, rspec was able to use that information temporarily > to distinguish edge from the published versions, since 1.2.0 was > retracted when 1.2.1 was released. > > So I posted a request to rails trac () to change the version number to > something larger that 1.2.3 so the generator can ask if > Rails::VERSION::STRING <= 1.2.3 to decide what kind of template to > generate. > > As it turns out, a change to the version was committed in the last few > days. Unfortunately it was changed to 1.2.3, which means that the real > 1.2.3 AND edge (the imposter) are both identifying themselves as > 1.2.3, which means that Spec::Rails' generators can't know to do the > right thing for edge, which means that rspec:pre_commit fails against > edge unless you manually change railties/lib/rails/version.rb to say > 1.2.4. I've done this locally, but since we don't commit rails to > rspec's svn, if you're doing any work on rspec you'll have to make > this change locally to get pre_commit to pass edge rails. > > So I posted an additional plea (with a patch) to rails trac to make > the version 1.2.4, but I understand that the rails team is busy and > don't expect this to be fixed very quickly, if at all. > > So - any suggestions as to a different way of determining the rails > version? ActionView::Base.const_defined? ('DEFAULT_TEMPLATE_HANDLER_PREFERENCE') && ActionView::Base::DEFAULT_TEMPLATE_HANDLER_PREFERENCE.include? ('erb') DEFAULT_TEMPLATE_HANDLER_PREFERENCE was just added a couple weeks ago, so it won't help for people on an older version of edge, but it at least gives something to go off of. Brandon From dchelimsky at gmail.com Wed Apr 25 06:01:37 2007 From: dchelimsky at gmail.com (David Chelimsky) Date: Wed, 25 Apr 2007 06:01:37 -0400 Subject: [rspec-devel] discovering rails version In-Reply-To: References: <57c63afe0704212233h205f9e15y78e6ecb265f8fe49@mail.gmail.com> Message-ID: <57c63afe0704250301k119a9a70oe9bd0891b15c5408@mail.gmail.com> On 4/24/07, Brandon Keepers wrote: > > On Apr 22, 2007, at 1:33 AM, David Chelimsky wrote: > > > Hi all, > > > > Edge rails has been using new template extensions (.erb instead of > > .rhtml), which means that Spec::Rails' generators need to find out > > what version of rails you are running so it can do the right thing. A > > couple of weeks ago, Rails::VERSION::STRING was returning 1.2.0 in > > edge. Ironically, rspec was able to use that information temporarily > > to distinguish edge from the published versions, since 1.2.0 was > > retracted when 1.2.1 was released. > > > > So I posted a request to rails trac () to change the version number to > > something larger that 1.2.3 so the generator can ask if > > Rails::VERSION::STRING <= 1.2.3 to decide what kind of template to > > generate. > > > > As it turns out, a change to the version was committed in the last few > > days. Unfortunately it was changed to 1.2.3, which means that the real > > 1.2.3 AND edge (the imposter) are both identifying themselves as > > 1.2.3, which means that Spec::Rails' generators can't know to do the > > right thing for edge, which means that rspec:pre_commit fails against > > edge unless you manually change railties/lib/rails/version.rb to say > > 1.2.4. I've done this locally, but since we don't commit rails to > > rspec's svn, if you're doing any work on rspec you'll have to make > > this change locally to get pre_commit to pass edge rails. > > > > So I posted an additional plea (with a patch) to rails trac to make > > the version 1.2.4, but I understand that the rails team is busy and > > don't expect this to be fixed very quickly, if at all. > > > > So - any suggestions as to a different way of determining the rails > > version? > > > ActionView::Base.const_defined? > ('DEFAULT_TEMPLATE_HANDLER_PREFERENCE') && > ActionView::Base::DEFAULT_TEMPLATE_HANDLER_PREFERENCE.include? > ('erb') > > DEFAULT_TEMPLATE_HANDLER_PREFERENCE was just added a couple weeks > ago, so it won't help for people on an older version of edge, but it > at least gives something to go off of. Keeping up w/ edge is challenging enough - there's no way we're supporting multiple versions of edge!!!! Good idea - thanks. David > > > Brandon > > > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From nicksieger at gmail.com Wed Apr 25 13:45:31 2007 From: nicksieger at gmail.com (Nick Sieger) Date: Wed, 25 Apr 2007 12:45:31 -0500 Subject: [rspec-devel] RSpec and JRuby spec failures Message-ID: Hi, we've got RSpec running in our CI server, and there's a weird cycle of 5 tests that fail and then don't fail: http://jruby.thresher.com/build/viewBuildHistory!default.action?buildKey=RSPEC-V082 Potential JRuby bugs aside, anything peculiar in RSpec or the specs that might cause this to happen? If not, we're probably just not doing equality or hashing quite the same way as C Ruby or something like that. Cheers, /Nick P.S. Bonus points if anyone has suggestions (or patches even!) for fixing any of the RSpec failures in JRuby -- we'd love to get RSpec to 100%! From bkeepers at gmail.com Wed Apr 25 14:47:39 2007 From: bkeepers at gmail.com (Brandon Keepers) Date: Wed, 25 Apr 2007 14:47:39 -0400 Subject: [rspec-devel] discovering rails version In-Reply-To: <57c63afe0704250301k119a9a70oe9bd0891b15c5408@mail.gmail.com> References: <57c63afe0704212233h205f9e15y78e6ecb265f8fe49@mail.gmail.com> <57c63afe0704250301k119a9a70oe9bd0891b15c5408@mail.gmail.com> Message-ID: On Apr 25, 2007, at 6:01 AM, David Chelimsky wrote: >> ActionView::Base.const_defined? >> ('DEFAULT_TEMPLATE_HANDLER_PREFERENCE') && >> ActionView::Base::DEFAULT_TEMPLATE_HANDLER_PREFERENCE.include? >> ('erb') >> >> DEFAULT_TEMPLATE_HANDLER_PREFERENCE was just added a couple weeks >> ago, so it won't help for people on an older version of edge, but it >> at least gives something to go off of. > > Keeping up w/ edge is challenging enough - there's no way we're > supporting multiple versions of edge!!!! I think it would be safe to assume that anyone using edge rails and generating specs will be using the latest version of edge. If not, then they just wouldn't get generated .erb files. Brandon From noreply at rubyforge.org Wed Apr 25 17:08:22 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 25 Apr 2007 17:08:22 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-10367 ] Route Confusion with Controllers with the same name in different directories Message-ID: <20070425210822.50F2A52409B7@rubyforge.org> Bugs item #10367, was opened at 2007-04-25 14:08 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10367&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Brian Takita (btakita) Assigned to: Nobody (None) Summary: Route Confusion with Controllers with the same name in different directories Initial Comment: For example, we have two controllers: PatentApplicationController at app/controllers/patent_application and Admin::PatentApplicationController at app/controllers/admin/patent_application When we run the spec: class PatentApplicationController < ApplicationController def index end end class Admin::PatentApplicationController < ApplicationController def admin_section end end context "A Patent Application Controller" do controller_name "patent_application" end context "An Admin Patent Application Controller" do controller_name "admin/patent_application" specify "has an admin_section" do # This tries to route to the Non-admin PatentApplication controller get :admin_section end end ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10367&group_id=797 From aslak.hellesoy at gmail.com Wed Apr 25 17:09:42 2007 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Wed, 25 Apr 2007 23:09:42 +0200 Subject: [rspec-devel] RSpec and JRuby spec failures In-Reply-To: References: Message-ID: <8d961d900704251409v789dc256hd020140dcf7a48db@mail.gmail.com> I haven't run RSpec with JRuby in a few weeks, but last time I tried there were some failures, probably due to JRuby incompatibilities with MRI. Would it be possible for you to set up Bamboo to build RSpec trunk:HEAD against JRuby trunk:HEAD? This is where both teams will be most likely to hunt bugs I think. I'm on the road for a few days, but I'll try to look at this next week. Aslak On 4/25/07, Nick Sieger wrote: > Hi, we've got RSpec running in our CI server, and there's a weird > cycle of 5 tests that fail and then don't fail: > > http://jruby.thresher.com/build/viewBuildHistory!default.action?buildKey=RSPEC-V082 > > Potential JRuby bugs aside, anything peculiar in RSpec or the specs > that might cause this to happen? If not, we're probably just not > doing equality or hashing quite the same way as C Ruby or something > like that. > > Cheers, > /Nick > > P.S. Bonus points if anyone has suggestions (or patches even!) for > fixing any of the RSpec failures in JRuby -- we'd love to get RSpec to > 100%! > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From nicksieger at gmail.com Wed Apr 25 17:39:21 2007 From: nicksieger at gmail.com (Nick Sieger) Date: Wed, 25 Apr 2007 16:39:21 -0500 Subject: [rspec-devel] RSpec and JRuby spec failures In-Reply-To: <8d961d900704251409v789dc256hd020140dcf7a48db@mail.gmail.com> References: <8d961d900704251409v789dc256hd020140dcf7a48db@mail.gmail.com> Message-ID: On 4/25/07, aslak hellesoy wrote: > I haven't run RSpec with JRuby in a few weeks, but last time I tried > there were some failures, probably due to JRuby incompatibilities with > MRI. > > Would it be possible for you to set up Bamboo to build RSpec > trunk:HEAD against JRuby trunk:HEAD? This is where both teams will be > most likely to hunt bugs I think. Agreed, I'll try to get to this soon. One of the reasons I haven't is that my reporting gem wasn't working w/ 0.9 until David kindly added spec_started/example_started back into BaseTextFormatter, so I couldn't track individual specs. /Nick From dchelimsky at gmail.com Wed Apr 25 17:44:46 2007 From: dchelimsky at gmail.com (David Chelimsky) Date: Wed, 25 Apr 2007 17:44:46 -0400 Subject: [rspec-devel] RSpec and JRuby spec failures In-Reply-To: References: <8d961d900704251409v789dc256hd020140dcf7a48db@mail.gmail.com> Message-ID: <57c63afe0704251444t60cd04cdv347bacf56ddab518@mail.gmail.com> On 4/25/07, Nick Sieger wrote: > On 4/25/07, aslak hellesoy wrote: > > I haven't run RSpec with JRuby in a few weeks, but last time I tried > > there were some failures, probably due to JRuby incompatibilities with > > MRI. > > > > Would it be possible for you to set up Bamboo to build RSpec > > trunk:HEAD against JRuby trunk:HEAD? This is where both teams will be > > most likely to hunt bugs I think. > > Agreed, I'll try to get to this soon. One of the reasons I haven't is > that my reporting gem wasn't working w/ 0.9 until David kindly Happy to be of service! (sorry for removing it in the first place :( ) > added > spec_started/example_started back into BaseTextFormatter, so I > couldn't track individual specs. > > /Nick > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From noreply at rubyforge.org Wed Apr 25 17:51:11 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 25 Apr 2007 17:51:11 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-10367 ] Route Confusion with Controllers with the same name in different directories Message-ID: <20070425215111.7348E52409C0@rubyforge.org> Bugs item #10367, was opened at 2007-04-25 14:08 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10367&group_id=797 Category: None Group: None >Status: Closed Resolution: None Priority: 3 Submitted By: Brian Takita (btakita) Assigned to: Nobody (None) Summary: Route Confusion with Controllers with the same name in different directories Initial Comment: For example, we have two controllers: PatentApplicationController at app/controllers/patent_application and Admin::PatentApplicationController at app/controllers/admin/patent_application When we run the spec: class PatentApplicationController < ApplicationController def index end end class Admin::PatentApplicationController < ApplicationController def admin_section end end context "A Patent Application Controller" do controller_name "patent_application" end context "An Admin Patent Application Controller" do controller_name "admin/patent_application" specify "has an admin_section" do # This tries to route to the Non-admin PatentApplication controller get :admin_section end end ---------------------------------------------------------------------- >Comment By: Brian Takita (btakita) Date: 2007-04-25 14:51 Message: This is a Rails Routing bug. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10367&group_id=797 From dchelimsky at gmail.com Wed Apr 25 19:26:17 2007 From: dchelimsky at gmail.com (David Chelimsky) Date: Wed, 25 Apr 2007 19:26:17 -0400 Subject: [rspec-devel] discovering rails version In-Reply-To: References: <57c63afe0704212233h205f9e15y78e6ecb265f8fe49@mail.gmail.com> <57c63afe0704250301k119a9a70oe9bd0891b15c5408@mail.gmail.com> Message-ID: <57c63afe0704251626sd30a0e4s643ea8fc7d1303d4@mail.gmail.com> On 4/25/07, Brandon Keepers wrote: > > On Apr 25, 2007, at 6:01 AM, David Chelimsky wrote: > > >> ActionView::Base.const_defined? > >> ('DEFAULT_TEMPLATE_HANDLER_PREFERENCE') && > >> ActionView::Base::DEFAULT_TEMPLATE_HANDLER_PREFERENCE.include? > >> ('erb') > >> > >> DEFAULT_TEMPLATE_HANDLER_PREFERENCE was just added a couple weeks > >> ago, so it won't help for people on an older version of edge, but it > >> at least gives something to go off of. > > > > Keeping up w/ edge is challenging enough - there's no way we're > > supporting multiple versions of edge!!!! > > I think it would be safe to assume that anyone using edge rails and > generating specs will be using the latest version of edge. If not, > then they just wouldn't get generated .erb files. Good point. I've committed this to svn. Cheers, David > > Brandon > > > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From noreply at rubyforge.org Thu Apr 26 02:09:28 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 26 Apr 2007 02:09:28 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-10376 ] Shorter mock syntax Message-ID: <20070426060929.0A7FC5240AF2@rubyforge.org> Feature Requests item #10376, was opened at 2007-04-25 23:09 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10376&group_id=797 Category: mock module Group: None Status: Open Priority: 3 Submitted By: Brian Takita (btakita) Assigned to: Nobody (None) Summary: Shorter mock syntax Initial Comment: One complaint I have and I've heard about mocks is that they reduce readability of the specs. I propose providing an alias for shorter version of mocks. For example: the_mock.mocks.foo(1,2) {|a, b| :bar} the_mock.mocks.foo(1,2).returning(:bar) the_mock.mocks(:foo).with(1, 2) {|a, b| :bar} the_mock.mocks(:foo).with(1, 2).returns(:bar) the_mock.receives(:foo).with(1, 2) {|a, b| :bar} the_mock.receives(:foo).with(1, 2).returns(:bar) Compare any of the previous syntax's with the current syntax: the_mock.should_receive(:foo).with(1, 2).and_return {|a, b| :bar} the_mock.should_receive(:foo).with(1, 2).and_return(:bar) ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10376&group_id=797 From noreply at rubyforge.org Thu Apr 26 02:13:52 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 26 Apr 2007 02:13:52 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-10377 ] Mock Blocks Message-ID: <20070426061352.66E985240AD3@rubyforge.org> Feature Requests item #10377, was opened at 2007-04-25 23:13 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10377&group_id=797 Category: None Group: None Status: Open Priority: 3 Submitted By: Brian Takita (btakita) Assigned to: Nobody (None) Summary: Mock Blocks Initial Comment: Heres a syntax that would improve readability by using a Mock Block. mock('The new mock') do foo(1,2) {:bar} baz(3,4).returning(:foobar) end User.mocks do find('3').once {user} destroy(7) end There would be a learning curve with this, but a terser mock syntax would be easier to read once somebody 'understands' mocks. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10377&group_id=797 From noreply at rubyforge.org Thu Apr 26 02:41:46 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 26 Apr 2007 02:41:46 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-10376 ] Shorter mock syntax Message-ID: <20070426064147.06A3D5240B25@rubyforge.org> Feature Requests item #10376, was opened at 2007-04-25 23:09 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10376&group_id=797 Category: mock module Group: None Status: Open Priority: 3 Submitted By: Brian Takita (btakita) Assigned to: Nobody (None) Summary: Shorter mock syntax Initial Comment: One complaint I have and I've heard about mocks is that they reduce readability of the specs. I propose providing an alias for shorter version of mocks. For example: the_mock.mocks.foo(1,2) {|a, b| :bar} the_mock.mocks.foo(1,2).returning(:bar) the_mock.mocks(:foo).with(1, 2) {|a, b| :bar} the_mock.mocks(:foo).with(1, 2).returns(:bar) the_mock.receives(:foo).with(1, 2) {|a, b| :bar} the_mock.receives(:foo).with(1, 2).returns(:bar) Compare any of the previous syntax's with the current syntax: the_mock.should_receive(:foo).with(1, 2).and_return {|a, b| :bar} the_mock.should_receive(:foo).with(1, 2).and_return(:bar) ---------------------------------------------------------------------- >Comment By: Brian Takita (btakita) Date: 2007-04-25 23:41 Message: Actually I think mock! would be a nice complement to the stub! method. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10376&group_id=797 From noreply at rubyforge.org Thu Apr 26 02:43:52 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 26 Apr 2007 02:43:52 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-10376 ] Shorter mock syntax Message-ID: <20070426064352.51D8E5240B25@rubyforge.org> Feature Requests item #10376, was opened at 2007-04-25 23:09 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10376&group_id=797 Category: mock module Group: None Status: Open Priority: 3 Submitted By: Brian Takita (btakita) Assigned to: Nobody (None) Summary: Shorter mock syntax Initial Comment: One complaint I have and I've heard about mocks is that they reduce readability of the specs. I propose providing an alias for shorter version of mocks. For example: the_mock.mocks.foo(1,2) {|a, b| :bar} the_mock.mocks.foo(1,2).returning(:bar) the_mock.mocks(:foo).with(1, 2) {|a, b| :bar} the_mock.mocks(:foo).with(1, 2).returns(:bar) the_mock.receives(:foo).with(1, 2) {|a, b| :bar} the_mock.receives(:foo).with(1, 2).returns(:bar) Compare any of the previous syntax's with the current syntax: the_mock.should_receive(:foo).with(1, 2).and_return {|a, b| :bar} the_mock.should_receive(:foo).with(1, 2).and_return(:bar) ---------------------------------------------------------------------- >Comment By: Brian Takita (btakita) Date: 2007-04-25 23:43 Message: Or pluralize mocks! and stubs! the_mock.mocks!.foo(1,2) {|a,b| :bar} the_mock.stubs!.foo {:bar} ---------------------------------------------------------------------- Comment By: Brian Takita (btakita) Date: 2007-04-25 23:41 Message: Actually I think mock! would be a nice complement to the stub! method. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10376&group_id=797 From noreply at rubyforge.org Thu Apr 26 06:46:29 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 26 Apr 2007 06:46:29 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-10377 ] Mock Blocks Message-ID: <20070426104629.AA4B25240998@rubyforge.org> Feature Requests item #10377, was opened at 2007-04-26 06:13 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10377&group_id=797 Category: None Group: None Status: Open Priority: 3 Submitted By: Brian Takita (btakita) Assigned to: Nobody (None) Summary: Mock Blocks Initial Comment: Heres a syntax that would improve readability by using a Mock Block. mock('The new mock') do foo(1,2) {:bar} baz(3,4).returning(:foobar) end User.mocks do find('3').once {user} destroy(7) end There would be a learning curve with this, but a terser mock syntax would be easier to read once somebody 'understands' mocks. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-04-26 10:46 Message: "Heres a syntax that would improve readability..." "There would be a learning curve with this, but a terser mock syntax would be easier to read once somebody 'understands' mocks." To me, readability is about NOT requiring someone to 'understand'. I think what's there now is far more readable. It's just more verbose. Opinions aside, I'm not quite sure how this is supposed to work. Can you explain the intent of each line? I have a few guesses, but I'd your explanation. Thanks, David ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10377&group_id=797 From noreply at rubyforge.org Thu Apr 26 06:53:07 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 26 Apr 2007 06:53:07 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-10376 ] Shorter mock syntax Message-ID: <20070426105307.AE9AE5240AA4@rubyforge.org> Feature Requests item #10376, was opened at 2007-04-26 06:09 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10376&group_id=797 Category: mock module Group: None Status: Open Priority: 3 Submitted By: Brian Takita (btakita) Assigned to: Nobody (None) Summary: Shorter mock syntax Initial Comment: One complaint I have and I've heard about mocks is that they reduce readability of the specs. I propose providing an alias for shorter version of mocks. For example: the_mock.mocks.foo(1,2) {|a, b| :bar} the_mock.mocks.foo(1,2).returning(:bar) the_mock.mocks(:foo).with(1, 2) {|a, b| :bar} the_mock.mocks(:foo).with(1, 2).returns(:bar) the_mock.receives(:foo).with(1, 2) {|a, b| :bar} the_mock.receives(:foo).with(1, 2).returns(:bar) Compare any of the previous syntax's with the current syntax: the_mock.should_receive(:foo).with(1, 2).and_return {|a, b| :bar} the_mock.should_receive(:foo).with(1, 2).and_return(:bar) ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-04-26 10:53 Message: I think if we were going to do this, I'd rather align w/ existing frameworks to minimize mental mapping for those experienced w/ them. Currently, the two leading frameworks outside of rspec are mocha and flexmock. rspec and flexmock both use #should_receive and #and_returns. mocha uses #expects and #returns. If we were going to alias #should_receive and #and_returns I'd be more inclined to align the aliases w/ mocha - for the reason just explained AND the fact that I think that #expects tells a more accurate story than #mocks or #receives. All of that said, I'm not convinced that I want rspec's mocks to offer so many options. I think that more than one way to do the same thing can be just as confusing as it might be helpful. WDYT? ---------------------------------------------------------------------- Comment By: Brian Takita (btakita) Date: 2007-04-26 06:43 Message: Or pluralize mocks! and stubs! the_mock.mocks!.foo(1,2) {|a,b| :bar} the_mock.stubs!.foo {:bar} ---------------------------------------------------------------------- Comment By: Brian Takita (btakita) Date: 2007-04-26 06:41 Message: Actually I think mock! would be a nice complement to the stub! method. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10376&group_id=797 From noreply at rubyforge.org Thu Apr 26 12:54:09 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 26 Apr 2007 12:54:09 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-10377 ] Mock Blocks Message-ID: <20070426165409.DEF615240AC5@rubyforge.org> Feature Requests item #10377, was opened at 2007-04-25 23:13 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10377&group_id=797 Category: None Group: None Status: Open Priority: 3 Submitted By: Brian Takita (btakita) Assigned to: Nobody (None) Summary: Mock Blocks Initial Comment: Heres a syntax that would improve readability by using a Mock Block. mock('The new mock') do foo(1,2) {:bar} baz(3,4).returning(:foobar) end User.mocks do find('3').once {user} destroy(7) end There would be a learning curve with this, but a terser mock syntax would be easier to read once somebody 'understands' mocks. ---------------------------------------------------------------------- >Comment By: Brian Takita (btakita) Date: 2007-04-26 09:54 Message: "To me, readability is about NOT requiring someone to 'understand'. I think what's there now is far more readable. It's just more verbose." There comes a point when the language evolves to be more easier to read or say a more 'to the point' expression. For example, we commonly say AIDS, not Acquired Immune Deficiency Syndrome. Also the current mock syntax is not readable for somebody new to mocks. However once the person gets used to mocks and the syntax, then it is understandable. There is a cost and benefit between explicitness and brevity. Different people have different weights on each. The team I'm currently on, and I, have been leaning more toward brevity. For example, in our specification descriptions, we dropped 'should' because its redundant and our brains just parse it out anyways. Here is an explanation of the syntax: mock('The new mock') do # create the mock foo(1,2) {:bar} # equivalent to the_mock.should_receive(:foo).with(1,2).and_receive(:bar) baz(3,4).returns(:foobar) # the_mock.should_receive(:baz).with(3,4).and_return(:foobar) end User.expects do find('3').once {user} # User.should_receive(:find).with('3').once.and_return {user} destroy(7) # User.should_receive(:destroy).with(7) end ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-26 03:46 Message: "Heres a syntax that would improve readability..." "There would be a learning curve with this, but a terser mock syntax would be easier to read once somebody 'understands' mocks." To me, readability is about NOT requiring someone to 'understand'. I think what's there now is far more readable. It's just more verbose. Opinions aside, I'm not quite sure how this is supposed to work. Can you explain the intent of each line? I have a few guesses, but I'd your explanation. Thanks, David ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10377&group_id=797 From noreply at rubyforge.org Thu Apr 26 12:59:15 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 26 Apr 2007 12:59:15 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-10376 ] Shorter mock syntax Message-ID: <20070426165915.AF04B5240AC5@rubyforge.org> Feature Requests item #10376, was opened at 2007-04-25 23:09 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10376&group_id=797 Category: mock module Group: None Status: Open Priority: 3 Submitted By: Brian Takita (btakita) Assigned to: Nobody (None) Summary: Shorter mock syntax Initial Comment: One complaint I have and I've heard about mocks is that they reduce readability of the specs. I propose providing an alias for shorter version of mocks. For example: the_mock.mocks.foo(1,2) {|a, b| :bar} the_mock.mocks.foo(1,2).returning(:bar) the_mock.mocks(:foo).with(1, 2) {|a, b| :bar} the_mock.mocks(:foo).with(1, 2).returns(:bar) the_mock.receives(:foo).with(1, 2) {|a, b| :bar} the_mock.receives(:foo).with(1, 2).returns(:bar) Compare any of the previous syntax's with the current syntax: the_mock.should_receive(:foo).with(1, 2).and_return {|a, b| :bar} the_mock.should_receive(:foo).with(1, 2).and_return(:bar) ---------------------------------------------------------------------- >Comment By: Brian Takita (btakita) Date: 2007-04-26 09:59 Message: I've found that alot of people shy away from mocks, in part because of the verbosity (and readability) issues. The issue is there is alot of syntax to parse with the existing syntax. I'm not sure the 'with' method is necessary, or that it adds much syntactical value. expects as an alias of should_receive works well. the_mock.expects.foo(1,2) {|a, b| :bar} the_mock.expects.foo(1,2).returns(:bar) the_mock.should_receive(:foo).with(1,2).and_return {|a, b| :bar} the_mock.should_receive(:foo).with(1,2).and_return(:bar) What I like about the proposed syntax is the expected method, arguments, and return value are all very close to each other. When I look at the current syntax, I focus on ':foo', '1,2', and ':bar'. My brain wants to ignore the rest of the verbiage. Given the choice, I would choose the shorter syntax, as long as its not ambiguous. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-26 03:53 Message: I think if we were going to do this, I'd rather align w/ existing frameworks to minimize mental mapping for those experienced w/ them. Currently, the two leading frameworks outside of rspec are mocha and flexmock. rspec and flexmock both use #should_receive and #and_returns. mocha uses #expects and #returns. If we were going to alias #should_receive and #and_returns I'd be more inclined to align the aliases w/ mocha - for the reason just explained AND the fact that I think that #expects tells a more accurate story than #mocks or #receives. All of that said, I'm not convinced that I want rspec's mocks to offer so many options. I think that more than one way to do the same thing can be just as confusing as it might be helpful. WDYT? ---------------------------------------------------------------------- Comment By: Brian Takita (btakita) Date: 2007-04-25 23:43 Message: Or pluralize mocks! and stubs! the_mock.mocks!.foo(1,2) {|a,b| :bar} the_mock.stubs!.foo {:bar} ---------------------------------------------------------------------- Comment By: Brian Takita (btakita) Date: 2007-04-25 23:41 Message: Actually I think mock! would be a nice complement to the stub! method. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10376&group_id=797 From noreply at rubyforge.org Thu Apr 26 13:50:53 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 26 Apr 2007 13:50:53 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-10377 ] Mock Blocks Message-ID: <20070426175053.1649F5240AFC@rubyforge.org> Feature Requests item #10377, was opened at 2007-04-26 06:13 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10377&group_id=797 >Category: mock module Group: None >Status: Closed Priority: 3 Submitted By: Brian Takita (btakita) >Assigned to: David Chelimsky (dchelimsky) Summary: Mock Blocks Initial Comment: Heres a syntax that would improve readability by using a Mock Block. mock('The new mock') do foo(1,2) {:bar} baz(3,4).returning(:foobar) end User.mocks do find('3').once {user} destroy(7) end There would be a learning curve with this, but a terser mock syntax would be easier to read once somebody 'understands' mocks. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-04-26 17:50 Message: This is mostly what I expected, which is good in that perhaps the ideas express themselves. I like the ideas, but this would be a lot of work and is just not a priority for rspec, so I'm going to reject this request. If you really want to see this happen you should consider building and releasing it yourself. You'll be able to use it w/ rspec because rspec now (in trunk) supports plugging in any mocking framework for which you provide an adapter. I'll be blogging about how you do this - perhaps sooner than later so you can see (you can also just look at behaviour.rb and configuration.rb in the current trunk). I apologize if this seems dismissive. The ideas are good and I encourage you to explore them. Cheers, David ---------------------------------------------------------------------- Comment By: Brian Takita (btakita) Date: 2007-04-26 16:54 Message: "To me, readability is about NOT requiring someone to 'understand'. I think what's there now is far more readable. It's just more verbose." There comes a point when the language evolves to be more easier to read or say a more 'to the point' expression. For example, we commonly say AIDS, not Acquired Immune Deficiency Syndrome. Also the current mock syntax is not readable for somebody new to mocks. However once the person gets used to mocks and the syntax, then it is understandable. There is a cost and benefit between explicitness and brevity. Different people have different weights on each. The team I'm currently on, and I, have been leaning more toward brevity. For example, in our specification descriptions, we dropped 'should' because its redundant and our brains just parse it out anyways. Here is an explanation of the syntax: mock('The new mock') do # create the mock foo(1,2) {:bar} # equivalent to the_mock.should_receive(:foo).with(1,2).and_receive(:bar) baz(3,4).returns(:foobar) # the_mock.should_receive(:baz).with(3,4).and_return(:foobar) end User.expects do find('3').once {user} # User.should_receive(:find).with('3').once.and_return {user} destroy(7) # User.should_receive(:destroy).with(7) end ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-26 10:46 Message: "Heres a syntax that would improve readability..." "There would be a learning curve with this, but a terser mock syntax would be easier to read once somebody 'understands' mocks." To me, readability is about NOT requiring someone to 'understand'. I think what's there now is far more readable. It's just more verbose. Opinions aside, I'm not quite sure how this is supposed to work. Can you explain the intent of each line? I have a few guesses, but I'd your explanation. Thanks, David ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10377&group_id=797 From noreply at rubyforge.org Thu Apr 26 13:55:15 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 26 Apr 2007 13:55:15 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-10376 ] Shorter mock syntax Message-ID: <20070426175516.6214B5240AFC@rubyforge.org> Feature Requests item #10376, was opened at 2007-04-26 06:09 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10376&group_id=797 Category: mock module Group: None >Status: Closed Priority: 3 Submitted By: Brian Takita (btakita) >Assigned to: David Chelimsky (dchelimsky) Summary: Shorter mock syntax Initial Comment: One complaint I have and I've heard about mocks is that they reduce readability of the specs. I propose providing an alias for shorter version of mocks. For example: the_mock.mocks.foo(1,2) {|a, b| :bar} the_mock.mocks.foo(1,2).returning(:bar) the_mock.mocks(:foo).with(1, 2) {|a, b| :bar} the_mock.mocks(:foo).with(1, 2).returns(:bar) the_mock.receives(:foo).with(1, 2) {|a, b| :bar} the_mock.receives(:foo).with(1, 2).returns(:bar) Compare any of the previous syntax's with the current syntax: the_mock.should_receive(:foo).with(1, 2).and_return {|a, b| :bar} the_mock.should_receive(:foo).with(1, 2).and_return(:bar) ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-04-26 17:55 Message: I'm rejecting this one too, on the same grounds as http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10377&group_id=797. ---------------------------------------------------------------------- Comment By: Brian Takita (btakita) Date: 2007-04-26 16:59 Message: I've found that alot of people shy away from mocks, in part because of the verbosity (and readability) issues. The issue is there is alot of syntax to parse with the existing syntax. I'm not sure the 'with' method is necessary, or that it adds much syntactical value. expects as an alias of should_receive works well. the_mock.expects.foo(1,2) {|a, b| :bar} the_mock.expects.foo(1,2).returns(:bar) the_mock.should_receive(:foo).with(1,2).and_return {|a, b| :bar} the_mock.should_receive(:foo).with(1,2).and_return(:bar) What I like about the proposed syntax is the expected method, arguments, and return value are all very close to each other. When I look at the current syntax, I focus on ':foo', '1,2', and ':bar'. My brain wants to ignore the rest of the verbiage. Given the choice, I would choose the shorter syntax, as long as its not ambiguous. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-26 10:53 Message: I think if we were going to do this, I'd rather align w/ existing frameworks to minimize mental mapping for those experienced w/ them. Currently, the two leading frameworks outside of rspec are mocha and flexmock. rspec and flexmock both use #should_receive and #and_returns. mocha uses #expects and #returns. If we were going to alias #should_receive and #and_returns I'd be more inclined to align the aliases w/ mocha - for the reason just explained AND the fact that I think that #expects tells a more accurate story than #mocks or #receives. All of that said, I'm not convinced that I want rspec's mocks to offer so many options. I think that more than one way to do the same thing can be just as confusing as it might be helpful. WDYT? ---------------------------------------------------------------------- Comment By: Brian Takita (btakita) Date: 2007-04-26 06:43 Message: Or pluralize mocks! and stubs! the_mock.mocks!.foo(1,2) {|a,b| :bar} the_mock.stubs!.foo {:bar} ---------------------------------------------------------------------- Comment By: Brian Takita (btakita) Date: 2007-04-26 06:41 Message: Actually I think mock! would be a nice complement to the stub! method. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10376&group_id=797 From noreply at rubyforge.org Fri Apr 27 11:01:18 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 27 Apr 2007 11:01:18 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-10410 ] redirect_to does not behave consistently with regards to query string parameter ordering Message-ID: <20070427150118.79ECC5240B2A@rubyforge.org> Patches item #10410, was opened at 2007-04-27 11:01 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=10410&group_id=797 Category: expectation module Group: None Status: Open Resolution: None Priority: 3 Submitted By: nicholas evans (nick_evans) Assigned to: Nobody (None) Summary: redirect_to does not behave consistently with regards to query string parameter ordering Initial Comment: This bug is *incredibly* difficult to reproduce. It ends up causing a spec to pass when run as a single file and fail when run as a group of files... or vice versa. Or pass on one computer, but fail on another. Or pass in an old working copy, but fail when re-checked out. Or pass when running the normal rake task, but fail when generating an HTML support. And so on and so forth! As you might imagine this can make continuous integration rather annoying. The problem is that rails will place the items in a hash into the query string in a semi-random order. Given similar hashes, the same URL will *usually* be generated by each. But often enough to be annoying, that is not the case. This is simply due to the unordered nature of hashes. So I made a patch to redirect_to to do two things: 1) If your redirect_to expectation is a hash, and the actual redirection is within http://test.host it will convert the actual redirect_url to a hash, and also convert the expectation to a URL and then back into a hash (this takes care of when you leave :controller out of the expectation). 2) If your redirect_to expectation is a hash, then the failure message will report the failure back as hashes. The previous error (expected hash but got string) was always a bit confusing. If your redirect_to expectation is a string or :back, then you will continue to get the old behavior: a direct string comparison (which may or may not be tripped up by query string order). I created the patch against version 0.8.3, because that is what I'm using, but the redirect_to matcher does not appear to have changed much (at all?) in trunk, and the patch applied cleanly. Although all of the specs using redirect_to in my app still work, I was having difficulties getting "rake precommit" to run correctly... Sorry. :-( ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=10410&group_id=797 From noreply at rubyforge.org Fri Apr 27 11:02:52 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 27 Apr 2007 11:02:52 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-10410 ] redirect_to does not behave consistently with regards to query string parameter ordering Message-ID: <20070427150252.27BF45240B2A@rubyforge.org> Patches item #10410, was opened at 2007-04-27 11:01 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=10410&group_id=797 Category: expectation module Group: None Status: Open Resolution: None Priority: 3 Submitted By: nicholas evans (nick_evans) Assigned to: Nobody (None) Summary: redirect_to does not behave consistently with regards to query string parameter ordering Initial Comment: This bug is *incredibly* difficult to reproduce. It ends up causing a spec to pass when run as a single file and fail when run as a group of files... or vice versa. Or pass on one computer, but fail on another. Or pass in an old working copy, but fail when re-checked out. Or pass when running the normal rake task, but fail when generating an HTML support. And so on and so forth! As you might imagine this can make continuous integration rather annoying. The problem is that rails will place the items in a hash into the query string in a semi-random order. Given similar hashes, the same URL will *usually* be generated by each. But often enough to be annoying, that is not the case. This is simply due to the unordered nature of hashes. So I made a patch to redirect_to to do two things: 1) If your redirect_to expectation is a hash, and the actual redirection is within http://test.host it will convert the actual redirect_url to a hash, and also convert the expectation to a URL and then back into a hash (this takes care of when you leave :controller out of the expectation). 2) If your redirect_to expectation is a hash, then the failure message will report the failure back as hashes. The previous error (expected hash but got string) was always a bit confusing. If your redirect_to expectation is a string or :back, then you will continue to get the old behavior: a direct string comparison (which may or may not be tripped up by query string order). I created the patch against version 0.8.3, because that is what I'm using, but the redirect_to matcher does not appear to have changed much (at all?) in trunk, and the patch applied cleanly. Although all of the specs using redirect_to in my app still work, I was having difficulties getting "rake precommit" to run correctly... Sorry. :-( ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=10410&group_id=797 From noreply at rubyforge.org Fri Apr 27 11:25:25 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 27 Apr 2007 11:25:25 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-10410 ] redirect_to does not behave consistently with regards to query string parameter ordering Message-ID: <20070427152526.0B9675240B2A@rubyforge.org> Patches item #10410, was opened at 2007-04-27 15:01 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=10410&group_id=797 Category: expectation module Group: None Status: Open Resolution: None Priority: 3 Submitted By: nicholas evans (nick_evans) Assigned to: Nobody (None) Summary: redirect_to does not behave consistently with regards to query string parameter ordering Initial Comment: This bug is *incredibly* difficult to reproduce. It ends up causing a spec to pass when run as a single file and fail when run as a group of files... or vice versa. Or pass on one computer, but fail on another. Or pass in an old working copy, but fail when re-checked out. Or pass when running the normal rake task, but fail when generating an HTML support. And so on and so forth! As you might imagine this can make continuous integration rather annoying. The problem is that rails will place the items in a hash into the query string in a semi-random order. Given similar hashes, the same URL will *usually* be generated by each. But often enough to be annoying, that is not the case. This is simply due to the unordered nature of hashes. So I made a patch to redirect_to to do two things: 1) If your redirect_to expectation is a hash, and the actual redirection is within http://test.host it will convert the actual redirect_url to a hash, and also convert the expectation to a URL and then back into a hash (this takes care of when you leave :controller out of the expectation). 2) If your redirect_to expectation is a hash, then the failure message will report the failure back as hashes. The previous error (expected hash but got string) was always a bit confusing. If your redirect_to expectation is a string or :back, then you will continue to get the old behavior: a direct string comparison (which may or may not be tripped up by query string order). I created the patch against version 0.8.3, because that is what I'm using, but the redirect_to matcher does not appear to have changed much (at all?) in trunk, and the patch applied cleanly. Although all of the specs using redirect_to in my app still work, I was having difficulties getting "rake precommit" to run correctly... Sorry. :-( ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-04-27 15:25 Message: I tried to apply this and 18 of the 18 examples in redirect_to_spec.rb fail. Some are due to the changes you made to the failure messages - some for other reasons I haven't looked at yet. You said you were having trouble getting it to run - can you be more specific? Thanks, David ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=10410&group_id=797 From noreply at rubyforge.org Fri Apr 27 11:34:31 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 27 Apr 2007 11:34:31 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-10410 ] redirect_to does not behave consistently with regards to query string parameter ordering Message-ID: <20070427153431.3E10C5240B2A@rubyforge.org> Patches item #10410, was opened at 2007-04-27 15:01 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=10410&group_id=797 Category: expectation module Group: None Status: Open Resolution: None Priority: 3 Submitted By: nicholas evans (nick_evans) Assigned to: Nobody (None) Summary: redirect_to does not behave consistently with regards to query string parameter ordering Initial Comment: This bug is *incredibly* difficult to reproduce. It ends up causing a spec to pass when run as a single file and fail when run as a group of files... or vice versa. Or pass on one computer, but fail on another. Or pass in an old working copy, but fail when re-checked out. Or pass when running the normal rake task, but fail when generating an HTML support. And so on and so forth! As you might imagine this can make continuous integration rather annoying. The problem is that rails will place the items in a hash into the query string in a semi-random order. Given similar hashes, the same URL will *usually* be generated by each. But often enough to be annoying, that is not the case. This is simply due to the unordered nature of hashes. So I made a patch to redirect_to to do two things: 1) If your redirect_to expectation is a hash, and the actual redirection is within http://test.host it will convert the actual redirect_url to a hash, and also convert the expectation to a URL and then back into a hash (this takes care of when you leave :controller out of the expectation). 2) If your redirect_to expectation is a hash, then the failure message will report the failure back as hashes. The previous error (expected hash but got string) was always a bit confusing. If your redirect_to expectation is a string or :back, then you will continue to get the old behavior: a direct string comparison (which may or may not be tripped up by query string order). I created the patch against version 0.8.3, because that is what I'm using, but the redirect_to matcher does not appear to have changed much (at all?) in trunk, and the patch applied cleanly. Although all of the specs using redirect_to in my app still work, I was having difficulties getting "rake precommit" to run correctly... Sorry. :-( ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-04-27 15:34 Message: That was 18 of 38 examples. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-27 15:25 Message: I tried to apply this and 18 of the 18 examples in redirect_to_spec.rb fail. Some are due to the changes you made to the failure messages - some for other reasons I haven't looked at yet. You said you were having trouble getting it to run - can you be more specific? Thanks, David ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=10410&group_id=797 From noreply at rubyforge.org Fri Apr 27 12:24:32 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 27 Apr 2007 12:24:32 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-10410 ] redirect_to does not behave consistently with regards to query string parameter ordering Message-ID: <20070427162432.4F1925240B2A@rubyforge.org> Patches item #10410, was opened at 2007-04-27 11:01 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=10410&group_id=797 Category: expectation module Group: None Status: Open Resolution: None Priority: 3 Submitted By: nicholas evans (nick_evans) Assigned to: Nobody (None) Summary: redirect_to does not behave consistently with regards to query string parameter ordering Initial Comment: This bug is *incredibly* difficult to reproduce. It ends up causing a spec to pass when run as a single file and fail when run as a group of files... or vice versa. Or pass on one computer, but fail on another. Or pass in an old working copy, but fail when re-checked out. Or pass when running the normal rake task, but fail when generating an HTML support. And so on and so forth! As you might imagine this can make continuous integration rather annoying. The problem is that rails will place the items in a hash into the query string in a semi-random order. Given similar hashes, the same URL will *usually* be generated by each. But often enough to be annoying, that is not the case. This is simply due to the unordered nature of hashes. So I made a patch to redirect_to to do two things: 1) If your redirect_to expectation is a hash, and the actual redirection is within http://test.host it will convert the actual redirect_url to a hash, and also convert the expectation to a URL and then back into a hash (this takes care of when you leave :controller out of the expectation). 2) If your redirect_to expectation is a hash, then the failure message will report the failure back as hashes. The previous error (expected hash but got string) was always a bit confusing. If your redirect_to expectation is a string or :back, then you will continue to get the old behavior: a direct string comparison (which may or may not be tripped up by query string order). I created the patch against version 0.8.3, because that is what I'm using, but the redirect_to matcher does not appear to have changed much (at all?) in trunk, and the patch applied cleanly. Although all of the specs using redirect_to in my app still work, I was having difficulties getting "rake precommit" to run correctly... Sorry. :-( ---------------------------------------------------------------------- >Comment By: nicholas evans (nick_evans) Date: 2007-04-27 12:24 Message: More specific explanation of my rake precommit trouble: I was being lazy and didn't bother to debug the problem. It was complaining because config/database.yml was missing. I've looked into the example rails app, and there seems to be some rake tasks for creating a sample sqlite db, so I'll look into that now. Is there a particular magic sequence that could be issued to make it "just work" upon checkout? :-) ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-27 11:34 Message: That was 18 of 38 examples. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-27 11:25 Message: I tried to apply this and 18 of the 18 examples in redirect_to_spec.rb fail. Some are due to the changes you made to the failure messages - some for other reasons I haven't looked at yet. You said you were having trouble getting it to run - can you be more specific? Thanks, David ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=10410&group_id=797 From noreply at rubyforge.org Fri Apr 27 12:27:32 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 27 Apr 2007 12:27:32 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-10377 ] Mock Blocks Message-ID: <20070427162732.572AA5240B30@rubyforge.org> Feature Requests item #10377, was opened at 2007-04-25 23:13 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10377&group_id=797 Category: mock module Group: None Status: Closed Priority: 3 Submitted By: Brian Takita (btakita) Assigned to: David Chelimsky (dchelimsky) Summary: Mock Blocks Initial Comment: Heres a syntax that would improve readability by using a Mock Block. mock('The new mock') do foo(1,2) {:bar} baz(3,4).returning(:foobar) end User.mocks do find('3').once {user} destroy(7) end There would be a learning curve with this, but a terser mock syntax would be easier to read once somebody 'understands' mocks. ---------------------------------------------------------------------- >Comment By: Brian Takita (btakita) Date: 2007-04-27 09:27 Message: It looks like Mocha implements some similar ideas. I'll add a feature request to their project. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-26 10:50 Message: This is mostly what I expected, which is good in that perhaps the ideas express themselves. I like the ideas, but this would be a lot of work and is just not a priority for rspec, so I'm going to reject this request. If you really want to see this happen you should consider building and releasing it yourself. You'll be able to use it w/ rspec because rspec now (in trunk) supports plugging in any mocking framework for which you provide an adapter. I'll be blogging about how you do this - perhaps sooner than later so you can see (you can also just look at behaviour.rb and configuration.rb in the current trunk). I apologize if this seems dismissive. The ideas are good and I encourage you to explore them. Cheers, David ---------------------------------------------------------------------- Comment By: Brian Takita (btakita) Date: 2007-04-26 09:54 Message: "To me, readability is about NOT requiring someone to 'understand'. I think what's there now is far more readable. It's just more verbose." There comes a point when the language evolves to be more easier to read or say a more 'to the point' expression. For example, we commonly say AIDS, not Acquired Immune Deficiency Syndrome. Also the current mock syntax is not readable for somebody new to mocks. However once the person gets used to mocks and the syntax, then it is understandable. There is a cost and benefit between explicitness and brevity. Different people have different weights on each. The team I'm currently on, and I, have been leaning more toward brevity. For example, in our specification descriptions, we dropped 'should' because its redundant and our brains just parse it out anyways. Here is an explanation of the syntax: mock('The new mock') do # create the mock foo(1,2) {:bar} # equivalent to the_mock.should_receive(:foo).with(1,2).and_receive(:bar) baz(3,4).returns(:foobar) # the_mock.should_receive(:baz).with(3,4).and_return(:foobar) end User.expects do find('3').once {user} # User.should_receive(:find).with('3').once.and_return {user} destroy(7) # User.should_receive(:destroy).with(7) end ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-26 03:46 Message: "Heres a syntax that would improve readability..." "There would be a learning curve with this, but a terser mock syntax would be easier to read once somebody 'understands' mocks." To me, readability is about NOT requiring someone to 'understand'. I think what's there now is far more readable. It's just more verbose. Opinions aside, I'm not quite sure how this is supposed to work. Can you explain the intent of each line? I have a few guesses, but I'd your explanation. Thanks, David ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10377&group_id=797 From noreply at rubyforge.org Fri Apr 27 12:28:23 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 27 Apr 2007 12:28:23 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-10410 ] redirect_to does not behave consistently with regards to query string parameter ordering Message-ID: <20070427162823.90B5B5240B2A@rubyforge.org> Patches item #10410, was opened at 2007-04-27 11:01 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=10410&group_id=797 Category: expectation module Group: None Status: Open Resolution: None Priority: 3 Submitted By: nicholas evans (nick_evans) Assigned to: Nobody (None) Summary: redirect_to does not behave consistently with regards to query string parameter ordering Initial Comment: This bug is *incredibly* difficult to reproduce. It ends up causing a spec to pass when run as a single file and fail when run as a group of files... or vice versa. Or pass on one computer, but fail on another. Or pass in an old working copy, but fail when re-checked out. Or pass when running the normal rake task, but fail when generating an HTML support. And so on and so forth! As you might imagine this can make continuous integration rather annoying. The problem is that rails will place the items in a hash into the query string in a semi-random order. Given similar hashes, the same URL will *usually* be generated by each. But often enough to be annoying, that is not the case. This is simply due to the unordered nature of hashes. So I made a patch to redirect_to to do two things: 1) If your redirect_to expectation is a hash, and the actual redirection is within http://test.host it will convert the actual redirect_url to a hash, and also convert the expectation to a URL and then back into a hash (this takes care of when you leave :controller out of the expectation). 2) If your redirect_to expectation is a hash, then the failure message will report the failure back as hashes. The previous error (expected hash but got string) was always a bit confusing. If your redirect_to expectation is a string or :back, then you will continue to get the old behavior: a direct string comparison (which may or may not be tripped up by query string order). I created the patch against version 0.8.3, because that is what I'm using, but the redirect_to matcher does not appear to have changed much (at all?) in trunk, and the patch applied cleanly. Although all of the specs using redirect_to in my app still work, I was having difficulties getting "rake precommit" to run correctly... Sorry. :-( ---------------------------------------------------------------------- >Comment By: nicholas evans (nick_evans) Date: 2007-04-27 12:28 Message: I found "rake rspec:generate_sqlite_config", and I'm working on getting the precommit bugs fixed now. ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 12:24 Message: More specific explanation of my rake precommit trouble: I was being lazy and didn't bother to debug the problem. It was complaining because config/database.yml was missing. I've looked into the example rails app, and there seems to be some rake tasks for creating a sample sqlite db, so I'll look into that now. Is there a particular magic sequence that could be issued to make it "just work" upon checkout? :-) ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-27 11:34 Message: That was 18 of 38 examples. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-27 11:25 Message: I tried to apply this and 18 of the 18 examples in redirect_to_spec.rb fail. Some are due to the changes you made to the failure messages - some for other reasons I haven't looked at yet. You said you were having trouble getting it to run - can you be more specific? Thanks, David ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=10410&group_id=797 From noreply at rubyforge.org Fri Apr 27 12:50:11 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 27 Apr 2007 12:50:11 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-10410 ] redirect_to does not behave consistently with regards to query string parameter ordering Message-ID: <20070427165011.A02885240B12@rubyforge.org> Patches item #10410, was opened at 2007-04-27 11:01 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=10410&group_id=797 Category: expectation module Group: None Status: Open Resolution: None Priority: 3 Submitted By: nicholas evans (nick_evans) Assigned to: Nobody (None) Summary: redirect_to does not behave consistently with regards to query string parameter ordering Initial Comment: This bug is *incredibly* difficult to reproduce. It ends up causing a spec to pass when run as a single file and fail when run as a group of files... or vice versa. Or pass on one computer, but fail on another. Or pass in an old working copy, but fail when re-checked out. Or pass when running the normal rake task, but fail when generating an HTML support. And so on and so forth! As you might imagine this can make continuous integration rather annoying. The problem is that rails will place the items in a hash into the query string in a semi-random order. Given similar hashes, the same URL will *usually* be generated by each. But often enough to be annoying, that is not the case. This is simply due to the unordered nature of hashes. So I made a patch to redirect_to to do two things: 1) If your redirect_to expectation is a hash, and the actual redirection is within http://test.host it will convert the actual redirect_url to a hash, and also convert the expectation to a URL and then back into a hash (this takes care of when you leave :controller out of the expectation). 2) If your redirect_to expectation is a hash, then the failure message will report the failure back as hashes. The previous error (expected hash but got string) was always a bit confusing. If your redirect_to expectation is a string or :back, then you will continue to get the old behavior: a direct string comparison (which may or may not be tripped up by query string order). I created the patch against version 0.8.3, because that is what I'm using, but the redirect_to matcher does not appear to have changed much (at all?) in trunk, and the patch applied cleanly. Although all of the specs using redirect_to in my app still work, I was having difficulties getting "rake precommit" to run correctly... Sorry. :-( ---------------------------------------------------------------------- >Comment By: nicholas evans (nick_evans) Date: 2007-04-27 12:50 Message: Now I'm getting segfaults when I run rake pre_commit! running against rails 1.2.3: ** Invoke environment ** Execute db:schema:load ** Execute spec:plugins /home/nevans/src/rspec/example_rails_app/vendor/rails/1.2.3/activerecord/lib/../../activesupport/lib/active_support/core_ext/object/extending.rb:27: [BUG] Segmentation fault ruby 1.8.4 (2005-12-24) [i486-linux] Aborted (core dumped) rake aborted! Command ruby -I"/home/nevans/src/rspec/rspec/lib" "/home/nevans/src/rspec/rspec/bin/spec" "vendor/plugins/rspec_on_rails/spec/rails/extensions/active_record_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/dsl/assigns_hash_proxy_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/dsl/ivar_proxy_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/assert_select_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/redirect_to_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/render_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/description_generation_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/controller_isolation_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/view_spec_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/helper_spec_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/behaviour_factory_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/controller_spec_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/test_unit_assertion_accessibility_spec.rb" --options "/home/nevans/src/rspec/example_rails_app/config/../spec/spec.opts" failed /home/nevans/src/rspec/rspec/lib/spec/rake/spectask.rb:131:in `define' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:835:in `verbose' /home/nevans/src/rspec/rspec/lib/spec/rake/spectask.rb:105:in `define' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:399:in `execute' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:399:in `execute' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:369:in `invoke' /usr/lib/ruby/1.8/thread.rb:135:in `synchronize' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:362:in `invoke' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:1935:in `run' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:1935:in `run' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/bin/rake:7 /usr/bin/rake:16 I deleted rails 1.2.3 and ran against 1.2.2 (which is what my other apps are using), and dies in the same location: ** Invoke environment ** Execute db:schema:load ** Execute spec:plugins /home/nevans/src/rspec/rspec/lib/spec/dsl/behaviour_callbacks.rb:48: [BUG] Segmentation fault ruby 1.8.4 (2005-12-24) [i486-linux] Aborted (core dumped) rake aborted! Command ruby -I"/home/nevans/src/rspec/rspec/lib" "/home/nevans/src/rspec/rspec/bin/spec" "vendor/plugins/rspec_on_rails/spec/rails/extensions/active_record_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/dsl/assigns_hash_proxy_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/dsl/ivar_proxy_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/assert_select_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/redirect_to_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/render_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/description_generation_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/controller_isolation_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/view_spec_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/helper_spec_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/behaviour_factory_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/controller_spec_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/test_unit_assertion_accessibility_spec.rb" --options "/home/nevans/src/rspec/example_rails_app/config/../spec/spec.opts" failed /home/nevans/src/rspec/rspec/lib/spec/rake/spectask.rb:131:in `define' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:835:in `verbose' /home/nevans/src/rspec/rspec/lib/spec/rake/spectask.rb:105:in `define' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:399:in `execute' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:399:in `execute' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:369:in `invoke' /usr/lib/ruby/1.8/thread.rb:135:in `synchronize' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:362:in `invoke' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:1935:in `run' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:1935:in `run' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/bin/rake:7 /usr/bin/rake:16 I'm running the Ubuntu Edgy version of ruby, which dpkg reports as 1.8.2, but ruby -v reports as 1.8.4. ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 12:28 Message: I found "rake rspec:generate_sqlite_config", and I'm working on getting the precommit bugs fixed now. ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 12:24 Message: More specific explanation of my rake precommit trouble: I was being lazy and didn't bother to debug the problem. It was complaining because config/database.yml was missing. I've looked into the example rails app, and there seems to be some rake tasks for creating a sample sqlite db, so I'll look into that now. Is there a particular magic sequence that could be issued to make it "just work" upon checkout? :-) ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-27 11:34 Message: That was 18 of 38 examples. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-27 11:25 Message: I tried to apply this and 18 of the 18 examples in redirect_to_spec.rb fail. Some are due to the changes you made to the failure messages - some for other reasons I haven't looked at yet. You said you were having trouble getting it to run - can you be more specific? Thanks, David ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=10410&group_id=797 From noreply at rubyforge.org Fri Apr 27 15:36:30 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 27 Apr 2007 15:36:30 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-10410 ] redirect_to does not behave consistently with regards to query string parameter ordering Message-ID: <20070427193630.2CA8A5240B69@rubyforge.org> Patches item #10410, was opened at 2007-04-27 11:01 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=10410&group_id=797 Category: expectation module Group: None Status: Open Resolution: None Priority: 3 Submitted By: nicholas evans (nick_evans) Assigned to: Nobody (None) Summary: redirect_to does not behave consistently with regards to query string parameter ordering Initial Comment: This bug is *incredibly* difficult to reproduce. It ends up causing a spec to pass when run as a single file and fail when run as a group of files... or vice versa. Or pass on one computer, but fail on another. Or pass in an old working copy, but fail when re-checked out. Or pass when running the normal rake task, but fail when generating an HTML support. And so on and so forth! As you might imagine this can make continuous integration rather annoying. The problem is that rails will place the items in a hash into the query string in a semi-random order. Given similar hashes, the same URL will *usually* be generated by each. But often enough to be annoying, that is not the case. This is simply due to the unordered nature of hashes. So I made a patch to redirect_to to do two things: 1) If your redirect_to expectation is a hash, and the actual redirection is within http://test.host it will convert the actual redirect_url to a hash, and also convert the expectation to a URL and then back into a hash (this takes care of when you leave :controller out of the expectation). 2) If your redirect_to expectation is a hash, then the failure message will report the failure back as hashes. The previous error (expected hash but got string) was always a bit confusing. If your redirect_to expectation is a string or :back, then you will continue to get the old behavior: a direct string comparison (which may or may not be tripped up by query string order). I created the patch against version 0.8.3, because that is what I'm using, but the redirect_to matcher does not appear to have changed much (at all?) in trunk, and the patch applied cleanly. Although all of the specs using redirect_to in my app still work, I was having difficulties getting "rake precommit" to run correctly... Sorry. :-( ---------------------------------------------------------------------- >Comment By: nicholas evans (nick_evans) Date: 2007-04-27 15:36 Message: Well, I can't run all of the specs, and I don't really know why, but I can run the redirect_to_spec.rb. I'll fix the patch to pass all of the tests in there, and I'll add another couple of specs which should fail without my patch. ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 12:50 Message: Now I'm getting segfaults when I run rake pre_commit! running against rails 1.2.3: ** Invoke environment ** Execute db:schema:load ** Execute spec:plugins /home/nevans/src/rspec/example_rails_app/vendor/rails/1.2.3/activerecord/lib/../../activesupport/lib/active_support/core_ext/object/extending.rb:27: [BUG] Segmentation fault ruby 1.8.4 (2005-12-24) [i486-linux] Aborted (core dumped) rake aborted! Command ruby -I"/home/nevans/src/rspec/rspec/lib" "/home/nevans/src/rspec/rspec/bin/spec" "vendor/plugins/rspec_on_rails/spec/rails/extensions/active_record_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/dsl/assigns_hash_proxy_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/dsl/ivar_proxy_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/assert_select_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/redirect_to_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/render_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/description_generation_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/controller_isolation_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/view_spec_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/helper_spec_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/behaviour_factory_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/controller_spec_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/test_unit_assertion_accessibility_spec.rb" --options "/home/nevans/src/rspec/example_rails_app/config/../spec/spec.opts" failed /home/nevans/src/rspec/rspec/lib/spec/rake/spectask.rb:131:in `define' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:835:in `verbose' /home/nevans/src/rspec/rspec/lib/spec/rake/spectask.rb:105:in `define' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:399:in `execute' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:399:in `execute' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:369:in `invoke' /usr/lib/ruby/1.8/thread.rb:135:in `synchronize' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:362:in `invoke' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:1935:in `run' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:1935:in `run' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/bin/rake:7 /usr/bin/rake:16 I deleted rails 1.2.3 and ran against 1.2.2 (which is what my other apps are using), and dies in the same location: ** Invoke environment ** Execute db:schema:load ** Execute spec:plugins /home/nevans/src/rspec/rspec/lib/spec/dsl/behaviour_callbacks.rb:48: [BUG] Segmentation fault ruby 1.8.4 (2005-12-24) [i486-linux] Aborted (core dumped) rake aborted! Command ruby -I"/home/nevans/src/rspec/rspec/lib" "/home/nevans/src/rspec/rspec/bin/spec" "vendor/plugins/rspec_on_rails/spec/rails/extensions/active_record_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/dsl/assigns_hash_proxy_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/dsl/ivar_proxy_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/assert_select_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/redirect_to_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/render_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/description_generation_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/controller_isolation_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/view_spec_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/helper_spec_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/behaviour_factory_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/controller_spec_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/test_unit_assertion_accessibility_spec.rb" --options "/home/nevans/src/rspec/example_rails_app/config/../spec/spec.opts" failed /home/nevans/src/rspec/rspec/lib/spec/rake/spectask.rb:131:in `define' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:835:in `verbose' /home/nevans/src/rspec/rspec/lib/spec/rake/spectask.rb:105:in `define' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:399:in `execute' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:399:in `execute' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:369:in `invoke' /usr/lib/ruby/1.8/thread.rb:135:in `synchronize' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:362:in `invoke' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:1935:in `run' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:1935:in `run' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/bin/rake:7 /usr/bin/rake:16 I'm running the Ubuntu Edgy version of ruby, which dpkg reports as 1.8.2, but ruby -v reports as 1.8.4. ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 12:28 Message: I found "rake rspec:generate_sqlite_config", and I'm working on getting the precommit bugs fixed now. ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 12:24 Message: More specific explanation of my rake precommit trouble: I was being lazy and didn't bother to debug the problem. It was complaining because config/database.yml was missing. I've looked into the example rails app, and there seems to be some rake tasks for creating a sample sqlite db, so I'll look into that now. Is there a particular magic sequence that could be issued to make it "just work" upon checkout? :-) ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-27 11:34 Message: That was 18 of 38 examples. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-27 11:25 Message: I tried to apply this and 18 of the 18 examples in redirect_to_spec.rb fail. Some are due to the changes you made to the failure messages - some for other reasons I haven't looked at yet. You said you were having trouble getting it to run - can you be more specific? Thanks, David ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=10410&group_id=797 From noreply at rubyforge.org Fri Apr 27 15:59:05 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 27 Apr 2007 15:59:05 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-10410 ] redirect_to does not behave consistently with regards to query string parameter ordering Message-ID: <20070427195905.EE59D5240B61@rubyforge.org> Patches item #10410, was opened at 2007-04-27 15:01 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=10410&group_id=797 Category: expectation module Group: None Status: Open Resolution: None Priority: 3 Submitted By: nicholas evans (nick_evans) Assigned to: Nobody (None) Summary: redirect_to does not behave consistently with regards to query string parameter ordering Initial Comment: This bug is *incredibly* difficult to reproduce. It ends up causing a spec to pass when run as a single file and fail when run as a group of files... or vice versa. Or pass on one computer, but fail on another. Or pass in an old working copy, but fail when re-checked out. Or pass when running the normal rake task, but fail when generating an HTML support. And so on and so forth! As you might imagine this can make continuous integration rather annoying. The problem is that rails will place the items in a hash into the query string in a semi-random order. Given similar hashes, the same URL will *usually* be generated by each. But often enough to be annoying, that is not the case. This is simply due to the unordered nature of hashes. So I made a patch to redirect_to to do two things: 1) If your redirect_to expectation is a hash, and the actual redirection is within http://test.host it will convert the actual redirect_url to a hash, and also convert the expectation to a URL and then back into a hash (this takes care of when you leave :controller out of the expectation). 2) If your redirect_to expectation is a hash, then the failure message will report the failure back as hashes. The previous error (expected hash but got string) was always a bit confusing. If your redirect_to expectation is a string or :back, then you will continue to get the old behavior: a direct string comparison (which may or may not be tripped up by query string order). I created the patch against version 0.8.3, because that is what I'm using, but the redirect_to matcher does not appear to have changed much (at all?) in trunk, and the patch applied cleanly. Although all of the specs using redirect_to in my app still work, I was having difficulties getting "rake precommit" to run correctly... Sorry. :-( ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-04-27 19:59 Message: Thanks Nicholas - the pre-patch-failing specs would be especially great. Cheers, David ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 19:36 Message: Well, I can't run all of the specs, and I don't really know why, but I can run the redirect_to_spec.rb. I'll fix the patch to pass all of the tests in there, and I'll add another couple of specs which should fail without my patch. ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 16:50 Message: Now I'm getting segfaults when I run rake pre_commit! running against rails 1.2.3: ** Invoke environment ** Execute db:schema:load ** Execute spec:plugins /home/nevans/src/rspec/example_rails_app/vendor/rails/1.2.3/activerecord/lib/../../activesupport/lib/active_support/core_ext/object/extending.rb:27: [BUG] Segmentation fault ruby 1.8.4 (2005-12-24) [i486-linux] Aborted (core dumped) rake aborted! Command ruby -I"/home/nevans/src/rspec/rspec/lib" "/home/nevans/src/rspec/rspec/bin/spec" "vendor/plugins/rspec_on_rails/spec/rails/extensions/active_record_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/dsl/assigns_hash_proxy_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/dsl/ivar_proxy_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/assert_select_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/redirect_to_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/render_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/description_generation_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/controller_isolation_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/view_spec_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/helper_spec_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/behaviour_factory_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/controller_spec_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/test_unit_assertion_accessibility_spec.rb" --options "/home/nevans/src/rspec/example_rails_app/config/../spec/spec.opts" failed /home/nevans/src/rspec/rspec/lib/spec/rake/spectask.rb:131:in `define' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:835:in `verbose' /home/nevans/src/rspec/rspec/lib/spec/rake/spectask.rb:105:in `define' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:399:in `execute' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:399:in `execute' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:369:in `invoke' /usr/lib/ruby/1.8/thread.rb:135:in `synchronize' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:362:in `invoke' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:1935:in `run' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:1935:in `run' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/bin/rake:7 /usr/bin/rake:16 I deleted rails 1.2.3 and ran against 1.2.2 (which is what my other apps are using), and dies in the same location: ** Invoke environment ** Execute db:schema:load ** Execute spec:plugins /home/nevans/src/rspec/rspec/lib/spec/dsl/behaviour_callbacks.rb:48: [BUG] Segmentation fault ruby 1.8.4 (2005-12-24) [i486-linux] Aborted (core dumped) rake aborted! Command ruby -I"/home/nevans/src/rspec/rspec/lib" "/home/nevans/src/rspec/rspec/bin/spec" "vendor/plugins/rspec_on_rails/spec/rails/extensions/active_record_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/dsl/assigns_hash_proxy_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/dsl/ivar_proxy_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/assert_select_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/redirect_to_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/render_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/description_generation_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/controller_isolation_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/view_spec_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/helper_spec_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/behaviour_factory_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/controller_spec_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/test_unit_assertion_accessibility_spec.rb" --options "/home/nevans/src/rspec/example_rails_app/config/../spec/spec.opts" failed /home/nevans/src/rspec/rspec/lib/spec/rake/spectask.rb:131:in `define' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:835:in `verbose' /home/nevans/src/rspec/rspec/lib/spec/rake/spectask.rb:105:in `define' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:399:in `execute' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:399:in `execute' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:369:in `invoke' /usr/lib/ruby/1.8/thread.rb:135:in `synchronize' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:362:in `invoke' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:1935:in `run' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:1935:in `run' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/bin/rake:7 /usr/bin/rake:16 I'm running the Ubuntu Edgy version of ruby, which dpkg reports as 1.8.2, but ruby -v reports as 1.8.4. ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 16:28 Message: I found "rake rspec:generate_sqlite_config", and I'm working on getting the precommit bugs fixed now. ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 16:24 Message: More specific explanation of my rake precommit trouble: I was being lazy and didn't bother to debug the problem. It was complaining because config/database.yml was missing. I've looked into the example rails app, and there seems to be some rake tasks for creating a sample sqlite db, so I'll look into that now. Is there a particular magic sequence that could be issued to make it "just work" upon checkout? :-) ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-27 15:34 Message: That was 18 of 38 examples. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-27 15:25 Message: I tried to apply this and 18 of the 18 examples in redirect_to_spec.rb fail. Some are due to the changes you made to the failure messages - some for other reasons I haven't looked at yet. You said you were having trouble getting it to run - can you be more specific? Thanks, David ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=10410&group_id=797 From noreply at rubyforge.org Fri Apr 27 15:59:29 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 27 Apr 2007 15:59:29 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-10410 ] redirect_to does not behave consistently with regards to query string parameter ordering Message-ID: <20070427195929.AA7125240AC4@rubyforge.org> Patches item #10410, was opened at 2007-04-27 15:01 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=10410&group_id=797 Category: expectation module Group: None Status: Open Resolution: None Priority: 3 Submitted By: nicholas evans (nick_evans) Assigned to: Nobody (None) Summary: redirect_to does not behave consistently with regards to query string parameter ordering Initial Comment: This bug is *incredibly* difficult to reproduce. It ends up causing a spec to pass when run as a single file and fail when run as a group of files... or vice versa. Or pass on one computer, but fail on another. Or pass in an old working copy, but fail when re-checked out. Or pass when running the normal rake task, but fail when generating an HTML support. And so on and so forth! As you might imagine this can make continuous integration rather annoying. The problem is that rails will place the items in a hash into the query string in a semi-random order. Given similar hashes, the same URL will *usually* be generated by each. But often enough to be annoying, that is not the case. This is simply due to the unordered nature of hashes. So I made a patch to redirect_to to do two things: 1) If your redirect_to expectation is a hash, and the actual redirection is within http://test.host it will convert the actual redirect_url to a hash, and also convert the expectation to a URL and then back into a hash (this takes care of when you leave :controller out of the expectation). 2) If your redirect_to expectation is a hash, then the failure message will report the failure back as hashes. The previous error (expected hash but got string) was always a bit confusing. If your redirect_to expectation is a string or :back, then you will continue to get the old behavior: a direct string comparison (which may or may not be tripped up by query string order). I created the patch against version 0.8.3, because that is what I'm using, but the redirect_to matcher does not appear to have changed much (at all?) in trunk, and the patch applied cleanly. Although all of the specs using redirect_to in my app still work, I was having difficulties getting "rake precommit" to run correctly... Sorry. :-( ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-04-27 19:59 Message: re: seg faults - are you using sqlite? Which version? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-27 19:59 Message: Thanks Nicholas - the pre-patch-failing specs would be especially great. Cheers, David ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 19:36 Message: Well, I can't run all of the specs, and I don't really know why, but I can run the redirect_to_spec.rb. I'll fix the patch to pass all of the tests in there, and I'll add another couple of specs which should fail without my patch. ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 16:50 Message: Now I'm getting segfaults when I run rake pre_commit! running against rails 1.2.3: ** Invoke environment ** Execute db:schema:load ** Execute spec:plugins /home/nevans/src/rspec/example_rails_app/vendor/rails/1.2.3/activerecord/lib/../../activesupport/lib/active_support/core_ext/object/extending.rb:27: [BUG] Segmentation fault ruby 1.8.4 (2005-12-24) [i486-linux] Aborted (core dumped) rake aborted! Command ruby -I"/home/nevans/src/rspec/rspec/lib" "/home/nevans/src/rspec/rspec/bin/spec" "vendor/plugins/rspec_on_rails/spec/rails/extensions/active_record_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/dsl/assigns_hash_proxy_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/dsl/ivar_proxy_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/assert_select_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/redirect_to_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/render_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/description_generation_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/controller_isolation_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/view_spec_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/helper_spec_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/behaviour_factory_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/controller_spec_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/test_unit_assertion_accessibility_spec.rb" --options "/home/nevans/src/rspec/example_rails_app/config/../spec/spec.opts" failed /home/nevans/src/rspec/rspec/lib/spec/rake/spectask.rb:131:in `define' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:835:in `verbose' /home/nevans/src/rspec/rspec/lib/spec/rake/spectask.rb:105:in `define' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:399:in `execute' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:399:in `execute' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:369:in `invoke' /usr/lib/ruby/1.8/thread.rb:135:in `synchronize' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:362:in `invoke' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:1935:in `run' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:1935:in `run' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/bin/rake:7 /usr/bin/rake:16 I deleted rails 1.2.3 and ran against 1.2.2 (which is what my other apps are using), and dies in the same location: ** Invoke environment ** Execute db:schema:load ** Execute spec:plugins /home/nevans/src/rspec/rspec/lib/spec/dsl/behaviour_callbacks.rb:48: [BUG] Segmentation fault ruby 1.8.4 (2005-12-24) [i486-linux] Aborted (core dumped) rake aborted! Command ruby -I"/home/nevans/src/rspec/rspec/lib" "/home/nevans/src/rspec/rspec/bin/spec" "vendor/plugins/rspec_on_rails/spec/rails/extensions/active_record_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/dsl/assigns_hash_proxy_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/dsl/ivar_proxy_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/assert_select_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/redirect_to_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/render_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/description_generation_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/controller_isolation_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/view_spec_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/helper_spec_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/behaviour_factory_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/controller_spec_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/test_unit_assertion_accessibility_spec.rb" --options "/home/nevans/src/rspec/example_rails_app/config/../spec/spec.opts" failed /home/nevans/src/rspec/rspec/lib/spec/rake/spectask.rb:131:in `define' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:835:in `verbose' /home/nevans/src/rspec/rspec/lib/spec/rake/spectask.rb:105:in `define' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:399:in `execute' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:399:in `execute' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:369:in `invoke' /usr/lib/ruby/1.8/thread.rb:135:in `synchronize' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:362:in `invoke' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:1935:in `run' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:1935:in `run' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/bin/rake:7 /usr/bin/rake:16 I'm running the Ubuntu Edgy version of ruby, which dpkg reports as 1.8.2, but ruby -v reports as 1.8.4. ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 16:28 Message: I found "rake rspec:generate_sqlite_config", and I'm working on getting the precommit bugs fixed now. ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 16:24 Message: More specific explanation of my rake precommit trouble: I was being lazy and didn't bother to debug the problem. It was complaining because config/database.yml was missing. I've looked into the example rails app, and there seems to be some rake tasks for creating a sample sqlite db, so I'll look into that now. Is there a particular magic sequence that could be issued to make it "just work" upon checkout? :-) ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-27 15:34 Message: That was 18 of 38 examples. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-27 15:25 Message: I tried to apply this and 18 of the 18 examples in redirect_to_spec.rb fail. Some are due to the changes you made to the failure messages - some for other reasons I haven't looked at yet. You said you were having trouble getting it to run - can you be more specific? Thanks, David ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=10410&group_id=797 From noreply at rubyforge.org Fri Apr 27 18:09:33 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 27 Apr 2007 18:09:33 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-10410 ] redirect_to does not behave consistently with regards to query string parameter ordering Message-ID: <20070427220933.928205240B30@rubyforge.org> Patches item #10410, was opened at 2007-04-27 11:01 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=10410&group_id=797 Category: expectation module Group: None Status: Open Resolution: None Priority: 3 Submitted By: nicholas evans (nick_evans) Assigned to: Nobody (None) Summary: redirect_to does not behave consistently with regards to query string parameter ordering Initial Comment: This bug is *incredibly* difficult to reproduce. It ends up causing a spec to pass when run as a single file and fail when run as a group of files... or vice versa. Or pass on one computer, but fail on another. Or pass in an old working copy, but fail when re-checked out. Or pass when running the normal rake task, but fail when generating an HTML support. And so on and so forth! As you might imagine this can make continuous integration rather annoying. The problem is that rails will place the items in a hash into the query string in a semi-random order. Given similar hashes, the same URL will *usually* be generated by each. But often enough to be annoying, that is not the case. This is simply due to the unordered nature of hashes. So I made a patch to redirect_to to do two things: 1) If your redirect_to expectation is a hash, and the actual redirection is within http://test.host it will convert the actual redirect_url to a hash, and also convert the expectation to a URL and then back into a hash (this takes care of when you leave :controller out of the expectation). 2) If your redirect_to expectation is a hash, then the failure message will report the failure back as hashes. The previous error (expected hash but got string) was always a bit confusing. If your redirect_to expectation is a string or :back, then you will continue to get the old behavior: a direct string comparison (which may or may not be tripped up by query string order). I created the patch against version 0.8.3, because that is what I'm using, but the redirect_to matcher does not appear to have changed much (at all?) in trunk, and the patch applied cleanly. Although all of the specs using redirect_to in my app still work, I was having difficulties getting "rake precommit" to run correctly... Sorry. :-( ---------------------------------------------------------------------- >Comment By: nicholas evans (nick_evans) Date: 2007-04-27 18:09 Message: Yep. I'm using sqlite. It seemed like it should be simpler than mysql. :-) (our production environment is running on SQL Server, which is emphatically *not* simpler than running on mysql.) $ dpkg -l|grep 'libsqlite\|sqlite.*ruby'|awk '{print $3,$2}' 0.0.23-3 libdbd-sqlite3-ruby 0.0.23-3 libdbd-sqlite3-ruby1.8 3.3.5-0.2 libsqlite3-0 1.1.0-2 libsqlite3-ruby 1.1.0-2 libsqlite3-ruby1.8 ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-27 15:59 Message: re: seg faults - are you using sqlite? Which version? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-27 15:59 Message: Thanks Nicholas - the pre-patch-failing specs would be especially great. Cheers, David ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 15:36 Message: Well, I can't run all of the specs, and I don't really know why, but I can run the redirect_to_spec.rb. I'll fix the patch to pass all of the tests in there, and I'll add another couple of specs which should fail without my patch. ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 12:50 Message: Now I'm getting segfaults when I run rake pre_commit! running against rails 1.2.3: ** Invoke environment ** Execute db:schema:load ** Execute spec:plugins /home/nevans/src/rspec/example_rails_app/vendor/rails/1.2.3/activerecord/lib/../../activesupport/lib/active_support/core_ext/object/extending.rb:27: [BUG] Segmentation fault ruby 1.8.4 (2005-12-24) [i486-linux] Aborted (core dumped) rake aborted! Command ruby -I"/home/nevans/src/rspec/rspec/lib" "/home/nevans/src/rspec/rspec/bin/spec" "vendor/plugins/rspec_on_rails/spec/rails/extensions/active_record_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/dsl/assigns_hash_proxy_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/dsl/ivar_proxy_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/assert_select_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/redirect_to_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/render_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/description_generation_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/controller_isolation_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/view_spec_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/helper_spec_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/behaviour_factory_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/controller_spec_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/test_unit_assertion_accessibility_spec.rb" --options "/home/nevans/src/rspec/example_rails_app/config/../spec/spec.opts" failed /home/nevans/src/rspec/rspec/lib/spec/rake/spectask.rb:131:in `define' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:835:in `verbose' /home/nevans/src/rspec/rspec/lib/spec/rake/spectask.rb:105:in `define' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:399:in `execute' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:399:in `execute' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:369:in `invoke' /usr/lib/ruby/1.8/thread.rb:135:in `synchronize' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:362:in `invoke' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:1935:in `run' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:1935:in `run' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/bin/rake:7 /usr/bin/rake:16 I deleted rails 1.2.3 and ran against 1.2.2 (which is what my other apps are using), and dies in the same location: ** Invoke environment ** Execute db:schema:load ** Execute spec:plugins /home/nevans/src/rspec/rspec/lib/spec/dsl/behaviour_callbacks.rb:48: [BUG] Segmentation fault ruby 1.8.4 (2005-12-24) [i486-linux] Aborted (core dumped) rake aborted! Command ruby -I"/home/nevans/src/rspec/rspec/lib" "/home/nevans/src/rspec/rspec/bin/spec" "vendor/plugins/rspec_on_rails/spec/rails/extensions/active_record_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/dsl/assigns_hash_proxy_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/dsl/ivar_proxy_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/assert_select_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/redirect_to_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/render_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/description_generation_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/controller_isolation_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/view_spec_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/helper_spec_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/behaviour_factory_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/controller_spec_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/test_unit_assertion_accessibility_spec.rb" --options "/home/nevans/src/rspec/example_rails_app/config/../spec/spec.opts" failed /home/nevans/src/rspec/rspec/lib/spec/rake/spectask.rb:131:in `define' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:835:in `verbose' /home/nevans/src/rspec/rspec/lib/spec/rake/spectask.rb:105:in `define' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:399:in `execute' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:399:in `execute' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:369:in `invoke' /usr/lib/ruby/1.8/thread.rb:135:in `synchronize' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:362:in `invoke' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:1935:in `run' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:1935:in `run' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/bin/rake:7 /usr/bin/rake:16 I'm running the Ubuntu Edgy version of ruby, which dpkg reports as 1.8.2, but ruby -v reports as 1.8.4. ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 12:28 Message: I found "rake rspec:generate_sqlite_config", and I'm working on getting the precommit bugs fixed now. ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 12:24 Message: More specific explanation of my rake precommit trouble: I was being lazy and didn't bother to debug the problem. It was complaining because config/database.yml was missing. I've looked into the example rails app, and there seems to be some rake tasks for creating a sample sqlite db, so I'll look into that now. Is there a particular magic sequence that could be issued to make it "just work" upon checkout? :-) ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-27 11:34 Message: That was 18 of 38 examples. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-27 11:25 Message: I tried to apply this and 18 of the 18 examples in redirect_to_spec.rb fail. Some are due to the changes you made to the failure messages - some for other reasons I haven't looked at yet. You said you were having trouble getting it to run - can you be more specific? Thanks, David ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=10410&group_id=797 From noreply at rubyforge.org Fri Apr 27 18:14:03 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 27 Apr 2007 18:14:03 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-10410 ] redirect_to does not behave consistently with regards to query string parameter ordering Message-ID: <20070427221403.F25425240B61@rubyforge.org> Patches item #10410, was opened at 2007-04-27 11:01 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=10410&group_id=797 Category: expectation module Group: None Status: Open Resolution: None Priority: 3 Submitted By: nicholas evans (nick_evans) Assigned to: Nobody (None) Summary: redirect_to does not behave consistently with regards to query string parameter ordering Initial Comment: This bug is *incredibly* difficult to reproduce. It ends up causing a spec to pass when run as a single file and fail when run as a group of files... or vice versa. Or pass on one computer, but fail on another. Or pass in an old working copy, but fail when re-checked out. Or pass when running the normal rake task, but fail when generating an HTML support. And so on and so forth! As you might imagine this can make continuous integration rather annoying. The problem is that rails will place the items in a hash into the query string in a semi-random order. Given similar hashes, the same URL will *usually* be generated by each. But often enough to be annoying, that is not the case. This is simply due to the unordered nature of hashes. So I made a patch to redirect_to to do two things: 1) If your redirect_to expectation is a hash, and the actual redirection is within http://test.host it will convert the actual redirect_url to a hash, and also convert the expectation to a URL and then back into a hash (this takes care of when you leave :controller out of the expectation). 2) If your redirect_to expectation is a hash, then the failure message will report the failure back as hashes. The previous error (expected hash but got string) was always a bit confusing. If your redirect_to expectation is a string or :back, then you will continue to get the old behavior: a direct string comparison (which may or may not be tripped up by query string order). I created the patch against version 0.8.3, because that is what I'm using, but the redirect_to matcher does not appear to have changed much (at all?) in trunk, and the patch applied cleanly. Although all of the specs using redirect_to in my app still work, I was having difficulties getting "rake precommit" to run correctly... Sorry. :-( ---------------------------------------------------------------------- >Comment By: nicholas evans (nick_evans) Date: 2007-04-27 18:14 Message: A comment on the failing specs patch and how to reproduce the failures: the first spec will fail only very occasionally... like... say, only on the continuous integration server and not on your development laptop and only when you commit your last change for the day and need to get home. The second and third of the two specs are attempting to replicate the conditions that semi-randomly occur within the first spec. Thus, one and only one of them will always fail, but which one is dependent upon when a particular African butterfly has last flapped its wings. :-) ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 18:09 Message: Yep. I'm using sqlite. It seemed like it should be simpler than mysql. :-) (our production environment is running on SQL Server, which is emphatically *not* simpler than running on mysql.) $ dpkg -l|grep 'libsqlite\|sqlite.*ruby'|awk '{print $3,$2}' 0.0.23-3 libdbd-sqlite3-ruby 0.0.23-3 libdbd-sqlite3-ruby1.8 3.3.5-0.2 libsqlite3-0 1.1.0-2 libsqlite3-ruby 1.1.0-2 libsqlite3-ruby1.8 ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-27 15:59 Message: re: seg faults - are you using sqlite? Which version? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-27 15:59 Message: Thanks Nicholas - the pre-patch-failing specs would be especially great. Cheers, David ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 15:36 Message: Well, I can't run all of the specs, and I don't really know why, but I can run the redirect_to_spec.rb. I'll fix the patch to pass all of the tests in there, and I'll add another couple of specs which should fail without my patch. ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 12:50 Message: Now I'm getting segfaults when I run rake pre_commit! running against rails 1.2.3: ** Invoke environment ** Execute db:schema:load ** Execute spec:plugins /home/nevans/src/rspec/example_rails_app/vendor/rails/1.2.3/activerecord/lib/../../activesupport/lib/active_support/core_ext/object/extending.rb:27: [BUG] Segmentation fault ruby 1.8.4 (2005-12-24) [i486-linux] Aborted (core dumped) rake aborted! Command ruby -I"/home/nevans/src/rspec/rspec/lib" "/home/nevans/src/rspec/rspec/bin/spec" "vendor/plugins/rspec_on_rails/spec/rails/extensions/active_record_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/dsl/assigns_hash_proxy_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/dsl/ivar_proxy_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/assert_select_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/redirect_to_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/render_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/description_generation_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/controller_isolation_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/view_spec_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/helper_spec_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/behaviour_factory_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/controller_spec_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/test_unit_assertion_accessibility_spec.rb" --options "/home/nevans/src/rspec/example_rails_app/config/../spec/spec.opts" failed /home/nevans/src/rspec/rspec/lib/spec/rake/spectask.rb:131:in `define' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:835:in `verbose' /home/nevans/src/rspec/rspec/lib/spec/rake/spectask.rb:105:in `define' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:399:in `execute' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:399:in `execute' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:369:in `invoke' /usr/lib/ruby/1.8/thread.rb:135:in `synchronize' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:362:in `invoke' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:1935:in `run' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:1935:in `run' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/bin/rake:7 /usr/bin/rake:16 I deleted rails 1.2.3 and ran against 1.2.2 (which is what my other apps are using), and dies in the same location: ** Invoke environment ** Execute db:schema:load ** Execute spec:plugins /home/nevans/src/rspec/rspec/lib/spec/dsl/behaviour_callbacks.rb:48: [BUG] Segmentation fault ruby 1.8.4 (2005-12-24) [i486-linux] Aborted (core dumped) rake aborted! Command ruby -I"/home/nevans/src/rspec/rspec/lib" "/home/nevans/src/rspec/rspec/bin/spec" "vendor/plugins/rspec_on_rails/spec/rails/extensions/active_record_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/dsl/assigns_hash_proxy_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/dsl/ivar_proxy_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/assert_select_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/redirect_to_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/render_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/description_generation_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/controller_isolation_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/view_spec_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/helper_spec_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/behaviour_factory_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/controller_spec_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/test_unit_assertion_accessibility_spec.rb" --options "/home/nevans/src/rspec/example_rails_app/config/../spec/spec.opts" failed /home/nevans/src/rspec/rspec/lib/spec/rake/spectask.rb:131:in `define' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:835:in `verbose' /home/nevans/src/rspec/rspec/lib/spec/rake/spectask.rb:105:in `define' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:399:in `execute' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:399:in `execute' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:369:in `invoke' /usr/lib/ruby/1.8/thread.rb:135:in `synchronize' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:362:in `invoke' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:1935:in `run' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:1935:in `run' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/bin/rake:7 /usr/bin/rake:16 I'm running the Ubuntu Edgy version of ruby, which dpkg reports as 1.8.2, but ruby -v reports as 1.8.4. ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 12:28 Message: I found "rake rspec:generate_sqlite_config", and I'm working on getting the precommit bugs fixed now. ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 12:24 Message: More specific explanation of my rake precommit trouble: I was being lazy and didn't bother to debug the problem. It was complaining because config/database.yml was missing. I've looked into the example rails app, and there seems to be some rake tasks for creating a sample sqlite db, so I'll look into that now. Is there a particular magic sequence that could be issued to make it "just work" upon checkout? :-) ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-27 11:34 Message: That was 18 of 38 examples. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-27 11:25 Message: I tried to apply this and 18 of the 18 examples in redirect_to_spec.rb fail. Some are due to the changes you made to the failure messages - some for other reasons I haven't looked at yet. You said you were having trouble getting it to run - can you be more specific? Thanks, David ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=10410&group_id=797 From noreply at rubyforge.org Fri Apr 27 18:15:09 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 27 Apr 2007 18:15:09 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-10410 ] redirect_to does not behave consistently with regards to query string parameter ordering Message-ID: <20070427221509.EAA155240B30@rubyforge.org> Patches item #10410, was opened at 2007-04-27 11:01 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=10410&group_id=797 Category: expectation module Group: None Status: Open Resolution: None Priority: 3 Submitted By: nicholas evans (nick_evans) Assigned to: Nobody (None) Summary: redirect_to does not behave consistently with regards to query string parameter ordering Initial Comment: This bug is *incredibly* difficult to reproduce. It ends up causing a spec to pass when run as a single file and fail when run as a group of files... or vice versa. Or pass on one computer, but fail on another. Or pass in an old working copy, but fail when re-checked out. Or pass when running the normal rake task, but fail when generating an HTML support. And so on and so forth! As you might imagine this can make continuous integration rather annoying. The problem is that rails will place the items in a hash into the query string in a semi-random order. Given similar hashes, the same URL will *usually* be generated by each. But often enough to be annoying, that is not the case. This is simply due to the unordered nature of hashes. So I made a patch to redirect_to to do two things: 1) If your redirect_to expectation is a hash, and the actual redirection is within http://test.host it will convert the actual redirect_url to a hash, and also convert the expectation to a URL and then back into a hash (this takes care of when you leave :controller out of the expectation). 2) If your redirect_to expectation is a hash, then the failure message will report the failure back as hashes. The previous error (expected hash but got string) was always a bit confusing. If your redirect_to expectation is a string or :back, then you will continue to get the old behavior: a direct string comparison (which may or may not be tripped up by query string order). I created the patch against version 0.8.3, because that is what I'm using, but the redirect_to matcher does not appear to have changed much (at all?) in trunk, and the patch applied cleanly. Although all of the specs using redirect_to in my app still work, I was having difficulties getting "rake precommit" to run correctly... Sorry. :-( ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 18:14 Message: A comment on the failing specs patch and how to reproduce the failures: the first spec will fail only very occasionally... like... say, only on the continuous integration server and not on your development laptop and only when you commit your last change for the day and need to get home. The second and third of the two specs are attempting to replicate the conditions that semi-randomly occur within the first spec. Thus, one and only one of them will always fail, but which one is dependent upon when a particular African butterfly has last flapped its wings. :-) ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 18:09 Message: Yep. I'm using sqlite. It seemed like it should be simpler than mysql. :-) (our production environment is running on SQL Server, which is emphatically *not* simpler than running on mysql.) $ dpkg -l|grep 'libsqlite\|sqlite.*ruby'|awk '{print $3,$2}' 0.0.23-3 libdbd-sqlite3-ruby 0.0.23-3 libdbd-sqlite3-ruby1.8 3.3.5-0.2 libsqlite3-0 1.1.0-2 libsqlite3-ruby 1.1.0-2 libsqlite3-ruby1.8 ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-27 15:59 Message: re: seg faults - are you using sqlite? Which version? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-27 15:59 Message: Thanks Nicholas - the pre-patch-failing specs would be especially great. Cheers, David ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 15:36 Message: Well, I can't run all of the specs, and I don't really know why, but I can run the redirect_to_spec.rb. I'll fix the patch to pass all of the tests in there, and I'll add another couple of specs which should fail without my patch. ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 12:50 Message: Now I'm getting segfaults when I run rake pre_commit! running against rails 1.2.3: ** Invoke environment ** Execute db:schema:load ** Execute spec:plugins /home/nevans/src/rspec/example_rails_app/vendor/rails/1.2.3/activerecord/lib/../../activesupport/lib/active_support/core_ext/object/extending.rb:27: [BUG] Segmentation fault ruby 1.8.4 (2005-12-24) [i486-linux] Aborted (core dumped) rake aborted! Command ruby -I"/home/nevans/src/rspec/rspec/lib" "/home/nevans/src/rspec/rspec/bin/spec" "vendor/plugins/rspec_on_rails/spec/rails/extensions/active_record_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/dsl/assigns_hash_proxy_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/dsl/ivar_proxy_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/assert_select_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/redirect_to_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/render_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/description_generation_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/controller_isolation_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/view_spec_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/helper_spec_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/behaviour_factory_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/controller_spec_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/test_unit_assertion_accessibility_spec.rb" --options "/home/nevans/src/rspec/example_rails_app/config/../spec/spec.opts" failed /home/nevans/src/rspec/rspec/lib/spec/rake/spectask.rb:131:in `define' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:835:in `verbose' /home/nevans/src/rspec/rspec/lib/spec/rake/spectask.rb:105:in `define' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:399:in `execute' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:399:in `execute' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:369:in `invoke' /usr/lib/ruby/1.8/thread.rb:135:in `synchronize' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:362:in `invoke' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:1935:in `run' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:1935:in `run' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/bin/rake:7 /usr/bin/rake:16 I deleted rails 1.2.3 and ran against 1.2.2 (which is what my other apps are using), and dies in the same location: ** Invoke environment ** Execute db:schema:load ** Execute spec:plugins /home/nevans/src/rspec/rspec/lib/spec/dsl/behaviour_callbacks.rb:48: [BUG] Segmentation fault ruby 1.8.4 (2005-12-24) [i486-linux] Aborted (core dumped) rake aborted! Command ruby -I"/home/nevans/src/rspec/rspec/lib" "/home/nevans/src/rspec/rspec/bin/spec" "vendor/plugins/rspec_on_rails/spec/rails/extensions/active_record_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/dsl/assigns_hash_proxy_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/dsl/ivar_proxy_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/assert_select_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/redirect_to_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/render_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/description_generation_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/controller_isolation_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/view_spec_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/helper_spec_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/behaviour_factory_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/controller_spec_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/test_unit_assertion_accessibility_spec.rb" --options "/home/nevans/src/rspec/example_rails_app/config/../spec/spec.opts" failed /home/nevans/src/rspec/rspec/lib/spec/rake/spectask.rb:131:in `define' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:835:in `verbose' /home/nevans/src/rspec/rspec/lib/spec/rake/spectask.rb:105:in `define' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:399:in `execute' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:399:in `execute' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:369:in `invoke' /usr/lib/ruby/1.8/thread.rb:135:in `synchronize' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:362:in `invoke' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:1935:in `run' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:1935:in `run' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/bin/rake:7 /usr/bin/rake:16 I'm running the Ubuntu Edgy version of ruby, which dpkg reports as 1.8.2, but ruby -v reports as 1.8.4. ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 12:28 Message: I found "rake rspec:generate_sqlite_config", and I'm working on getting the precommit bugs fixed now. ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 12:24 Message: More specific explanation of my rake precommit trouble: I was being lazy and didn't bother to debug the problem. It was complaining because config/database.yml was missing. I've looked into the example rails app, and there seems to be some rake tasks for creating a sample sqlite db, so I'll look into that now. Is there a particular magic sequence that could be issued to make it "just work" upon checkout? :-) ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-27 11:34 Message: That was 18 of 38 examples. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-27 11:25 Message: I tried to apply this and 18 of the 18 examples in redirect_to_spec.rb fail. Some are due to the changes you made to the failure messages - some for other reasons I haven't looked at yet. You said you were having trouble getting it to run - can you be more specific? Thanks, David ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=10410&group_id=797 From noreply at rubyforge.org Fri Apr 27 18:15:43 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 27 Apr 2007 18:15:43 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-10410 ] redirect_to does not behave consistently with regards to query string parameter ordering Message-ID: <20070427221543.973625240B30@rubyforge.org> Patches item #10410, was opened at 2007-04-27 11:01 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=10410&group_id=797 Category: expectation module Group: None Status: Open Resolution: None Priority: 3 Submitted By: nicholas evans (nick_evans) Assigned to: Nobody (None) Summary: redirect_to does not behave consistently with regards to query string parameter ordering Initial Comment: This bug is *incredibly* difficult to reproduce. It ends up causing a spec to pass when run as a single file and fail when run as a group of files... or vice versa. Or pass on one computer, but fail on another. Or pass in an old working copy, but fail when re-checked out. Or pass when running the normal rake task, but fail when generating an HTML support. And so on and so forth! As you might imagine this can make continuous integration rather annoying. The problem is that rails will place the items in a hash into the query string in a semi-random order. Given similar hashes, the same URL will *usually* be generated by each. But often enough to be annoying, that is not the case. This is simply due to the unordered nature of hashes. So I made a patch to redirect_to to do two things: 1) If your redirect_to expectation is a hash, and the actual redirection is within http://test.host it will convert the actual redirect_url to a hash, and also convert the expectation to a URL and then back into a hash (this takes care of when you leave :controller out of the expectation). 2) If your redirect_to expectation is a hash, then the failure message will report the failure back as hashes. The previous error (expected hash but got string) was always a bit confusing. If your redirect_to expectation is a string or :back, then you will continue to get the old behavior: a direct string comparison (which may or may not be tripped up by query string order). I created the patch against version 0.8.3, because that is what I'm using, but the redirect_to matcher does not appear to have changed much (at all?) in trunk, and the patch applied cleanly. Although all of the specs using redirect_to in my app still work, I was having difficulties getting "rake precommit" to run correctly... Sorry. :-( ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 18:14 Message: A comment on the failing specs patch and how to reproduce the failures: the first spec will fail only very occasionally... like... say, only on the continuous integration server and not on your development laptop and only when you commit your last change for the day and need to get home. The second and third of the two specs are attempting to replicate the conditions that semi-randomly occur within the first spec. Thus, one and only one of them will always fail, but which one is dependent upon when a particular African butterfly has last flapped its wings. :-) ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 18:09 Message: Yep. I'm using sqlite. It seemed like it should be simpler than mysql. :-) (our production environment is running on SQL Server, which is emphatically *not* simpler than running on mysql.) $ dpkg -l|grep 'libsqlite\|sqlite.*ruby'|awk '{print $3,$2}' 0.0.23-3 libdbd-sqlite3-ruby 0.0.23-3 libdbd-sqlite3-ruby1.8 3.3.5-0.2 libsqlite3-0 1.1.0-2 libsqlite3-ruby 1.1.0-2 libsqlite3-ruby1.8 ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-27 15:59 Message: re: seg faults - are you using sqlite? Which version? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-27 15:59 Message: Thanks Nicholas - the pre-patch-failing specs would be especially great. Cheers, David ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 15:36 Message: Well, I can't run all of the specs, and I don't really know why, but I can run the redirect_to_spec.rb. I'll fix the patch to pass all of the tests in there, and I'll add another couple of specs which should fail without my patch. ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 12:50 Message: Now I'm getting segfaults when I run rake pre_commit! running against rails 1.2.3: ** Invoke environment ** Execute db:schema:load ** Execute spec:plugins /home/nevans/src/rspec/example_rails_app/vendor/rails/1.2.3/activerecord/lib/../../activesupport/lib/active_support/core_ext/object/extending.rb:27: [BUG] Segmentation fault ruby 1.8.4 (2005-12-24) [i486-linux] Aborted (core dumped) rake aborted! Command ruby -I"/home/nevans/src/rspec/rspec/lib" "/home/nevans/src/rspec/rspec/bin/spec" "vendor/plugins/rspec_on_rails/spec/rails/extensions/active_record_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/dsl/assigns_hash_proxy_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/dsl/ivar_proxy_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/assert_select_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/redirect_to_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/render_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/description_generation_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/controller_isolation_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/view_spec_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/helper_spec_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/behaviour_factory_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/controller_spec_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/test_unit_assertion_accessibility_spec.rb" --options "/home/nevans/src/rspec/example_rails_app/config/../spec/spec.opts" failed /home/nevans/src/rspec/rspec/lib/spec/rake/spectask.rb:131:in `define' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:835:in `verbose' /home/nevans/src/rspec/rspec/lib/spec/rake/spectask.rb:105:in `define' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:399:in `execute' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:399:in `execute' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:369:in `invoke' /usr/lib/ruby/1.8/thread.rb:135:in `synchronize' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:362:in `invoke' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:1935:in `run' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:1935:in `run' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/bin/rake:7 /usr/bin/rake:16 I deleted rails 1.2.3 and ran against 1.2.2 (which is what my other apps are using), and dies in the same location: ** Invoke environment ** Execute db:schema:load ** Execute spec:plugins /home/nevans/src/rspec/rspec/lib/spec/dsl/behaviour_callbacks.rb:48: [BUG] Segmentation fault ruby 1.8.4 (2005-12-24) [i486-linux] Aborted (core dumped) rake aborted! Command ruby -I"/home/nevans/src/rspec/rspec/lib" "/home/nevans/src/rspec/rspec/bin/spec" "vendor/plugins/rspec_on_rails/spec/rails/extensions/active_record_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/dsl/assigns_hash_proxy_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/dsl/ivar_proxy_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/assert_select_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/redirect_to_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/render_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/description_generation_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/controller_isolation_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/view_spec_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/helper_spec_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/behaviour_factory_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/controller_spec_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/test_unit_assertion_accessibility_spec.rb" --options "/home/nevans/src/rspec/example_rails_app/config/../spec/spec.opts" failed /home/nevans/src/rspec/rspec/lib/spec/rake/spectask.rb:131:in `define' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:835:in `verbose' /home/nevans/src/rspec/rspec/lib/spec/rake/spectask.rb:105:in `define' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:399:in `execute' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:399:in `execute' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:369:in `invoke' /usr/lib/ruby/1.8/thread.rb:135:in `synchronize' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:362:in `invoke' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:1935:in `run' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:1935:in `run' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/bin/rake:7 /usr/bin/rake:16 I'm running the Ubuntu Edgy version of ruby, which dpkg reports as 1.8.2, but ruby -v reports as 1.8.4. ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 12:28 Message: I found "rake rspec:generate_sqlite_config", and I'm working on getting the precommit bugs fixed now. ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 12:24 Message: More specific explanation of my rake precommit trouble: I was being lazy and didn't bother to debug the problem. It was complaining because config/database.yml was missing. I've looked into the example rails app, and there seems to be some rake tasks for creating a sample sqlite db, so I'll look into that now. Is there a particular magic sequence that could be issued to make it "just work" upon checkout? :-) ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-27 11:34 Message: That was 18 of 38 examples. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-27 11:25 Message: I tried to apply this and 18 of the 18 examples in redirect_to_spec.rb fail. Some are due to the changes you made to the failure messages - some for other reasons I haven't looked at yet. You said you were having trouble getting it to run - can you be more specific? Thanks, David ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=10410&group_id=797 From noreply at rubyforge.org Fri Apr 27 18:25:07 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 27 Apr 2007 18:25:07 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-10410 ] redirect_to does not behave consistently with regards to query string parameter ordering Message-ID: <20070427222507.811655240B30@rubyforge.org> Patches item #10410, was opened at 2007-04-27 11:01 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=10410&group_id=797 Category: expectation module Group: None Status: Open Resolution: None Priority: 3 Submitted By: nicholas evans (nick_evans) Assigned to: Nobody (None) Summary: redirect_to does not behave consistently with regards to query string parameter ordering Initial Comment: This bug is *incredibly* difficult to reproduce. It ends up causing a spec to pass when run as a single file and fail when run as a group of files... or vice versa. Or pass on one computer, but fail on another. Or pass in an old working copy, but fail when re-checked out. Or pass when running the normal rake task, but fail when generating an HTML support. And so on and so forth! As you might imagine this can make continuous integration rather annoying. The problem is that rails will place the items in a hash into the query string in a semi-random order. Given similar hashes, the same URL will *usually* be generated by each. But often enough to be annoying, that is not the case. This is simply due to the unordered nature of hashes. So I made a patch to redirect_to to do two things: 1) If your redirect_to expectation is a hash, and the actual redirection is within http://test.host it will convert the actual redirect_url to a hash, and also convert the expectation to a URL and then back into a hash (this takes care of when you leave :controller out of the expectation). 2) If your redirect_to expectation is a hash, then the failure message will report the failure back as hashes. The previous error (expected hash but got string) was always a bit confusing. If your redirect_to expectation is a string or :back, then you will continue to get the old behavior: a direct string comparison (which may or may not be tripped up by query string order). I created the patch against version 0.8.3, because that is what I'm using, but the redirect_to matcher does not appear to have changed much (at all?) in trunk, and the patch applied cleanly. Although all of the specs using redirect_to in my app still work, I was having difficulties getting "rake precommit" to run correctly... Sorry. :-( ---------------------------------------------------------------------- >Comment By: nicholas evans (nick_evans) Date: 2007-04-27 18:25 Message: Okay, I figured out what the problem is: Since I'm converting the URL string back into a hash containing the controller, action, etc, the URL must be routable within the application. However, url_for and ActionController::Routing::Routes.generate have no such restrictions. For example: >> ActionController::Routing::Routes.generate :controller => "foo", :action => "bar" => "/foo/bar" >> ActionController::Routing::Routes.recognize_path "/foo/bar" ActionController::RoutingError: no route found to match "/foo/bar" with {} from ./script/../config/../config/../vendor/rails/actionpack/lib/action_controller/routing.rb:1292:in `recognize_path' from (irb):66 from :0 It seems reasonable to me to adjust the behavior of "response.should redirect_to" so that it returns an error if the controller attempts to redirect to an non-routable URL when your spec is trying to match against it by using a hash. If you want to spec against a URL that lives outside of your application's ability to route, you should probably be spec'ing against the string, right? At least, that's my current thought on the matter. It might be seen as a major change in behavior for the redirect_to matcher. What do you think? So, the controllers that are stored in the rspec_on_rails plugin are not recognized by the example_rails_app's routing. If I move redirect_spec_controller.rb from the plugin into the example app (and remove the require from spec_helper.rb), that allows almost all of the specs to pass. The only specs that don't pass then are the two that redirect to :controller => "other", which is the same error. If I change those to redirect to :controller => "people", then their errors go away as well. ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 18:14 Message: A comment on the failing specs patch and how to reproduce the failures: the first spec will fail only very occasionally... like... say, only on the continuous integration server and not on your development laptop and only when you commit your last change for the day and need to get home. The second and third of the two specs are attempting to replicate the conditions that semi-randomly occur within the first spec. Thus, one and only one of them will always fail, but which one is dependent upon when a particular African butterfly has last flapped its wings. :-) ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 18:09 Message: Yep. I'm using sqlite. It seemed like it should be simpler than mysql. :-) (our production environment is running on SQL Server, which is emphatically *not* simpler than running on mysql.) $ dpkg -l|grep 'libsqlite\|sqlite.*ruby'|awk '{print $3,$2}' 0.0.23-3 libdbd-sqlite3-ruby 0.0.23-3 libdbd-sqlite3-ruby1.8 3.3.5-0.2 libsqlite3-0 1.1.0-2 libsqlite3-ruby 1.1.0-2 libsqlite3-ruby1.8 ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-27 15:59 Message: re: seg faults - are you using sqlite? Which version? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-27 15:59 Message: Thanks Nicholas - the pre-patch-failing specs would be especially great. Cheers, David ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 15:36 Message: Well, I can't run all of the specs, and I don't really know why, but I can run the redirect_to_spec.rb. I'll fix the patch to pass all of the tests in there, and I'll add another couple of specs which should fail without my patch. ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 12:50 Message: Now I'm getting segfaults when I run rake pre_commit! running against rails 1.2.3: ** Invoke environment ** Execute db:schema:load ** Execute spec:plugins /home/nevans/src/rspec/example_rails_app/vendor/rails/1.2.3/activerecord/lib/../../activesupport/lib/active_support/core_ext/object/extending.rb:27: [BUG] Segmentation fault ruby 1.8.4 (2005-12-24) [i486-linux] Aborted (core dumped) rake aborted! Command ruby -I"/home/nevans/src/rspec/rspec/lib" "/home/nevans/src/rspec/rspec/bin/spec" "vendor/plugins/rspec_on_rails/spec/rails/extensions/active_record_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/dsl/assigns_hash_proxy_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/dsl/ivar_proxy_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/assert_select_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/redirect_to_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/render_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/description_generation_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/controller_isolation_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/view_spec_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/helper_spec_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/behaviour_factory_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/controller_spec_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/test_unit_assertion_accessibility_spec.rb" --options "/home/nevans/src/rspec/example_rails_app/config/../spec/spec.opts" failed /home/nevans/src/rspec/rspec/lib/spec/rake/spectask.rb:131:in `define' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:835:in `verbose' /home/nevans/src/rspec/rspec/lib/spec/rake/spectask.rb:105:in `define' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:399:in `execute' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:399:in `execute' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:369:in `invoke' /usr/lib/ruby/1.8/thread.rb:135:in `synchronize' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:362:in `invoke' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:1935:in `run' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:1935:in `run' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/bin/rake:7 /usr/bin/rake:16 I deleted rails 1.2.3 and ran against 1.2.2 (which is what my other apps are using), and dies in the same location: ** Invoke environment ** Execute db:schema:load ** Execute spec:plugins /home/nevans/src/rspec/rspec/lib/spec/dsl/behaviour_callbacks.rb:48: [BUG] Segmentation fault ruby 1.8.4 (2005-12-24) [i486-linux] Aborted (core dumped) rake aborted! Command ruby -I"/home/nevans/src/rspec/rspec/lib" "/home/nevans/src/rspec/rspec/bin/spec" "vendor/plugins/rspec_on_rails/spec/rails/extensions/active_record_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/dsl/assigns_hash_proxy_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/dsl/ivar_proxy_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/assert_select_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/redirect_to_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/render_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/description_generation_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/controller_isolation_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/view_spec_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/helper_spec_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/behaviour_factory_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/controller_spec_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/test_unit_assertion_accessibility_spec.rb" --options "/home/nevans/src/rspec/example_rails_app/config/../spec/spec.opts" failed /home/nevans/src/rspec/rspec/lib/spec/rake/spectask.rb:131:in `define' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:835:in `verbose' /home/nevans/src/rspec/rspec/lib/spec/rake/spectask.rb:105:in `define' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:399:in `execute' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:399:in `execute' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:369:in `invoke' /usr/lib/ruby/1.8/thread.rb:135:in `synchronize' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:362:in `invoke' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:1935:in `run' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:1935:in `run' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/bin/rake:7 /usr/bin/rake:16 I'm running the Ubuntu Edgy version of ruby, which dpkg reports as 1.8.2, but ruby -v reports as 1.8.4. ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 12:28 Message: I found "rake rspec:generate_sqlite_config", and I'm working on getting the precommit bugs fixed now. ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 12:24 Message: More specific explanation of my rake precommit trouble: I was being lazy and didn't bother to debug the problem. It was complaining because config/database.yml was missing. I've looked into the example rails app, and there seems to be some rake tasks for creating a sample sqlite db, so I'll look into that now. Is there a particular magic sequence that could be issued to make it "just work" upon checkout? :-) ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-27 11:34 Message: That was 18 of 38 examples. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-27 11:25 Message: I tried to apply this and 18 of the 18 examples in redirect_to_spec.rb fail. Some are due to the changes you made to the failure messages - some for other reasons I haven't looked at yet. You said you were having trouble getting it to run - can you be more specific? Thanks, David ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=10410&group_id=797 From noreply at rubyforge.org Fri Apr 27 18:27:32 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 27 Apr 2007 18:27:32 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-10410 ] redirect_to does not behave consistently with regards to query string parameter ordering Message-ID: <20070427222732.4AF365240B4E@rubyforge.org> Patches item #10410, was opened at 2007-04-27 11:01 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=10410&group_id=797 Category: expectation module Group: None Status: Open Resolution: None Priority: 3 Submitted By: nicholas evans (nick_evans) Assigned to: Nobody (None) Summary: redirect_to does not behave consistently with regards to query string parameter ordering Initial Comment: This bug is *incredibly* difficult to reproduce. It ends up causing a spec to pass when run as a single file and fail when run as a group of files... or vice versa. Or pass on one computer, but fail on another. Or pass in an old working copy, but fail when re-checked out. Or pass when running the normal rake task, but fail when generating an HTML support. And so on and so forth! As you might imagine this can make continuous integration rather annoying. The problem is that rails will place the items in a hash into the query string in a semi-random order. Given similar hashes, the same URL will *usually* be generated by each. But often enough to be annoying, that is not the case. This is simply due to the unordered nature of hashes. So I made a patch to redirect_to to do two things: 1) If your redirect_to expectation is a hash, and the actual redirection is within http://test.host it will convert the actual redirect_url to a hash, and also convert the expectation to a URL and then back into a hash (this takes care of when you leave :controller out of the expectation). 2) If your redirect_to expectation is a hash, then the failure message will report the failure back as hashes. The previous error (expected hash but got string) was always a bit confusing. If your redirect_to expectation is a string or :back, then you will continue to get the old behavior: a direct string comparison (which may or may not be tripped up by query string order). I created the patch against version 0.8.3, because that is what I'm using, but the redirect_to matcher does not appear to have changed much (at all?) in trunk, and the patch applied cleanly. Although all of the specs using redirect_to in my app still work, I was having difficulties getting "rake precommit" to run correctly... Sorry. :-( ---------------------------------------------------------------------- >Comment By: nicholas evans (nick_evans) Date: 2007-04-27 18:27 Message: Two comments on the passing specs patch: 1) because "svn mv" doesn't translate well into the diff format, you'll want to apply it with the following three commands: svn cp rspec_on_rails/spec_resources/controllers/redirect_spec_controller.rb example_rails_app/app/controllers/redirect_spec_controller.rb patch -p0 < passes_specs.patch svn rm rspec_on_rails/spec_resources/controllers/redirect_spec_controller.rb --force 2) I haven't yet added the specs for the additional failure behavior (I actually reverted the failure message behavior that I originally added, and then added some new behavior for the new error type), but I'll get to that momentarily (with another patch). ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 18:25 Message: Okay, I figured out what the problem is: Since I'm converting the URL string back into a hash containing the controller, action, etc, the URL must be routable within the application. However, url_for and ActionController::Routing::Routes.generate have no such restrictions. For example: >> ActionController::Routing::Routes.generate :controller => "foo", :action => "bar" => "/foo/bar" >> ActionController::Routing::Routes.recognize_path "/foo/bar" ActionController::RoutingError: no route found to match "/foo/bar" with {} from ./script/../config/../config/../vendor/rails/actionpack/lib/action_controller/routing.rb:1292:in `recognize_path' from (irb):66 from :0 It seems reasonable to me to adjust the behavior of "response.should redirect_to" so that it returns an error if the controller attempts to redirect to an non-routable URL when your spec is trying to match against it by using a hash. If you want to spec against a URL that lives outside of your application's ability to route, you should probably be spec'ing against the string, right? At least, that's my current thought on the matter. It might be seen as a major change in behavior for the redirect_to matcher. What do you think? So, the controllers that are stored in the rspec_on_rails plugin are not recognized by the example_rails_app's routing. If I move redirect_spec_controller.rb from the plugin into the example app (and remove the require from spec_helper.rb), that allows almost all of the specs to pass. The only specs that don't pass then are the two that redirect to :controller => "other", which is the same error. If I change those to redirect to :controller => "people", then their errors go away as well. ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 18:14 Message: A comment on the failing specs patch and how to reproduce the failures: the first spec will fail only very occasionally... like... say, only on the continuous integration server and not on your development laptop and only when you commit your last change for the day and need to get home. The second and third of the two specs are attempting to replicate the conditions that semi-randomly occur within the first spec. Thus, one and only one of them will always fail, but which one is dependent upon when a particular African butterfly has last flapped its wings. :-) ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 18:09 Message: Yep. I'm using sqlite. It seemed like it should be simpler than mysql. :-) (our production environment is running on SQL Server, which is emphatically *not* simpler than running on mysql.) $ dpkg -l|grep 'libsqlite\|sqlite.*ruby'|awk '{print $3,$2}' 0.0.23-3 libdbd-sqlite3-ruby 0.0.23-3 libdbd-sqlite3-ruby1.8 3.3.5-0.2 libsqlite3-0 1.1.0-2 libsqlite3-ruby 1.1.0-2 libsqlite3-ruby1.8 ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-27 15:59 Message: re: seg faults - are you using sqlite? Which version? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-27 15:59 Message: Thanks Nicholas - the pre-patch-failing specs would be especially great. Cheers, David ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 15:36 Message: Well, I can't run all of the specs, and I don't really know why, but I can run the redirect_to_spec.rb. I'll fix the patch to pass all of the tests in there, and I'll add another couple of specs which should fail without my patch. ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 12:50 Message: Now I'm getting segfaults when I run rake pre_commit! running against rails 1.2.3: ** Invoke environment ** Execute db:schema:load ** Execute spec:plugins /home/nevans/src/rspec/example_rails_app/vendor/rails/1.2.3/activerecord/lib/../../activesupport/lib/active_support/core_ext/object/extending.rb:27: [BUG] Segmentation fault ruby 1.8.4 (2005-12-24) [i486-linux] Aborted (core dumped) rake aborted! Command ruby -I"/home/nevans/src/rspec/rspec/lib" "/home/nevans/src/rspec/rspec/bin/spec" "vendor/plugins/rspec_on_rails/spec/rails/extensions/active_record_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/dsl/assigns_hash_proxy_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/dsl/ivar_proxy_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/assert_select_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/redirect_to_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/render_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/description_generation_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/controller_isolation_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/view_spec_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/helper_spec_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/behaviour_factory_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/controller_spec_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/test_unit_assertion_accessibility_spec.rb" --options "/home/nevans/src/rspec/example_rails_app/config/../spec/spec.opts" failed /home/nevans/src/rspec/rspec/lib/spec/rake/spectask.rb:131:in `define' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:835:in `verbose' /home/nevans/src/rspec/rspec/lib/spec/rake/spectask.rb:105:in `define' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:399:in `execute' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:399:in `execute' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:369:in `invoke' /usr/lib/ruby/1.8/thread.rb:135:in `synchronize' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:362:in `invoke' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:1935:in `run' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:1935:in `run' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/bin/rake:7 /usr/bin/rake:16 I deleted rails 1.2.3 and ran against 1.2.2 (which is what my other apps are using), and dies in the same location: ** Invoke environment ** Execute db:schema:load ** Execute spec:plugins /home/nevans/src/rspec/rspec/lib/spec/dsl/behaviour_callbacks.rb:48: [BUG] Segmentation fault ruby 1.8.4 (2005-12-24) [i486-linux] Aborted (core dumped) rake aborted! Command ruby -I"/home/nevans/src/rspec/rspec/lib" "/home/nevans/src/rspec/rspec/bin/spec" "vendor/plugins/rspec_on_rails/spec/rails/extensions/active_record_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/dsl/assigns_hash_proxy_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/dsl/ivar_proxy_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/assert_select_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/redirect_to_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/render_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/description_generation_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/controller_isolation_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/view_spec_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/helper_spec_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/behaviour_factory_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/controller_spec_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/test_unit_assertion_accessibility_spec.rb" --options "/home/nevans/src/rspec/example_rails_app/config/../spec/spec.opts" failed /home/nevans/src/rspec/rspec/lib/spec/rake/spectask.rb:131:in `define' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:835:in `verbose' /home/nevans/src/rspec/rspec/lib/spec/rake/spectask.rb:105:in `define' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:399:in `execute' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:399:in `execute' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:369:in `invoke' /usr/lib/ruby/1.8/thread.rb:135:in `synchronize' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:362:in `invoke' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:1935:in `run' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:1935:in `run' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/bin/rake:7 /usr/bin/rake:16 I'm running the Ubuntu Edgy version of ruby, which dpkg reports as 1.8.2, but ruby -v reports as 1.8.4. ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 12:28 Message: I found "rake rspec:generate_sqlite_config", and I'm working on getting the precommit bugs fixed now. ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 12:24 Message: More specific explanation of my rake precommit trouble: I was being lazy and didn't bother to debug the problem. It was complaining because config/database.yml was missing. I've looked into the example rails app, and there seems to be some rake tasks for creating a sample sqlite db, so I'll look into that now. Is there a particular magic sequence that could be issued to make it "just work" upon checkout? :-) ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-27 11:34 Message: That was 18 of 38 examples. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-27 11:25 Message: I tried to apply this and 18 of the 18 examples in redirect_to_spec.rb fail. Some are due to the changes you made to the failure messages - some for other reasons I haven't looked at yet. You said you were having trouble getting it to run - can you be more specific? Thanks, David ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=10410&group_id=797 From noreply at rubyforge.org Fri Apr 27 18:29:08 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 27 Apr 2007 18:29:08 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-10410 ] redirect_to does not behave consistently with regards to query string parameter ordering Message-ID: <20070427222908.4AC335240B61@rubyforge.org> Patches item #10410, was opened at 2007-04-27 11:01 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=10410&group_id=797 Category: expectation module Group: None Status: Open Resolution: None Priority: 3 Submitted By: nicholas evans (nick_evans) Assigned to: Nobody (None) Summary: redirect_to does not behave consistently with regards to query string parameter ordering Initial Comment: This bug is *incredibly* difficult to reproduce. It ends up causing a spec to pass when run as a single file and fail when run as a group of files... or vice versa. Or pass on one computer, but fail on another. Or pass in an old working copy, but fail when re-checked out. Or pass when running the normal rake task, but fail when generating an HTML support. And so on and so forth! As you might imagine this can make continuous integration rather annoying. The problem is that rails will place the items in a hash into the query string in a semi-random order. Given similar hashes, the same URL will *usually* be generated by each. But often enough to be annoying, that is not the case. This is simply due to the unordered nature of hashes. So I made a patch to redirect_to to do two things: 1) If your redirect_to expectation is a hash, and the actual redirection is within http://test.host it will convert the actual redirect_url to a hash, and also convert the expectation to a URL and then back into a hash (this takes care of when you leave :controller out of the expectation). 2) If your redirect_to expectation is a hash, then the failure message will report the failure back as hashes. The previous error (expected hash but got string) was always a bit confusing. If your redirect_to expectation is a string or :back, then you will continue to get the old behavior: a direct string comparison (which may or may not be tripped up by query string order). I created the patch against version 0.8.3, because that is what I'm using, but the redirect_to matcher does not appear to have changed much (at all?) in trunk, and the patch applied cleanly. Although all of the specs using redirect_to in my app still work, I was having difficulties getting "rake precommit" to run correctly... Sorry. :-( ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 18:27 Message: Two comments on the passing specs patch: 1) because "svn mv" doesn't translate well into the diff format, you'll want to apply it with the following three commands: svn cp rspec_on_rails/spec_resources/controllers/redirect_spec_controller.rb example_rails_app/app/controllers/redirect_spec_controller.rb patch -p0 < passes_specs.patch svn rm rspec_on_rails/spec_resources/controllers/redirect_spec_controller.rb --force 2) I haven't yet added the specs for the additional failure behavior (I actually reverted the failure message behavior that I originally added, and then added some new behavior for the new error type), but I'll get to that momentarily (with another patch). ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 18:25 Message: Okay, I figured out what the problem is: Since I'm converting the URL string back into a hash containing the controller, action, etc, the URL must be routable within the application. However, url_for and ActionController::Routing::Routes.generate have no such restrictions. For example: >> ActionController::Routing::Routes.generate :controller => "foo", :action => "bar" => "/foo/bar" >> ActionController::Routing::Routes.recognize_path "/foo/bar" ActionController::RoutingError: no route found to match "/foo/bar" with {} from ./script/../config/../config/../vendor/rails/actionpack/lib/action_controller/routing.rb:1292:in `recognize_path' from (irb):66 from :0 It seems reasonable to me to adjust the behavior of "response.should redirect_to" so that it returns an error if the controller attempts to redirect to an non-routable URL when your spec is trying to match against it by using a hash. If you want to spec against a URL that lives outside of your application's ability to route, you should probably be spec'ing against the string, right? At least, that's my current thought on the matter. It might be seen as a major change in behavior for the redirect_to matcher. What do you think? So, the controllers that are stored in the rspec_on_rails plugin are not recognized by the example_rails_app's routing. If I move redirect_spec_controller.rb from the plugin into the example app (and remove the require from spec_helper.rb), that allows almost all of the specs to pass. The only specs that don't pass then are the two that redirect to :controller => "other", which is the same error. If I change those to redirect to :controller => "people", then their errors go away as well. ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 18:14 Message: A comment on the failing specs patch and how to reproduce the failures: the first spec will fail only very occasionally... like... say, only on the continuous integration server and not on your development laptop and only when you commit your last change for the day and need to get home. The second and third of the two specs are attempting to replicate the conditions that semi-randomly occur within the first spec. Thus, one and only one of them will always fail, but which one is dependent upon when a particular African butterfly has last flapped its wings. :-) ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 18:09 Message: Yep. I'm using sqlite. It seemed like it should be simpler than mysql. :-) (our production environment is running on SQL Server, which is emphatically *not* simpler than running on mysql.) $ dpkg -l|grep 'libsqlite\|sqlite.*ruby'|awk '{print $3,$2}' 0.0.23-3 libdbd-sqlite3-ruby 0.0.23-3 libdbd-sqlite3-ruby1.8 3.3.5-0.2 libsqlite3-0 1.1.0-2 libsqlite3-ruby 1.1.0-2 libsqlite3-ruby1.8 ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-27 15:59 Message: re: seg faults - are you using sqlite? Which version? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-27 15:59 Message: Thanks Nicholas - the pre-patch-failing specs would be especially great. Cheers, David ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 15:36 Message: Well, I can't run all of the specs, and I don't really know why, but I can run the redirect_to_spec.rb. I'll fix the patch to pass all of the tests in there, and I'll add another couple of specs which should fail without my patch. ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 12:50 Message: Now I'm getting segfaults when I run rake pre_commit! running against rails 1.2.3: ** Invoke environment ** Execute db:schema:load ** Execute spec:plugins /home/nevans/src/rspec/example_rails_app/vendor/rails/1.2.3/activerecord/lib/../../activesupport/lib/active_support/core_ext/object/extending.rb:27: [BUG] Segmentation fault ruby 1.8.4 (2005-12-24) [i486-linux] Aborted (core dumped) rake aborted! Command ruby -I"/home/nevans/src/rspec/rspec/lib" "/home/nevans/src/rspec/rspec/bin/spec" "vendor/plugins/rspec_on_rails/spec/rails/extensions/active_record_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/dsl/assigns_hash_proxy_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/dsl/ivar_proxy_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/assert_select_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/redirect_to_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/render_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/description_generation_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/controller_isolation_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/view_spec_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/helper_spec_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/behaviour_factory_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/controller_spec_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/test_unit_assertion_accessibility_spec.rb" --options "/home/nevans/src/rspec/example_rails_app/config/../spec/spec.opts" failed /home/nevans/src/rspec/rspec/lib/spec/rake/spectask.rb:131:in `define' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:835:in `verbose' /home/nevans/src/rspec/rspec/lib/spec/rake/spectask.rb:105:in `define' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:399:in `execute' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:399:in `execute' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:369:in `invoke' /usr/lib/ruby/1.8/thread.rb:135:in `synchronize' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:362:in `invoke' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:1935:in `run' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:1935:in `run' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/bin/rake:7 /usr/bin/rake:16 I deleted rails 1.2.3 and ran against 1.2.2 (which is what my other apps are using), and dies in the same location: ** Invoke environment ** Execute db:schema:load ** Execute spec:plugins /home/nevans/src/rspec/rspec/lib/spec/dsl/behaviour_callbacks.rb:48: [BUG] Segmentation fault ruby 1.8.4 (2005-12-24) [i486-linux] Aborted (core dumped) rake aborted! Command ruby -I"/home/nevans/src/rspec/rspec/lib" "/home/nevans/src/rspec/rspec/bin/spec" "vendor/plugins/rspec_on_rails/spec/rails/extensions/active_record_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/dsl/assigns_hash_proxy_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/dsl/ivar_proxy_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/assert_select_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/redirect_to_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/render_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/description_generation_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/controller_isolation_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/view_spec_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/helper_spec_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/behaviour_factory_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/controller_spec_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/test_unit_assertion_accessibility_spec.rb" --options "/home/nevans/src/rspec/example_rails_app/config/../spec/spec.opts" failed /home/nevans/src/rspec/rspec/lib/spec/rake/spectask.rb:131:in `define' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:835:in `verbose' /home/nevans/src/rspec/rspec/lib/spec/rake/spectask.rb:105:in `define' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:399:in `execute' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:399:in `execute' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:369:in `invoke' /usr/lib/ruby/1.8/thread.rb:135:in `synchronize' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:362:in `invoke' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:1935:in `run' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:1935:in `run' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/bin/rake:7 /usr/bin/rake:16 I'm running the Ubuntu Edgy version of ruby, which dpkg reports as 1.8.2, but ruby -v reports as 1.8.4. ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 12:28 Message: I found "rake rspec:generate_sqlite_config", and I'm working on getting the precommit bugs fixed now. ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 12:24 Message: More specific explanation of my rake precommit trouble: I was being lazy and didn't bother to debug the problem. It was complaining because config/database.yml was missing. I've looked into the example rails app, and there seems to be some rake tasks for creating a sample sqlite db, so I'll look into that now. Is there a particular magic sequence that could be issued to make it "just work" upon checkout? :-) ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-27 11:34 Message: That was 18 of 38 examples. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-27 11:25 Message: I tried to apply this and 18 of the 18 examples in redirect_to_spec.rb fail. Some are due to the changes you made to the failure messages - some for other reasons I haven't looked at yet. You said you were having trouble getting it to run - can you be more specific? Thanks, David ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=10410&group_id=797 From noreply at rubyforge.org Fri Apr 27 18:29:46 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 27 Apr 2007 18:29:46 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-10410 ] redirect_to does not behave consistently with regards to query string parameter ordering Message-ID: <20070427222947.030BD5240B30@rubyforge.org> Patches item #10410, was opened at 2007-04-27 11:01 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=10410&group_id=797 Category: expectation module Group: None Status: Open Resolution: None Priority: 3 Submitted By: nicholas evans (nick_evans) Assigned to: Nobody (None) Summary: redirect_to does not behave consistently with regards to query string parameter ordering Initial Comment: This bug is *incredibly* difficult to reproduce. It ends up causing a spec to pass when run as a single file and fail when run as a group of files... or vice versa. Or pass on one computer, but fail on another. Or pass in an old working copy, but fail when re-checked out. Or pass when running the normal rake task, but fail when generating an HTML support. And so on and so forth! As you might imagine this can make continuous integration rather annoying. The problem is that rails will place the items in a hash into the query string in a semi-random order. Given similar hashes, the same URL will *usually* be generated by each. But often enough to be annoying, that is not the case. This is simply due to the unordered nature of hashes. So I made a patch to redirect_to to do two things: 1) If your redirect_to expectation is a hash, and the actual redirection is within http://test.host it will convert the actual redirect_url to a hash, and also convert the expectation to a URL and then back into a hash (this takes care of when you leave :controller out of the expectation). 2) If your redirect_to expectation is a hash, then the failure message will report the failure back as hashes. The previous error (expected hash but got string) was always a bit confusing. If your redirect_to expectation is a string or :back, then you will continue to get the old behavior: a direct string comparison (which may or may not be tripped up by query string order). I created the patch against version 0.8.3, because that is what I'm using, but the redirect_to matcher does not appear to have changed much (at all?) in trunk, and the patch applied cleanly. Although all of the specs using redirect_to in my app still work, I was having difficulties getting "rake precommit" to run correctly... Sorry. :-( ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 18:27 Message: Two comments on the passing specs patch: 1) because "svn mv" doesn't translate well into the diff format, you'll want to apply it with the following three commands: svn cp rspec_on_rails/spec_resources/controllers/redirect_spec_controller.rb example_rails_app/app/controllers/redirect_spec_controller.rb patch -p0 < passes_specs.patch svn rm rspec_on_rails/spec_resources/controllers/redirect_spec_controller.rb --force 2) I haven't yet added the specs for the additional failure behavior (I actually reverted the failure message behavior that I originally added, and then added some new behavior for the new error type), but I'll get to that momentarily (with another patch). ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 18:25 Message: Okay, I figured out what the problem is: Since I'm converting the URL string back into a hash containing the controller, action, etc, the URL must be routable within the application. However, url_for and ActionController::Routing::Routes.generate have no such restrictions. For example: >> ActionController::Routing::Routes.generate :controller => "foo", :action => "bar" => "/foo/bar" >> ActionController::Routing::Routes.recognize_path "/foo/bar" ActionController::RoutingError: no route found to match "/foo/bar" with {} from ./script/../config/../config/../vendor/rails/actionpack/lib/action_controller/routing.rb:1292:in `recognize_path' from (irb):66 from :0 It seems reasonable to me to adjust the behavior of "response.should redirect_to" so that it returns an error if the controller attempts to redirect to an non-routable URL when your spec is trying to match against it by using a hash. If you want to spec against a URL that lives outside of your application's ability to route, you should probably be spec'ing against the string, right? At least, that's my current thought on the matter. It might be seen as a major change in behavior for the redirect_to matcher. What do you think? So, the controllers that are stored in the rspec_on_rails plugin are not recognized by the example_rails_app's routing. If I move redirect_spec_controller.rb from the plugin into the example app (and remove the require from spec_helper.rb), that allows almost all of the specs to pass. The only specs that don't pass then are the two that redirect to :controller => "other", which is the same error. If I change those to redirect to :controller => "people", then their errors go away as well. ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 18:14 Message: A comment on the failing specs patch and how to reproduce the failures: the first spec will fail only very occasionally... like... say, only on the continuous integration server and not on your development laptop and only when you commit your last change for the day and need to get home. The second and third of the two specs are attempting to replicate the conditions that semi-randomly occur within the first spec. Thus, one and only one of them will always fail, but which one is dependent upon when a particular African butterfly has last flapped its wings. :-) ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 18:09 Message: Yep. I'm using sqlite. It seemed like it should be simpler than mysql. :-) (our production environment is running on SQL Server, which is emphatically *not* simpler than running on mysql.) $ dpkg -l|grep 'libsqlite\|sqlite.*ruby'|awk '{print $3,$2}' 0.0.23-3 libdbd-sqlite3-ruby 0.0.23-3 libdbd-sqlite3-ruby1.8 3.3.5-0.2 libsqlite3-0 1.1.0-2 libsqlite3-ruby 1.1.0-2 libsqlite3-ruby1.8 ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-27 15:59 Message: re: seg faults - are you using sqlite? Which version? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-27 15:59 Message: Thanks Nicholas - the pre-patch-failing specs would be especially great. Cheers, David ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 15:36 Message: Well, I can't run all of the specs, and I don't really know why, but I can run the redirect_to_spec.rb. I'll fix the patch to pass all of the tests in there, and I'll add another couple of specs which should fail without my patch. ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 12:50 Message: Now I'm getting segfaults when I run rake pre_commit! running against rails 1.2.3: ** Invoke environment ** Execute db:schema:load ** Execute spec:plugins /home/nevans/src/rspec/example_rails_app/vendor/rails/1.2.3/activerecord/lib/../../activesupport/lib/active_support/core_ext/object/extending.rb:27: [BUG] Segmentation fault ruby 1.8.4 (2005-12-24) [i486-linux] Aborted (core dumped) rake aborted! Command ruby -I"/home/nevans/src/rspec/rspec/lib" "/home/nevans/src/rspec/rspec/bin/spec" "vendor/plugins/rspec_on_rails/spec/rails/extensions/active_record_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/dsl/assigns_hash_proxy_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/dsl/ivar_proxy_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/assert_select_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/redirect_to_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/render_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/description_generation_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/controller_isolation_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/view_spec_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/helper_spec_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/behaviour_factory_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/controller_spec_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/test_unit_assertion_accessibility_spec.rb" --options "/home/nevans/src/rspec/example_rails_app/config/../spec/spec.opts" failed /home/nevans/src/rspec/rspec/lib/spec/rake/spectask.rb:131:in `define' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:835:in `verbose' /home/nevans/src/rspec/rspec/lib/spec/rake/spectask.rb:105:in `define' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:399:in `execute' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:399:in `execute' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:369:in `invoke' /usr/lib/ruby/1.8/thread.rb:135:in `synchronize' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:362:in `invoke' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:1935:in `run' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:1935:in `run' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/bin/rake:7 /usr/bin/rake:16 I deleted rails 1.2.3 and ran against 1.2.2 (which is what my other apps are using), and dies in the same location: ** Invoke environment ** Execute db:schema:load ** Execute spec:plugins /home/nevans/src/rspec/rspec/lib/spec/dsl/behaviour_callbacks.rb:48: [BUG] Segmentation fault ruby 1.8.4 (2005-12-24) [i486-linux] Aborted (core dumped) rake aborted! Command ruby -I"/home/nevans/src/rspec/rspec/lib" "/home/nevans/src/rspec/rspec/bin/spec" "vendor/plugins/rspec_on_rails/spec/rails/extensions/active_record_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/dsl/assigns_hash_proxy_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/dsl/ivar_proxy_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/assert_select_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/redirect_to_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/render_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/description_generation_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/controller_isolation_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/view_spec_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/helper_spec_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/behaviour_factory_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/controller_spec_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/test_unit_assertion_accessibility_spec.rb" --options "/home/nevans/src/rspec/example_rails_app/config/../spec/spec.opts" failed /home/nevans/src/rspec/rspec/lib/spec/rake/spectask.rb:131:in `define' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:835:in `verbose' /home/nevans/src/rspec/rspec/lib/spec/rake/spectask.rb:105:in `define' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:399:in `execute' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:399:in `execute' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:369:in `invoke' /usr/lib/ruby/1.8/thread.rb:135:in `synchronize' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:362:in `invoke' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:1935:in `run' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:1935:in `run' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/bin/rake:7 /usr/bin/rake:16 I'm running the Ubuntu Edgy version of ruby, which dpkg reports as 1.8.2, but ruby -v reports as 1.8.4. ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 12:28 Message: I found "rake rspec:generate_sqlite_config", and I'm working on getting the precommit bugs fixed now. ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 12:24 Message: More specific explanation of my rake precommit trouble: I was being lazy and didn't bother to debug the problem. It was complaining because config/database.yml was missing. I've looked into the example rails app, and there seems to be some rake tasks for creating a sample sqlite db, so I'll look into that now. Is there a particular magic sequence that could be issued to make it "just work" upon checkout? :-) ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-27 11:34 Message: That was 18 of 38 examples. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-27 11:25 Message: I tried to apply this and 18 of the 18 examples in redirect_to_spec.rb fail. Some are due to the changes you made to the failure messages - some for other reasons I haven't looked at yet. You said you were having trouble getting it to run - can you be more specific? Thanks, David ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=10410&group_id=797 From noreply at rubyforge.org Fri Apr 27 18:50:48 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 27 Apr 2007 18:50:48 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-10410 ] redirect_to does not behave consistently with regards to query string parameter ordering Message-ID: <20070427225048.D488D5240B30@rubyforge.org> Patches item #10410, was opened at 2007-04-27 11:01 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=10410&group_id=797 Category: expectation module Group: None Status: Open Resolution: None Priority: 3 Submitted By: nicholas evans (nick_evans) Assigned to: Nobody (None) Summary: redirect_to does not behave consistently with regards to query string parameter ordering Initial Comment: This bug is *incredibly* difficult to reproduce. It ends up causing a spec to pass when run as a single file and fail when run as a group of files... or vice versa. Or pass on one computer, but fail on another. Or pass in an old working copy, but fail when re-checked out. Or pass when running the normal rake task, but fail when generating an HTML support. And so on and so forth! As you might imagine this can make continuous integration rather annoying. The problem is that rails will place the items in a hash into the query string in a semi-random order. Given similar hashes, the same URL will *usually* be generated by each. But often enough to be annoying, that is not the case. This is simply due to the unordered nature of hashes. So I made a patch to redirect_to to do two things: 1) If your redirect_to expectation is a hash, and the actual redirection is within http://test.host it will convert the actual redirect_url to a hash, and also convert the expectation to a URL and then back into a hash (this takes care of when you leave :controller out of the expectation). 2) If your redirect_to expectation is a hash, then the failure message will report the failure back as hashes. The previous error (expected hash but got string) was always a bit confusing. If your redirect_to expectation is a string or :back, then you will continue to get the old behavior: a direct string comparison (which may or may not be tripped up by query string order). I created the patch against version 0.8.3, because that is what I'm using, but the redirect_to matcher does not appear to have changed much (at all?) in trunk, and the patch applied cleanly. Although all of the specs using redirect_to in my app still work, I was having difficulties getting "rake precommit" to run correctly... Sorry. :-( ---------------------------------------------------------------------- >Comment By: nicholas evans (nick_evans) Date: 2007-04-27 18:50 Message: As promised, I'm attaching the completed specs, including specs for the new error behavior: "response.should redirect_to(hash)" should fail if the redirection is not to a URL that is routable within the application. Same 3-step directions for application apply as with the last patch. I didn't add back the "failure message should print actual redirection as a hash when expectation is for a hash" behavior, because that extra layer of redirection was only really annoying when I couldn't depend on rails and rspec to behave nicely with their URLs. I don't really mind that the failure message compares a hash and a string now. :-) ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 18:27 Message: Two comments on the passing specs patch: 1) because "svn mv" doesn't translate well into the diff format, you'll want to apply it with the following three commands: svn cp rspec_on_rails/spec_resources/controllers/redirect_spec_controller.rb example_rails_app/app/controllers/redirect_spec_controller.rb patch -p0 < passes_specs.patch svn rm rspec_on_rails/spec_resources/controllers/redirect_spec_controller.rb --force 2) I haven't yet added the specs for the additional failure behavior (I actually reverted the failure message behavior that I originally added, and then added some new behavior for the new error type), but I'll get to that momentarily (with another patch). ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 18:25 Message: Okay, I figured out what the problem is: Since I'm converting the URL string back into a hash containing the controller, action, etc, the URL must be routable within the application. However, url_for and ActionController::Routing::Routes.generate have no such restrictions. For example: >> ActionController::Routing::Routes.generate :controller => "foo", :action => "bar" => "/foo/bar" >> ActionController::Routing::Routes.recognize_path "/foo/bar" ActionController::RoutingError: no route found to match "/foo/bar" with {} from ./script/../config/../config/../vendor/rails/actionpack/lib/action_controller/routing.rb:1292:in `recognize_path' from (irb):66 from :0 It seems reasonable to me to adjust the behavior of "response.should redirect_to" so that it returns an error if the controller attempts to redirect to an non-routable URL when your spec is trying to match against it by using a hash. If you want to spec against a URL that lives outside of your application's ability to route, you should probably be spec'ing against the string, right? At least, that's my current thought on the matter. It might be seen as a major change in behavior for the redirect_to matcher. What do you think? So, the controllers that are stored in the rspec_on_rails plugin are not recognized by the example_rails_app's routing. If I move redirect_spec_controller.rb from the plugin into the example app (and remove the require from spec_helper.rb), that allows almost all of the specs to pass. The only specs that don't pass then are the two that redirect to :controller => "other", which is the same error. If I change those to redirect to :controller => "people", then their errors go away as well. ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 18:14 Message: A comment on the failing specs patch and how to reproduce the failures: the first spec will fail only very occasionally... like... say, only on the continuous integration server and not on your development laptop and only when you commit your last change for the day and need to get home. The second and third of the two specs are attempting to replicate the conditions that semi-randomly occur within the first spec. Thus, one and only one of them will always fail, but which one is dependent upon when a particular African butterfly has last flapped its wings. :-) ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 18:09 Message: Yep. I'm using sqlite. It seemed like it should be simpler than mysql. :-) (our production environment is running on SQL Server, which is emphatically *not* simpler than running on mysql.) $ dpkg -l|grep 'libsqlite\|sqlite.*ruby'|awk '{print $3,$2}' 0.0.23-3 libdbd-sqlite3-ruby 0.0.23-3 libdbd-sqlite3-ruby1.8 3.3.5-0.2 libsqlite3-0 1.1.0-2 libsqlite3-ruby 1.1.0-2 libsqlite3-ruby1.8 ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-27 15:59 Message: re: seg faults - are you using sqlite? Which version? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-27 15:59 Message: Thanks Nicholas - the pre-patch-failing specs would be especially great. Cheers, David ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 15:36 Message: Well, I can't run all of the specs, and I don't really know why, but I can run the redirect_to_spec.rb. I'll fix the patch to pass all of the tests in there, and I'll add another couple of specs which should fail without my patch. ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 12:50 Message: Now I'm getting segfaults when I run rake pre_commit! running against rails 1.2.3: ** Invoke environment ** Execute db:schema:load ** Execute spec:plugins /home/nevans/src/rspec/example_rails_app/vendor/rails/1.2.3/activerecord/lib/../../activesupport/lib/active_support/core_ext/object/extending.rb:27: [BUG] Segmentation fault ruby 1.8.4 (2005-12-24) [i486-linux] Aborted (core dumped) rake aborted! Command ruby -I"/home/nevans/src/rspec/rspec/lib" "/home/nevans/src/rspec/rspec/bin/spec" "vendor/plugins/rspec_on_rails/spec/rails/extensions/active_record_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/dsl/assigns_hash_proxy_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/dsl/ivar_proxy_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/assert_select_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/redirect_to_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/render_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/description_generation_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/controller_isolation_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/view_spec_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/helper_spec_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/behaviour_factory_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/controller_spec_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/test_unit_assertion_accessibility_spec.rb" --options "/home/nevans/src/rspec/example_rails_app/config/../spec/spec.opts" failed /home/nevans/src/rspec/rspec/lib/spec/rake/spectask.rb:131:in `define' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:835:in `verbose' /home/nevans/src/rspec/rspec/lib/spec/rake/spectask.rb:105:in `define' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:399:in `execute' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:399:in `execute' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:369:in `invoke' /usr/lib/ruby/1.8/thread.rb:135:in `synchronize' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:362:in `invoke' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:1935:in `run' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:1935:in `run' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/bin/rake:7 /usr/bin/rake:16 I deleted rails 1.2.3 and ran against 1.2.2 (which is what my other apps are using), and dies in the same location: ** Invoke environment ** Execute db:schema:load ** Execute spec:plugins /home/nevans/src/rspec/rspec/lib/spec/dsl/behaviour_callbacks.rb:48: [BUG] Segmentation fault ruby 1.8.4 (2005-12-24) [i486-linux] Aborted (core dumped) rake aborted! Command ruby -I"/home/nevans/src/rspec/rspec/lib" "/home/nevans/src/rspec/rspec/bin/spec" "vendor/plugins/rspec_on_rails/spec/rails/extensions/active_record_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/dsl/assigns_hash_proxy_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/dsl/ivar_proxy_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/assert_select_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/redirect_to_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/render_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/description_generation_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/controller_isolation_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/view_spec_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/helper_spec_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/behaviour_factory_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/controller_spec_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/test_unit_assertion_accessibility_spec.rb" --options "/home/nevans/src/rspec/example_rails_app/config/../spec/spec.opts" failed /home/nevans/src/rspec/rspec/lib/spec/rake/spectask.rb:131:in `define' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:835:in `verbose' /home/nevans/src/rspec/rspec/lib/spec/rake/spectask.rb:105:in `define' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:399:in `execute' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:399:in `execute' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:369:in `invoke' /usr/lib/ruby/1.8/thread.rb:135:in `synchronize' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:362:in `invoke' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:1935:in `run' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:1935:in `run' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/bin/rake:7 /usr/bin/rake:16 I'm running the Ubuntu Edgy version of ruby, which dpkg reports as 1.8.2, but ruby -v reports as 1.8.4. ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 12:28 Message: I found "rake rspec:generate_sqlite_config", and I'm working on getting the precommit bugs fixed now. ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 12:24 Message: More specific explanation of my rake precommit trouble: I was being lazy and didn't bother to debug the problem. It was complaining because config/database.yml was missing. I've looked into the example rails app, and there seems to be some rake tasks for creating a sample sqlite db, so I'll look into that now. Is there a particular magic sequence that could be issued to make it "just work" upon checkout? :-) ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-27 11:34 Message: That was 18 of 38 examples. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-27 11:25 Message: I tried to apply this and 18 of the 18 examples in redirect_to_spec.rb fail. Some are due to the changes you made to the failure messages - some for other reasons I haven't looked at yet. You said you were having trouble getting it to run - can you be more specific? Thanks, David ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=10410&group_id=797 From noreply at rubyforge.org Fri Apr 27 18:56:48 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 27 Apr 2007 18:56:48 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-10410 ] redirect_to does not behave consistently with regards to query string parameter ordering Message-ID: <20070427225648.730435240B61@rubyforge.org> Patches item #10410, was opened at 2007-04-27 11:01 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=10410&group_id=797 Category: expectation module Group: None Status: Open Resolution: None Priority: 3 Submitted By: nicholas evans (nick_evans) Assigned to: Nobody (None) Summary: redirect_to does not behave consistently with regards to query string parameter ordering Initial Comment: This bug is *incredibly* difficult to reproduce. It ends up causing a spec to pass when run as a single file and fail when run as a group of files... or vice versa. Or pass on one computer, but fail on another. Or pass in an old working copy, but fail when re-checked out. Or pass when running the normal rake task, but fail when generating an HTML support. And so on and so forth! As you might imagine this can make continuous integration rather annoying. The problem is that rails will place the items in a hash into the query string in a semi-random order. Given similar hashes, the same URL will *usually* be generated by each. But often enough to be annoying, that is not the case. This is simply due to the unordered nature of hashes. So I made a patch to redirect_to to do two things: 1) If your redirect_to expectation is a hash, and the actual redirection is within http://test.host it will convert the actual redirect_url to a hash, and also convert the expectation to a URL and then back into a hash (this takes care of when you leave :controller out of the expectation). 2) If your redirect_to expectation is a hash, then the failure message will report the failure back as hashes. The previous error (expected hash but got string) was always a bit confusing. If your redirect_to expectation is a string or :back, then you will continue to get the old behavior: a direct string comparison (which may or may not be tripped up by query string order). I created the patch against version 0.8.3, because that is what I'm using, but the redirect_to matcher does not appear to have changed much (at all?) in trunk, and the patch applied cleanly. Although all of the specs using redirect_to in my app still work, I was having difficulties getting "rake precommit" to run correctly... Sorry. :-( ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 18:50 Message: As promised, I'm attaching the completed specs, including specs for the new error behavior: "response.should redirect_to(hash)" should fail if the redirection is not to a URL that is routable within the application. Same 3-step directions for application apply as with the last patch. I didn't add back the "failure message should print actual redirection as a hash when expectation is for a hash" behavior, because that extra layer of redirection was only really annoying when I couldn't depend on rails and rspec to behave nicely with their URLs. I don't really mind that the failure message compares a hash and a string now. :-) ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 18:27 Message: Two comments on the passing specs patch: 1) because "svn mv" doesn't translate well into the diff format, you'll want to apply it with the following three commands: svn cp rspec_on_rails/spec_resources/controllers/redirect_spec_controller.rb example_rails_app/app/controllers/redirect_spec_controller.rb patch -p0 < passes_specs.patch svn rm rspec_on_rails/spec_resources/controllers/redirect_spec_controller.rb --force 2) I haven't yet added the specs for the additional failure behavior (I actually reverted the failure message behavior that I originally added, and then added some new behavior for the new error type), but I'll get to that momentarily (with another patch). ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 18:25 Message: Okay, I figured out what the problem is: Since I'm converting the URL string back into a hash containing the controller, action, etc, the URL must be routable within the application. However, url_for and ActionController::Routing::Routes.generate have no such restrictions. For example: >> ActionController::Routing::Routes.generate :controller => "foo", :action => "bar" => "/foo/bar" >> ActionController::Routing::Routes.recognize_path "/foo/bar" ActionController::RoutingError: no route found to match "/foo/bar" with {} from ./script/../config/../config/../vendor/rails/actionpack/lib/action_controller/routing.rb:1292:in `recognize_path' from (irb):66 from :0 It seems reasonable to me to adjust the behavior of "response.should redirect_to" so that it returns an error if the controller attempts to redirect to an non-routable URL when your spec is trying to match against it by using a hash. If you want to spec against a URL that lives outside of your application's ability to route, you should probably be spec'ing against the string, right? At least, that's my current thought on the matter. It might be seen as a major change in behavior for the redirect_to matcher. What do you think? So, the controllers that are stored in the rspec_on_rails plugin are not recognized by the example_rails_app's routing. If I move redirect_spec_controller.rb from the plugin into the example app (and remove the require from spec_helper.rb), that allows almost all of the specs to pass. The only specs that don't pass then are the two that redirect to :controller => "other", which is the same error. If I change those to redirect to :controller => "people", then their errors go away as well. ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 18:14 Message: A comment on the failing specs patch and how to reproduce the failures: the first spec will fail only very occasionally... like... say, only on the continuous integration server and not on your development laptop and only when you commit your last change for the day and need to get home. The second and third of the two specs are attempting to replicate the conditions that semi-randomly occur within the first spec. Thus, one and only one of them will always fail, but which one is dependent upon when a particular African butterfly has last flapped its wings. :-) ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 18:09 Message: Yep. I'm using sqlite. It seemed like it should be simpler than mysql. :-) (our production environment is running on SQL Server, which is emphatically *not* simpler than running on mysql.) $ dpkg -l|grep 'libsqlite\|sqlite.*ruby'|awk '{print $3,$2}' 0.0.23-3 libdbd-sqlite3-ruby 0.0.23-3 libdbd-sqlite3-ruby1.8 3.3.5-0.2 libsqlite3-0 1.1.0-2 libsqlite3-ruby 1.1.0-2 libsqlite3-ruby1.8 ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-27 15:59 Message: re: seg faults - are you using sqlite? Which version? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-27 15:59 Message: Thanks Nicholas - the pre-patch-failing specs would be especially great. Cheers, David ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 15:36 Message: Well, I can't run all of the specs, and I don't really know why, but I can run the redirect_to_spec.rb. I'll fix the patch to pass all of the tests in there, and I'll add another couple of specs which should fail without my patch. ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 12:50 Message: Now I'm getting segfaults when I run rake pre_commit! running against rails 1.2.3: ** Invoke environment ** Execute db:schema:load ** Execute spec:plugins /home/nevans/src/rspec/example_rails_app/vendor/rails/1.2.3/activerecord/lib/../../activesupport/lib/active_support/core_ext/object/extending.rb:27: [BUG] Segmentation fault ruby 1.8.4 (2005-12-24) [i486-linux] Aborted (core dumped) rake aborted! Command ruby -I"/home/nevans/src/rspec/rspec/lib" "/home/nevans/src/rspec/rspec/bin/spec" "vendor/plugins/rspec_on_rails/spec/rails/extensions/active_record_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/dsl/assigns_hash_proxy_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/dsl/ivar_proxy_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/assert_select_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/redirect_to_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/render_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/description_generation_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/controller_isolation_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/view_spec_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/helper_spec_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/behaviour_factory_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/controller_spec_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/test_unit_assertion_accessibility_spec.rb" --options "/home/nevans/src/rspec/example_rails_app/config/../spec/spec.opts" failed /home/nevans/src/rspec/rspec/lib/spec/rake/spectask.rb:131:in `define' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:835:in `verbose' /home/nevans/src/rspec/rspec/lib/spec/rake/spectask.rb:105:in `define' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:399:in `execute' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:399:in `execute' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:369:in `invoke' /usr/lib/ruby/1.8/thread.rb:135:in `synchronize' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:362:in `invoke' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:1935:in `run' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:1935:in `run' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/bin/rake:7 /usr/bin/rake:16 I deleted rails 1.2.3 and ran against 1.2.2 (which is what my other apps are using), and dies in the same location: ** Invoke environment ** Execute db:schema:load ** Execute spec:plugins /home/nevans/src/rspec/rspec/lib/spec/dsl/behaviour_callbacks.rb:48: [BUG] Segmentation fault ruby 1.8.4 (2005-12-24) [i486-linux] Aborted (core dumped) rake aborted! Command ruby -I"/home/nevans/src/rspec/rspec/lib" "/home/nevans/src/rspec/rspec/bin/spec" "vendor/plugins/rspec_on_rails/spec/rails/extensions/active_record_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/dsl/assigns_hash_proxy_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/dsl/ivar_proxy_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/assert_select_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/redirect_to_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/render_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/description_generation_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/controller_isolation_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/view_spec_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/helper_spec_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/behaviour_factory_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/controller_spec_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/test_unit_assertion_accessibility_spec.rb" --options "/home/nevans/src/rspec/example_rails_app/config/../spec/spec.opts" failed /home/nevans/src/rspec/rspec/lib/spec/rake/spectask.rb:131:in `define' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:835:in `verbose' /home/nevans/src/rspec/rspec/lib/spec/rake/spectask.rb:105:in `define' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:399:in `execute' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:399:in `execute' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:369:in `invoke' /usr/lib/ruby/1.8/thread.rb:135:in `synchronize' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:362:in `invoke' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:1935:in `run' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:1935:in `run' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/bin/rake:7 /usr/bin/rake:16 I'm running the Ubuntu Edgy version of ruby, which dpkg reports as 1.8.2, but ruby -v reports as 1.8.4. ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 12:28 Message: I found "rake rspec:generate_sqlite_config", and I'm working on getting the precommit bugs fixed now. ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 12:24 Message: More specific explanation of my rake precommit trouble: I was being lazy and didn't bother to debug the problem. It was complaining because config/database.yml was missing. I've looked into the example rails app, and there seems to be some rake tasks for creating a sample sqlite db, so I'll look into that now. Is there a particular magic sequence that could be issued to make it "just work" upon checkout? :-) ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-27 11:34 Message: That was 18 of 38 examples. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-27 11:25 Message: I tried to apply this and 18 of the 18 examples in redirect_to_spec.rb fail. Some are due to the changes you made to the failure messages - some for other reasons I haven't looked at yet. You said you were having trouble getting it to run - can you be more specific? Thanks, David ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=10410&group_id=797 From noreply at rubyforge.org Fri Apr 27 19:03:41 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 27 Apr 2007 19:03:41 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-10410 ] redirect_to does not behave consistently with regards to query string parameter ordering Message-ID: <20070427230341.C97815240ABF@rubyforge.org> Patches item #10410, was opened at 2007-04-27 11:01 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=10410&group_id=797 Category: expectation module Group: None Status: Open Resolution: None Priority: 3 Submitted By: nicholas evans (nick_evans) Assigned to: Nobody (None) Summary: redirect_to does not behave consistently with regards to query string parameter ordering Initial Comment: This bug is *incredibly* difficult to reproduce. It ends up causing a spec to pass when run as a single file and fail when run as a group of files... or vice versa. Or pass on one computer, but fail on another. Or pass in an old working copy, but fail when re-checked out. Or pass when running the normal rake task, but fail when generating an HTML support. And so on and so forth! As you might imagine this can make continuous integration rather annoying. The problem is that rails will place the items in a hash into the query string in a semi-random order. Given similar hashes, the same URL will *usually* be generated by each. But often enough to be annoying, that is not the case. This is simply due to the unordered nature of hashes. So I made a patch to redirect_to to do two things: 1) If your redirect_to expectation is a hash, and the actual redirection is within http://test.host it will convert the actual redirect_url to a hash, and also convert the expectation to a URL and then back into a hash (this takes care of when you leave :controller out of the expectation). 2) If your redirect_to expectation is a hash, then the failure message will report the failure back as hashes. The previous error (expected hash but got string) was always a bit confusing. If your redirect_to expectation is a string or :back, then you will continue to get the old behavior: a direct string comparison (which may or may not be tripped up by query string order). I created the patch against version 0.8.3, because that is what I'm using, but the redirect_to matcher does not appear to have changed much (at all?) in trunk, and the patch applied cleanly. Although all of the specs using redirect_to in my app still work, I was having difficulties getting "rake precommit" to run correctly... Sorry. :-( ---------------------------------------------------------------------- >Comment By: nicholas evans (nick_evans) Date: 2007-04-27 19:03 Message: D'oh! I had a copy/paste error... bad description text for the final new spec. $ diff passing_specs_including_new_error_behavior* 169c169 < + it "redirected to an internal URL which is unroutable but matched via a string" do --- > + it "redirected to an internal URL which is unroutable and matched via a hash" do ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 18:50 Message: As promised, I'm attaching the completed specs, including specs for the new error behavior: "response.should redirect_to(hash)" should fail if the redirection is not to a URL that is routable within the application. Same 3-step directions for application apply as with the last patch. I didn't add back the "failure message should print actual redirection as a hash when expectation is for a hash" behavior, because that extra layer of redirection was only really annoying when I couldn't depend on rails and rspec to behave nicely with their URLs. I don't really mind that the failure message compares a hash and a string now. :-) ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 18:27 Message: Two comments on the passing specs patch: 1) because "svn mv" doesn't translate well into the diff format, you'll want to apply it with the following three commands: svn cp rspec_on_rails/spec_resources/controllers/redirect_spec_controller.rb example_rails_app/app/controllers/redirect_spec_controller.rb patch -p0 < passes_specs.patch svn rm rspec_on_rails/spec_resources/controllers/redirect_spec_controller.rb --force 2) I haven't yet added the specs for the additional failure behavior (I actually reverted the failure message behavior that I originally added, and then added some new behavior for the new error type), but I'll get to that momentarily (with another patch). ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 18:25 Message: Okay, I figured out what the problem is: Since I'm converting the URL string back into a hash containing the controller, action, etc, the URL must be routable within the application. However, url_for and ActionController::Routing::Routes.generate have no such restrictions. For example: >> ActionController::Routing::Routes.generate :controller => "foo", :action => "bar" => "/foo/bar" >> ActionController::Routing::Routes.recognize_path "/foo/bar" ActionController::RoutingError: no route found to match "/foo/bar" with {} from ./script/../config/../config/../vendor/rails/actionpack/lib/action_controller/routing.rb:1292:in `recognize_path' from (irb):66 from :0 It seems reasonable to me to adjust the behavior of "response.should redirect_to" so that it returns an error if the controller attempts to redirect to an non-routable URL when your spec is trying to match against it by using a hash. If you want to spec against a URL that lives outside of your application's ability to route, you should probably be spec'ing against the string, right? At least, that's my current thought on the matter. It might be seen as a major change in behavior for the redirect_to matcher. What do you think? So, the controllers that are stored in the rspec_on_rails plugin are not recognized by the example_rails_app's routing. If I move redirect_spec_controller.rb from the plugin into the example app (and remove the require from spec_helper.rb), that allows almost all of the specs to pass. The only specs that don't pass then are the two that redirect to :controller => "other", which is the same error. If I change those to redirect to :controller => "people", then their errors go away as well. ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 18:14 Message: A comment on the failing specs patch and how to reproduce the failures: the first spec will fail only very occasionally... like... say, only on the continuous integration server and not on your development laptop and only when you commit your last change for the day and need to get home. The second and third of the two specs are attempting to replicate the conditions that semi-randomly occur within the first spec. Thus, one and only one of them will always fail, but which one is dependent upon when a particular African butterfly has last flapped its wings. :-) ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 18:09 Message: Yep. I'm using sqlite. It seemed like it should be simpler than mysql. :-) (our production environment is running on SQL Server, which is emphatically *not* simpler than running on mysql.) $ dpkg -l|grep 'libsqlite\|sqlite.*ruby'|awk '{print $3,$2}' 0.0.23-3 libdbd-sqlite3-ruby 0.0.23-3 libdbd-sqlite3-ruby1.8 3.3.5-0.2 libsqlite3-0 1.1.0-2 libsqlite3-ruby 1.1.0-2 libsqlite3-ruby1.8 ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-27 15:59 Message: re: seg faults - are you using sqlite? Which version? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-27 15:59 Message: Thanks Nicholas - the pre-patch-failing specs would be especially great. Cheers, David ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 15:36 Message: Well, I can't run all of the specs, and I don't really know why, but I can run the redirect_to_spec.rb. I'll fix the patch to pass all of the tests in there, and I'll add another couple of specs which should fail without my patch. ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 12:50 Message: Now I'm getting segfaults when I run rake pre_commit! running against rails 1.2.3: ** Invoke environment ** Execute db:schema:load ** Execute spec:plugins /home/nevans/src/rspec/example_rails_app/vendor/rails/1.2.3/activerecord/lib/../../activesupport/lib/active_support/core_ext/object/extending.rb:27: [BUG] Segmentation fault ruby 1.8.4 (2005-12-24) [i486-linux] Aborted (core dumped) rake aborted! Command ruby -I"/home/nevans/src/rspec/rspec/lib" "/home/nevans/src/rspec/rspec/bin/spec" "vendor/plugins/rspec_on_rails/spec/rails/extensions/active_record_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/dsl/assigns_hash_proxy_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/dsl/ivar_proxy_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/assert_select_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/redirect_to_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/render_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/description_generation_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/controller_isolation_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/view_spec_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/helper_spec_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/behaviour_factory_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/controller_spec_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/test_unit_assertion_accessibility_spec.rb" --options "/home/nevans/src/rspec/example_rails_app/config/../spec/spec.opts" failed /home/nevans/src/rspec/rspec/lib/spec/rake/spectask.rb:131:in `define' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:835:in `verbose' /home/nevans/src/rspec/rspec/lib/spec/rake/spectask.rb:105:in `define' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:399:in `execute' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:399:in `execute' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:369:in `invoke' /usr/lib/ruby/1.8/thread.rb:135:in `synchronize' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:362:in `invoke' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:1935:in `run' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:1935:in `run' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/bin/rake:7 /usr/bin/rake:16 I deleted rails 1.2.3 and ran against 1.2.2 (which is what my other apps are using), and dies in the same location: ** Invoke environment ** Execute db:schema:load ** Execute spec:plugins /home/nevans/src/rspec/rspec/lib/spec/dsl/behaviour_callbacks.rb:48: [BUG] Segmentation fault ruby 1.8.4 (2005-12-24) [i486-linux] Aborted (core dumped) rake aborted! Command ruby -I"/home/nevans/src/rspec/rspec/lib" "/home/nevans/src/rspec/rspec/bin/spec" "vendor/plugins/rspec_on_rails/spec/rails/extensions/active_record_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/dsl/assigns_hash_proxy_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/dsl/ivar_proxy_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/assert_select_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/redirect_to_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/render_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/description_generation_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/controller_isolation_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/view_spec_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/helper_spec_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/behaviour_factory_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/controller_spec_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/test_unit_assertion_accessibility_spec.rb" --options "/home/nevans/src/rspec/example_rails_app/config/../spec/spec.opts" failed /home/nevans/src/rspec/rspec/lib/spec/rake/spectask.rb:131:in `define' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:835:in `verbose' /home/nevans/src/rspec/rspec/lib/spec/rake/spectask.rb:105:in `define' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:399:in `execute' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:399:in `execute' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:369:in `invoke' /usr/lib/ruby/1.8/thread.rb:135:in `synchronize' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:362:in `invoke' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:1935:in `run' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:1935:in `run' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/bin/rake:7 /usr/bin/rake:16 I'm running the Ubuntu Edgy version of ruby, which dpkg reports as 1.8.2, but ruby -v reports as 1.8.4. ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 12:28 Message: I found "rake rspec:generate_sqlite_config", and I'm working on getting the precommit bugs fixed now. ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 12:24 Message: More specific explanation of my rake precommit trouble: I was being lazy and didn't bother to debug the problem. It was complaining because config/database.yml was missing. I've looked into the example rails app, and there seems to be some rake tasks for creating a sample sqlite db, so I'll look into that now. Is there a particular magic sequence that could be issued to make it "just work" upon checkout? :-) ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-27 11:34 Message: That was 18 of 38 examples. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-27 11:25 Message: I tried to apply this and 18 of the 18 examples in redirect_to_spec.rb fail. Some are due to the changes you made to the failure messages - some for other reasons I haven't looked at yet. You said you were having trouble getting it to run - can you be more specific? Thanks, David ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=10410&group_id=797 From noreply at rubyforge.org Fri Apr 27 19:44:18 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 27 Apr 2007 19:44:18 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-10410 ] redirect_to does not behave consistently with regards to query string parameter ordering Message-ID: <20070427234419.030815240ABF@rubyforge.org> Patches item #10410, was opened at 2007-04-27 15:01 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=10410&group_id=797 Category: expectation module Group: None Status: Open Resolution: None Priority: 3 Submitted By: nicholas evans (nick_evans) Assigned to: Nobody (None) Summary: redirect_to does not behave consistently with regards to query string parameter ordering Initial Comment: This bug is *incredibly* difficult to reproduce. It ends up causing a spec to pass when run as a single file and fail when run as a group of files... or vice versa. Or pass on one computer, but fail on another. Or pass in an old working copy, but fail when re-checked out. Or pass when running the normal rake task, but fail when generating an HTML support. And so on and so forth! As you might imagine this can make continuous integration rather annoying. The problem is that rails will place the items in a hash into the query string in a semi-random order. Given similar hashes, the same URL will *usually* be generated by each. But often enough to be annoying, that is not the case. This is simply due to the unordered nature of hashes. So I made a patch to redirect_to to do two things: 1) If your redirect_to expectation is a hash, and the actual redirection is within http://test.host it will convert the actual redirect_url to a hash, and also convert the expectation to a URL and then back into a hash (this takes care of when you leave :controller out of the expectation). 2) If your redirect_to expectation is a hash, then the failure message will report the failure back as hashes. The previous error (expected hash but got string) was always a bit confusing. If your redirect_to expectation is a string or :back, then you will continue to get the old behavior: a direct string comparison (which may or may not be tripped up by query string order). I created the patch against version 0.8.3, because that is what I'm using, but the redirect_to matcher does not appear to have changed much (at all?) in trunk, and the patch applied cleanly. Although all of the specs using redirect_to in my app still work, I was having difficulties getting "rake precommit" to run correctly... Sorry. :-( ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-04-27 23:44 Message: Hey Nick - thanks for the effort, but this patch presents a problem. To get the routing to work, it looks like you moved redirect_spec_controller.rb from rspec_on_rails/spec_resources to the example_rails_app. We've gone through great pains to decouple the plugin from the app, which is why all of the controllers for the specs that live in rspec_on_rails/spec/ are in rspec_on_rails/spec_resources. We need to figure out a way to maintain the location before I'm willing to apply this patch. Any ideas? I hope we can come up w/ something because it's a nice patch otherwise. Cheers, David ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 23:03 Message: D'oh! I had a copy/paste error... bad description text for the final new spec. $ diff passing_specs_including_new_error_behavior* 169c169 < + it "redirected to an internal URL which is unroutable but matched via a string" do --- > + it "redirected to an internal URL which is unroutable and matched via a hash" do ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 22:50 Message: As promised, I'm attaching the completed specs, including specs for the new error behavior: "response.should redirect_to(hash)" should fail if the redirection is not to a URL that is routable within the application. Same 3-step directions for application apply as with the last patch. I didn't add back the "failure message should print actual redirection as a hash when expectation is for a hash" behavior, because that extra layer of redirection was only really annoying when I couldn't depend on rails and rspec to behave nicely with their URLs. I don't really mind that the failure message compares a hash and a string now. :-) ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 22:27 Message: Two comments on the passing specs patch: 1) because "svn mv" doesn't translate well into the diff format, you'll want to apply it with the following three commands: svn cp rspec_on_rails/spec_resources/controllers/redirect_spec_controller.rb example_rails_app/app/controllers/redirect_spec_controller.rb patch -p0 < passes_specs.patch svn rm rspec_on_rails/spec_resources/controllers/redirect_spec_controller.rb --force 2) I haven't yet added the specs for the additional failure behavior (I actually reverted the failure message behavior that I originally added, and then added some new behavior for the new error type), but I'll get to that momentarily (with another patch). ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 22:25 Message: Okay, I figured out what the problem is: Since I'm converting the URL string back into a hash containing the controller, action, etc, the URL must be routable within the application. However, url_for and ActionController::Routing::Routes.generate have no such restrictions. For example: >> ActionController::Routing::Routes.generate :controller => "foo", :action => "bar" => "/foo/bar" >> ActionController::Routing::Routes.recognize_path "/foo/bar" ActionController::RoutingError: no route found to match "/foo/bar" with {} from ./script/../config/../config/../vendor/rails/actionpack/lib/action_controller/routing.rb:1292:in `recognize_path' from (irb):66 from :0 It seems reasonable to me to adjust the behavior of "response.should redirect_to" so that it returns an error if the controller attempts to redirect to an non-routable URL when your spec is trying to match against it by using a hash. If you want to spec against a URL that lives outside of your application's ability to route, you should probably be spec'ing against the string, right? At least, that's my current thought on the matter. It might be seen as a major change in behavior for the redirect_to matcher. What do you think? So, the controllers that are stored in the rspec_on_rails plugin are not recognized by the example_rails_app's routing. If I move redirect_spec_controller.rb from the plugin into the example app (and remove the require from spec_helper.rb), that allows almost all of the specs to pass. The only specs that don't pass then are the two that redirect to :controller => "other", which is the same error. If I change those to redirect to :controller => "people", then their errors go away as well. ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 22:14 Message: A comment on the failing specs patch and how to reproduce the failures: the first spec will fail only very occasionally... like... say, only on the continuous integration server and not on your development laptop and only when you commit your last change for the day and need to get home. The second and third of the two specs are attempting to replicate the conditions that semi-randomly occur within the first spec. Thus, one and only one of them will always fail, but which one is dependent upon when a particular African butterfly has last flapped its wings. :-) ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 22:09 Message: Yep. I'm using sqlite. It seemed like it should be simpler than mysql. :-) (our production environment is running on SQL Server, which is emphatically *not* simpler than running on mysql.) $ dpkg -l|grep 'libsqlite\|sqlite.*ruby'|awk '{print $3,$2}' 0.0.23-3 libdbd-sqlite3-ruby 0.0.23-3 libdbd-sqlite3-ruby1.8 3.3.5-0.2 libsqlite3-0 1.1.0-2 libsqlite3-ruby 1.1.0-2 libsqlite3-ruby1.8 ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-27 19:59 Message: re: seg faults - are you using sqlite? Which version? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-27 19:59 Message: Thanks Nicholas - the pre-patch-failing specs would be especially great. Cheers, David ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 19:36 Message: Well, I can't run all of the specs, and I don't really know why, but I can run the redirect_to_spec.rb. I'll fix the patch to pass all of the tests in there, and I'll add another couple of specs which should fail without my patch. ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 16:50 Message: Now I'm getting segfaults when I run rake pre_commit! running against rails 1.2.3: ** Invoke environment ** Execute db:schema:load ** Execute spec:plugins /home/nevans/src/rspec/example_rails_app/vendor/rails/1.2.3/activerecord/lib/../../activesupport/lib/active_support/core_ext/object/extending.rb:27: [BUG] Segmentation fault ruby 1.8.4 (2005-12-24) [i486-linux] Aborted (core dumped) rake aborted! Command ruby -I"/home/nevans/src/rspec/rspec/lib" "/home/nevans/src/rspec/rspec/bin/spec" "vendor/plugins/rspec_on_rails/spec/rails/extensions/active_record_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/dsl/assigns_hash_proxy_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/dsl/ivar_proxy_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/assert_select_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/redirect_to_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/render_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/description_generation_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/controller_isolation_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/view_spec_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/helper_spec_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/behaviour_factory_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/controller_spec_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/test_unit_assertion_accessibility_spec.rb" --options "/home/nevans/src/rspec/example_rails_app/config/../spec/spec.opts" failed /home/nevans/src/rspec/rspec/lib/spec/rake/spectask.rb:131:in `define' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:835:in `verbose' /home/nevans/src/rspec/rspec/lib/spec/rake/spectask.rb:105:in `define' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:399:in `execute' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:399:in `execute' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:369:in `invoke' /usr/lib/ruby/1.8/thread.rb:135:in `synchronize' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:362:in `invoke' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:1935:in `run' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:1935:in `run' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/bin/rake:7 /usr/bin/rake:16 I deleted rails 1.2.3 and ran against 1.2.2 (which is what my other apps are using), and dies in the same location: ** Invoke environment ** Execute db:schema:load ** Execute spec:plugins /home/nevans/src/rspec/rspec/lib/spec/dsl/behaviour_callbacks.rb:48: [BUG] Segmentation fault ruby 1.8.4 (2005-12-24) [i486-linux] Aborted (core dumped) rake aborted! Command ruby -I"/home/nevans/src/rspec/rspec/lib" "/home/nevans/src/rspec/rspec/bin/spec" "vendor/plugins/rspec_on_rails/spec/rails/extensions/active_record_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/dsl/assigns_hash_proxy_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/dsl/ivar_proxy_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/assert_select_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/redirect_to_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/render_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/description_generation_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/controller_isolation_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/view_spec_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/helper_spec_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/behaviour_factory_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/controller_spec_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/test_unit_assertion_accessibility_spec.rb" --options "/home/nevans/src/rspec/example_rails_app/config/../spec/spec.opts" failed /home/nevans/src/rspec/rspec/lib/spec/rake/spectask.rb:131:in `define' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:835:in `verbose' /home/nevans/src/rspec/rspec/lib/spec/rake/spectask.rb:105:in `define' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:399:in `execute' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:399:in `execute' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:369:in `invoke' /usr/lib/ruby/1.8/thread.rb:135:in `synchronize' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:362:in `invoke' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:1935:in `run' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:1935:in `run' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/bin/rake:7 /usr/bin/rake:16 I'm running the Ubuntu Edgy version of ruby, which dpkg reports as 1.8.2, but ruby -v reports as 1.8.4. ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 16:28 Message: I found "rake rspec:generate_sqlite_config", and I'm working on getting the precommit bugs fixed now. ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 16:24 Message: More specific explanation of my rake precommit trouble: I was being lazy and didn't bother to debug the problem. It was complaining because config/database.yml was missing. I've looked into the example rails app, and there seems to be some rake tasks for creating a sample sqlite db, so I'll look into that now. Is there a particular magic sequence that could be issued to make it "just work" upon checkout? :-) ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-27 15:34 Message: That was 18 of 38 examples. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-27 15:25 Message: I tried to apply this and 18 of the 18 examples in redirect_to_spec.rb fail. Some are due to the changes you made to the failure messages - some for other reasons I haven't looked at yet. You said you were having trouble getting it to run - can you be more specific? Thanks, David ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=10410&group_id=797 From noreply at rubyforge.org Fri Apr 27 23:46:59 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 27 Apr 2007 23:46:59 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-10410 ] redirect_to does not behave consistently with regards to query string parameter ordering Message-ID: <20070428034659.6D1925240BE5@rubyforge.org> Patches item #10410, was opened at 2007-04-27 11:01 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=10410&group_id=797 Category: expectation module Group: None Status: Open Resolution: None Priority: 3 Submitted By: nicholas evans (nick_evans) Assigned to: Nobody (None) Summary: redirect_to does not behave consistently with regards to query string parameter ordering Initial Comment: This bug is *incredibly* difficult to reproduce. It ends up causing a spec to pass when run as a single file and fail when run as a group of files... or vice versa. Or pass on one computer, but fail on another. Or pass in an old working copy, but fail when re-checked out. Or pass when running the normal rake task, but fail when generating an HTML support. And so on and so forth! As you might imagine this can make continuous integration rather annoying. The problem is that rails will place the items in a hash into the query string in a semi-random order. Given similar hashes, the same URL will *usually* be generated by each. But often enough to be annoying, that is not the case. This is simply due to the unordered nature of hashes. So I made a patch to redirect_to to do two things: 1) If your redirect_to expectation is a hash, and the actual redirection is within http://test.host it will convert the actual redirect_url to a hash, and also convert the expectation to a URL and then back into a hash (this takes care of when you leave :controller out of the expectation). 2) If your redirect_to expectation is a hash, then the failure message will report the failure back as hashes. The previous error (expected hash but got string) was always a bit confusing. If your redirect_to expectation is a string or :back, then you will continue to get the old behavior: a direct string comparison (which may or may not be tripped up by query string order). I created the patch against version 0.8.3, because that is what I'm using, but the redirect_to matcher does not appear to have changed much (at all?) in trunk, and the patch applied cleanly. Although all of the specs using redirect_to in my app still work, I was having difficulties getting "rake precommit" to run correctly... Sorry. :-( ---------------------------------------------------------------------- >Comment By: nicholas evans (nick_evans) Date: 2007-04-27 23:46 Message: I was afraid that you might say that. ;-) I just wanted to tackle one problem at a time. My thought is that the only way to make this work would be to convince Rails routing to consider the rspec_on_rails controllers (or only the RedirectSpecController). I don't know the syntax for how to do that exactly, but I can search inside the code for rails engines or appable plugins to find out how they've done it. Hopefully I can find a minimally invasive method for doing this. The additional problem with that is that we certainly wouldn't want the rspec_on_rails plugin to be adding any controllers (or otherwise mucking with the environment) to every app that its included in, even in the test environment. We really only want this functionality to be triggered when the rspec_on_rails plugin specs are being run. Can this be accomplished simply by only putting the controller loading code into rspec_on_rails's spec_helper.rb? I don't know how to do either of these things at the moment, but I'll look into them both. But (unless something else comes up), I think this should solve our problem... right? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-27 19:44 Message: Hey Nick - thanks for the effort, but this patch presents a problem. To get the routing to work, it looks like you moved redirect_spec_controller.rb from rspec_on_rails/spec_resources to the example_rails_app. We've gone through great pains to decouple the plugin from the app, which is why all of the controllers for the specs that live in rspec_on_rails/spec/ are in rspec_on_rails/spec_resources. We need to figure out a way to maintain the location before I'm willing to apply this patch. Any ideas? I hope we can come up w/ something because it's a nice patch otherwise. Cheers, David ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 19:03 Message: D'oh! I had a copy/paste error... bad description text for the final new spec. $ diff passing_specs_including_new_error_behavior* 169c169 < + it "redirected to an internal URL which is unroutable but matched via a string" do --- > + it "redirected to an internal URL which is unroutable and matched via a hash" do ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 18:50 Message: As promised, I'm attaching the completed specs, including specs for the new error behavior: "response.should redirect_to(hash)" should fail if the redirection is not to a URL that is routable within the application. Same 3-step directions for application apply as with the last patch. I didn't add back the "failure message should print actual redirection as a hash when expectation is for a hash" behavior, because that extra layer of redirection was only really annoying when I couldn't depend on rails and rspec to behave nicely with their URLs. I don't really mind that the failure message compares a hash and a string now. :-) ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 18:27 Message: Two comments on the passing specs patch: 1) because "svn mv" doesn't translate well into the diff format, you'll want to apply it with the following three commands: svn cp rspec_on_rails/spec_resources/controllers/redirect_spec_controller.rb example_rails_app/app/controllers/redirect_spec_controller.rb patch -p0 < passes_specs.patch svn rm rspec_on_rails/spec_resources/controllers/redirect_spec_controller.rb --force 2) I haven't yet added the specs for the additional failure behavior (I actually reverted the failure message behavior that I originally added, and then added some new behavior for the new error type), but I'll get to that momentarily (with another patch). ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 18:25 Message: Okay, I figured out what the problem is: Since I'm converting the URL string back into a hash containing the controller, action, etc, the URL must be routable within the application. However, url_for and ActionController::Routing::Routes.generate have no such restrictions. For example: >> ActionController::Routing::Routes.generate :controller => "foo", :action => "bar" => "/foo/bar" >> ActionController::Routing::Routes.recognize_path "/foo/bar" ActionController::RoutingError: no route found to match "/foo/bar" with {} from ./script/../config/../config/../vendor/rails/actionpack/lib/action_controller/routing.rb:1292:in `recognize_path' from (irb):66 from :0 It seems reasonable to me to adjust the behavior of "response.should redirect_to" so that it returns an error if the controller attempts to redirect to an non-routable URL when your spec is trying to match against it by using a hash. If you want to spec against a URL that lives outside of your application's ability to route, you should probably be spec'ing against the string, right? At least, that's my current thought on the matter. It might be seen as a major change in behavior for the redirect_to matcher. What do you think? So, the controllers that are stored in the rspec_on_rails plugin are not recognized by the example_rails_app's routing. If I move redirect_spec_controller.rb from the plugin into the example app (and remove the require from spec_helper.rb), that allows almost all of the specs to pass. The only specs that don't pass then are the two that redirect to :controller => "other", which is the same error. If I change those to redirect to :controller => "people", then their errors go away as well. ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 18:14 Message: A comment on the failing specs patch and how to reproduce the failures: the first spec will fail only very occasionally... like... say, only on the continuous integration server and not on your development laptop and only when you commit your last change for the day and need to get home. The second and third of the two specs are attempting to replicate the conditions that semi-randomly occur within the first spec. Thus, one and only one of them will always fail, but which one is dependent upon when a particular African butterfly has last flapped its wings. :-) ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 18:09 Message: Yep. I'm using sqlite. It seemed like it should be simpler than mysql. :-) (our production environment is running on SQL Server, which is emphatically *not* simpler than running on mysql.) $ dpkg -l|grep 'libsqlite\|sqlite.*ruby'|awk '{print $3,$2}' 0.0.23-3 libdbd-sqlite3-ruby 0.0.23-3 libdbd-sqlite3-ruby1.8 3.3.5-0.2 libsqlite3-0 1.1.0-2 libsqlite3-ruby 1.1.0-2 libsqlite3-ruby1.8 ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-27 15:59 Message: re: seg faults - are you using sqlite? Which version? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-27 15:59 Message: Thanks Nicholas - the pre-patch-failing specs would be especially great. Cheers, David ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 15:36 Message: Well, I can't run all of the specs, and I don't really know why, but I can run the redirect_to_spec.rb. I'll fix the patch to pass all of the tests in there, and I'll add another couple of specs which should fail without my patch. ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 12:50 Message: Now I'm getting segfaults when I run rake pre_commit! running against rails 1.2.3: ** Invoke environment ** Execute db:schema:load ** Execute spec:plugins /home/nevans/src/rspec/example_rails_app/vendor/rails/1.2.3/activerecord/lib/../../activesupport/lib/active_support/core_ext/object/extending.rb:27: [BUG] Segmentation fault ruby 1.8.4 (2005-12-24) [i486-linux] Aborted (core dumped) rake aborted! Command ruby -I"/home/nevans/src/rspec/rspec/lib" "/home/nevans/src/rspec/rspec/bin/spec" "vendor/plugins/rspec_on_rails/spec/rails/extensions/active_record_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/dsl/assigns_hash_proxy_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/dsl/ivar_proxy_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/assert_select_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/redirect_to_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/render_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/description_generation_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/controller_isolation_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/view_spec_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/helper_spec_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/behaviour_factory_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/controller_spec_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/test_unit_assertion_accessibility_spec.rb" --options "/home/nevans/src/rspec/example_rails_app/config/../spec/spec.opts" failed /home/nevans/src/rspec/rspec/lib/spec/rake/spectask.rb:131:in `define' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:835:in `verbose' /home/nevans/src/rspec/rspec/lib/spec/rake/spectask.rb:105:in `define' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:399:in `execute' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:399:in `execute' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:369:in `invoke' /usr/lib/ruby/1.8/thread.rb:135:in `synchronize' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:362:in `invoke' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:1935:in `run' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:1935:in `run' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/bin/rake:7 /usr/bin/rake:16 I deleted rails 1.2.3 and ran against 1.2.2 (which is what my other apps are using), and dies in the same location: ** Invoke environment ** Execute db:schema:load ** Execute spec:plugins /home/nevans/src/rspec/rspec/lib/spec/dsl/behaviour_callbacks.rb:48: [BUG] Segmentation fault ruby 1.8.4 (2005-12-24) [i486-linux] Aborted (core dumped) rake aborted! Command ruby -I"/home/nevans/src/rspec/rspec/lib" "/home/nevans/src/rspec/rspec/bin/spec" "vendor/plugins/rspec_on_rails/spec/rails/extensions/active_record_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/dsl/assigns_hash_proxy_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/dsl/ivar_proxy_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/assert_select_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/redirect_to_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/render_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/description_generation_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/controller_isolation_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/view_spec_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/helper_spec_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/behaviour_factory_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/controller_spec_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/test_unit_assertion_accessibility_spec.rb" --options "/home/nevans/src/rspec/example_rails_app/config/../spec/spec.opts" failed /home/nevans/src/rspec/rspec/lib/spec/rake/spectask.rb:131:in `define' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:835:in `verbose' /home/nevans/src/rspec/rspec/lib/spec/rake/spectask.rb:105:in `define' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:399:in `execute' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:399:in `execute' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:369:in `invoke' /usr/lib/ruby/1.8/thread.rb:135:in `synchronize' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:362:in `invoke' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:1935:in `run' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:1935:in `run' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/bin/rake:7 /usr/bin/rake:16 I'm running the Ubuntu Edgy version of ruby, which dpkg reports as 1.8.2, but ruby -v reports as 1.8.4. ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 12:28 Message: I found "rake rspec:generate_sqlite_config", and I'm working on getting the precommit bugs fixed now. ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 12:24 Message: More specific explanation of my rake precommit trouble: I was being lazy and didn't bother to debug the problem. It was complaining because config/database.yml was missing. I've looked into the example rails app, and there seems to be some rake tasks for creating a sample sqlite db, so I'll look into that now. Is there a particular magic sequence that could be issued to make it "just work" upon checkout? :-) ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-27 11:34 Message: That was 18 of 38 examples. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-27 11:25 Message: I tried to apply this and 18 of the 18 examples in redirect_to_spec.rb fail. Some are due to the changes you made to the failure messages - some for other reasons I haven't looked at yet. You said you were having trouble getting it to run - can you be more specific? Thanks, David ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=10410&group_id=797 From noreply at rubyforge.org Sat Apr 28 00:03:11 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sat, 28 Apr 2007 00:03:11 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-10410 ] redirect_to does not behave consistently with regards to query string parameter ordering Message-ID: <20070428040311.5103B5240BF5@rubyforge.org> Patches item #10410, was opened at 2007-04-27 15:01 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=10410&group_id=797 Category: expectation module Group: None Status: Open Resolution: None Priority: 3 Submitted By: nicholas evans (nick_evans) Assigned to: Nobody (None) Summary: redirect_to does not behave consistently with regards to query string parameter ordering Initial Comment: This bug is *incredibly* difficult to reproduce. It ends up causing a spec to pass when run as a single file and fail when run as a group of files... or vice versa. Or pass on one computer, but fail on another. Or pass in an old working copy, but fail when re-checked out. Or pass when running the normal rake task, but fail when generating an HTML support. And so on and so forth! As you might imagine this can make continuous integration rather annoying. The problem is that rails will place the items in a hash into the query string in a semi-random order. Given similar hashes, the same URL will *usually* be generated by each. But often enough to be annoying, that is not the case. This is simply due to the unordered nature of hashes. So I made a patch to redirect_to to do two things: 1) If your redirect_to expectation is a hash, and the actual redirection is within http://test.host it will convert the actual redirect_url to a hash, and also convert the expectation to a URL and then back into a hash (this takes care of when you leave :controller out of the expectation). 2) If your redirect_to expectation is a hash, then the failure message will report the failure back as hashes. The previous error (expected hash but got string) was always a bit confusing. If your redirect_to expectation is a string or :back, then you will continue to get the old behavior: a direct string comparison (which may or may not be tripped up by query string order). I created the patch against version 0.8.3, because that is what I'm using, but the redirect_to matcher does not appear to have changed much (at all?) in trunk, and the patch applied cleanly. Although all of the specs using redirect_to in my app still work, I was having difficulties getting "rake precommit" to run correctly... Sorry. :-( ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-04-28 04:03 Message: This sounds right. As things stand right now, these controllers are only included (from rspec_on_rails/spec/spec_helper.rb) when you run the specs for rspec_on_rails itself, so that problem is solved. Whatever monkey patching may be necessary to coerce routing into looking at the rspec_on_rails/spec_resources directory could also be included in the same file. Thanks for playing! I look forward to getting this in place. Cheers, David ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-28 03:46 Message: I was afraid that you might say that. ;-) I just wanted to tackle one problem at a time. My thought is that the only way to make this work would be to convince Rails routing to consider the rspec_on_rails controllers (or only the RedirectSpecController). I don't know the syntax for how to do that exactly, but I can search inside the code for rails engines or appable plugins to find out how they've done it. Hopefully I can find a minimally invasive method for doing this. The additional problem with that is that we certainly wouldn't want the rspec_on_rails plugin to be adding any controllers (or otherwise mucking with the environment) to every app that its included in, even in the test environment. We really only want this functionality to be triggered when the rspec_on_rails plugin specs are being run. Can this be accomplished simply by only putting the controller loading code into rspec_on_rails's spec_helper.rb? I don't know how to do either of these things at the moment, but I'll look into them both. But (unless something else comes up), I think this should solve our problem... right? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-27 23:44 Message: Hey Nick - thanks for the effort, but this patch presents a problem. To get the routing to work, it looks like you moved redirect_spec_controller.rb from rspec_on_rails/spec_resources to the example_rails_app. We've gone through great pains to decouple the plugin from the app, which is why all of the controllers for the specs that live in rspec_on_rails/spec/ are in rspec_on_rails/spec_resources. We need to figure out a way to maintain the location before I'm willing to apply this patch. Any ideas? I hope we can come up w/ something because it's a nice patch otherwise. Cheers, David ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 23:03 Message: D'oh! I had a copy/paste error... bad description text for the final new spec. $ diff passing_specs_including_new_error_behavior* 169c169 < + it "redirected to an internal URL which is unroutable but matched via a string" do --- > + it "redirected to an internal URL which is unroutable and matched via a hash" do ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 22:50 Message: As promised, I'm attaching the completed specs, including specs for the new error behavior: "response.should redirect_to(hash)" should fail if the redirection is not to a URL that is routable within the application. Same 3-step directions for application apply as with the last patch. I didn't add back the "failure message should print actual redirection as a hash when expectation is for a hash" behavior, because that extra layer of redirection was only really annoying when I couldn't depend on rails and rspec to behave nicely with their URLs. I don't really mind that the failure message compares a hash and a string now. :-) ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 22:27 Message: Two comments on the passing specs patch: 1) because "svn mv" doesn't translate well into the diff format, you'll want to apply it with the following three commands: svn cp rspec_on_rails/spec_resources/controllers/redirect_spec_controller.rb example_rails_app/app/controllers/redirect_spec_controller.rb patch -p0 < passes_specs.patch svn rm rspec_on_rails/spec_resources/controllers/redirect_spec_controller.rb --force 2) I haven't yet added the specs for the additional failure behavior (I actually reverted the failure message behavior that I originally added, and then added some new behavior for the new error type), but I'll get to that momentarily (with another patch). ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 22:25 Message: Okay, I figured out what the problem is: Since I'm converting the URL string back into a hash containing the controller, action, etc, the URL must be routable within the application. However, url_for and ActionController::Routing::Routes.generate have no such restrictions. For example: >> ActionController::Routing::Routes.generate :controller => "foo", :action => "bar" => "/foo/bar" >> ActionController::Routing::Routes.recognize_path "/foo/bar" ActionController::RoutingError: no route found to match "/foo/bar" with {} from ./script/../config/../config/../vendor/rails/actionpack/lib/action_controller/routing.rb:1292:in `recognize_path' from (irb):66 from :0 It seems reasonable to me to adjust the behavior of "response.should redirect_to" so that it returns an error if the controller attempts to redirect to an non-routable URL when your spec is trying to match against it by using a hash. If you want to spec against a URL that lives outside of your application's ability to route, you should probably be spec'ing against the string, right? At least, that's my current thought on the matter. It might be seen as a major change in behavior for the redirect_to matcher. What do you think? So, the controllers that are stored in the rspec_on_rails plugin are not recognized by the example_rails_app's routing. If I move redirect_spec_controller.rb from the plugin into the example app (and remove the require from spec_helper.rb), that allows almost all of the specs to pass. The only specs that don't pass then are the two that redirect to :controller => "other", which is the same error. If I change those to redirect to :controller => "people", then their errors go away as well. ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 22:14 Message: A comment on the failing specs patch and how to reproduce the failures: the first spec will fail only very occasionally... like... say, only on the continuous integration server and not on your development laptop and only when you commit your last change for the day and need to get home. The second and third of the two specs are attempting to replicate the conditions that semi-randomly occur within the first spec. Thus, one and only one of them will always fail, but which one is dependent upon when a particular African butterfly has last flapped its wings. :-) ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 22:09 Message: Yep. I'm using sqlite. It seemed like it should be simpler than mysql. :-) (our production environment is running on SQL Server, which is emphatically *not* simpler than running on mysql.) $ dpkg -l|grep 'libsqlite\|sqlite.*ruby'|awk '{print $3,$2}' 0.0.23-3 libdbd-sqlite3-ruby 0.0.23-3 libdbd-sqlite3-ruby1.8 3.3.5-0.2 libsqlite3-0 1.1.0-2 libsqlite3-ruby 1.1.0-2 libsqlite3-ruby1.8 ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-27 19:59 Message: re: seg faults - are you using sqlite? Which version? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-27 19:59 Message: Thanks Nicholas - the pre-patch-failing specs would be especially great. Cheers, David ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 19:36 Message: Well, I can't run all of the specs, and I don't really know why, but I can run the redirect_to_spec.rb. I'll fix the patch to pass all of the tests in there, and I'll add another couple of specs which should fail without my patch. ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 16:50 Message: Now I'm getting segfaults when I run rake pre_commit! running against rails 1.2.3: ** Invoke environment ** Execute db:schema:load ** Execute spec:plugins /home/nevans/src/rspec/example_rails_app/vendor/rails/1.2.3/activerecord/lib/../../activesupport/lib/active_support/core_ext/object/extending.rb:27: [BUG] Segmentation fault ruby 1.8.4 (2005-12-24) [i486-linux] Aborted (core dumped) rake aborted! Command ruby -I"/home/nevans/src/rspec/rspec/lib" "/home/nevans/src/rspec/rspec/bin/spec" "vendor/plugins/rspec_on_rails/spec/rails/extensions/active_record_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/dsl/assigns_hash_proxy_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/dsl/ivar_proxy_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/assert_select_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/redirect_to_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/render_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/description_generation_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/controller_isolation_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/view_spec_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/helper_spec_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/behaviour_factory_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/controller_spec_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/test_unit_assertion_accessibility_spec.rb" --options "/home/nevans/src/rspec/example_rails_app/config/../spec/spec.opts" failed /home/nevans/src/rspec/rspec/lib/spec/rake/spectask.rb:131:in `define' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:835:in `verbose' /home/nevans/src/rspec/rspec/lib/spec/rake/spectask.rb:105:in `define' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:399:in `execute' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:399:in `execute' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:369:in `invoke' /usr/lib/ruby/1.8/thread.rb:135:in `synchronize' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:362:in `invoke' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:1935:in `run' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:1935:in `run' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/bin/rake:7 /usr/bin/rake:16 I deleted rails 1.2.3 and ran against 1.2.2 (which is what my other apps are using), and dies in the same location: ** Invoke environment ** Execute db:schema:load ** Execute spec:plugins /home/nevans/src/rspec/rspec/lib/spec/dsl/behaviour_callbacks.rb:48: [BUG] Segmentation fault ruby 1.8.4 (2005-12-24) [i486-linux] Aborted (core dumped) rake aborted! Command ruby -I"/home/nevans/src/rspec/rspec/lib" "/home/nevans/src/rspec/rspec/bin/spec" "vendor/plugins/rspec_on_rails/spec/rails/extensions/active_record_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/dsl/assigns_hash_proxy_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/dsl/ivar_proxy_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/assert_select_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/redirect_to_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/render_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/description_generation_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/controller_isolation_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/view_spec_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/helper_spec_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/behaviour_factory_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/controller_spec_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/test_unit_assertion_accessibility_spec.rb" --options "/home/nevans/src/rspec/example_rails_app/config/../spec/spec.opts" failed /home/nevans/src/rspec/rspec/lib/spec/rake/spectask.rb:131:in `define' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:835:in `verbose' /home/nevans/src/rspec/rspec/lib/spec/rake/spectask.rb:105:in `define' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:399:in `execute' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:399:in `execute' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:369:in `invoke' /usr/lib/ruby/1.8/thread.rb:135:in `synchronize' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:362:in `invoke' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:1935:in `run' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:1935:in `run' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/bin/rake:7 /usr/bin/rake:16 I'm running the Ubuntu Edgy version of ruby, which dpkg reports as 1.8.2, but ruby -v reports as 1.8.4. ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 16:28 Message: I found "rake rspec:generate_sqlite_config", and I'm working on getting the precommit bugs fixed now. ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 16:24 Message: More specific explanation of my rake precommit trouble: I was being lazy and didn't bother to debug the problem. It was complaining because config/database.yml was missing. I've looked into the example rails app, and there seems to be some rake tasks for creating a sample sqlite db, so I'll look into that now. Is there a particular magic sequence that could be issued to make it "just work" upon checkout? :-) ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-27 15:34 Message: That was 18 of 38 examples. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-27 15:25 Message: I tried to apply this and 18 of the 18 examples in redirect_to_spec.rb fail. Some are due to the changes you made to the failure messages - some for other reasons I haven't looked at yet. You said you were having trouble getting it to run - can you be more specific? Thanks, David ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=10410&group_id=797 From noreply at rubyforge.org Sat Apr 28 01:11:16 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sat, 28 Apr 2007 01:11:16 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-10410 ] redirect_to does not behave consistently with regards to query string parameter ordering Message-ID: <20070428051116.D51905240BF5@rubyforge.org> Patches item #10410, was opened at 2007-04-27 11:01 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=10410&group_id=797 Category: expectation module Group: None Status: Open Resolution: None Priority: 3 Submitted By: nicholas evans (nick_evans) Assigned to: Nobody (None) Summary: redirect_to does not behave consistently with regards to query string parameter ordering Initial Comment: This bug is *incredibly* difficult to reproduce. It ends up causing a spec to pass when run as a single file and fail when run as a group of files... or vice versa. Or pass on one computer, but fail on another. Or pass in an old working copy, but fail when re-checked out. Or pass when running the normal rake task, but fail when generating an HTML support. And so on and so forth! As you might imagine this can make continuous integration rather annoying. The problem is that rails will place the items in a hash into the query string in a semi-random order. Given similar hashes, the same URL will *usually* be generated by each. But often enough to be annoying, that is not the case. This is simply due to the unordered nature of hashes. So I made a patch to redirect_to to do two things: 1) If your redirect_to expectation is a hash, and the actual redirection is within http://test.host it will convert the actual redirect_url to a hash, and also convert the expectation to a URL and then back into a hash (this takes care of when you leave :controller out of the expectation). 2) If your redirect_to expectation is a hash, then the failure message will report the failure back as hashes. The previous error (expected hash but got string) was always a bit confusing. If your redirect_to expectation is a string or :back, then you will continue to get the old behavior: a direct string comparison (which may or may not be tripped up by query string order). I created the patch against version 0.8.3, because that is what I'm using, but the redirect_to matcher does not appear to have changed much (at all?) in trunk, and the patch applied cleanly. Although all of the specs using redirect_to in my app still work, I was having difficulties getting "rake precommit" to run correctly... Sorry. :-( ---------------------------------------------------------------------- >Comment By: nicholas evans (nick_evans) Date: 2007-04-28 01:11 Message: Placed judiciously inside the spec_helper.rb: ActionController::Routing.controller_paths << "#{dir}/../spec_resources/controllers" That was easy! :-) ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-28 00:03 Message: This sounds right. As things stand right now, these controllers are only included (from rspec_on_rails/spec/spec_helper.rb) when you run the specs for rspec_on_rails itself, so that problem is solved. Whatever monkey patching may be necessary to coerce routing into looking at the rspec_on_rails/spec_resources directory could also be included in the same file. Thanks for playing! I look forward to getting this in place. Cheers, David ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 23:46 Message: I was afraid that you might say that. ;-) I just wanted to tackle one problem at a time. My thought is that the only way to make this work would be to convince Rails routing to consider the rspec_on_rails controllers (or only the RedirectSpecController). I don't know the syntax for how to do that exactly, but I can search inside the code for rails engines or appable plugins to find out how they've done it. Hopefully I can find a minimally invasive method for doing this. The additional problem with that is that we certainly wouldn't want the rspec_on_rails plugin to be adding any controllers (or otherwise mucking with the environment) to every app that its included in, even in the test environment. We really only want this functionality to be triggered when the rspec_on_rails plugin specs are being run. Can this be accomplished simply by only putting the controller loading code into rspec_on_rails's spec_helper.rb? I don't know how to do either of these things at the moment, but I'll look into them both. But (unless something else comes up), I think this should solve our problem... right? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-27 19:44 Message: Hey Nick - thanks for the effort, but this patch presents a problem. To get the routing to work, it looks like you moved redirect_spec_controller.rb from rspec_on_rails/spec_resources to the example_rails_app. We've gone through great pains to decouple the plugin from the app, which is why all of the controllers for the specs that live in rspec_on_rails/spec/ are in rspec_on_rails/spec_resources. We need to figure out a way to maintain the location before I'm willing to apply this patch. Any ideas? I hope we can come up w/ something because it's a nice patch otherwise. Cheers, David ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 19:03 Message: D'oh! I had a copy/paste error... bad description text for the final new spec. $ diff passing_specs_including_new_error_behavior* 169c169 < + it "redirected to an internal URL which is unroutable but matched via a string" do --- > + it "redirected to an internal URL which is unroutable and matched via a hash" do ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 18:50 Message: As promised, I'm attaching the completed specs, including specs for the new error behavior: "response.should redirect_to(hash)" should fail if the redirection is not to a URL that is routable within the application. Same 3-step directions for application apply as with the last patch. I didn't add back the "failure message should print actual redirection as a hash when expectation is for a hash" behavior, because that extra layer of redirection was only really annoying when I couldn't depend on rails and rspec to behave nicely with their URLs. I don't really mind that the failure message compares a hash and a string now. :-) ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 18:27 Message: Two comments on the passing specs patch: 1) because "svn mv" doesn't translate well into the diff format, you'll want to apply it with the following three commands: svn cp rspec_on_rails/spec_resources/controllers/redirect_spec_controller.rb example_rails_app/app/controllers/redirect_spec_controller.rb patch -p0 < passes_specs.patch svn rm rspec_on_rails/spec_resources/controllers/redirect_spec_controller.rb --force 2) I haven't yet added the specs for the additional failure behavior (I actually reverted the failure message behavior that I originally added, and then added some new behavior for the new error type), but I'll get to that momentarily (with another patch). ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 18:25 Message: Okay, I figured out what the problem is: Since I'm converting the URL string back into a hash containing the controller, action, etc, the URL must be routable within the application. However, url_for and ActionController::Routing::Routes.generate have no such restrictions. For example: >> ActionController::Routing::Routes.generate :controller => "foo", :action => "bar" => "/foo/bar" >> ActionController::Routing::Routes.recognize_path "/foo/bar" ActionController::RoutingError: no route found to match "/foo/bar" with {} from ./script/../config/../config/../vendor/rails/actionpack/lib/action_controller/routing.rb:1292:in `recognize_path' from (irb):66 from :0 It seems reasonable to me to adjust the behavior of "response.should redirect_to" so that it returns an error if the controller attempts to redirect to an non-routable URL when your spec is trying to match against it by using a hash. If you want to spec against a URL that lives outside of your application's ability to route, you should probably be spec'ing against the string, right? At least, that's my current thought on the matter. It might be seen as a major change in behavior for the redirect_to matcher. What do you think? So, the controllers that are stored in the rspec_on_rails plugin are not recognized by the example_rails_app's routing. If I move redirect_spec_controller.rb from the plugin into the example app (and remove the require from spec_helper.rb), that allows almost all of the specs to pass. The only specs that don't pass then are the two that redirect to :controller => "other", which is the same error. If I change those to redirect to :controller => "people", then their errors go away as well. ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 18:14 Message: A comment on the failing specs patch and how to reproduce the failures: the first spec will fail only very occasionally... like... say, only on the continuous integration server and not on your development laptop and only when you commit your last change for the day and need to get home. The second and third of the two specs are attempting to replicate the conditions that semi-randomly occur within the first spec. Thus, one and only one of them will always fail, but which one is dependent upon when a particular African butterfly has last flapped its wings. :-) ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 18:09 Message: Yep. I'm using sqlite. It seemed like it should be simpler than mysql. :-) (our production environment is running on SQL Server, which is emphatically *not* simpler than running on mysql.) $ dpkg -l|grep 'libsqlite\|sqlite.*ruby'|awk '{print $3,$2}' 0.0.23-3 libdbd-sqlite3-ruby 0.0.23-3 libdbd-sqlite3-ruby1.8 3.3.5-0.2 libsqlite3-0 1.1.0-2 libsqlite3-ruby 1.1.0-2 libsqlite3-ruby1.8 ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-27 15:59 Message: re: seg faults - are you using sqlite? Which version? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-27 15:59 Message: Thanks Nicholas - the pre-patch-failing specs would be especially great. Cheers, David ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 15:36 Message: Well, I can't run all of the specs, and I don't really know why, but I can run the redirect_to_spec.rb. I'll fix the patch to pass all of the tests in there, and I'll add another couple of specs which should fail without my patch. ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 12:50 Message: Now I'm getting segfaults when I run rake pre_commit! running against rails 1.2.3: ** Invoke environment ** Execute db:schema:load ** Execute spec:plugins /home/nevans/src/rspec/example_rails_app/vendor/rails/1.2.3/activerecord/lib/../../activesupport/lib/active_support/core_ext/object/extending.rb:27: [BUG] Segmentation fault ruby 1.8.4 (2005-12-24) [i486-linux] Aborted (core dumped) rake aborted! Command ruby -I"/home/nevans/src/rspec/rspec/lib" "/home/nevans/src/rspec/rspec/bin/spec" "vendor/plugins/rspec_on_rails/spec/rails/extensions/active_record_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/dsl/assigns_hash_proxy_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/dsl/ivar_proxy_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/assert_select_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/redirect_to_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/render_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/description_generation_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/controller_isolation_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/view_spec_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/helper_spec_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/behaviour_factory_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/controller_spec_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/test_unit_assertion_accessibility_spec.rb" --options "/home/nevans/src/rspec/example_rails_app/config/../spec/spec.opts" failed /home/nevans/src/rspec/rspec/lib/spec/rake/spectask.rb:131:in `define' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:835:in `verbose' /home/nevans/src/rspec/rspec/lib/spec/rake/spectask.rb:105:in `define' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:399:in `execute' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:399:in `execute' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:369:in `invoke' /usr/lib/ruby/1.8/thread.rb:135:in `synchronize' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:362:in `invoke' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:1935:in `run' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:1935:in `run' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/bin/rake:7 /usr/bin/rake:16 I deleted rails 1.2.3 and ran against 1.2.2 (which is what my other apps are using), and dies in the same location: ** Invoke environment ** Execute db:schema:load ** Execute spec:plugins /home/nevans/src/rspec/rspec/lib/spec/dsl/behaviour_callbacks.rb:48: [BUG] Segmentation fault ruby 1.8.4 (2005-12-24) [i486-linux] Aborted (core dumped) rake aborted! Command ruby -I"/home/nevans/src/rspec/rspec/lib" "/home/nevans/src/rspec/rspec/bin/spec" "vendor/plugins/rspec_on_rails/spec/rails/extensions/active_record_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/dsl/assigns_hash_proxy_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/dsl/ivar_proxy_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/assert_select_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/redirect_to_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/render_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/description_generation_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/controller_isolation_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/view_spec_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/helper_spec_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/behaviour_factory_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/controller_spec_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/test_unit_assertion_accessibility_spec.rb" --options "/home/nevans/src/rspec/example_rails_app/config/../spec/spec.opts" failed /home/nevans/src/rspec/rspec/lib/spec/rake/spectask.rb:131:in `define' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:835:in `verbose' /home/nevans/src/rspec/rspec/lib/spec/rake/spectask.rb:105:in `define' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:399:in `execute' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:399:in `execute' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:369:in `invoke' /usr/lib/ruby/1.8/thread.rb:135:in `synchronize' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:362:in `invoke' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:1935:in `run' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:1935:in `run' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/bin/rake:7 /usr/bin/rake:16 I'm running the Ubuntu Edgy version of ruby, which dpkg reports as 1.8.2, but ruby -v reports as 1.8.4. ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 12:28 Message: I found "rake rspec:generate_sqlite_config", and I'm working on getting the precommit bugs fixed now. ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 12:24 Message: More specific explanation of my rake precommit trouble: I was being lazy and didn't bother to debug the problem. It was complaining because config/database.yml was missing. I've looked into the example rails app, and there seems to be some rake tasks for creating a sample sqlite db, so I'll look into that now. Is there a particular magic sequence that could be issued to make it "just work" upon checkout? :-) ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-27 11:34 Message: That was 18 of 38 examples. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-27 11:25 Message: I tried to apply this and 18 of the 18 examples in redirect_to_spec.rb fail. Some are due to the changes you made to the failure messages - some for other reasons I haven't looked at yet. You said you were having trouble getting it to run - can you be more specific? Thanks, David ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=10410&group_id=797 From noreply at rubyforge.org Sat Apr 28 01:16:34 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sat, 28 Apr 2007 01:16:34 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-10410 ] redirect_to does not behave consistently with regards to query string parameter ordering Message-ID: <20070428051634.9F31F5240BF5@rubyforge.org> Patches item #10410, was opened at 2007-04-27 11:01 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=10410&group_id=797 Category: expectation module Group: None Status: Open Resolution: None Priority: 3 Submitted By: nicholas evans (nick_evans) Assigned to: Nobody (None) Summary: redirect_to does not behave consistently with regards to query string parameter ordering Initial Comment: This bug is *incredibly* difficult to reproduce. It ends up causing a spec to pass when run as a single file and fail when run as a group of files... or vice versa. Or pass on one computer, but fail on another. Or pass in an old working copy, but fail when re-checked out. Or pass when running the normal rake task, but fail when generating an HTML support. And so on and so forth! As you might imagine this can make continuous integration rather annoying. The problem is that rails will place the items in a hash into the query string in a semi-random order. Given similar hashes, the same URL will *usually* be generated by each. But often enough to be annoying, that is not the case. This is simply due to the unordered nature of hashes. So I made a patch to redirect_to to do two things: 1) If your redirect_to expectation is a hash, and the actual redirection is within http://test.host it will convert the actual redirect_url to a hash, and also convert the expectation to a URL and then back into a hash (this takes care of when you leave :controller out of the expectation). 2) If your redirect_to expectation is a hash, then the failure message will report the failure back as hashes. The previous error (expected hash but got string) was always a bit confusing. If your redirect_to expectation is a string or :back, then you will continue to get the old behavior: a direct string comparison (which may or may not be tripped up by query string order). I created the patch against version 0.8.3, because that is what I'm using, but the redirect_to matcher does not appear to have changed much (at all?) in trunk, and the patch applied cleanly. Although all of the specs using redirect_to in my app still work, I was having difficulties getting "rake precommit" to run correctly... Sorry. :-( ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-28 01:11 Message: Placed judiciously inside the spec_helper.rb: ActionController::Routing.controller_paths << "#{dir}/../spec_resources/controllers" That was easy! :-) ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-28 00:03 Message: This sounds right. As things stand right now, these controllers are only included (from rspec_on_rails/spec/spec_helper.rb) when you run the specs for rspec_on_rails itself, so that problem is solved. Whatever monkey patching may be necessary to coerce routing into looking at the rspec_on_rails/spec_resources directory could also be included in the same file. Thanks for playing! I look forward to getting this in place. Cheers, David ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 23:46 Message: I was afraid that you might say that. ;-) I just wanted to tackle one problem at a time. My thought is that the only way to make this work would be to convince Rails routing to consider the rspec_on_rails controllers (or only the RedirectSpecController). I don't know the syntax for how to do that exactly, but I can search inside the code for rails engines or appable plugins to find out how they've done it. Hopefully I can find a minimally invasive method for doing this. The additional problem with that is that we certainly wouldn't want the rspec_on_rails plugin to be adding any controllers (or otherwise mucking with the environment) to every app that its included in, even in the test environment. We really only want this functionality to be triggered when the rspec_on_rails plugin specs are being run. Can this be accomplished simply by only putting the controller loading code into rspec_on_rails's spec_helper.rb? I don't know how to do either of these things at the moment, but I'll look into them both. But (unless something else comes up), I think this should solve our problem... right? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-27 19:44 Message: Hey Nick - thanks for the effort, but this patch presents a problem. To get the routing to work, it looks like you moved redirect_spec_controller.rb from rspec_on_rails/spec_resources to the example_rails_app. We've gone through great pains to decouple the plugin from the app, which is why all of the controllers for the specs that live in rspec_on_rails/spec/ are in rspec_on_rails/spec_resources. We need to figure out a way to maintain the location before I'm willing to apply this patch. Any ideas? I hope we can come up w/ something because it's a nice patch otherwise. Cheers, David ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 19:03 Message: D'oh! I had a copy/paste error... bad description text for the final new spec. $ diff passing_specs_including_new_error_behavior* 169c169 < + it "redirected to an internal URL which is unroutable but matched via a string" do --- > + it "redirected to an internal URL which is unroutable and matched via a hash" do ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 18:50 Message: As promised, I'm attaching the completed specs, including specs for the new error behavior: "response.should redirect_to(hash)" should fail if the redirection is not to a URL that is routable within the application. Same 3-step directions for application apply as with the last patch. I didn't add back the "failure message should print actual redirection as a hash when expectation is for a hash" behavior, because that extra layer of redirection was only really annoying when I couldn't depend on rails and rspec to behave nicely with their URLs. I don't really mind that the failure message compares a hash and a string now. :-) ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 18:27 Message: Two comments on the passing specs patch: 1) because "svn mv" doesn't translate well into the diff format, you'll want to apply it with the following three commands: svn cp rspec_on_rails/spec_resources/controllers/redirect_spec_controller.rb example_rails_app/app/controllers/redirect_spec_controller.rb patch -p0 < passes_specs.patch svn rm rspec_on_rails/spec_resources/controllers/redirect_spec_controller.rb --force 2) I haven't yet added the specs for the additional failure behavior (I actually reverted the failure message behavior that I originally added, and then added some new behavior for the new error type), but I'll get to that momentarily (with another patch). ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 18:25 Message: Okay, I figured out what the problem is: Since I'm converting the URL string back into a hash containing the controller, action, etc, the URL must be routable within the application. However, url_for and ActionController::Routing::Routes.generate have no such restrictions. For example: >> ActionController::Routing::Routes.generate :controller => "foo", :action => "bar" => "/foo/bar" >> ActionController::Routing::Routes.recognize_path "/foo/bar" ActionController::RoutingError: no route found to match "/foo/bar" with {} from ./script/../config/../config/../vendor/rails/actionpack/lib/action_controller/routing.rb:1292:in `recognize_path' from (irb):66 from :0 It seems reasonable to me to adjust the behavior of "response.should redirect_to" so that it returns an error if the controller attempts to redirect to an non-routable URL when your spec is trying to match against it by using a hash. If you want to spec against a URL that lives outside of your application's ability to route, you should probably be spec'ing against the string, right? At least, that's my current thought on the matter. It might be seen as a major change in behavior for the redirect_to matcher. What do you think? So, the controllers that are stored in the rspec_on_rails plugin are not recognized by the example_rails_app's routing. If I move redirect_spec_controller.rb from the plugin into the example app (and remove the require from spec_helper.rb), that allows almost all of the specs to pass. The only specs that don't pass then are the two that redirect to :controller => "other", which is the same error. If I change those to redirect to :controller => "people", then their errors go away as well. ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 18:14 Message: A comment on the failing specs patch and how to reproduce the failures: the first spec will fail only very occasionally... like... say, only on the continuous integration server and not on your development laptop and only when you commit your last change for the day and need to get home. The second and third of the two specs are attempting to replicate the conditions that semi-randomly occur within the first spec. Thus, one and only one of them will always fail, but which one is dependent upon when a particular African butterfly has last flapped its wings. :-) ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 18:09 Message: Yep. I'm using sqlite. It seemed like it should be simpler than mysql. :-) (our production environment is running on SQL Server, which is emphatically *not* simpler than running on mysql.) $ dpkg -l|grep 'libsqlite\|sqlite.*ruby'|awk '{print $3,$2}' 0.0.23-3 libdbd-sqlite3-ruby 0.0.23-3 libdbd-sqlite3-ruby1.8 3.3.5-0.2 libsqlite3-0 1.1.0-2 libsqlite3-ruby 1.1.0-2 libsqlite3-ruby1.8 ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-27 15:59 Message: re: seg faults - are you using sqlite? Which version? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-27 15:59 Message: Thanks Nicholas - the pre-patch-failing specs would be especially great. Cheers, David ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 15:36 Message: Well, I can't run all of the specs, and I don't really know why, but I can run the redirect_to_spec.rb. I'll fix the patch to pass all of the tests in there, and I'll add another couple of specs which should fail without my patch. ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 12:50 Message: Now I'm getting segfaults when I run rake pre_commit! running against rails 1.2.3: ** Invoke environment ** Execute db:schema:load ** Execute spec:plugins /home/nevans/src/rspec/example_rails_app/vendor/rails/1.2.3/activerecord/lib/../../activesupport/lib/active_support/core_ext/object/extending.rb:27: [BUG] Segmentation fault ruby 1.8.4 (2005-12-24) [i486-linux] Aborted (core dumped) rake aborted! Command ruby -I"/home/nevans/src/rspec/rspec/lib" "/home/nevans/src/rspec/rspec/bin/spec" "vendor/plugins/rspec_on_rails/spec/rails/extensions/active_record_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/dsl/assigns_hash_proxy_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/dsl/ivar_proxy_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/assert_select_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/redirect_to_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/render_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/description_generation_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/controller_isolation_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/view_spec_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/helper_spec_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/behaviour_factory_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/controller_spec_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/test_unit_assertion_accessibility_spec.rb" --options "/home/nevans/src/rspec/example_rails_app/config/../spec/spec.opts" failed /home/nevans/src/rspec/rspec/lib/spec/rake/spectask.rb:131:in `define' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:835:in `verbose' /home/nevans/src/rspec/rspec/lib/spec/rake/spectask.rb:105:in `define' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:399:in `execute' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:399:in `execute' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:369:in `invoke' /usr/lib/ruby/1.8/thread.rb:135:in `synchronize' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:362:in `invoke' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:1935:in `run' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:1935:in `run' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/bin/rake:7 /usr/bin/rake:16 I deleted rails 1.2.3 and ran against 1.2.2 (which is what my other apps are using), and dies in the same location: ** Invoke environment ** Execute db:schema:load ** Execute spec:plugins /home/nevans/src/rspec/rspec/lib/spec/dsl/behaviour_callbacks.rb:48: [BUG] Segmentation fault ruby 1.8.4 (2005-12-24) [i486-linux] Aborted (core dumped) rake aborted! Command ruby -I"/home/nevans/src/rspec/rspec/lib" "/home/nevans/src/rspec/rspec/bin/spec" "vendor/plugins/rspec_on_rails/spec/rails/extensions/active_record_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/dsl/assigns_hash_proxy_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/dsl/ivar_proxy_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/assert_select_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/redirect_to_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/render_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/description_generation_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/controller_isolation_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/view_spec_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/helper_spec_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/behaviour_factory_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/controller_spec_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/test_unit_assertion_accessibility_spec.rb" --options "/home/nevans/src/rspec/example_rails_app/config/../spec/spec.opts" failed /home/nevans/src/rspec/rspec/lib/spec/rake/spectask.rb:131:in `define' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:835:in `verbose' /home/nevans/src/rspec/rspec/lib/spec/rake/spectask.rb:105:in `define' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:399:in `execute' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:399:in `execute' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:369:in `invoke' /usr/lib/ruby/1.8/thread.rb:135:in `synchronize' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:362:in `invoke' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:1935:in `run' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:1935:in `run' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/bin/rake:7 /usr/bin/rake:16 I'm running the Ubuntu Edgy version of ruby, which dpkg reports as 1.8.2, but ruby -v reports as 1.8.4. ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 12:28 Message: I found "rake rspec:generate_sqlite_config", and I'm working on getting the precommit bugs fixed now. ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 12:24 Message: More specific explanation of my rake precommit trouble: I was being lazy and didn't bother to debug the problem. It was complaining because config/database.yml was missing. I've looked into the example rails app, and there seems to be some rake tasks for creating a sample sqlite db, so I'll look into that now. Is there a particular magic sequence that could be issued to make it "just work" upon checkout? :-) ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-27 11:34 Message: That was 18 of 38 examples. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-27 11:25 Message: I tried to apply this and 18 of the 18 examples in redirect_to_spec.rb fail. Some are due to the changes you made to the failure messages - some for other reasons I haven't looked at yet. You said you were having trouble getting it to run - can you be more specific? Thanks, David ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=10410&group_id=797 From noreply at rubyforge.org Sat Apr 28 01:20:17 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sat, 28 Apr 2007 01:20:17 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-10410 ] redirect_to does not behave consistently with regards to query string parameter ordering Message-ID: <20070428052018.196295240C05@rubyforge.org> Patches item #10410, was opened at 2007-04-27 11:01 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=10410&group_id=797 Category: expectation module Group: None Status: Open Resolution: None Priority: 3 Submitted By: nicholas evans (nick_evans) Assigned to: Nobody (None) Summary: redirect_to does not behave consistently with regards to query string parameter ordering Initial Comment: This bug is *incredibly* difficult to reproduce. It ends up causing a spec to pass when run as a single file and fail when run as a group of files... or vice versa. Or pass on one computer, but fail on another. Or pass in an old working copy, but fail when re-checked out. Or pass when running the normal rake task, but fail when generating an HTML support. And so on and so forth! As you might imagine this can make continuous integration rather annoying. The problem is that rails will place the items in a hash into the query string in a semi-random order. Given similar hashes, the same URL will *usually* be generated by each. But often enough to be annoying, that is not the case. This is simply due to the unordered nature of hashes. So I made a patch to redirect_to to do two things: 1) If your redirect_to expectation is a hash, and the actual redirection is within http://test.host it will convert the actual redirect_url to a hash, and also convert the expectation to a URL and then back into a hash (this takes care of when you leave :controller out of the expectation). 2) If your redirect_to expectation is a hash, then the failure message will report the failure back as hashes. The previous error (expected hash but got string) was always a bit confusing. If your redirect_to expectation is a string or :back, then you will continue to get the old behavior: a direct string comparison (which may or may not be tripped up by query string order). I created the patch against version 0.8.3, because that is what I'm using, but the redirect_to matcher does not appear to have changed much (at all?) in trunk, and the patch applied cleanly. Although all of the specs using redirect_to in my app still work, I was having difficulties getting "rake precommit" to run correctly... Sorry. :-( ---------------------------------------------------------------------- >Comment By: nicholas evans (nick_evans) Date: 2007-04-28 01:20 Message: Oh... I just tried it out with rails 1.1.6... and it failed horribly. ActionController::Routing.controller_paths is a Rails 1.2 feature! :-( ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-28 01:11 Message: Placed judiciously inside the spec_helper.rb: ActionController::Routing.controller_paths << "#{dir}/../spec_resources/controllers" That was easy! :-) ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-28 00:03 Message: This sounds right. As things stand right now, these controllers are only included (from rspec_on_rails/spec/spec_helper.rb) when you run the specs for rspec_on_rails itself, so that problem is solved. Whatever monkey patching may be necessary to coerce routing into looking at the rspec_on_rails/spec_resources directory could also be included in the same file. Thanks for playing! I look forward to getting this in place. Cheers, David ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 23:46 Message: I was afraid that you might say that. ;-) I just wanted to tackle one problem at a time. My thought is that the only way to make this work would be to convince Rails routing to consider the rspec_on_rails controllers (or only the RedirectSpecController). I don't know the syntax for how to do that exactly, but I can search inside the code for rails engines or appable plugins to find out how they've done it. Hopefully I can find a minimally invasive method for doing this. The additional problem with that is that we certainly wouldn't want the rspec_on_rails plugin to be adding any controllers (or otherwise mucking with the environment) to every app that its included in, even in the test environment. We really only want this functionality to be triggered when the rspec_on_rails plugin specs are being run. Can this be accomplished simply by only putting the controller loading code into rspec_on_rails's spec_helper.rb? I don't know how to do either of these things at the moment, but I'll look into them both. But (unless something else comes up), I think this should solve our problem... right? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-27 19:44 Message: Hey Nick - thanks for the effort, but this patch presents a problem. To get the routing to work, it looks like you moved redirect_spec_controller.rb from rspec_on_rails/spec_resources to the example_rails_app. We've gone through great pains to decouple the plugin from the app, which is why all of the controllers for the specs that live in rspec_on_rails/spec/ are in rspec_on_rails/spec_resources. We need to figure out a way to maintain the location before I'm willing to apply this patch. Any ideas? I hope we can come up w/ something because it's a nice patch otherwise. Cheers, David ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 19:03 Message: D'oh! I had a copy/paste error... bad description text for the final new spec. $ diff passing_specs_including_new_error_behavior* 169c169 < + it "redirected to an internal URL which is unroutable but matched via a string" do --- > + it "redirected to an internal URL which is unroutable and matched via a hash" do ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 18:50 Message: As promised, I'm attaching the completed specs, including specs for the new error behavior: "response.should redirect_to(hash)" should fail if the redirection is not to a URL that is routable within the application. Same 3-step directions for application apply as with the last patch. I didn't add back the "failure message should print actual redirection as a hash when expectation is for a hash" behavior, because that extra layer of redirection was only really annoying when I couldn't depend on rails and rspec to behave nicely with their URLs. I don't really mind that the failure message compares a hash and a string now. :-) ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 18:27 Message: Two comments on the passing specs patch: 1) because "svn mv" doesn't translate well into the diff format, you'll want to apply it with the following three commands: svn cp rspec_on_rails/spec_resources/controllers/redirect_spec_controller.rb example_rails_app/app/controllers/redirect_spec_controller.rb patch -p0 < passes_specs.patch svn rm rspec_on_rails/spec_resources/controllers/redirect_spec_controller.rb --force 2) I haven't yet added the specs for the additional failure behavior (I actually reverted the failure message behavior that I originally added, and then added some new behavior for the new error type), but I'll get to that momentarily (with another patch). ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 18:25 Message: Okay, I figured out what the problem is: Since I'm converting the URL string back into a hash containing the controller, action, etc, the URL must be routable within the application. However, url_for and ActionController::Routing::Routes.generate have no such restrictions. For example: >> ActionController::Routing::Routes.generate :controller => "foo", :action => "bar" => "/foo/bar" >> ActionController::Routing::Routes.recognize_path "/foo/bar" ActionController::RoutingError: no route found to match "/foo/bar" with {} from ./script/../config/../config/../vendor/rails/actionpack/lib/action_controller/routing.rb:1292:in `recognize_path' from (irb):66 from :0 It seems reasonable to me to adjust the behavior of "response.should redirect_to" so that it returns an error if the controller attempts to redirect to an non-routable URL when your spec is trying to match against it by using a hash. If you want to spec against a URL that lives outside of your application's ability to route, you should probably be spec'ing against the string, right? At least, that's my current thought on the matter. It might be seen as a major change in behavior for the redirect_to matcher. What do you think? So, the controllers that are stored in the rspec_on_rails plugin are not recognized by the example_rails_app's routing. If I move redirect_spec_controller.rb from the plugin into the example app (and remove the require from spec_helper.rb), that allows almost all of the specs to pass. The only specs that don't pass then are the two that redirect to :controller => "other", which is the same error. If I change those to redirect to :controller => "people", then their errors go away as well. ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 18:14 Message: A comment on the failing specs patch and how to reproduce the failures: the first spec will fail only very occasionally... like... say, only on the continuous integration server and not on your development laptop and only when you commit your last change for the day and need to get home. The second and third of the two specs are attempting to replicate the conditions that semi-randomly occur within the first spec. Thus, one and only one of them will always fail, but which one is dependent upon when a particular African butterfly has last flapped its wings. :-) ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 18:09 Message: Yep. I'm using sqlite. It seemed like it should be simpler than mysql. :-) (our production environment is running on SQL Server, which is emphatically *not* simpler than running on mysql.) $ dpkg -l|grep 'libsqlite\|sqlite.*ruby'|awk '{print $3,$2}' 0.0.23-3 libdbd-sqlite3-ruby 0.0.23-3 libdbd-sqlite3-ruby1.8 3.3.5-0.2 libsqlite3-0 1.1.0-2 libsqlite3-ruby 1.1.0-2 libsqlite3-ruby1.8 ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-27 15:59 Message: re: seg faults - are you using sqlite? Which version? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-27 15:59 Message: Thanks Nicholas - the pre-patch-failing specs would be especially great. Cheers, David ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 15:36 Message: Well, I can't run all of the specs, and I don't really know why, but I can run the redirect_to_spec.rb. I'll fix the patch to pass all of the tests in there, and I'll add another couple of specs which should fail without my patch. ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 12:50 Message: Now I'm getting segfaults when I run rake pre_commit! running against rails 1.2.3: ** Invoke environment ** Execute db:schema:load ** Execute spec:plugins /home/nevans/src/rspec/example_rails_app/vendor/rails/1.2.3/activerecord/lib/../../activesupport/lib/active_support/core_ext/object/extending.rb:27: [BUG] Segmentation fault ruby 1.8.4 (2005-12-24) [i486-linux] Aborted (core dumped) rake aborted! Command ruby -I"/home/nevans/src/rspec/rspec/lib" "/home/nevans/src/rspec/rspec/bin/spec" "vendor/plugins/rspec_on_rails/spec/rails/extensions/active_record_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/dsl/assigns_hash_proxy_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/dsl/ivar_proxy_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/assert_select_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/redirect_to_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/render_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/description_generation_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/controller_isolation_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/view_spec_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/helper_spec_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/behaviour_factory_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/controller_spec_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/test_unit_assertion_accessibility_spec.rb" --options "/home/nevans/src/rspec/example_rails_app/config/../spec/spec.opts" failed /home/nevans/src/rspec/rspec/lib/spec/rake/spectask.rb:131:in `define' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:835:in `verbose' /home/nevans/src/rspec/rspec/lib/spec/rake/spectask.rb:105:in `define' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:399:in `execute' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:399:in `execute' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:369:in `invoke' /usr/lib/ruby/1.8/thread.rb:135:in `synchronize' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:362:in `invoke' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:1935:in `run' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:1935:in `run' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/bin/rake:7 /usr/bin/rake:16 I deleted rails 1.2.3 and ran against 1.2.2 (which is what my other apps are using), and dies in the same location: ** Invoke environment ** Execute db:schema:load ** Execute spec:plugins /home/nevans/src/rspec/rspec/lib/spec/dsl/behaviour_callbacks.rb:48: [BUG] Segmentation fault ruby 1.8.4 (2005-12-24) [i486-linux] Aborted (core dumped) rake aborted! Command ruby -I"/home/nevans/src/rspec/rspec/lib" "/home/nevans/src/rspec/rspec/bin/spec" "vendor/plugins/rspec_on_rails/spec/rails/extensions/active_record_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/dsl/assigns_hash_proxy_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/dsl/ivar_proxy_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/assert_select_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/redirect_to_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/render_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/description_generation_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/controller_isolation_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/view_spec_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/helper_spec_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/behaviour_factory_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/controller_spec_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/test_unit_assertion_accessibility_spec.rb" --options "/home/nevans/src/rspec/example_rails_app/config/../spec/spec.opts" failed /home/nevans/src/rspec/rspec/lib/spec/rake/spectask.rb:131:in `define' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:835:in `verbose' /home/nevans/src/rspec/rspec/lib/spec/rake/spectask.rb:105:in `define' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:399:in `execute' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:399:in `execute' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:369:in `invoke' /usr/lib/ruby/1.8/thread.rb:135:in `synchronize' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:362:in `invoke' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:1935:in `run' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:1935:in `run' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/bin/rake:7 /usr/bin/rake:16 I'm running the Ubuntu Edgy version of ruby, which dpkg reports as 1.8.2, but ruby -v reports as 1.8.4. ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 12:28 Message: I found "rake rspec:generate_sqlite_config", and I'm working on getting the precommit bugs fixed now. ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 12:24 Message: More specific explanation of my rake precommit trouble: I was being lazy and didn't bother to debug the problem. It was complaining because config/database.yml was missing. I've looked into the example rails app, and there seems to be some rake tasks for creating a sample sqlite db, so I'll look into that now. Is there a particular magic sequence that could be issued to make it "just work" upon checkout? :-) ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-27 11:34 Message: That was 18 of 38 examples. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-27 11:25 Message: I tried to apply this and 18 of the 18 examples in redirect_to_spec.rb fail. Some are due to the changes you made to the failure messages - some for other reasons I haven't looked at yet. You said you were having trouble getting it to run - can you be more specific? Thanks, David ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=10410&group_id=797 From noreply at rubyforge.org Sat Apr 28 03:23:42 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sat, 28 Apr 2007 03:23:42 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-9983 ] Allow before_setup and after_teardown to be called in BehaviourEval Message-ID: <20070428072343.5876C5240BE5@rubyforge.org> Feature Requests item #9983, was opened at 2007-04-08 23:29 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=9983&group_id=797 Category: None Group: None >Status: Closed Priority: 3 Submitted By: Brian Takita (btakita) Assigned to: Nobody (None) Summary: Allow before_setup and after_teardown to be called in BehaviourEval Initial Comment: This would provide a hook for cross cutting. For example: Somebody wants to have setup and/or teardown functionality in a select few Examples. One may want to create a module and define the included method. module Foobar def self.included(mod) mod.before_setup do puts 'my special setup hook' end end end describe MyObject include Foobar end ---------------------------------------------------------------------- Comment By: Brian Takita (btakita) Date: 2007-04-23 22:54 Message: It looks like the current callback library may be obsolete in favor of the new implementation in behaviour_eval. Perhaps some common behaviour can be extracted. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-12 05:30 Message: before and after (:each or :all) have been implemented now. These are there for use within examples. The other methods are still around as aliases to avoid compatibility problems, so you don't have to change existing specs (yet). Looking through the code, we do have before_setup and after_teardown hooks in Example (formerly Specification). I think you actually added these, Brian. So we need to do two things: - Come up w/ better names given the new API. - Add these to Behaviour so that they are accessible (right now I don't think anybody is using them). ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-04-12 02:37 Message: Contexts are gone, and so are specify (ok, they are around a little bit longer for compatibility). We should come up with names that make sense with the new API. The following has been suggested in various emails and chats: before(what=:each) # you can also pass :all after(what=:each) # you can also pass :all ---------------------------------------------------------------------- Comment By: Brian Takita (btakita) Date: 2007-04-12 00:19 Message: Great. This would get run before each example. I think we both agree that before_setup provides value. That would bring 4 hooks. Actually there are also the global before_setup hooks. Maybe there should be global before_context_setup hooks too? Your idea with the setup methods arguments looks good. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-10 22:48 Message: Brian - what you say makes sense to me. Thanks for the explanation. RSpec currently supports a context_setup that happens once before all of the examples in a given context. So when is the hook supposed to get run? Before each example? Once before all examples? Would we want to have 4 hooks? before_context_setup, before_setup, and their teardown counterparts? On a side note, I'm planning to change setup so it takes an arg: def setup(scope=:each, &block) This will default to :each, but you can supply :all .... describe Thing do setup :all { ... } setup :each { ... } ... end So "setup :all" would replace context_setup (we'd leave context_setup for backwards compatibility). This might actually simplify this hook question because we could say: before_setup :each or before_setup :all WDYT? ---------------------------------------------------------------------- Comment By: Brian Takita (btakita) Date: 2007-04-10 22:03 Message: The objection I received, that I agree with, was a lack of cross cutting hooks. There are cases when a library developer would not want to require up to 3 touch points (include, setup, and teardown) to get the added feature set to run. In house, we have a number of helper packages that get applied only certain specs. For example, we have a module that hooks into TestCase that print how long the test took. Sometimes we want to apply to all of our tests, and sometimes we don't. Another example would be if you want some specs to print out the specdocs, but not others. At some level, it would be helpful to allow users to make 'plugins' of some type, rather than have to rely on editing core classes. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-09 03:59 Message: Right now you can do the following - would it suffice? # in a central location like spec_helper.rb module SpecialSetups def stuff_to_do_first ... end end Spec::Runner.configure do |config| config.include SpecialSetups end # in a spec file describe SomeObject do setup do stuff_to_do_first # other stuff end ... end This makes things a bit more transparent in the specs and is not really any more verbose if you've got a setup anyhow. WDYT? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=9983&group_id=797 From noreply at rubyforge.org Sat Apr 28 07:57:18 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sat, 28 Apr 2007 07:57:18 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-10410 ] redirect_to does not behave consistently with regards to query string parameter ordering Message-ID: <20070428115718.D713A5240A7D@rubyforge.org> Patches item #10410, was opened at 2007-04-27 15:01 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=10410&group_id=797 Category: expectation module Group: None Status: Open Resolution: None Priority: 3 Submitted By: nicholas evans (nick_evans) >Assigned to: David Chelimsky (dchelimsky) Summary: redirect_to does not behave consistently with regards to query string parameter ordering Initial Comment: This bug is *incredibly* difficult to reproduce. It ends up causing a spec to pass when run as a single file and fail when run as a group of files... or vice versa. Or pass on one computer, but fail on another. Or pass in an old working copy, but fail when re-checked out. Or pass when running the normal rake task, but fail when generating an HTML support. And so on and so forth! As you might imagine this can make continuous integration rather annoying. The problem is that rails will place the items in a hash into the query string in a semi-random order. Given similar hashes, the same URL will *usually* be generated by each. But often enough to be annoying, that is not the case. This is simply due to the unordered nature of hashes. So I made a patch to redirect_to to do two things: 1) If your redirect_to expectation is a hash, and the actual redirection is within http://test.host it will convert the actual redirect_url to a hash, and also convert the expectation to a URL and then back into a hash (this takes care of when you leave :controller out of the expectation). 2) If your redirect_to expectation is a hash, then the failure message will report the failure back as hashes. The previous error (expected hash but got string) was always a bit confusing. If your redirect_to expectation is a string or :back, then you will continue to get the old behavior: a direct string comparison (which may or may not be tripped up by query string order). I created the patch against version 0.8.3, because that is what I'm using, but the redirect_to matcher does not appear to have changed much (at all?) in trunk, and the patch applied cleanly. Although all of the specs using redirect_to in my app still work, I was having difficulties getting "rake precommit" to run correctly... Sorry. :-( ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-04-28 11:57 Message: Will this work (in spec_helper.rb)? Rails::Initializer.run do |config| config.controller_paths << "#{dir}/../spec_resources/controllers" end ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-28 05:20 Message: Oh... I just tried it out with rails 1.1.6... and it failed horribly. ActionController::Routing.controller_paths is a Rails 1.2 feature! :-( ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-28 05:11 Message: Placed judiciously inside the spec_helper.rb: ActionController::Routing.controller_paths << "#{dir}/../spec_resources/controllers" That was easy! :-) ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-28 04:03 Message: This sounds right. As things stand right now, these controllers are only included (from rspec_on_rails/spec/spec_helper.rb) when you run the specs for rspec_on_rails itself, so that problem is solved. Whatever monkey patching may be necessary to coerce routing into looking at the rspec_on_rails/spec_resources directory could also be included in the same file. Thanks for playing! I look forward to getting this in place. Cheers, David ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-28 03:46 Message: I was afraid that you might say that. ;-) I just wanted to tackle one problem at a time. My thought is that the only way to make this work would be to convince Rails routing to consider the rspec_on_rails controllers (or only the RedirectSpecController). I don't know the syntax for how to do that exactly, but I can search inside the code for rails engines or appable plugins to find out how they've done it. Hopefully I can find a minimally invasive method for doing this. The additional problem with that is that we certainly wouldn't want the rspec_on_rails plugin to be adding any controllers (or otherwise mucking with the environment) to every app that its included in, even in the test environment. We really only want this functionality to be triggered when the rspec_on_rails plugin specs are being run. Can this be accomplished simply by only putting the controller loading code into rspec_on_rails's spec_helper.rb? I don't know how to do either of these things at the moment, but I'll look into them both. But (unless something else comes up), I think this should solve our problem... right? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-27 23:44 Message: Hey Nick - thanks for the effort, but this patch presents a problem. To get the routing to work, it looks like you moved redirect_spec_controller.rb from rspec_on_rails/spec_resources to the example_rails_app. We've gone through great pains to decouple the plugin from the app, which is why all of the controllers for the specs that live in rspec_on_rails/spec/ are in rspec_on_rails/spec_resources. We need to figure out a way to maintain the location before I'm willing to apply this patch. Any ideas? I hope we can come up w/ something because it's a nice patch otherwise. Cheers, David ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 23:03 Message: D'oh! I had a copy/paste error... bad description text for the final new spec. $ diff passing_specs_including_new_error_behavior* 169c169 < + it "redirected to an internal URL which is unroutable but matched via a string" do --- > + it "redirected to an internal URL which is unroutable and matched via a hash" do ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 22:50 Message: As promised, I'm attaching the completed specs, including specs for the new error behavior: "response.should redirect_to(hash)" should fail if the redirection is not to a URL that is routable within the application. Same 3-step directions for application apply as with the last patch. I didn't add back the "failure message should print actual redirection as a hash when expectation is for a hash" behavior, because that extra layer of redirection was only really annoying when I couldn't depend on rails and rspec to behave nicely with their URLs. I don't really mind that the failure message compares a hash and a string now. :-) ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 22:27 Message: Two comments on the passing specs patch: 1) because "svn mv" doesn't translate well into the diff format, you'll want to apply it with the following three commands: svn cp rspec_on_rails/spec_resources/controllers/redirect_spec_controller.rb example_rails_app/app/controllers/redirect_spec_controller.rb patch -p0 < passes_specs.patch svn rm rspec_on_rails/spec_resources/controllers/redirect_spec_controller.rb --force 2) I haven't yet added the specs for the additional failure behavior (I actually reverted the failure message behavior that I originally added, and then added some new behavior for the new error type), but I'll get to that momentarily (with another patch). ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 22:25 Message: Okay, I figured out what the problem is: Since I'm converting the URL string back into a hash containing the controller, action, etc, the URL must be routable within the application. However, url_for and ActionController::Routing::Routes.generate have no such restrictions. For example: >> ActionController::Routing::Routes.generate :controller => "foo", :action => "bar" => "/foo/bar" >> ActionController::Routing::Routes.recognize_path "/foo/bar" ActionController::RoutingError: no route found to match "/foo/bar" with {} from ./script/../config/../config/../vendor/rails/actionpack/lib/action_controller/routing.rb:1292:in `recognize_path' from (irb):66 from :0 It seems reasonable to me to adjust the behavior of "response.should redirect_to" so that it returns an error if the controller attempts to redirect to an non-routable URL when your spec is trying to match against it by using a hash. If you want to spec against a URL that lives outside of your application's ability to route, you should probably be spec'ing against the string, right? At least, that's my current thought on the matter. It might be seen as a major change in behavior for the redirect_to matcher. What do you think? So, the controllers that are stored in the rspec_on_rails plugin are not recognized by the example_rails_app's routing. If I move redirect_spec_controller.rb from the plugin into the example app (and remove the require from spec_helper.rb), that allows almost all of the specs to pass. The only specs that don't pass then are the two that redirect to :controller => "other", which is the same error. If I change those to redirect to :controller => "people", then their errors go away as well. ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 22:14 Message: A comment on the failing specs patch and how to reproduce the failures: the first spec will fail only very occasionally... like... say, only on the continuous integration server and not on your development laptop and only when you commit your last change for the day and need to get home. The second and third of the two specs are attempting to replicate the conditions that semi-randomly occur within the first spec. Thus, one and only one of them will always fail, but which one is dependent upon when a particular African butterfly has last flapped its wings. :-) ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 22:09 Message: Yep. I'm using sqlite. It seemed like it should be simpler than mysql. :-) (our production environment is running on SQL Server, which is emphatically *not* simpler than running on mysql.) $ dpkg -l|grep 'libsqlite\|sqlite.*ruby'|awk '{print $3,$2}' 0.0.23-3 libdbd-sqlite3-ruby 0.0.23-3 libdbd-sqlite3-ruby1.8 3.3.5-0.2 libsqlite3-0 1.1.0-2 libsqlite3-ruby 1.1.0-2 libsqlite3-ruby1.8 ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-27 19:59 Message: re: seg faults - are you using sqlite? Which version? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-27 19:59 Message: Thanks Nicholas - the pre-patch-failing specs would be especially great. Cheers, David ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 19:36 Message: Well, I can't run all of the specs, and I don't really know why, but I can run the redirect_to_spec.rb. I'll fix the patch to pass all of the tests in there, and I'll add another couple of specs which should fail without my patch. ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 16:50 Message: Now I'm getting segfaults when I run rake pre_commit! running against rails 1.2.3: ** Invoke environment ** Execute db:schema:load ** Execute spec:plugins /home/nevans/src/rspec/example_rails_app/vendor/rails/1.2.3/activerecord/lib/../../activesupport/lib/active_support/core_ext/object/extending.rb:27: [BUG] Segmentation fault ruby 1.8.4 (2005-12-24) [i486-linux] Aborted (core dumped) rake aborted! Command ruby -I"/home/nevans/src/rspec/rspec/lib" "/home/nevans/src/rspec/rspec/bin/spec" "vendor/plugins/rspec_on_rails/spec/rails/extensions/active_record_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/dsl/assigns_hash_proxy_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/dsl/ivar_proxy_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/assert_select_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/redirect_to_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/render_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/description_generation_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/controller_isolation_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/view_spec_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/helper_spec_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/behaviour_factory_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/controller_spec_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/test_unit_assertion_accessibility_spec.rb" --options "/home/nevans/src/rspec/example_rails_app/config/../spec/spec.opts" failed /home/nevans/src/rspec/rspec/lib/spec/rake/spectask.rb:131:in `define' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:835:in `verbose' /home/nevans/src/rspec/rspec/lib/spec/rake/spectask.rb:105:in `define' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:399:in `execute' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:399:in `execute' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:369:in `invoke' /usr/lib/ruby/1.8/thread.rb:135:in `synchronize' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:362:in `invoke' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:1935:in `run' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:1935:in `run' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/bin/rake:7 /usr/bin/rake:16 I deleted rails 1.2.3 and ran against 1.2.2 (which is what my other apps are using), and dies in the same location: ** Invoke environment ** Execute db:schema:load ** Execute spec:plugins /home/nevans/src/rspec/rspec/lib/spec/dsl/behaviour_callbacks.rb:48: [BUG] Segmentation fault ruby 1.8.4 (2005-12-24) [i486-linux] Aborted (core dumped) rake aborted! Command ruby -I"/home/nevans/src/rspec/rspec/lib" "/home/nevans/src/rspec/rspec/bin/spec" "vendor/plugins/rspec_on_rails/spec/rails/extensions/active_record_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/dsl/assigns_hash_proxy_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/dsl/ivar_proxy_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/assert_select_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/redirect_to_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/render_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/description_generation_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/controller_isolation_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/view_spec_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/helper_spec_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/behaviour_factory_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/controller_spec_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/test_unit_assertion_accessibility_spec.rb" --options "/home/nevans/src/rspec/example_rails_app/config/../spec/spec.opts" failed /home/nevans/src/rspec/rspec/lib/spec/rake/spectask.rb:131:in `define' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:835:in `verbose' /home/nevans/src/rspec/rspec/lib/spec/rake/spectask.rb:105:in `define' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:399:in `execute' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:399:in `execute' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:369:in `invoke' /usr/lib/ruby/1.8/thread.rb:135:in `synchronize' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:362:in `invoke' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:1935:in `run' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:1935:in `run' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/bin/rake:7 /usr/bin/rake:16 I'm running the Ubuntu Edgy version of ruby, which dpkg reports as 1.8.2, but ruby -v reports as 1.8.4. ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 16:28 Message: I found "rake rspec:generate_sqlite_config", and I'm working on getting the precommit bugs fixed now. ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 16:24 Message: More specific explanation of my rake precommit trouble: I was being lazy and didn't bother to debug the problem. It was complaining because config/database.yml was missing. I've looked into the example rails app, and there seems to be some rake tasks for creating a sample sqlite db, so I'll look into that now. Is there a particular magic sequence that could be issued to make it "just work" upon checkout? :-) ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-27 15:34 Message: That was 18 of 38 examples. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-27 15:25 Message: I tried to apply this and 18 of the 18 examples in redirect_to_spec.rb fail. Some are due to the changes you made to the failure messages - some for other reasons I haven't looked at yet. You said you were having trouble getting it to run - can you be more specific? Thanks, David ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=10410&group_id=797 From noreply at rubyforge.org Sat Apr 28 08:34:24 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sat, 28 Apr 2007 08:34:24 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-10410 ] redirect_to does not behave consistently with regards to query string parameter ordering Message-ID: <20070428123424.B47F55240A7D@rubyforge.org> Patches item #10410, was opened at 2007-04-27 11:01 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=10410&group_id=797 Category: expectation module Group: None Status: Open Resolution: None Priority: 3 Submitted By: nicholas evans (nick_evans) Assigned to: David Chelimsky (dchelimsky) Summary: redirect_to does not behave consistently with regards to query string parameter ordering Initial Comment: This bug is *incredibly* difficult to reproduce. It ends up causing a spec to pass when run as a single file and fail when run as a group of files... or vice versa. Or pass on one computer, but fail on another. Or pass in an old working copy, but fail when re-checked out. Or pass when running the normal rake task, but fail when generating an HTML support. And so on and so forth! As you might imagine this can make continuous integration rather annoying. The problem is that rails will place the items in a hash into the query string in a semi-random order. Given similar hashes, the same URL will *usually* be generated by each. But often enough to be annoying, that is not the case. This is simply due to the unordered nature of hashes. So I made a patch to redirect_to to do two things: 1) If your redirect_to expectation is a hash, and the actual redirection is within http://test.host it will convert the actual redirect_url to a hash, and also convert the expectation to a URL and then back into a hash (this takes care of when you leave :controller out of the expectation). 2) If your redirect_to expectation is a hash, then the failure message will report the failure back as hashes. The previous error (expected hash but got string) was always a bit confusing. If your redirect_to expectation is a string or :back, then you will continue to get the old behavior: a direct string comparison (which may or may not be tripped up by query string order). I created the patch against version 0.8.3, because that is what I'm using, but the redirect_to matcher does not appear to have changed much (at all?) in trunk, and the patch applied cleanly. Although all of the specs using redirect_to in my app still work, I was having difficulties getting "rake precommit" to run correctly... Sorry. :-( ---------------------------------------------------------------------- >Comment By: nicholas evans (nick_evans) Date: 2007-04-28 08:34 Message: That works for 1.2, but not 1.1.6 ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-28 07:57 Message: Will this work (in spec_helper.rb)? Rails::Initializer.run do |config| config.controller_paths << "#{dir}/../spec_resources/controllers" end ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-28 01:20 Message: Oh... I just tried it out with rails 1.1.6... and it failed horribly. ActionController::Routing.controller_paths is a Rails 1.2 feature! :-( ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-28 01:11 Message: Placed judiciously inside the spec_helper.rb: ActionController::Routing.controller_paths << "#{dir}/../spec_resources/controllers" That was easy! :-) ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-28 00:03 Message: This sounds right. As things stand right now, these controllers are only included (from rspec_on_rails/spec/spec_helper.rb) when you run the specs for rspec_on_rails itself, so that problem is solved. Whatever monkey patching may be necessary to coerce routing into looking at the rspec_on_rails/spec_resources directory could also be included in the same file. Thanks for playing! I look forward to getting this in place. Cheers, David ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 23:46 Message: I was afraid that you might say that. ;-) I just wanted to tackle one problem at a time. My thought is that the only way to make this work would be to convince Rails routing to consider the rspec_on_rails controllers (or only the RedirectSpecController). I don't know the syntax for how to do that exactly, but I can search inside the code for rails engines or appable plugins to find out how they've done it. Hopefully I can find a minimally invasive method for doing this. The additional problem with that is that we certainly wouldn't want the rspec_on_rails plugin to be adding any controllers (or otherwise mucking with the environment) to every app that its included in, even in the test environment. We really only want this functionality to be triggered when the rspec_on_rails plugin specs are being run. Can this be accomplished simply by only putting the controller loading code into rspec_on_rails's spec_helper.rb? I don't know how to do either of these things at the moment, but I'll look into them both. But (unless something else comes up), I think this should solve our problem... right? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-27 19:44 Message: Hey Nick - thanks for the effort, but this patch presents a problem. To get the routing to work, it looks like you moved redirect_spec_controller.rb from rspec_on_rails/spec_resources to the example_rails_app. We've gone through great pains to decouple the plugin from the app, which is why all of the controllers for the specs that live in rspec_on_rails/spec/ are in rspec_on_rails/spec_resources. We need to figure out a way to maintain the location before I'm willing to apply this patch. Any ideas? I hope we can come up w/ something because it's a nice patch otherwise. Cheers, David ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 19:03 Message: D'oh! I had a copy/paste error... bad description text for the final new spec. $ diff passing_specs_including_new_error_behavior* 169c169 < + it "redirected to an internal URL which is unroutable but matched via a string" do --- > + it "redirected to an internal URL which is unroutable and matched via a hash" do ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 18:50 Message: As promised, I'm attaching the completed specs, including specs for the new error behavior: "response.should redirect_to(hash)" should fail if the redirection is not to a URL that is routable within the application. Same 3-step directions for application apply as with the last patch. I didn't add back the "failure message should print actual redirection as a hash when expectation is for a hash" behavior, because that extra layer of redirection was only really annoying when I couldn't depend on rails and rspec to behave nicely with their URLs. I don't really mind that the failure message compares a hash and a string now. :-) ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 18:27 Message: Two comments on the passing specs patch: 1) because "svn mv" doesn't translate well into the diff format, you'll want to apply it with the following three commands: svn cp rspec_on_rails/spec_resources/controllers/redirect_spec_controller.rb example_rails_app/app/controllers/redirect_spec_controller.rb patch -p0 < passes_specs.patch svn rm rspec_on_rails/spec_resources/controllers/redirect_spec_controller.rb --force 2) I haven't yet added the specs for the additional failure behavior (I actually reverted the failure message behavior that I originally added, and then added some new behavior for the new error type), but I'll get to that momentarily (with another patch). ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 18:25 Message: Okay, I figured out what the problem is: Since I'm converting the URL string back into a hash containing the controller, action, etc, the URL must be routable within the application. However, url_for and ActionController::Routing::Routes.generate have no such restrictions. For example: >> ActionController::Routing::Routes.generate :controller => "foo", :action => "bar" => "/foo/bar" >> ActionController::Routing::Routes.recognize_path "/foo/bar" ActionController::RoutingError: no route found to match "/foo/bar" with {} from ./script/../config/../config/../vendor/rails/actionpack/lib/action_controller/routing.rb:1292:in `recognize_path' from (irb):66 from :0 It seems reasonable to me to adjust the behavior of "response.should redirect_to" so that it returns an error if the controller attempts to redirect to an non-routable URL when your spec is trying to match against it by using a hash. If you want to spec against a URL that lives outside of your application's ability to route, you should probably be spec'ing against the string, right? At least, that's my current thought on the matter. It might be seen as a major change in behavior for the redirect_to matcher. What do you think? So, the controllers that are stored in the rspec_on_rails plugin are not recognized by the example_rails_app's routing. If I move redirect_spec_controller.rb from the plugin into the example app (and remove the require from spec_helper.rb), that allows almost all of the specs to pass. The only specs that don't pass then are the two that redirect to :controller => "other", which is the same error. If I change those to redirect to :controller => "people", then their errors go away as well. ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 18:14 Message: A comment on the failing specs patch and how to reproduce the failures: the first spec will fail only very occasionally... like... say, only on the continuous integration server and not on your development laptop and only when you commit your last change for the day and need to get home. The second and third of the two specs are attempting to replicate the conditions that semi-randomly occur within the first spec. Thus, one and only one of them will always fail, but which one is dependent upon when a particular African butterfly has last flapped its wings. :-) ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 18:09 Message: Yep. I'm using sqlite. It seemed like it should be simpler than mysql. :-) (our production environment is running on SQL Server, which is emphatically *not* simpler than running on mysql.) $ dpkg -l|grep 'libsqlite\|sqlite.*ruby'|awk '{print $3,$2}' 0.0.23-3 libdbd-sqlite3-ruby 0.0.23-3 libdbd-sqlite3-ruby1.8 3.3.5-0.2 libsqlite3-0 1.1.0-2 libsqlite3-ruby 1.1.0-2 libsqlite3-ruby1.8 ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-27 15:59 Message: re: seg faults - are you using sqlite? Which version? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-27 15:59 Message: Thanks Nicholas - the pre-patch-failing specs would be especially great. Cheers, David ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 15:36 Message: Well, I can't run all of the specs, and I don't really know why, but I can run the redirect_to_spec.rb. I'll fix the patch to pass all of the tests in there, and I'll add another couple of specs which should fail without my patch. ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 12:50 Message: Now I'm getting segfaults when I run rake pre_commit! running against rails 1.2.3: ** Invoke environment ** Execute db:schema:load ** Execute spec:plugins /home/nevans/src/rspec/example_rails_app/vendor/rails/1.2.3/activerecord/lib/../../activesupport/lib/active_support/core_ext/object/extending.rb:27: [BUG] Segmentation fault ruby 1.8.4 (2005-12-24) [i486-linux] Aborted (core dumped) rake aborted! Command ruby -I"/home/nevans/src/rspec/rspec/lib" "/home/nevans/src/rspec/rspec/bin/spec" "vendor/plugins/rspec_on_rails/spec/rails/extensions/active_record_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/dsl/assigns_hash_proxy_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/dsl/ivar_proxy_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/assert_select_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/redirect_to_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/render_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/description_generation_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/controller_isolation_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/view_spec_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/helper_spec_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/behaviour_factory_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/controller_spec_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/test_unit_assertion_accessibility_spec.rb" --options "/home/nevans/src/rspec/example_rails_app/config/../spec/spec.opts" failed /home/nevans/src/rspec/rspec/lib/spec/rake/spectask.rb:131:in `define' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:835:in `verbose' /home/nevans/src/rspec/rspec/lib/spec/rake/spectask.rb:105:in `define' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:399:in `execute' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:399:in `execute' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:369:in `invoke' /usr/lib/ruby/1.8/thread.rb:135:in `synchronize' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:362:in `invoke' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:1935:in `run' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:1935:in `run' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/bin/rake:7 /usr/bin/rake:16 I deleted rails 1.2.3 and ran against 1.2.2 (which is what my other apps are using), and dies in the same location: ** Invoke environment ** Execute db:schema:load ** Execute spec:plugins /home/nevans/src/rspec/rspec/lib/spec/dsl/behaviour_callbacks.rb:48: [BUG] Segmentation fault ruby 1.8.4 (2005-12-24) [i486-linux] Aborted (core dumped) rake aborted! Command ruby -I"/home/nevans/src/rspec/rspec/lib" "/home/nevans/src/rspec/rspec/bin/spec" "vendor/plugins/rspec_on_rails/spec/rails/extensions/active_record_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/dsl/assigns_hash_proxy_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/dsl/ivar_proxy_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/assert_select_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/redirect_to_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/render_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/description_generation_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/controller_isolation_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/view_spec_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/helper_spec_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/behaviour_factory_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/controller_spec_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/test_unit_assertion_accessibility_spec.rb" --options "/home/nevans/src/rspec/example_rails_app/config/../spec/spec.opts" failed /home/nevans/src/rspec/rspec/lib/spec/rake/spectask.rb:131:in `define' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:835:in `verbose' /home/nevans/src/rspec/rspec/lib/spec/rake/spectask.rb:105:in `define' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:399:in `execute' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:399:in `execute' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:369:in `invoke' /usr/lib/ruby/1.8/thread.rb:135:in `synchronize' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:362:in `invoke' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:1935:in `run' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:1935:in `run' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/bin/rake:7 /usr/bin/rake:16 I'm running the Ubuntu Edgy version of ruby, which dpkg reports as 1.8.2, but ruby -v reports as 1.8.4. ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 12:28 Message: I found "rake rspec:generate_sqlite_config", and I'm working on getting the precommit bugs fixed now. ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 12:24 Message: More specific explanation of my rake precommit trouble: I was being lazy and didn't bother to debug the problem. It was complaining because config/database.yml was missing. I've looked into the example rails app, and there seems to be some rake tasks for creating a sample sqlite db, so I'll look into that now. Is there a particular magic sequence that could be issued to make it "just work" upon checkout? :-) ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-27 11:34 Message: That was 18 of 38 examples. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-27 11:25 Message: I tried to apply this and 18 of the 18 examples in redirect_to_spec.rb fail. Some are due to the changes you made to the failure messages - some for other reasons I haven't looked at yet. You said you were having trouble getting it to run - can you be more specific? Thanks, David ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=10410&group_id=797 From noreply at rubyforge.org Sat Apr 28 10:34:18 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sat, 28 Apr 2007 10:34:18 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-9605 ] Patch for ER 9472, shared behaviour Message-ID: <20070428143418.393295240B55@rubyforge.org> Patches item #9605, was opened at 2007-03-27 04:08 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=9605&group_id=797 >Category: runner module Group: None >Status: Closed >Resolution: Accepted Priority: 3 Submitted By: Bob Cotton (bcotton) >Assigned to: David Chelimsky (dchelimsky) Summary: Patch for ER 9472, shared behaviour Initial Comment: I chose behaves_as, as the inclusion method. I don't like the use of the global, behavior_runner, in Behavior to find shared behaviors. Putting the collection on Spec::Runner seemed just as bad. Had to move some methods on module Spec::DSL::BehaviourEval::ModuleMethods from private to protected to faciliate copying things from one EvalModule to another. There are many combinations of include, setup/teardown, context_setup/context_teardown and inherit that are not covered in the shared_behavior spec. Let me know if you want more. Might be a good place for shared behaviors! -Bob ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-04-28 14:34 Message: Applied to trunk rev 1820. Nice work Bob - thanks! ---------------------------------------------------------------------- Comment By: Bob Cotton (bcotton) Date: 2007-04-02 14:11 Message: Newest version of the patch attached. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-03-28 11:11 Message: I haven't had time to look into this in detail, but it looks interesting. Right now we're trying to get 0.9 out the door, and we're reluctant to add new features before 0.9 is released. Let's revisit this post 0.9 ---------------------------------------------------------------------- Comment By: Bob Cotton (bcotton) Date: 2007-03-27 12:12 Message: Missed the checkbox. Sorry. ---------------------------------------------------------------------- Comment By: Bob Cotton (bcotton) Date: 2007-03-27 12:11 Message: One more thing, rcov is at 100%, but I can't get pre_commit to run. It either runs out of memory, or the stack is too deep. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-03-27 04:16 Message: File please. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-03-27 04:15 Message: Hi Bob - I'll take a look at this tomorrow. Thanks. FYI - the problem you had running pre_commit was due to something we were trying to fix w/ 1.8.6. I reverted the spectask and you can run pre_commit now. ---------------------------------------------------------------------- Comment By: Bob Cotton (bcotton) Date: 2007-03-27 04:10 Message: One more thing, rcov is at 100%, but I can't get pre_commit to run. It either runs out of memory, or the stack is too deep. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=9605&group_id=797 From dchelimsky at gmail.com Sat Apr 28 10:39:34 2007 From: dchelimsky at gmail.com (David Chelimsky) Date: Sat, 28 Apr 2007 10:39:34 -0400 Subject: [rspec-devel] [ rspec-Patches-9605 ] Patch for ER 9472, shared behaviour In-Reply-To: <20070428143418.393295240B55@rubyforge.org> References: <20070428143418.393295240B55@rubyforge.org> Message-ID: <57c63afe0704280739r2cabe186qe2ae15672c6ab077@mail.gmail.com> Hi all - I've applied (to trunk) Bob Cotton's patch which supports shared behaviours (link to tracker below). I'm still toying w/ names, so please be aware that until this is released w/ 0.9 it should be considered experimental and there will NOT be translation support for it. It will definitely be included in some form - just the names (specifically it_should_behave_like) might change. That said, I encourage all you trunksters to grab the latest trunk and give this feature a roll. I think it solves the problem of duplication across behaviours very nicely. And please provide feedback. If you have any issues with this I want to know about them before we release 0.9 (which is coming VERY soon). Cheers, David On 4/28/07, noreply at rubyforge.org wrote: > Patches item #9605, was opened at 2007-03-27 04:08 > You can respond by visiting: > http://rubyforge.org/tracker/?func=detail&atid=3151&aid=9605&group_id=797 > > >Category: runner module > Group: None > >Status: Closed > >Resolution: Accepted > Priority: 3 > Submitted By: Bob Cotton (bcotton) > >Assigned to: David Chelimsky (dchelimsky) > Summary: Patch for ER 9472, shared behaviour > > Initial Comment: > I chose behaves_as, as the inclusion method. > > I don't like the use of the global, behavior_runner, in Behavior to find shared behaviors. Putting the collection on Spec::Runner seemed just as bad. > > > > Had to move some methods on module Spec::DSL::BehaviourEval::ModuleMethods from private to protected to faciliate copying things from one EvalModule to another. > > > > There are many combinations of include, setup/teardown, context_setup/context_teardown and inherit that are not covered in the shared_behavior spec. Let me know if you want more. Might be a good place for shared behaviors! > > > > -Bob > > ---------------------------------------------------------------------- > > >Comment By: David Chelimsky (dchelimsky) > Date: 2007-04-28 14:34 > > Message: > Applied to trunk rev 1820. > > > > Nice work Bob - thanks! > > ---------------------------------------------------------------------- > > Comment By: Bob Cotton (bcotton) > Date: 2007-04-02 14:11 > > Message: > Newest version of the patch attached. > > ---------------------------------------------------------------------- > > Comment By: Aslak Helles?y (aslak_hellesoy) > Date: 2007-03-28 11:11 > > Message: > I haven't had time to look into this in detail, but it looks interesting. Right now we're trying to get 0.9 out the door, and we're reluctant to add new features before 0.9 is released. > > > > Let's revisit this post 0.9 > > ---------------------------------------------------------------------- > > Comment By: Bob Cotton (bcotton) > Date: 2007-03-27 12:12 > > Message: > Missed the checkbox. Sorry. > > ---------------------------------------------------------------------- > > Comment By: Bob Cotton (bcotton) > Date: 2007-03-27 12:11 > > Message: > One more thing, rcov is at 100%, but I can't get pre_commit > > to run. It either runs out of memory, or the stack is too deep. > > ---------------------------------------------------------------------- > > Comment By: David Chelimsky (dchelimsky) > Date: 2007-03-27 04:16 > > Message: > File please. > > ---------------------------------------------------------------------- > > Comment By: David Chelimsky (dchelimsky) > Date: 2007-03-27 04:15 > > Message: > Hi Bob - I'll take a look at this tomorrow. Thanks. > > > > FYI - the problem you had running pre_commit was due to something we were trying to fix w/ 1.8.6. I reverted the spectask and you can run pre_commit now. > > ---------------------------------------------------------------------- > > Comment By: Bob Cotton (bcotton) > Date: 2007-03-27 04:10 > > Message: > One more thing, rcov is at 100%, but I can't get pre_commit > > to run. It either runs out of memory, or the stack is too deep. > > ---------------------------------------------------------------------- > > You can respond by visiting: > http://rubyforge.org/tracker/?func=detail&atid=3151&aid=9605&group_id=797 > From noreply at rubyforge.org Sat Apr 28 10:54:34 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sat, 28 Apr 2007 10:54:34 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-10410 ] redirect_to does not behave consistently with regards to query string parameter ordering Message-ID: <20070428145434.8F4DA5240A89@rubyforge.org> Patches item #10410, was opened at 2007-04-27 15:01 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=10410&group_id=797 Category: expectation module Group: None Status: Open Resolution: None Priority: 3 Submitted By: nicholas evans (nick_evans) Assigned to: David Chelimsky (dchelimsky) Summary: redirect_to does not behave consistently with regards to query string parameter ordering Initial Comment: This bug is *incredibly* difficult to reproduce. It ends up causing a spec to pass when run as a single file and fail when run as a group of files... or vice versa. Or pass on one computer, but fail on another. Or pass in an old working copy, but fail when re-checked out. Or pass when running the normal rake task, but fail when generating an HTML support. And so on and so forth! As you might imagine this can make continuous integration rather annoying. The problem is that rails will place the items in a hash into the query string in a semi-random order. Given similar hashes, the same URL will *usually* be generated by each. But often enough to be annoying, that is not the case. This is simply due to the unordered nature of hashes. So I made a patch to redirect_to to do two things: 1) If your redirect_to expectation is a hash, and the actual redirection is within http://test.host it will convert the actual redirect_url to a hash, and also convert the expectation to a URL and then back into a hash (this takes care of when you leave :controller out of the expectation). 2) If your redirect_to expectation is a hash, then the failure message will report the failure back as hashes. The previous error (expected hash but got string) was always a bit confusing. If your redirect_to expectation is a string or :back, then you will continue to get the old behavior: a direct string comparison (which may or may not be tripped up by query string order). I created the patch against version 0.8.3, because that is what I'm using, but the redirect_to matcher does not appear to have changed much (at all?) in trunk, and the patch applied cleanly. Although all of the specs using redirect_to in my app still work, I was having difficulties getting "rake precommit" to run correctly... Sorry. :-( ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-04-28 14:54 Message: I think you can do it this way in 1.1.6: config = Rails::Configuration.new config.controller_paths << "#{dir}/../spec_resources/controllers" Rails::Initializer.run(:process, config) ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-28 12:34 Message: That works for 1.2, but not 1.1.6 ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-28 11:57 Message: Will this work (in spec_helper.rb)? Rails::Initializer.run do |config| config.controller_paths << "#{dir}/../spec_resources/controllers" end ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-28 05:20 Message: Oh... I just tried it out with rails 1.1.6... and it failed horribly. ActionController::Routing.controller_paths is a Rails 1.2 feature! :-( ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-28 05:11 Message: Placed judiciously inside the spec_helper.rb: ActionController::Routing.controller_paths << "#{dir}/../spec_resources/controllers" That was easy! :-) ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-28 04:03 Message: This sounds right. As things stand right now, these controllers are only included (from rspec_on_rails/spec/spec_helper.rb) when you run the specs for rspec_on_rails itself, so that problem is solved. Whatever monkey patching may be necessary to coerce routing into looking at the rspec_on_rails/spec_resources directory could also be included in the same file. Thanks for playing! I look forward to getting this in place. Cheers, David ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-28 03:46 Message: I was afraid that you might say that. ;-) I just wanted to tackle one problem at a time. My thought is that the only way to make this work would be to convince Rails routing to consider the rspec_on_rails controllers (or only the RedirectSpecController). I don't know the syntax for how to do that exactly, but I can search inside the code for rails engines or appable plugins to find out how they've done it. Hopefully I can find a minimally invasive method for doing this. The additional problem with that is that we certainly wouldn't want the rspec_on_rails plugin to be adding any controllers (or otherwise mucking with the environment) to every app that its included in, even in the test environment. We really only want this functionality to be triggered when the rspec_on_rails plugin specs are being run. Can this be accomplished simply by only putting the controller loading code into rspec_on_rails's spec_helper.rb? I don't know how to do either of these things at the moment, but I'll look into them both. But (unless something else comes up), I think this should solve our problem... right? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-27 23:44 Message: Hey Nick - thanks for the effort, but this patch presents a problem. To get the routing to work, it looks like you moved redirect_spec_controller.rb from rspec_on_rails/spec_resources to the example_rails_app. We've gone through great pains to decouple the plugin from the app, which is why all of the controllers for the specs that live in rspec_on_rails/spec/ are in rspec_on_rails/spec_resources. We need to figure out a way to maintain the location before I'm willing to apply this patch. Any ideas? I hope we can come up w/ something because it's a nice patch otherwise. Cheers, David ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 23:03 Message: D'oh! I had a copy/paste error... bad description text for the final new spec. $ diff passing_specs_including_new_error_behavior* 169c169 < + it "redirected to an internal URL which is unroutable but matched via a string" do --- > + it "redirected to an internal URL which is unroutable and matched via a hash" do ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 22:50 Message: As promised, I'm attaching the completed specs, including specs for the new error behavior: "response.should redirect_to(hash)" should fail if the redirection is not to a URL that is routable within the application. Same 3-step directions for application apply as with the last patch. I didn't add back the "failure message should print actual redirection as a hash when expectation is for a hash" behavior, because that extra layer of redirection was only really annoying when I couldn't depend on rails and rspec to behave nicely with their URLs. I don't really mind that the failure message compares a hash and a string now. :-) ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 22:27 Message: Two comments on the passing specs patch: 1) because "svn mv" doesn't translate well into the diff format, you'll want to apply it with the following three commands: svn cp rspec_on_rails/spec_resources/controllers/redirect_spec_controller.rb example_rails_app/app/controllers/redirect_spec_controller.rb patch -p0 < passes_specs.patch svn rm rspec_on_rails/spec_resources/controllers/redirect_spec_controller.rb --force 2) I haven't yet added the specs for the additional failure behavior (I actually reverted the failure message behavior that I originally added, and then added some new behavior for the new error type), but I'll get to that momentarily (with another patch). ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 22:25 Message: Okay, I figured out what the problem is: Since I'm converting the URL string back into a hash containing the controller, action, etc, the URL must be routable within the application. However, url_for and ActionController::Routing::Routes.generate have no such restrictions. For example: >> ActionController::Routing::Routes.generate :controller => "foo", :action => "bar" => "/foo/bar" >> ActionController::Routing::Routes.recognize_path "/foo/bar" ActionController::RoutingError: no route found to match "/foo/bar" with {} from ./script/../config/../config/../vendor/rails/actionpack/lib/action_controller/routing.rb:1292:in `recognize_path' from (irb):66 from :0 It seems reasonable to me to adjust the behavior of "response.should redirect_to" so that it returns an error if the controller attempts to redirect to an non-routable URL when your spec is trying to match against it by using a hash. If you want to spec against a URL that lives outside of your application's ability to route, you should probably be spec'ing against the string, right? At least, that's my current thought on the matter. It might be seen as a major change in behavior for the redirect_to matcher. What do you think? So, the controllers that are stored in the rspec_on_rails plugin are not recognized by the example_rails_app's routing. If I move redirect_spec_controller.rb from the plugin into the example app (and remove the require from spec_helper.rb), that allows almost all of the specs to pass. The only specs that don't pass then are the two that redirect to :controller => "other", which is the same error. If I change those to redirect to :controller => "people", then their errors go away as well. ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 22:14 Message: A comment on the failing specs patch and how to reproduce the failures: the first spec will fail only very occasionally... like... say, only on the continuous integration server and not on your development laptop and only when you commit your last change for the day and need to get home. The second and third of the two specs are attempting to replicate the conditions that semi-randomly occur within the first spec. Thus, one and only one of them will always fail, but which one is dependent upon when a particular African butterfly has last flapped its wings. :-) ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 22:09 Message: Yep. I'm using sqlite. It seemed like it should be simpler than mysql. :-) (our production environment is running on SQL Server, which is emphatically *not* simpler than running on mysql.) $ dpkg -l|grep 'libsqlite\|sqlite.*ruby'|awk '{print $3,$2}' 0.0.23-3 libdbd-sqlite3-ruby 0.0.23-3 libdbd-sqlite3-ruby1.8 3.3.5-0.2 libsqlite3-0 1.1.0-2 libsqlite3-ruby 1.1.0-2 libsqlite3-ruby1.8 ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-27 19:59 Message: re: seg faults - are you using sqlite? Which version? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-27 19:59 Message: Thanks Nicholas - the pre-patch-failing specs would be especially great. Cheers, David ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 19:36 Message: Well, I can't run all of the specs, and I don't really know why, but I can run the redirect_to_spec.rb. I'll fix the patch to pass all of the tests in there, and I'll add another couple of specs which should fail without my patch. ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 16:50 Message: Now I'm getting segfaults when I run rake pre_commit! running against rails 1.2.3: ** Invoke environment ** Execute db:schema:load ** Execute spec:plugins /home/nevans/src/rspec/example_rails_app/vendor/rails/1.2.3/activerecord/lib/../../activesupport/lib/active_support/core_ext/object/extending.rb:27: [BUG] Segmentation fault ruby 1.8.4 (2005-12-24) [i486-linux] Aborted (core dumped) rake aborted! Command ruby -I"/home/nevans/src/rspec/rspec/lib" "/home/nevans/src/rspec/rspec/bin/spec" "vendor/plugins/rspec_on_rails/spec/rails/extensions/active_record_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/dsl/assigns_hash_proxy_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/dsl/ivar_proxy_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/assert_select_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/redirect_to_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/render_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/description_generation_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/controller_isolation_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/view_spec_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/helper_spec_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/behaviour_factory_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/controller_spec_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/test_unit_assertion_accessibility_spec.rb" --options "/home/nevans/src/rspec/example_rails_app/config/../spec/spec.opts" failed /home/nevans/src/rspec/rspec/lib/spec/rake/spectask.rb:131:in `define' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:835:in `verbose' /home/nevans/src/rspec/rspec/lib/spec/rake/spectask.rb:105:in `define' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:399:in `execute' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:399:in `execute' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:369:in `invoke' /usr/lib/ruby/1.8/thread.rb:135:in `synchronize' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:362:in `invoke' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:1935:in `run' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:1935:in `run' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/bin/rake:7 /usr/bin/rake:16 I deleted rails 1.2.3 and ran against 1.2.2 (which is what my other apps are using), and dies in the same location: ** Invoke environment ** Execute db:schema:load ** Execute spec:plugins /home/nevans/src/rspec/rspec/lib/spec/dsl/behaviour_callbacks.rb:48: [BUG] Segmentation fault ruby 1.8.4 (2005-12-24) [i486-linux] Aborted (core dumped) rake aborted! Command ruby -I"/home/nevans/src/rspec/rspec/lib" "/home/nevans/src/rspec/rspec/bin/spec" "vendor/plugins/rspec_on_rails/spec/rails/extensions/active_record_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/dsl/assigns_hash_proxy_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/dsl/ivar_proxy_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/assert_select_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/redirect_to_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/render_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/description_generation_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/controller_isolation_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/view_spec_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/helper_spec_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/behaviour_factory_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/controller_spec_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/test_unit_assertion_accessibility_spec.rb" --options "/home/nevans/src/rspec/example_rails_app/config/../spec/spec.opts" failed /home/nevans/src/rspec/rspec/lib/spec/rake/spectask.rb:131:in `define' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:835:in `verbose' /home/nevans/src/rspec/rspec/lib/spec/rake/spectask.rb:105:in `define' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:399:in `execute' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:399:in `execute' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:369:in `invoke' /usr/lib/ruby/1.8/thread.rb:135:in `synchronize' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:362:in `invoke' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:1935:in `run' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:1935:in `run' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/bin/rake:7 /usr/bin/rake:16 I'm running the Ubuntu Edgy version of ruby, which dpkg reports as 1.8.2, but ruby -v reports as 1.8.4. ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 16:28 Message: I found "rake rspec:generate_sqlite_config", and I'm working on getting the precommit bugs fixed now. ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 16:24 Message: More specific explanation of my rake precommit trouble: I was being lazy and didn't bother to debug the problem. It was complaining because config/database.yml was missing. I've looked into the example rails app, and there seems to be some rake tasks for creating a sample sqlite db, so I'll look into that now. Is there a particular magic sequence that could be issued to make it "just work" upon checkout? :-) ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-27 15:34 Message: That was 18 of 38 examples. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-27 15:25 Message: I tried to apply this and 18 of the 18 examples in redirect_to_spec.rb fail. Some are due to the changes you made to the failure messages - some for other reasons I haven't looked at yet. You said you were having trouble getting it to run - can you be more specific? Thanks, David ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=10410&group_id=797 From noreply at rubyforge.org Sat Apr 28 11:20:35 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sat, 28 Apr 2007 11:20:35 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-10410 ] redirect_to does not behave consistently with regards to query string parameter ordering Message-ID: <20070428152035.384695240B55@rubyforge.org> Patches item #10410, was opened at 2007-04-27 11:01 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=10410&group_id=797 Category: expectation module Group: None Status: Open Resolution: None Priority: 3 Submitted By: nicholas evans (nick_evans) Assigned to: David Chelimsky (dchelimsky) Summary: redirect_to does not behave consistently with regards to query string parameter ordering Initial Comment: This bug is *incredibly* difficult to reproduce. It ends up causing a spec to pass when run as a single file and fail when run as a group of files... or vice versa. Or pass on one computer, but fail on another. Or pass in an old working copy, but fail when re-checked out. Or pass when running the normal rake task, but fail when generating an HTML support. And so on and so forth! As you might imagine this can make continuous integration rather annoying. The problem is that rails will place the items in a hash into the query string in a semi-random order. Given similar hashes, the same URL will *usually* be generated by each. But often enough to be annoying, that is not the case. This is simply due to the unordered nature of hashes. So I made a patch to redirect_to to do two things: 1) If your redirect_to expectation is a hash, and the actual redirection is within http://test.host it will convert the actual redirect_url to a hash, and also convert the expectation to a URL and then back into a hash (this takes care of when you leave :controller out of the expectation). 2) If your redirect_to expectation is a hash, then the failure message will report the failure back as hashes. The previous error (expected hash but got string) was always a bit confusing. If your redirect_to expectation is a string or :back, then you will continue to get the old behavior: a direct string comparison (which may or may not be tripped up by query string order). I created the patch against version 0.8.3, because that is what I'm using, but the redirect_to matcher does not appear to have changed much (at all?) in trunk, and the patch applied cleanly. Although all of the specs using redirect_to in my app still work, I was having difficulties getting "rake precommit" to run correctly... Sorry. :-( ---------------------------------------------------------------------- >Comment By: nicholas evans (nick_evans) Date: 2007-04-28 11:20 Message: Still working with 1.2, but not with 1.1.6... Here's what I've placed under all of the require lines in rspec_on_rails/spec/spec_helper.rb: http://pastie.caboo.se/57298 Does it matter that the Rails::Initializer has already run (by inclusion of the environment.rb which was included by the example_rails_app's spec_helper.rb, which was included by the rspec_on_rails plugin's spec_helper.rb)? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-28 10:54 Message: I think you can do it this way in 1.1.6: config = Rails::Configuration.new config.controller_paths << "#{dir}/../spec_resources/controllers" Rails::Initializer.run(:process, config) ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-28 08:34 Message: That works for 1.2, but not 1.1.6 ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-28 07:57 Message: Will this work (in spec_helper.rb)? Rails::Initializer.run do |config| config.controller_paths << "#{dir}/../spec_resources/controllers" end ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-28 01:20 Message: Oh... I just tried it out with rails 1.1.6... and it failed horribly. ActionController::Routing.controller_paths is a Rails 1.2 feature! :-( ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-28 01:11 Message: Placed judiciously inside the spec_helper.rb: ActionController::Routing.controller_paths << "#{dir}/../spec_resources/controllers" That was easy! :-) ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-28 00:03 Message: This sounds right. As things stand right now, these controllers are only included (from rspec_on_rails/spec/spec_helper.rb) when you run the specs for rspec_on_rails itself, so that problem is solved. Whatever monkey patching may be necessary to coerce routing into looking at the rspec_on_rails/spec_resources directory could also be included in the same file. Thanks for playing! I look forward to getting this in place. Cheers, David ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 23:46 Message: I was afraid that you might say that. ;-) I just wanted to tackle one problem at a time. My thought is that the only way to make this work would be to convince Rails routing to consider the rspec_on_rails controllers (or only the RedirectSpecController). I don't know the syntax for how to do that exactly, but I can search inside the code for rails engines or appable plugins to find out how they've done it. Hopefully I can find a minimally invasive method for doing this. The additional problem with that is that we certainly wouldn't want the rspec_on_rails plugin to be adding any controllers (or otherwise mucking with the environment) to every app that its included in, even in the test environment. We really only want this functionality to be triggered when the rspec_on_rails plugin specs are being run. Can this be accomplished simply by only putting the controller loading code into rspec_on_rails's spec_helper.rb? I don't know how to do either of these things at the moment, but I'll look into them both. But (unless something else comes up), I think this should solve our problem... right? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-27 19:44 Message: Hey Nick - thanks for the effort, but this patch presents a problem. To get the routing to work, it looks like you moved redirect_spec_controller.rb from rspec_on_rails/spec_resources to the example_rails_app. We've gone through great pains to decouple the plugin from the app, which is why all of the controllers for the specs that live in rspec_on_rails/spec/ are in rspec_on_rails/spec_resources. We need to figure out a way to maintain the location before I'm willing to apply this patch. Any ideas? I hope we can come up w/ something because it's a nice patch otherwise. Cheers, David ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 19:03 Message: D'oh! I had a copy/paste error... bad description text for the final new spec. $ diff passing_specs_including_new_error_behavior* 169c169 < + it "redirected to an internal URL which is unroutable but matched via a string" do --- > + it "redirected to an internal URL which is unroutable and matched via a hash" do ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 18:50 Message: As promised, I'm attaching the completed specs, including specs for the new error behavior: "response.should redirect_to(hash)" should fail if the redirection is not to a URL that is routable within the application. Same 3-step directions for application apply as with the last patch. I didn't add back the "failure message should print actual redirection as a hash when expectation is for a hash" behavior, because that extra layer of redirection was only really annoying when I couldn't depend on rails and rspec to behave nicely with their URLs. I don't really mind that the failure message compares a hash and a string now. :-) ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 18:27 Message: Two comments on the passing specs patch: 1) because "svn mv" doesn't translate well into the diff format, you'll want to apply it with the following three commands: svn cp rspec_on_rails/spec_resources/controllers/redirect_spec_controller.rb example_rails_app/app/controllers/redirect_spec_controller.rb patch -p0 < passes_specs.patch svn rm rspec_on_rails/spec_resources/controllers/redirect_spec_controller.rb --force 2) I haven't yet added the specs for the additional failure behavior (I actually reverted the failure message behavior that I originally added, and then added some new behavior for the new error type), but I'll get to that momentarily (with another patch). ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 18:25 Message: Okay, I figured out what the problem is: Since I'm converting the URL string back into a hash containing the controller, action, etc, the URL must be routable within the application. However, url_for and ActionController::Routing::Routes.generate have no such restrictions. For example: >> ActionController::Routing::Routes.generate :controller => "foo", :action => "bar" => "/foo/bar" >> ActionController::Routing::Routes.recognize_path "/foo/bar" ActionController::RoutingError: no route found to match "/foo/bar" with {} from ./script/../config/../config/../vendor/rails/actionpack/lib/action_controller/routing.rb:1292:in `recognize_path' from (irb):66 from :0 It seems reasonable to me to adjust the behavior of "response.should redirect_to" so that it returns an error if the controller attempts to redirect to an non-routable URL when your spec is trying to match against it by using a hash. If you want to spec against a URL that lives outside of your application's ability to route, you should probably be spec'ing against the string, right? At least, that's my current thought on the matter. It might be seen as a major change in behavior for the redirect_to matcher. What do you think? So, the controllers that are stored in the rspec_on_rails plugin are not recognized by the example_rails_app's routing. If I move redirect_spec_controller.rb from the plugin into the example app (and remove the require from spec_helper.rb), that allows almost all of the specs to pass. The only specs that don't pass then are the two that redirect to :controller => "other", which is the same error. If I change those to redirect to :controller => "people", then their errors go away as well. ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 18:14 Message: A comment on the failing specs patch and how to reproduce the failures: the first spec will fail only very occasionally... like... say, only on the continuous integration server and not on your development laptop and only when you commit your last change for the day and need to get home. The second and third of the two specs are attempting to replicate the conditions that semi-randomly occur within the first spec. Thus, one and only one of them will always fail, but which one is dependent upon when a particular African butterfly has last flapped its wings. :-) ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 18:09 Message: Yep. I'm using sqlite. It seemed like it should be simpler than mysql. :-) (our production environment is running on SQL Server, which is emphatically *not* simpler than running on mysql.) $ dpkg -l|grep 'libsqlite\|sqlite.*ruby'|awk '{print $3,$2}' 0.0.23-3 libdbd-sqlite3-ruby 0.0.23-3 libdbd-sqlite3-ruby1.8 3.3.5-0.2 libsqlite3-0 1.1.0-2 libsqlite3-ruby 1.1.0-2 libsqlite3-ruby1.8 ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-27 15:59 Message: re: seg faults - are you using sqlite? Which version? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-27 15:59 Message: Thanks Nicholas - the pre-patch-failing specs would be especially great. Cheers, David ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 15:36 Message: Well, I can't run all of the specs, and I don't really know why, but I can run the redirect_to_spec.rb. I'll fix the patch to pass all of the tests in there, and I'll add another couple of specs which should fail without my patch. ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 12:50 Message: Now I'm getting segfaults when I run rake pre_commit! running against rails 1.2.3: ** Invoke environment ** Execute db:schema:load ** Execute spec:plugins /home/nevans/src/rspec/example_rails_app/vendor/rails/1.2.3/activerecord/lib/../../activesupport/lib/active_support/core_ext/object/extending.rb:27: [BUG] Segmentation fault ruby 1.8.4 (2005-12-24) [i486-linux] Aborted (core dumped) rake aborted! Command ruby -I"/home/nevans/src/rspec/rspec/lib" "/home/nevans/src/rspec/rspec/bin/spec" "vendor/plugins/rspec_on_rails/spec/rails/extensions/active_record_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/dsl/assigns_hash_proxy_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/dsl/ivar_proxy_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/assert_select_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/redirect_to_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/render_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/description_generation_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/controller_isolation_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/view_spec_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/helper_spec_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/behaviour_factory_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/controller_spec_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/test_unit_assertion_accessibility_spec.rb" --options "/home/nevans/src/rspec/example_rails_app/config/../spec/spec.opts" failed /home/nevans/src/rspec/rspec/lib/spec/rake/spectask.rb:131:in `define' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:835:in `verbose' /home/nevans/src/rspec/rspec/lib/spec/rake/spectask.rb:105:in `define' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:399:in `execute' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:399:in `execute' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:369:in `invoke' /usr/lib/ruby/1.8/thread.rb:135:in `synchronize' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:362:in `invoke' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:1935:in `run' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:1935:in `run' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/bin/rake:7 /usr/bin/rake:16 I deleted rails 1.2.3 and ran against 1.2.2 (which is what my other apps are using), and dies in the same location: ** Invoke environment ** Execute db:schema:load ** Execute spec:plugins /home/nevans/src/rspec/rspec/lib/spec/dsl/behaviour_callbacks.rb:48: [BUG] Segmentation fault ruby 1.8.4 (2005-12-24) [i486-linux] Aborted (core dumped) rake aborted! Command ruby -I"/home/nevans/src/rspec/rspec/lib" "/home/nevans/src/rspec/rspec/bin/spec" "vendor/plugins/rspec_on_rails/spec/rails/extensions/active_record_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/dsl/assigns_hash_proxy_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/dsl/ivar_proxy_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/assert_select_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/redirect_to_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/render_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/description_generation_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/controller_isolation_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/view_spec_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/helper_spec_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/behaviour_factory_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/controller_spec_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/test_unit_assertion_accessibility_spec.rb" --options "/home/nevans/src/rspec/example_rails_app/config/../spec/spec.opts" failed /home/nevans/src/rspec/rspec/lib/spec/rake/spectask.rb:131:in `define' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:835:in `verbose' /home/nevans/src/rspec/rspec/lib/spec/rake/spectask.rb:105:in `define' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:399:in `execute' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:399:in `execute' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:369:in `invoke' /usr/lib/ruby/1.8/thread.rb:135:in `synchronize' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:362:in `invoke' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:1935:in `run' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:1935:in `run' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/bin/rake:7 /usr/bin/rake:16 I'm running the Ubuntu Edgy version of ruby, which dpkg reports as 1.8.2, but ruby -v reports as 1.8.4. ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 12:28 Message: I found "rake rspec:generate_sqlite_config", and I'm working on getting the precommit bugs fixed now. ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 12:24 Message: More specific explanation of my rake precommit trouble: I was being lazy and didn't bother to debug the problem. It was complaining because config/database.yml was missing. I've looked into the example rails app, and there seems to be some rake tasks for creating a sample sqlite db, so I'll look into that now. Is there a particular magic sequence that could be issued to make it "just work" upon checkout? :-) ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-27 11:34 Message: That was 18 of 38 examples. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-27 11:25 Message: I tried to apply this and 18 of the 18 examples in redirect_to_spec.rb fail. Some are due to the changes you made to the failure messages - some for other reasons I haven't looked at yet. You said you were having trouble getting it to run - can you be more specific? Thanks, David ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=10410&group_id=797 From dchelimsky at gmail.com Sat Apr 28 11:58:05 2007 From: dchelimsky at gmail.com (David Chelimsky) Date: Sat, 28 Apr 2007 11:58:05 -0400 Subject: [rspec-devel] [ rspec-Patches-9605 ] Patch for ER 9472, shared behaviour In-Reply-To: <57c63afe0704280739r2cabe186qe2ae15672c6ab077@mail.gmail.com> References: <20070428143418.393295240B55@rubyforge.org> <57c63afe0704280739r2cabe186qe2ae15672c6ab077@mail.gmail.com> Message-ID: <57c63afe0704280858y23876b59o81b8855060bb7067@mail.gmail.com> Sorry for the noise - I applied this patch after some time had passed since it was submitted. I got all the specs passing and assumed all was OK, but I just tried this outside of RSpec's own environment and it doesn't work so I must have botched something up. I'll get this working in the next couple of days and follow up on both lists when its ready to try for real. Cheers, David On 4/28/07, David Chelimsky wrote: > Hi all - I've applied (to trunk) Bob Cotton's patch which supports > shared behaviours (link to tracker below). > > I'm still toying w/ names, so please be aware that until this is > released w/ 0.9 it should be considered experimental and there will > NOT be translation support for it. It will definitely be included in > some form - just the names (specifically it_should_behave_like) might > change. > > That said, I encourage all you trunksters to grab the latest trunk and > give this feature a roll. I think it solves the problem of duplication > across behaviours very nicely. And please provide feedback. If you > have any issues with this I want to know about them before we release > 0.9 (which is coming VERY soon). > > Cheers, > David > > On 4/28/07, noreply at rubyforge.org wrote: > > Patches item #9605, was opened at 2007-03-27 04:08 > > You can respond by visiting: > > http://rubyforge.org/tracker/?func=detail&atid=3151&aid=9605&group_id=797 > > > > >Category: runner module > > Group: None > > >Status: Closed > > >Resolution: Accepted > > Priority: 3 > > Submitted By: Bob Cotton (bcotton) > > >Assigned to: David Chelimsky (dchelimsky) > > Summary: Patch for ER 9472, shared behaviour > > > > Initial Comment: > > I chose behaves_as, as the inclusion method. > > > > I don't like the use of the global, behavior_runner, in Behavior to find shared behaviors. Putting the collection on Spec::Runner seemed just as bad. > > > > > > > > Had to move some methods on module Spec::DSL::BehaviourEval::ModuleMethods from private to protected to faciliate copying things from one EvalModule to another. > > > > > > > > There are many combinations of include, setup/teardown, context_setup/context_teardown and inherit that are not covered in the shared_behavior spec. Let me know if you want more. Might be a good place for shared behaviors! > > > > > > > > -Bob > > > > ---------------------------------------------------------------------- > > > > >Comment By: David Chelimsky (dchelimsky) > > Date: 2007-04-28 14:34 > > > > Message: > > Applied to trunk rev 1820. > > > > > > > > Nice work Bob - thanks! > > > > ---------------------------------------------------------------------- > > > > Comment By: Bob Cotton (bcotton) > > Date: 2007-04-02 14:11 > > > > Message: > > Newest version of the patch attached. > > > > ---------------------------------------------------------------------- > > > > Comment By: Aslak Helles?y (aslak_hellesoy) > > Date: 2007-03-28 11:11 > > > > Message: > > I haven't had time to look into this in detail, but it looks interesting. Right now we're trying to get 0.9 out the door, and we're reluctant to add new features before 0.9 is released. > > > > > > > > Let's revisit this post 0.9 > > > > ---------------------------------------------------------------------- > > > > Comment By: Bob Cotton (bcotton) > > Date: 2007-03-27 12:12 > > > > Message: > > Missed the checkbox. Sorry. > > > > ---------------------------------------------------------------------- > > > > Comment By: Bob Cotton (bcotton) > > Date: 2007-03-27 12:11 > > > > Message: > > One more thing, rcov is at 100%, but I can't get pre_commit > > > > to run. It either runs out of memory, or the stack is too deep. > > > > ---------------------------------------------------------------------- > > > > Comment By: David Chelimsky (dchelimsky) > > Date: 2007-03-27 04:16 > > > > Message: > > File please. > > > > ---------------------------------------------------------------------- > > > > Comment By: David Chelimsky (dchelimsky) > > Date: 2007-03-27 04:15 > > > > Message: > > Hi Bob - I'll take a look at this tomorrow. Thanks. > > > > > > > > FYI - the problem you had running pre_commit was due to something we were trying to fix w/ 1.8.6. I reverted the spectask and you can run pre_commit now. > > > > ---------------------------------------------------------------------- > > > > Comment By: Bob Cotton (bcotton) > > Date: 2007-03-27 04:10 > > > > Message: > > One more thing, rcov is at 100%, but I can't get pre_commit > > > > to run. It either runs out of memory, or the stack is too deep. > > > > ---------------------------------------------------------------------- > > > > You can respond by visiting: > > http://rubyforge.org/tracker/?func=detail&atid=3151&aid=9605&group_id=797 > > > From noreply at rubyforge.org Sat Apr 28 14:33:25 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sat, 28 Apr 2007 14:33:25 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-10434 ] Please Make -s synonymous with -e for autotest compat. Message-ID: <20070428183325.54F3A5240B5F@rubyforge.org> Feature Requests item #10434, was opened at 2007-04-28 11:33 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10434&group_id=797 Category: runner / command line Group: None Status: Open Priority: 3 Submitted By: steve ross (cwd) Assigned to: Nobody (None) Summary: Please Make -s synonymous with -e for autotest compat. Initial Comment: Autotest uses -s to specify which specs to run. Rather than replacing -s, please make it synonymous with -e so as not to break autotest. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10434&group_id=797 From noreply at rubyforge.org Sat Apr 28 15:31:44 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sat, 28 Apr 2007 15:31:44 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-10434 ] Please Make -s synonymous with -e for autotest compat. Message-ID: <20070428193144.D60BD5240B8D@rubyforge.org> Feature Requests item #10434, was opened at 2007-04-28 18:33 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10434&group_id=797 Category: runner / command line Group: None >Status: Closed Priority: 3 Submitted By: steve ross (cwd) >Assigned to: David Chelimsky (dchelimsky) Summary: Please Make -s synonymous with -e for autotest compat. Initial Comment: Autotest uses -s to specify which specs to run. Rather than replacing -s, please make it synonymous with -e so as not to break autotest. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-04-28 19:31 Message: There were some other problems w/ rspec_autotest and I've already submitted a patch to Ryan (ZenTest's author), which includes using -e as well as some changes to the directories. Ryan indicated me that he'd be doing a 3.5.2 release very shortly. I expect that will be available before 0.9 is officially released. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10434&group_id=797 From dchelimsky at gmail.com Sat Apr 28 17:21:51 2007 From: dchelimsky at gmail.com (David Chelimsky) Date: Sat, 28 Apr 2007 17:21:51 -0400 Subject: [rspec-devel] [ rspec-Patches-9605 ] Patch for ER 9472, shared behaviour In-Reply-To: <57c63afe0704280858y23876b59o81b8855060bb7067@mail.gmail.com> References: <20070428143418.393295240B55@rubyforge.org> <57c63afe0704280739r2cabe186qe2ae15672c6ab077@mail.gmail.com> <57c63afe0704280858y23876b59o81b8855060bb7067@mail.gmail.com> Message-ID: <57c63afe0704281421k1da5492dwf2e3a03fb3bc951f@mail.gmail.com> OK - this is actually working now. Check out rev 1825 (or later). Take a peek at examples/shared_behaviours_example.rb to see how to use it. Cheers, David On 4/28/07, David Chelimsky wrote: > Sorry for the noise - I applied this patch after some time had passed > since it was submitted. I got all the specs passing and assumed all > was OK, but I just tried this outside of RSpec's own environment and > it doesn't work so I must have botched something up. > > I'll get this working in the next couple of days and follow up on both > lists when its ready to try for real. > > Cheers, > David > > On 4/28/07, David Chelimsky wrote: > > Hi all - I've applied (to trunk) Bob Cotton's patch which supports > > shared behaviours (link to tracker below). > > > > I'm still toying w/ names, so please be aware that until this is > > released w/ 0.9 it should be considered experimental and there will > > NOT be translation support for it. It will definitely be included in > > some form - just the names (specifically it_should_behave_like) might > > change. > > > > That said, I encourage all you trunksters to grab the latest trunk and > > give this feature a roll. I think it solves the problem of duplication > > across behaviours very nicely. And please provide feedback. If you > > have any issues with this I want to know about them before we release > > 0.9 (which is coming VERY soon). > > > > Cheers, > > David > > > > On 4/28/07, noreply at rubyforge.org wrote: > > > Patches item #9605, was opened at 2007-03-27 04:08 > > > You can respond by visiting: > > > http://rubyforge.org/tracker/?func=detail&atid=3151&aid=9605&group_id=797 > > > > > > >Category: runner module > > > Group: None > > > >Status: Closed > > > >Resolution: Accepted > > > Priority: 3 > > > Submitted By: Bob Cotton (bcotton) > > > >Assigned to: David Chelimsky (dchelimsky) > > > Summary: Patch for ER 9472, shared behaviour > > > > > > Initial Comment: > > > I chose behaves_as, as the inclusion method. > > > > > > I don't like the use of the global, behavior_runner, in Behavior to find shared behaviors. Putting the collection on Spec::Runner seemed just as bad. > > > > > > > > > > > > Had to move some methods on module Spec::DSL::BehaviourEval::ModuleMethods from private to protected to faciliate copying things from one EvalModule to another. > > > > > > > > > > > > There are many combinations of include, setup/teardown, context_setup/context_teardown and inherit that are not covered in the shared_behavior spec. Let me know if you want more. Might be a good place for shared behaviors! > > > > > > > > > > > > -Bob > > > > > > ---------------------------------------------------------------------- > > > > > > >Comment By: David Chelimsky (dchelimsky) > > > Date: 2007-04-28 14:34 > > > > > > Message: > > > Applied to trunk rev 1820. > > > > > > > > > > > > Nice work Bob - thanks! > > > > > > ---------------------------------------------------------------------- > > > > > > Comment By: Bob Cotton (bcotton) > > > Date: 2007-04-02 14:11 > > > > > > Message: > > > Newest version of the patch attached. > > > > > > ---------------------------------------------------------------------- > > > > > > Comment By: Aslak Helles?y (aslak_hellesoy) > > > Date: 2007-03-28 11:11 > > > > > > Message: > > > I haven't had time to look into this in detail, but it looks interesting. Right now we're trying to get 0.9 out the door, and we're reluctant to add new features before 0.9 is released. > > > > > > > > > > > > Let's revisit this post 0.9 > > > > > > ---------------------------------------------------------------------- > > > > > > Comment By: Bob Cotton (bcotton) > > > Date: 2007-03-27 12:12 > > > > > > Message: > > > Missed the checkbox. Sorry. > > > > > > ---------------------------------------------------------------------- > > > > > > Comment By: Bob Cotton (bcotton) > > > Date: 2007-03-27 12:11 > > > > > > Message: > > > One more thing, rcov is at 100%, but I can't get pre_commit > > > > > > to run. It either runs out of memory, or the stack is too deep. > > > > > > ---------------------------------------------------------------------- > > > > > > Comment By: David Chelimsky (dchelimsky) > > > Date: 2007-03-27 04:16 > > > > > > Message: > > > File please. > > > > > > ---------------------------------------------------------------------- > > > > > > Comment By: David Chelimsky (dchelimsky) > > > Date: 2007-03-27 04:15 > > > > > > Message: > > > Hi Bob - I'll take a look at this tomorrow. Thanks. > > > > > > > > > > > > FYI - the problem you had running pre_commit was due to something we were trying to fix w/ 1.8.6. I reverted the spectask and you can run pre_commit now. > > > > > > ---------------------------------------------------------------------- > > > > > > Comment By: Bob Cotton (bcotton) > > > Date: 2007-03-27 04:10 > > > > > > Message: > > > One more thing, rcov is at 100%, but I can't get pre_commit > > > > > > to run. It either runs out of memory, or the stack is too deep. > > > > > > ---------------------------------------------------------------------- > > > > > > You can respond by visiting: > > > http://rubyforge.org/tracker/?func=detail&atid=3151&aid=9605&group_id=797 > > > > > > From noreply at rubyforge.org Sat Apr 28 19:37:42 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sat, 28 Apr 2007 19:37:42 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-10410 ] redirect_to does not behave consistently with regards to query string parameter ordering Message-ID: <20070428233742.141F75240B8D@rubyforge.org> Patches item #10410, was opened at 2007-04-27 11:01 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=10410&group_id=797 Category: expectation module Group: None Status: Open Resolution: None Priority: 3 Submitted By: nicholas evans (nick_evans) Assigned to: David Chelimsky (dchelimsky) Summary: redirect_to does not behave consistently with regards to query string parameter ordering Initial Comment: This bug is *incredibly* difficult to reproduce. It ends up causing a spec to pass when run as a single file and fail when run as a group of files... or vice versa. Or pass on one computer, but fail on another. Or pass in an old working copy, but fail when re-checked out. Or pass when running the normal rake task, but fail when generating an HTML support. And so on and so forth! As you might imagine this can make continuous integration rather annoying. The problem is that rails will place the items in a hash into the query string in a semi-random order. Given similar hashes, the same URL will *usually* be generated by each. But often enough to be annoying, that is not the case. This is simply due to the unordered nature of hashes. So I made a patch to redirect_to to do two things: 1) If your redirect_to expectation is a hash, and the actual redirection is within http://test.host it will convert the actual redirect_url to a hash, and also convert the expectation to a URL and then back into a hash (this takes care of when you leave :controller out of the expectation). 2) If your redirect_to expectation is a hash, then the failure message will report the failure back as hashes. The previous error (expected hash but got string) was always a bit confusing. If your redirect_to expectation is a string or :back, then you will continue to get the old behavior: a direct string comparison (which may or may not be tripped up by query string order). I created the patch against version 0.8.3, because that is what I'm using, but the redirect_to matcher does not appear to have changed much (at all?) in trunk, and the patch applied cleanly. Although all of the specs using redirect_to in my app still work, I was having difficulties getting "rake precommit" to run correctly... Sorry. :-( ---------------------------------------------------------------------- >Comment By: nicholas evans (nick_evans) Date: 2007-04-28 19:37 Message: I looked into the code for ActionController::Routing::Routes.recognize_path in rails 1.1.6, and it's completely different. It even has a different signature. In rails 1.2, it takes a string (e.g. "/controller/action"). In rails 1.1, it takes an array (e.g. %w(controller action)). So, in addition to letting rails load the controller path (I think that safe_load_paths is the key to that), I'll need to modify the code in the redirect_to matcher to play nice with rails 1.1.6. ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-28 11:20 Message: Still working with 1.2, but not with 1.1.6... Here's what I've placed under all of the require lines in rspec_on_rails/spec/spec_helper.rb: http://pastie.caboo.se/57298 Does it matter that the Rails::Initializer has already run (by inclusion of the environment.rb which was included by the example_rails_app's spec_helper.rb, which was included by the rspec_on_rails plugin's spec_helper.rb)? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-28 10:54 Message: I think you can do it this way in 1.1.6: config = Rails::Configuration.new config.controller_paths << "#{dir}/../spec_resources/controllers" Rails::Initializer.run(:process, config) ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-28 08:34 Message: That works for 1.2, but not 1.1.6 ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-28 07:57 Message: Will this work (in spec_helper.rb)? Rails::Initializer.run do |config| config.controller_paths << "#{dir}/../spec_resources/controllers" end ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-28 01:20 Message: Oh... I just tried it out with rails 1.1.6... and it failed horribly. ActionController::Routing.controller_paths is a Rails 1.2 feature! :-( ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-28 01:11 Message: Placed judiciously inside the spec_helper.rb: ActionController::Routing.controller_paths << "#{dir}/../spec_resources/controllers" That was easy! :-) ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-28 00:03 Message: This sounds right. As things stand right now, these controllers are only included (from rspec_on_rails/spec/spec_helper.rb) when you run the specs for rspec_on_rails itself, so that problem is solved. Whatever monkey patching may be necessary to coerce routing into looking at the rspec_on_rails/spec_resources directory could also be included in the same file. Thanks for playing! I look forward to getting this in place. Cheers, David ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 23:46 Message: I was afraid that you might say that. ;-) I just wanted to tackle one problem at a time. My thought is that the only way to make this work would be to convince Rails routing to consider the rspec_on_rails controllers (or only the RedirectSpecController). I don't know the syntax for how to do that exactly, but I can search inside the code for rails engines or appable plugins to find out how they've done it. Hopefully I can find a minimally invasive method for doing this. The additional problem with that is that we certainly wouldn't want the rspec_on_rails plugin to be adding any controllers (or otherwise mucking with the environment) to every app that its included in, even in the test environment. We really only want this functionality to be triggered when the rspec_on_rails plugin specs are being run. Can this be accomplished simply by only putting the controller loading code into rspec_on_rails's spec_helper.rb? I don't know how to do either of these things at the moment, but I'll look into them both. But (unless something else comes up), I think this should solve our problem... right? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-27 19:44 Message: Hey Nick - thanks for the effort, but this patch presents a problem. To get the routing to work, it looks like you moved redirect_spec_controller.rb from rspec_on_rails/spec_resources to the example_rails_app. We've gone through great pains to decouple the plugin from the app, which is why all of the controllers for the specs that live in rspec_on_rails/spec/ are in rspec_on_rails/spec_resources. We need to figure out a way to maintain the location before I'm willing to apply this patch. Any ideas? I hope we can come up w/ something because it's a nice patch otherwise. Cheers, David ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 19:03 Message: D'oh! I had a copy/paste error... bad description text for the final new spec. $ diff passing_specs_including_new_error_behavior* 169c169 < + it "redirected to an internal URL which is unroutable but matched via a string" do --- > + it "redirected to an internal URL which is unroutable and matched via a hash" do ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 18:50 Message: As promised, I'm attaching the completed specs, including specs for the new error behavior: "response.should redirect_to(hash)" should fail if the redirection is not to a URL that is routable within the application. Same 3-step directions for application apply as with the last patch. I didn't add back the "failure message should print actual redirection as a hash when expectation is for a hash" behavior, because that extra layer of redirection was only really annoying when I couldn't depend on rails and rspec to behave nicely with their URLs. I don't really mind that the failure message compares a hash and a string now. :-) ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 18:27 Message: Two comments on the passing specs patch: 1) because "svn mv" doesn't translate well into the diff format, you'll want to apply it with the following three commands: svn cp rspec_on_rails/spec_resources/controllers/redirect_spec_controller.rb example_rails_app/app/controllers/redirect_spec_controller.rb patch -p0 < passes_specs.patch svn rm rspec_on_rails/spec_resources/controllers/redirect_spec_controller.rb --force 2) I haven't yet added the specs for the additional failure behavior (I actually reverted the failure message behavior that I originally added, and then added some new behavior for the new error type), but I'll get to that momentarily (with another patch). ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 18:25 Message: Okay, I figured out what the problem is: Since I'm converting the URL string back into a hash containing the controller, action, etc, the URL must be routable within the application. However, url_for and ActionController::Routing::Routes.generate have no such restrictions. For example: >> ActionController::Routing::Routes.generate :controller => "foo", :action => "bar" => "/foo/bar" >> ActionController::Routing::Routes.recognize_path "/foo/bar" ActionController::RoutingError: no route found to match "/foo/bar" with {} from ./script/../config/../config/../vendor/rails/actionpack/lib/action_controller/routing.rb:1292:in `recognize_path' from (irb):66 from :0 It seems reasonable to me to adjust the behavior of "response.should redirect_to" so that it returns an error if the controller attempts to redirect to an non-routable URL when your spec is trying to match against it by using a hash. If you want to spec against a URL that lives outside of your application's ability to route, you should probably be spec'ing against the string, right? At least, that's my current thought on the matter. It might be seen as a major change in behavior for the redirect_to matcher. What do you think? So, the controllers that are stored in the rspec_on_rails plugin are not recognized by the example_rails_app's routing. If I move redirect_spec_controller.rb from the plugin into the example app (and remove the require from spec_helper.rb), that allows almost all of the specs to pass. The only specs that don't pass then are the two that redirect to :controller => "other", which is the same error. If I change those to redirect to :controller => "people", then their errors go away as well. ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 18:14 Message: A comment on the failing specs patch and how to reproduce the failures: the first spec will fail only very occasionally... like... say, only on the continuous integration server and not on your development laptop and only when you commit your last change for the day and need to get home. The second and third of the two specs are attempting to replicate the conditions that semi-randomly occur within the first spec. Thus, one and only one of them will always fail, but which one is dependent upon when a particular African butterfly has last flapped its wings. :-) ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 18:09 Message: Yep. I'm using sqlite. It seemed like it should be simpler than mysql. :-) (our production environment is running on SQL Server, which is emphatically *not* simpler than running on mysql.) $ dpkg -l|grep 'libsqlite\|sqlite.*ruby'|awk '{print $3,$2}' 0.0.23-3 libdbd-sqlite3-ruby 0.0.23-3 libdbd-sqlite3-ruby1.8 3.3.5-0.2 libsqlite3-0 1.1.0-2 libsqlite3-ruby 1.1.0-2 libsqlite3-ruby1.8 ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-27 15:59 Message: re: seg faults - are you using sqlite? Which version? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-27 15:59 Message: Thanks Nicholas - the pre-patch-failing specs would be especially great. Cheers, David ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 15:36 Message: Well, I can't run all of the specs, and I don't really know why, but I can run the redirect_to_spec.rb. I'll fix the patch to pass all of the tests in there, and I'll add another couple of specs which should fail without my patch. ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 12:50 Message: Now I'm getting segfaults when I run rake pre_commit! running against rails 1.2.3: ** Invoke environment ** Execute db:schema:load ** Execute spec:plugins /home/nevans/src/rspec/example_rails_app/vendor/rails/1.2.3/activerecord/lib/../../activesupport/lib/active_support/core_ext/object/extending.rb:27: [BUG] Segmentation fault ruby 1.8.4 (2005-12-24) [i486-linux] Aborted (core dumped) rake aborted! Command ruby -I"/home/nevans/src/rspec/rspec/lib" "/home/nevans/src/rspec/rspec/bin/spec" "vendor/plugins/rspec_on_rails/spec/rails/extensions/active_record_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/dsl/assigns_hash_proxy_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/dsl/ivar_proxy_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/assert_select_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/redirect_to_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/render_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/description_generation_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/controller_isolation_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/view_spec_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/helper_spec_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/behaviour_factory_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/controller_spec_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/test_unit_assertion_accessibility_spec.rb" --options "/home/nevans/src/rspec/example_rails_app/config/../spec/spec.opts" failed /home/nevans/src/rspec/rspec/lib/spec/rake/spectask.rb:131:in `define' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:835:in `verbose' /home/nevans/src/rspec/rspec/lib/spec/rake/spectask.rb:105:in `define' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:399:in `execute' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:399:in `execute' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:369:in `invoke' /usr/lib/ruby/1.8/thread.rb:135:in `synchronize' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:362:in `invoke' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:1935:in `run' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:1935:in `run' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/bin/rake:7 /usr/bin/rake:16 I deleted rails 1.2.3 and ran against 1.2.2 (which is what my other apps are using), and dies in the same location: ** Invoke environment ** Execute db:schema:load ** Execute spec:plugins /home/nevans/src/rspec/rspec/lib/spec/dsl/behaviour_callbacks.rb:48: [BUG] Segmentation fault ruby 1.8.4 (2005-12-24) [i486-linux] Aborted (core dumped) rake aborted! Command ruby -I"/home/nevans/src/rspec/rspec/lib" "/home/nevans/src/rspec/rspec/bin/spec" "vendor/plugins/rspec_on_rails/spec/rails/extensions/active_record_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/dsl/assigns_hash_proxy_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/dsl/ivar_proxy_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/assert_select_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/redirect_to_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/render_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/description_generation_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/controller_isolation_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/view_spec_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/helper_spec_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/behaviour_factory_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/controller_spec_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/test_unit_assertion_accessibility_spec.rb" --options "/home/nevans/src/rspec/example_rails_app/config/../spec/spec.opts" failed /home/nevans/src/rspec/rspec/lib/spec/rake/spectask.rb:131:in `define' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:835:in `verbose' /home/nevans/src/rspec/rspec/lib/spec/rake/spectask.rb:105:in `define' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:399:in `execute' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:399:in `execute' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:369:in `invoke' /usr/lib/ruby/1.8/thread.rb:135:in `synchronize' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:362:in `invoke' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:1935:in `run' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:1935:in `run' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/bin/rake:7 /usr/bin/rake:16 I'm running the Ubuntu Edgy version of ruby, which dpkg reports as 1.8.2, but ruby -v reports as 1.8.4. ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 12:28 Message: I found "rake rspec:generate_sqlite_config", and I'm working on getting the precommit bugs fixed now. ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 12:24 Message: More specific explanation of my rake precommit trouble: I was being lazy and didn't bother to debug the problem. It was complaining because config/database.yml was missing. I've looked into the example rails app, and there seems to be some rake tasks for creating a sample sqlite db, so I'll look into that now. Is there a particular magic sequence that could be issued to make it "just work" upon checkout? :-) ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-27 11:34 Message: That was 18 of 38 examples. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-27 11:25 Message: I tried to apply this and 18 of the 18 examples in redirect_to_spec.rb fail. Some are due to the changes you made to the failure messages - some for other reasons I haven't looked at yet. You said you were having trouble getting it to run - can you be more specific? Thanks, David ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=10410&group_id=797 From noreply at rubyforge.org Sat Apr 28 20:13:29 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sat, 28 Apr 2007 20:13:29 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-10410 ] redirect_to does not behave consistently with regards to query string parameter ordering Message-ID: <20070429001330.03345A970002@rubyforge.org> Patches item #10410, was opened at 2007-04-27 11:01 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=10410&group_id=797 Category: expectation module Group: None Status: Open Resolution: None Priority: 3 Submitted By: nicholas evans (nick_evans) Assigned to: David Chelimsky (dchelimsky) Summary: redirect_to does not behave consistently with regards to query string parameter ordering Initial Comment: This bug is *incredibly* difficult to reproduce. It ends up causing a spec to pass when run as a single file and fail when run as a group of files... or vice versa. Or pass on one computer, but fail on another. Or pass in an old working copy, but fail when re-checked out. Or pass when running the normal rake task, but fail when generating an HTML support. And so on and so forth! As you might imagine this can make continuous integration rather annoying. The problem is that rails will place the items in a hash into the query string in a semi-random order. Given similar hashes, the same URL will *usually* be generated by each. But often enough to be annoying, that is not the case. This is simply due to the unordered nature of hashes. So I made a patch to redirect_to to do two things: 1) If your redirect_to expectation is a hash, and the actual redirection is within http://test.host it will convert the actual redirect_url to a hash, and also convert the expectation to a URL and then back into a hash (this takes care of when you leave :controller out of the expectation). 2) If your redirect_to expectation is a hash, then the failure message will report the failure back as hashes. The previous error (expected hash but got string) was always a bit confusing. If your redirect_to expectation is a string or :back, then you will continue to get the old behavior: a direct string comparison (which may or may not be tripped up by query string order). I created the patch against version 0.8.3, because that is what I'm using, but the redirect_to matcher does not appear to have changed much (at all?) in trunk, and the patch applied cleanly. Although all of the specs using redirect_to in my app still work, I was having difficulties getting "rake precommit" to run correctly... Sorry. :-( ---------------------------------------------------------------------- >Comment By: nicholas evans (nick_evans) Date: 2007-04-28 20:13 Message: So, it turns out that 1.1.6 doesn't need any initialization to use that controller path. Sticking it $LOAD_PATH (already done at the top of the spec_helper) and preloading it via const_missing (when the spec references the actual controller class) was good enough. (1.2 still needs the controller_paths initialization). What *was* necessary was massaging the input to recognize_path to fit the 1.1.6 API, as in lines 508-509 of 1.1.6/actionpack/lib/action_controller/routing.rb. So then... maybe *this* patch will get the job done? (phew!) ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-28 19:37 Message: I looked into the code for ActionController::Routing::Routes.recognize_path in rails 1.1.6, and it's completely different. It even has a different signature. In rails 1.2, it takes a string (e.g. "/controller/action"). In rails 1.1, it takes an array (e.g. %w(controller action)). So, in addition to letting rails load the controller path (I think that safe_load_paths is the key to that), I'll need to modify the code in the redirect_to matcher to play nice with rails 1.1.6. ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-28 11:20 Message: Still working with 1.2, but not with 1.1.6... Here's what I've placed under all of the require lines in rspec_on_rails/spec/spec_helper.rb: http://pastie.caboo.se/57298 Does it matter that the Rails::Initializer has already run (by inclusion of the environment.rb which was included by the example_rails_app's spec_helper.rb, which was included by the rspec_on_rails plugin's spec_helper.rb)? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-28 10:54 Message: I think you can do it this way in 1.1.6: config = Rails::Configuration.new config.controller_paths << "#{dir}/../spec_resources/controllers" Rails::Initializer.run(:process, config) ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-28 08:34 Message: That works for 1.2, but not 1.1.6 ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-28 07:57 Message: Will this work (in spec_helper.rb)? Rails::Initializer.run do |config| config.controller_paths << "#{dir}/../spec_resources/controllers" end ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-28 01:20 Message: Oh... I just tried it out with rails 1.1.6... and it failed horribly. ActionController::Routing.controller_paths is a Rails 1.2 feature! :-( ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-28 01:11 Message: Placed judiciously inside the spec_helper.rb: ActionController::Routing.controller_paths << "#{dir}/../spec_resources/controllers" That was easy! :-) ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-28 00:03 Message: This sounds right. As things stand right now, these controllers are only included (from rspec_on_rails/spec/spec_helper.rb) when you run the specs for rspec_on_rails itself, so that problem is solved. Whatever monkey patching may be necessary to coerce routing into looking at the rspec_on_rails/spec_resources directory could also be included in the same file. Thanks for playing! I look forward to getting this in place. Cheers, David ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 23:46 Message: I was afraid that you might say that. ;-) I just wanted to tackle one problem at a time. My thought is that the only way to make this work would be to convince Rails routing to consider the rspec_on_rails controllers (or only the RedirectSpecController). I don't know the syntax for how to do that exactly, but I can search inside the code for rails engines or appable plugins to find out how they've done it. Hopefully I can find a minimally invasive method for doing this. The additional problem with that is that we certainly wouldn't want the rspec_on_rails plugin to be adding any controllers (or otherwise mucking with the environment) to every app that its included in, even in the test environment. We really only want this functionality to be triggered when the rspec_on_rails plugin specs are being run. Can this be accomplished simply by only putting the controller loading code into rspec_on_rails's spec_helper.rb? I don't know how to do either of these things at the moment, but I'll look into them both. But (unless something else comes up), I think this should solve our problem... right? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-27 19:44 Message: Hey Nick - thanks for the effort, but this patch presents a problem. To get the routing to work, it looks like you moved redirect_spec_controller.rb from rspec_on_rails/spec_resources to the example_rails_app. We've gone through great pains to decouple the plugin from the app, which is why all of the controllers for the specs that live in rspec_on_rails/spec/ are in rspec_on_rails/spec_resources. We need to figure out a way to maintain the location before I'm willing to apply this patch. Any ideas? I hope we can come up w/ something because it's a nice patch otherwise. Cheers, David ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 19:03 Message: D'oh! I had a copy/paste error... bad description text for the final new spec. $ diff passing_specs_including_new_error_behavior* 169c169 < + it "redirected to an internal URL which is unroutable but matched via a string" do --- > + it "redirected to an internal URL which is unroutable and matched via a hash" do ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 18:50 Message: As promised, I'm attaching the completed specs, including specs for the new error behavior: "response.should redirect_to(hash)" should fail if the redirection is not to a URL that is routable within the application. Same 3-step directions for application apply as with the last patch. I didn't add back the "failure message should print actual redirection as a hash when expectation is for a hash" behavior, because that extra layer of redirection was only really annoying when I couldn't depend on rails and rspec to behave nicely with their URLs. I don't really mind that the failure message compares a hash and a string now. :-) ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 18:27 Message: Two comments on the passing specs patch: 1) because "svn mv" doesn't translate well into the diff format, you'll want to apply it with the following three commands: svn cp rspec_on_rails/spec_resources/controllers/redirect_spec_controller.rb example_rails_app/app/controllers/redirect_spec_controller.rb patch -p0 < passes_specs.patch svn rm rspec_on_rails/spec_resources/controllers/redirect_spec_controller.rb --force 2) I haven't yet added the specs for the additional failure behavior (I actually reverted the failure message behavior that I originally added, and then added some new behavior for the new error type), but I'll get to that momentarily (with another patch). ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 18:25 Message: Okay, I figured out what the problem is: Since I'm converting the URL string back into a hash containing the controller, action, etc, the URL must be routable within the application. However, url_for and ActionController::Routing::Routes.generate have no such restrictions. For example: >> ActionController::Routing::Routes.generate :controller => "foo", :action => "bar" => "/foo/bar" >> ActionController::Routing::Routes.recognize_path "/foo/bar" ActionController::RoutingError: no route found to match "/foo/bar" with {} from ./script/../config/../config/../vendor/rails/actionpack/lib/action_controller/routing.rb:1292:in `recognize_path' from (irb):66 from :0 It seems reasonable to me to adjust the behavior of "response.should redirect_to" so that it returns an error if the controller attempts to redirect to an non-routable URL when your spec is trying to match against it by using a hash. If you want to spec against a URL that lives outside of your application's ability to route, you should probably be spec'ing against the string, right? At least, that's my current thought on the matter. It might be seen as a major change in behavior for the redirect_to matcher. What do you think? So, the controllers that are stored in the rspec_on_rails plugin are not recognized by the example_rails_app's routing. If I move redirect_spec_controller.rb from the plugin into the example app (and remove the require from spec_helper.rb), that allows almost all of the specs to pass. The only specs that don't pass then are the two that redirect to :controller => "other", which is the same error. If I change those to redirect to :controller => "people", then their errors go away as well. ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 18:14 Message: A comment on the failing specs patch and how to reproduce the failures: the first spec will fail only very occasionally... like... say, only on the continuous integration server and not on your development laptop and only when you commit your last change for the day and need to get home. The second and third of the two specs are attempting to replicate the conditions that semi-randomly occur within the first spec. Thus, one and only one of them will always fail, but which one is dependent upon when a particular African butterfly has last flapped its wings. :-) ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 18:09 Message: Yep. I'm using sqlite. It seemed like it should be simpler than mysql. :-) (our production environment is running on SQL Server, which is emphatically *not* simpler than running on mysql.) $ dpkg -l|grep 'libsqlite\|sqlite.*ruby'|awk '{print $3,$2}' 0.0.23-3 libdbd-sqlite3-ruby 0.0.23-3 libdbd-sqlite3-ruby1.8 3.3.5-0.2 libsqlite3-0 1.1.0-2 libsqlite3-ruby 1.1.0-2 libsqlite3-ruby1.8 ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-27 15:59 Message: re: seg faults - are you using sqlite? Which version? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-27 15:59 Message: Thanks Nicholas - the pre-patch-failing specs would be especially great. Cheers, David ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 15:36 Message: Well, I can't run all of the specs, and I don't really know why, but I can run the redirect_to_spec.rb. I'll fix the patch to pass all of the tests in there, and I'll add another couple of specs which should fail without my patch. ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 12:50 Message: Now I'm getting segfaults when I run rake pre_commit! running against rails 1.2.3: ** Invoke environment ** Execute db:schema:load ** Execute spec:plugins /home/nevans/src/rspec/example_rails_app/vendor/rails/1.2.3/activerecord/lib/../../activesupport/lib/active_support/core_ext/object/extending.rb:27: [BUG] Segmentation fault ruby 1.8.4 (2005-12-24) [i486-linux] Aborted (core dumped) rake aborted! Command ruby -I"/home/nevans/src/rspec/rspec/lib" "/home/nevans/src/rspec/rspec/bin/spec" "vendor/plugins/rspec_on_rails/spec/rails/extensions/active_record_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/dsl/assigns_hash_proxy_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/dsl/ivar_proxy_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/assert_select_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/redirect_to_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/render_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/description_generation_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/controller_isolation_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/view_spec_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/helper_spec_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/behaviour_factory_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/controller_spec_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/test_unit_assertion_accessibility_spec.rb" --options "/home/nevans/src/rspec/example_rails_app/config/../spec/spec.opts" failed /home/nevans/src/rspec/rspec/lib/spec/rake/spectask.rb:131:in `define' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:835:in `verbose' /home/nevans/src/rspec/rspec/lib/spec/rake/spectask.rb:105:in `define' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:399:in `execute' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:399:in `execute' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:369:in `invoke' /usr/lib/ruby/1.8/thread.rb:135:in `synchronize' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:362:in `invoke' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:1935:in `run' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:1935:in `run' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/bin/rake:7 /usr/bin/rake:16 I deleted rails 1.2.3 and ran against 1.2.2 (which is what my other apps are using), and dies in the same location: ** Invoke environment ** Execute db:schema:load ** Execute spec:plugins /home/nevans/src/rspec/rspec/lib/spec/dsl/behaviour_callbacks.rb:48: [BUG] Segmentation fault ruby 1.8.4 (2005-12-24) [i486-linux] Aborted (core dumped) rake aborted! Command ruby -I"/home/nevans/src/rspec/rspec/lib" "/home/nevans/src/rspec/rspec/bin/spec" "vendor/plugins/rspec_on_rails/spec/rails/extensions/active_record_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/dsl/assigns_hash_proxy_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/dsl/ivar_proxy_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/assert_select_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/redirect_to_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/render_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/description_generation_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/controller_isolation_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/view_spec_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/helper_spec_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/behaviour_factory_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/controller_spec_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/test_unit_assertion_accessibility_spec.rb" --options "/home/nevans/src/rspec/example_rails_app/config/../spec/spec.opts" failed /home/nevans/src/rspec/rspec/lib/spec/rake/spectask.rb:131:in `define' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:835:in `verbose' /home/nevans/src/rspec/rspec/lib/spec/rake/spectask.rb:105:in `define' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:399:in `execute' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:399:in `execute' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:369:in `invoke' /usr/lib/ruby/1.8/thread.rb:135:in `synchronize' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:362:in `invoke' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:1935:in `run' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:1935:in `run' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/bin/rake:7 /usr/bin/rake:16 I'm running the Ubuntu Edgy version of ruby, which dpkg reports as 1.8.2, but ruby -v reports as 1.8.4. ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 12:28 Message: I found "rake rspec:generate_sqlite_config", and I'm working on getting the precommit bugs fixed now. ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 12:24 Message: More specific explanation of my rake precommit trouble: I was being lazy and didn't bother to debug the problem. It was complaining because config/database.yml was missing. I've looked into the example rails app, and there seems to be some rake tasks for creating a sample sqlite db, so I'll look into that now. Is there a particular magic sequence that could be issued to make it "just work" upon checkout? :-) ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-27 11:34 Message: That was 18 of 38 examples. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-27 11:25 Message: I tried to apply this and 18 of the 18 examples in redirect_to_spec.rb fail. Some are due to the changes you made to the failure messages - some for other reasons I haven't looked at yet. You said you were having trouble getting it to run - can you be more specific? Thanks, David ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=10410&group_id=797 From noreply at rubyforge.org Sat Apr 28 20:14:28 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sat, 28 Apr 2007 20:14:28 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-10410 ] redirect_to does not behave consistently with regards to query string parameter ordering Message-ID: <20070429001428.90E3A5240BC3@rubyforge.org> Patches item #10410, was opened at 2007-04-27 11:01 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=10410&group_id=797 Category: expectation module Group: None Status: Open Resolution: None Priority: 3 Submitted By: nicholas evans (nick_evans) Assigned to: David Chelimsky (dchelimsky) Summary: redirect_to does not behave consistently with regards to query string parameter ordering Initial Comment: This bug is *incredibly* difficult to reproduce. It ends up causing a spec to pass when run as a single file and fail when run as a group of files... or vice versa. Or pass on one computer, but fail on another. Or pass in an old working copy, but fail when re-checked out. Or pass when running the normal rake task, but fail when generating an HTML support. And so on and so forth! As you might imagine this can make continuous integration rather annoying. The problem is that rails will place the items in a hash into the query string in a semi-random order. Given similar hashes, the same URL will *usually* be generated by each. But often enough to be annoying, that is not the case. This is simply due to the unordered nature of hashes. So I made a patch to redirect_to to do two things: 1) If your redirect_to expectation is a hash, and the actual redirection is within http://test.host it will convert the actual redirect_url to a hash, and also convert the expectation to a URL and then back into a hash (this takes care of when you leave :controller out of the expectation). 2) If your redirect_to expectation is a hash, then the failure message will report the failure back as hashes. The previous error (expected hash but got string) was always a bit confusing. If your redirect_to expectation is a string or :back, then you will continue to get the old behavior: a direct string comparison (which may or may not be tripped up by query string order). I created the patch against version 0.8.3, because that is what I'm using, but the redirect_to matcher does not appear to have changed much (at all?) in trunk, and the patch applied cleanly. Although all of the specs using redirect_to in my app still work, I was having difficulties getting "rake precommit" to run correctly... Sorry. :-( ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-28 20:13 Message: So, it turns out that 1.1.6 doesn't need any initialization to use that controller path. Sticking it $LOAD_PATH (already done at the top of the spec_helper) and preloading it via const_missing (when the spec references the actual controller class) was good enough. (1.2 still needs the controller_paths initialization). What *was* necessary was massaging the input to recognize_path to fit the 1.1.6 API, as in lines 508-509 of 1.1.6/actionpack/lib/action_controller/routing.rb. So then... maybe *this* patch will get the job done? (phew!) ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-28 19:37 Message: I looked into the code for ActionController::Routing::Routes.recognize_path in rails 1.1.6, and it's completely different. It even has a different signature. In rails 1.2, it takes a string (e.g. "/controller/action"). In rails 1.1, it takes an array (e.g. %w(controller action)). So, in addition to letting rails load the controller path (I think that safe_load_paths is the key to that), I'll need to modify the code in the redirect_to matcher to play nice with rails 1.1.6. ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-28 11:20 Message: Still working with 1.2, but not with 1.1.6... Here's what I've placed under all of the require lines in rspec_on_rails/spec/spec_helper.rb: http://pastie.caboo.se/57298 Does it matter that the Rails::Initializer has already run (by inclusion of the environment.rb which was included by the example_rails_app's spec_helper.rb, which was included by the rspec_on_rails plugin's spec_helper.rb)? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-28 10:54 Message: I think you can do it this way in 1.1.6: config = Rails::Configuration.new config.controller_paths << "#{dir}/../spec_resources/controllers" Rails::Initializer.run(:process, config) ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-28 08:34 Message: That works for 1.2, but not 1.1.6 ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-28 07:57 Message: Will this work (in spec_helper.rb)? Rails::Initializer.run do |config| config.controller_paths << "#{dir}/../spec_resources/controllers" end ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-28 01:20 Message: Oh... I just tried it out with rails 1.1.6... and it failed horribly. ActionController::Routing.controller_paths is a Rails 1.2 feature! :-( ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-28 01:11 Message: Placed judiciously inside the spec_helper.rb: ActionController::Routing.controller_paths << "#{dir}/../spec_resources/controllers" That was easy! :-) ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-28 00:03 Message: This sounds right. As things stand right now, these controllers are only included (from rspec_on_rails/spec/spec_helper.rb) when you run the specs for rspec_on_rails itself, so that problem is solved. Whatever monkey patching may be necessary to coerce routing into looking at the rspec_on_rails/spec_resources directory could also be included in the same file. Thanks for playing! I look forward to getting this in place. Cheers, David ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 23:46 Message: I was afraid that you might say that. ;-) I just wanted to tackle one problem at a time. My thought is that the only way to make this work would be to convince Rails routing to consider the rspec_on_rails controllers (or only the RedirectSpecController). I don't know the syntax for how to do that exactly, but I can search inside the code for rails engines or appable plugins to find out how they've done it. Hopefully I can find a minimally invasive method for doing this. The additional problem with that is that we certainly wouldn't want the rspec_on_rails plugin to be adding any controllers (or otherwise mucking with the environment) to every app that its included in, even in the test environment. We really only want this functionality to be triggered when the rspec_on_rails plugin specs are being run. Can this be accomplished simply by only putting the controller loading code into rspec_on_rails's spec_helper.rb? I don't know how to do either of these things at the moment, but I'll look into them both. But (unless something else comes up), I think this should solve our problem... right? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-27 19:44 Message: Hey Nick - thanks for the effort, but this patch presents a problem. To get the routing to work, it looks like you moved redirect_spec_controller.rb from rspec_on_rails/spec_resources to the example_rails_app. We've gone through great pains to decouple the plugin from the app, which is why all of the controllers for the specs that live in rspec_on_rails/spec/ are in rspec_on_rails/spec_resources. We need to figure out a way to maintain the location before I'm willing to apply this patch. Any ideas? I hope we can come up w/ something because it's a nice patch otherwise. Cheers, David ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 19:03 Message: D'oh! I had a copy/paste error... bad description text for the final new spec. $ diff passing_specs_including_new_error_behavior* 169c169 < + it "redirected to an internal URL which is unroutable but matched via a string" do --- > + it "redirected to an internal URL which is unroutable and matched via a hash" do ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 18:50 Message: As promised, I'm attaching the completed specs, including specs for the new error behavior: "response.should redirect_to(hash)" should fail if the redirection is not to a URL that is routable within the application. Same 3-step directions for application apply as with the last patch. I didn't add back the "failure message should print actual redirection as a hash when expectation is for a hash" behavior, because that extra layer of redirection was only really annoying when I couldn't depend on rails and rspec to behave nicely with their URLs. I don't really mind that the failure message compares a hash and a string now. :-) ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 18:27 Message: Two comments on the passing specs patch: 1) because "svn mv" doesn't translate well into the diff format, you'll want to apply it with the following three commands: svn cp rspec_on_rails/spec_resources/controllers/redirect_spec_controller.rb example_rails_app/app/controllers/redirect_spec_controller.rb patch -p0 < passes_specs.patch svn rm rspec_on_rails/spec_resources/controllers/redirect_spec_controller.rb --force 2) I haven't yet added the specs for the additional failure behavior (I actually reverted the failure message behavior that I originally added, and then added some new behavior for the new error type), but I'll get to that momentarily (with another patch). ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 18:25 Message: Okay, I figured out what the problem is: Since I'm converting the URL string back into a hash containing the controller, action, etc, the URL must be routable within the application. However, url_for and ActionController::Routing::Routes.generate have no such restrictions. For example: >> ActionController::Routing::Routes.generate :controller => "foo", :action => "bar" => "/foo/bar" >> ActionController::Routing::Routes.recognize_path "/foo/bar" ActionController::RoutingError: no route found to match "/foo/bar" with {} from ./script/../config/../config/../vendor/rails/actionpack/lib/action_controller/routing.rb:1292:in `recognize_path' from (irb):66 from :0 It seems reasonable to me to adjust the behavior of "response.should redirect_to" so that it returns an error if the controller attempts to redirect to an non-routable URL when your spec is trying to match against it by using a hash. If you want to spec against a URL that lives outside of your application's ability to route, you should probably be spec'ing against the string, right? At least, that's my current thought on the matter. It might be seen as a major change in behavior for the redirect_to matcher. What do you think? So, the controllers that are stored in the rspec_on_rails plugin are not recognized by the example_rails_app's routing. If I move redirect_spec_controller.rb from the plugin into the example app (and remove the require from spec_helper.rb), that allows almost all of the specs to pass. The only specs that don't pass then are the two that redirect to :controller => "other", which is the same error. If I change those to redirect to :controller => "people", then their errors go away as well. ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 18:14 Message: A comment on the failing specs patch and how to reproduce the failures: the first spec will fail only very occasionally... like... say, only on the continuous integration server and not on your development laptop and only when you commit your last change for the day and need to get home. The second and third of the two specs are attempting to replicate the conditions that semi-randomly occur within the first spec. Thus, one and only one of them will always fail, but which one is dependent upon when a particular African butterfly has last flapped its wings. :-) ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 18:09 Message: Yep. I'm using sqlite. It seemed like it should be simpler than mysql. :-) (our production environment is running on SQL Server, which is emphatically *not* simpler than running on mysql.) $ dpkg -l|grep 'libsqlite\|sqlite.*ruby'|awk '{print $3,$2}' 0.0.23-3 libdbd-sqlite3-ruby 0.0.23-3 libdbd-sqlite3-ruby1.8 3.3.5-0.2 libsqlite3-0 1.1.0-2 libsqlite3-ruby 1.1.0-2 libsqlite3-ruby1.8 ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-27 15:59 Message: re: seg faults - are you using sqlite? Which version? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-27 15:59 Message: Thanks Nicholas - the pre-patch-failing specs would be especially great. Cheers, David ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 15:36 Message: Well, I can't run all of the specs, and I don't really know why, but I can run the redirect_to_spec.rb. I'll fix the patch to pass all of the tests in there, and I'll add another couple of specs which should fail without my patch. ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 12:50 Message: Now I'm getting segfaults when I run rake pre_commit! running against rails 1.2.3: ** Invoke environment ** Execute db:schema:load ** Execute spec:plugins /home/nevans/src/rspec/example_rails_app/vendor/rails/1.2.3/activerecord/lib/../../activesupport/lib/active_support/core_ext/object/extending.rb:27: [BUG] Segmentation fault ruby 1.8.4 (2005-12-24) [i486-linux] Aborted (core dumped) rake aborted! Command ruby -I"/home/nevans/src/rspec/rspec/lib" "/home/nevans/src/rspec/rspec/bin/spec" "vendor/plugins/rspec_on_rails/spec/rails/extensions/active_record_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/dsl/assigns_hash_proxy_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/dsl/ivar_proxy_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/assert_select_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/redirect_to_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/render_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/description_generation_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/controller_isolation_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/view_spec_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/helper_spec_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/behaviour_factory_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/controller_spec_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/test_unit_assertion_accessibility_spec.rb" --options "/home/nevans/src/rspec/example_rails_app/config/../spec/spec.opts" failed /home/nevans/src/rspec/rspec/lib/spec/rake/spectask.rb:131:in `define' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:835:in `verbose' /home/nevans/src/rspec/rspec/lib/spec/rake/spectask.rb:105:in `define' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:399:in `execute' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:399:in `execute' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:369:in `invoke' /usr/lib/ruby/1.8/thread.rb:135:in `synchronize' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:362:in `invoke' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:1935:in `run' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:1935:in `run' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/bin/rake:7 /usr/bin/rake:16 I deleted rails 1.2.3 and ran against 1.2.2 (which is what my other apps are using), and dies in the same location: ** Invoke environment ** Execute db:schema:load ** Execute spec:plugins /home/nevans/src/rspec/rspec/lib/spec/dsl/behaviour_callbacks.rb:48: [BUG] Segmentation fault ruby 1.8.4 (2005-12-24) [i486-linux] Aborted (core dumped) rake aborted! Command ruby -I"/home/nevans/src/rspec/rspec/lib" "/home/nevans/src/rspec/rspec/bin/spec" "vendor/plugins/rspec_on_rails/spec/rails/extensions/active_record_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/dsl/assigns_hash_proxy_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/dsl/ivar_proxy_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/assert_select_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/redirect_to_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/render_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/description_generation_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/controller_isolation_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/view_spec_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/helper_spec_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/behaviour_factory_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/controller_spec_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/test_unit_assertion_accessibility_spec.rb" --options "/home/nevans/src/rspec/example_rails_app/config/../spec/spec.opts" failed /home/nevans/src/rspec/rspec/lib/spec/rake/spectask.rb:131:in `define' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:835:in `verbose' /home/nevans/src/rspec/rspec/lib/spec/rake/spectask.rb:105:in `define' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:399:in `execute' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:399:in `execute' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:369:in `invoke' /usr/lib/ruby/1.8/thread.rb:135:in `synchronize' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:362:in `invoke' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:1935:in `run' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:1935:in `run' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/bin/rake:7 /usr/bin/rake:16 I'm running the Ubuntu Edgy version of ruby, which dpkg reports as 1.8.2, but ruby -v reports as 1.8.4. ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 12:28 Message: I found "rake rspec:generate_sqlite_config", and I'm working on getting the precommit bugs fixed now. ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 12:24 Message: More specific explanation of my rake precommit trouble: I was being lazy and didn't bother to debug the problem. It was complaining because config/database.yml was missing. I've looked into the example rails app, and there seems to be some rake tasks for creating a sample sqlite db, so I'll look into that now. Is there a particular magic sequence that could be issued to make it "just work" upon checkout? :-) ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-27 11:34 Message: That was 18 of 38 examples. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-27 11:25 Message: I tried to apply this and 18 of the 18 examples in redirect_to_spec.rb fail. Some are due to the changes you made to the failure messages - some for other reasons I haven't looked at yet. You said you were having trouble getting it to run - can you be more specific? Thanks, David ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=10410&group_id=797 From noreply at rubyforge.org Sun Apr 29 02:32:33 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 29 Apr 2007 02:32:33 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-10410 ] redirect_to does not behave consistently with regards to query string parameter ordering Message-ID: <20070429063233.0EF1A5240BF5@rubyforge.org> Patches item #10410, was opened at 2007-04-27 15:01 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=10410&group_id=797 Category: expectation module Group: None >Status: Closed >Resolution: Accepted Priority: 3 Submitted By: nicholas evans (nick_evans) Assigned to: David Chelimsky (dchelimsky) Summary: redirect_to does not behave consistently with regards to query string parameter ordering Initial Comment: This bug is *incredibly* difficult to reproduce. It ends up causing a spec to pass when run as a single file and fail when run as a group of files... or vice versa. Or pass on one computer, but fail on another. Or pass in an old working copy, but fail when re-checked out. Or pass when running the normal rake task, but fail when generating an HTML support. And so on and so forth! As you might imagine this can make continuous integration rather annoying. The problem is that rails will place the items in a hash into the query string in a semi-random order. Given similar hashes, the same URL will *usually* be generated by each. But often enough to be annoying, that is not the case. This is simply due to the unordered nature of hashes. So I made a patch to redirect_to to do two things: 1) If your redirect_to expectation is a hash, and the actual redirection is within http://test.host it will convert the actual redirect_url to a hash, and also convert the expectation to a URL and then back into a hash (this takes care of when you leave :controller out of the expectation). 2) If your redirect_to expectation is a hash, then the failure message will report the failure back as hashes. The previous error (expected hash but got string) was always a bit confusing. If your redirect_to expectation is a string or :back, then you will continue to get the old behavior: a direct string comparison (which may or may not be tripped up by query string order). I created the patch against version 0.8.3, because that is what I'm using, but the redirect_to matcher does not appear to have changed much (at all?) in trunk, and the patch applied cleanly. Although all of the specs using redirect_to in my app still work, I was having difficulties getting "rake precommit" to run correctly... Sorry. :-( ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-04-29 06:32 Message: Applied to trunk rev 1828. Nice work Nicholas. Thanks! ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-29 00:13 Message: So, it turns out that 1.1.6 doesn't need any initialization to use that controller path. Sticking it $LOAD_PATH (already done at the top of the spec_helper) and preloading it via const_missing (when the spec references the actual controller class) was good enough. (1.2 still needs the controller_paths initialization). What *was* necessary was massaging the input to recognize_path to fit the 1.1.6 API, as in lines 508-509 of 1.1.6/actionpack/lib/action_controller/routing.rb. So then... maybe *this* patch will get the job done? (phew!) ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-28 23:37 Message: I looked into the code for ActionController::Routing::Routes.recognize_path in rails 1.1.6, and it's completely different. It even has a different signature. In rails 1.2, it takes a string (e.g. "/controller/action"). In rails 1.1, it takes an array (e.g. %w(controller action)). So, in addition to letting rails load the controller path (I think that safe_load_paths is the key to that), I'll need to modify the code in the redirect_to matcher to play nice with rails 1.1.6. ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-28 15:20 Message: Still working with 1.2, but not with 1.1.6... Here's what I've placed under all of the require lines in rspec_on_rails/spec/spec_helper.rb: http://pastie.caboo.se/57298 Does it matter that the Rails::Initializer has already run (by inclusion of the environment.rb which was included by the example_rails_app's spec_helper.rb, which was included by the rspec_on_rails plugin's spec_helper.rb)? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-28 14:54 Message: I think you can do it this way in 1.1.6: config = Rails::Configuration.new config.controller_paths << "#{dir}/../spec_resources/controllers" Rails::Initializer.run(:process, config) ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-28 12:34 Message: That works for 1.2, but not 1.1.6 ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-28 11:57 Message: Will this work (in spec_helper.rb)? Rails::Initializer.run do |config| config.controller_paths << "#{dir}/../spec_resources/controllers" end ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-28 05:20 Message: Oh... I just tried it out with rails 1.1.6... and it failed horribly. ActionController::Routing.controller_paths is a Rails 1.2 feature! :-( ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-28 05:11 Message: Placed judiciously inside the spec_helper.rb: ActionController::Routing.controller_paths << "#{dir}/../spec_resources/controllers" That was easy! :-) ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-28 04:03 Message: This sounds right. As things stand right now, these controllers are only included (from rspec_on_rails/spec/spec_helper.rb) when you run the specs for rspec_on_rails itself, so that problem is solved. Whatever monkey patching may be necessary to coerce routing into looking at the rspec_on_rails/spec_resources directory could also be included in the same file. Thanks for playing! I look forward to getting this in place. Cheers, David ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-28 03:46 Message: I was afraid that you might say that. ;-) I just wanted to tackle one problem at a time. My thought is that the only way to make this work would be to convince Rails routing to consider the rspec_on_rails controllers (or only the RedirectSpecController). I don't know the syntax for how to do that exactly, but I can search inside the code for rails engines or appable plugins to find out how they've done it. Hopefully I can find a minimally invasive method for doing this. The additional problem with that is that we certainly wouldn't want the rspec_on_rails plugin to be adding any controllers (or otherwise mucking with the environment) to every app that its included in, even in the test environment. We really only want this functionality to be triggered when the rspec_on_rails plugin specs are being run. Can this be accomplished simply by only putting the controller loading code into rspec_on_rails's spec_helper.rb? I don't know how to do either of these things at the moment, but I'll look into them both. But (unless something else comes up), I think this should solve our problem... right? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-27 23:44 Message: Hey Nick - thanks for the effort, but this patch presents a problem. To get the routing to work, it looks like you moved redirect_spec_controller.rb from rspec_on_rails/spec_resources to the example_rails_app. We've gone through great pains to decouple the plugin from the app, which is why all of the controllers for the specs that live in rspec_on_rails/spec/ are in rspec_on_rails/spec_resources. We need to figure out a way to maintain the location before I'm willing to apply this patch. Any ideas? I hope we can come up w/ something because it's a nice patch otherwise. Cheers, David ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 23:03 Message: D'oh! I had a copy/paste error... bad description text for the final new spec. $ diff passing_specs_including_new_error_behavior* 169c169 < + it "redirected to an internal URL which is unroutable but matched via a string" do --- > + it "redirected to an internal URL which is unroutable and matched via a hash" do ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 22:50 Message: As promised, I'm attaching the completed specs, including specs for the new error behavior: "response.should redirect_to(hash)" should fail if the redirection is not to a URL that is routable within the application. Same 3-step directions for application apply as with the last patch. I didn't add back the "failure message should print actual redirection as a hash when expectation is for a hash" behavior, because that extra layer of redirection was only really annoying when I couldn't depend on rails and rspec to behave nicely with their URLs. I don't really mind that the failure message compares a hash and a string now. :-) ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 22:27 Message: Two comments on the passing specs patch: 1) because "svn mv" doesn't translate well into the diff format, you'll want to apply it with the following three commands: svn cp rspec_on_rails/spec_resources/controllers/redirect_spec_controller.rb example_rails_app/app/controllers/redirect_spec_controller.rb patch -p0 < passes_specs.patch svn rm rspec_on_rails/spec_resources/controllers/redirect_spec_controller.rb --force 2) I haven't yet added the specs for the additional failure behavior (I actually reverted the failure message behavior that I originally added, and then added some new behavior for the new error type), but I'll get to that momentarily (with another patch). ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 22:25 Message: Okay, I figured out what the problem is: Since I'm converting the URL string back into a hash containing the controller, action, etc, the URL must be routable within the application. However, url_for and ActionController::Routing::Routes.generate have no such restrictions. For example: >> ActionController::Routing::Routes.generate :controller => "foo", :action => "bar" => "/foo/bar" >> ActionController::Routing::Routes.recognize_path "/foo/bar" ActionController::RoutingError: no route found to match "/foo/bar" with {} from ./script/../config/../config/../vendor/rails/actionpack/lib/action_controller/routing.rb:1292:in `recognize_path' from (irb):66 from :0 It seems reasonable to me to adjust the behavior of "response.should redirect_to" so that it returns an error if the controller attempts to redirect to an non-routable URL when your spec is trying to match against it by using a hash. If you want to spec against a URL that lives outside of your application's ability to route, you should probably be spec'ing against the string, right? At least, that's my current thought on the matter. It might be seen as a major change in behavior for the redirect_to matcher. What do you think? So, the controllers that are stored in the rspec_on_rails plugin are not recognized by the example_rails_app's routing. If I move redirect_spec_controller.rb from the plugin into the example app (and remove the require from spec_helper.rb), that allows almost all of the specs to pass. The only specs that don't pass then are the two that redirect to :controller => "other", which is the same error. If I change those to redirect to :controller => "people", then their errors go away as well. ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 22:14 Message: A comment on the failing specs patch and how to reproduce the failures: the first spec will fail only very occasionally... like... say, only on the continuous integration server and not on your development laptop and only when you commit your last change for the day and need to get home. The second and third of the two specs are attempting to replicate the conditions that semi-randomly occur within the first spec. Thus, one and only one of them will always fail, but which one is dependent upon when a particular African butterfly has last flapped its wings. :-) ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 22:09 Message: Yep. I'm using sqlite. It seemed like it should be simpler than mysql. :-) (our production environment is running on SQL Server, which is emphatically *not* simpler than running on mysql.) $ dpkg -l|grep 'libsqlite\|sqlite.*ruby'|awk '{print $3,$2}' 0.0.23-3 libdbd-sqlite3-ruby 0.0.23-3 libdbd-sqlite3-ruby1.8 3.3.5-0.2 libsqlite3-0 1.1.0-2 libsqlite3-ruby 1.1.0-2 libsqlite3-ruby1.8 ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-27 19:59 Message: re: seg faults - are you using sqlite? Which version? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-27 19:59 Message: Thanks Nicholas - the pre-patch-failing specs would be especially great. Cheers, David ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 19:36 Message: Well, I can't run all of the specs, and I don't really know why, but I can run the redirect_to_spec.rb. I'll fix the patch to pass all of the tests in there, and I'll add another couple of specs which should fail without my patch. ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 16:50 Message: Now I'm getting segfaults when I run rake pre_commit! running against rails 1.2.3: ** Invoke environment ** Execute db:schema:load ** Execute spec:plugins /home/nevans/src/rspec/example_rails_app/vendor/rails/1.2.3/activerecord/lib/../../activesupport/lib/active_support/core_ext/object/extending.rb:27: [BUG] Segmentation fault ruby 1.8.4 (2005-12-24) [i486-linux] Aborted (core dumped) rake aborted! Command ruby -I"/home/nevans/src/rspec/rspec/lib" "/home/nevans/src/rspec/rspec/bin/spec" "vendor/plugins/rspec_on_rails/spec/rails/extensions/active_record_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/dsl/assigns_hash_proxy_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/dsl/ivar_proxy_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/assert_select_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/redirect_to_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/render_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/description_generation_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/controller_isolation_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/view_spec_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/helper_spec_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/behaviour_factory_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/controller_spec_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/test_unit_assertion_accessibility_spec.rb" --options "/home/nevans/src/rspec/example_rails_app/config/../spec/spec.opts" failed /home/nevans/src/rspec/rspec/lib/spec/rake/spectask.rb:131:in `define' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:835:in `verbose' /home/nevans/src/rspec/rspec/lib/spec/rake/spectask.rb:105:in `define' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:399:in `execute' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:399:in `execute' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:369:in `invoke' /usr/lib/ruby/1.8/thread.rb:135:in `synchronize' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:362:in `invoke' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:1935:in `run' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:1935:in `run' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/bin/rake:7 /usr/bin/rake:16 I deleted rails 1.2.3 and ran against 1.2.2 (which is what my other apps are using), and dies in the same location: ** Invoke environment ** Execute db:schema:load ** Execute spec:plugins /home/nevans/src/rspec/rspec/lib/spec/dsl/behaviour_callbacks.rb:48: [BUG] Segmentation fault ruby 1.8.4 (2005-12-24) [i486-linux] Aborted (core dumped) rake aborted! Command ruby -I"/home/nevans/src/rspec/rspec/lib" "/home/nevans/src/rspec/rspec/bin/spec" "vendor/plugins/rspec_on_rails/spec/rails/extensions/active_record_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/dsl/assigns_hash_proxy_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/dsl/ivar_proxy_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/assert_select_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/redirect_to_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/render_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/matchers/description_generation_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/controller_isolation_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/view_spec_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/helper_spec_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/behaviour_factory_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/controller_spec_spec.rb" "vendor/plugins/rspec_on_rails/spec/rails/runner/test_unit_assertion_accessibility_spec.rb" --options "/home/nevans/src/rspec/example_rails_app/config/../spec/spec.opts" failed /home/nevans/src/rspec/rspec/lib/spec/rake/spectask.rb:131:in `define' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:835:in `verbose' /home/nevans/src/rspec/rspec/lib/spec/rake/spectask.rb:105:in `define' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:399:in `execute' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:399:in `execute' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:369:in `invoke' /usr/lib/ruby/1.8/thread.rb:135:in `synchronize' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:362:in `invoke' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:1935:in `run' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:1935:in `run' /usr/lib/ruby/gems/1.8/gems/rake-0.7.2/bin/rake:7 /usr/bin/rake:16 I'm running the Ubuntu Edgy version of ruby, which dpkg reports as 1.8.2, but ruby -v reports as 1.8.4. ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 16:28 Message: I found "rake rspec:generate_sqlite_config", and I'm working on getting the precommit bugs fixed now. ---------------------------------------------------------------------- Comment By: nicholas evans (nick_evans) Date: 2007-04-27 16:24 Message: More specific explanation of my rake precommit trouble: I was being lazy and didn't bother to debug the problem. It was complaining because config/database.yml was missing. I've looked into the example rails app, and there seems to be some rake tasks for creating a sample sqlite db, so I'll look into that now. Is there a particular magic sequence that could be issued to make it "just work" upon checkout? :-) ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-27 15:34 Message: That was 18 of 38 examples. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-27 15:25 Message: I tried to apply this and 18 of the 18 examples in redirect_to_spec.rb fail. Some are due to the changes you made to the failure messages - some for other reasons I haven't looked at yet. You said you were having trouble getting it to run - can you be more specific? Thanks, David ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=10410&group_id=797 From noreply at rubyforge.org Sun Apr 29 02:44:33 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 29 Apr 2007 02:44:33 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-10245 ] Patch to HTML escape the behavior name when using HTML Formatter Message-ID: <20070429064433.616B75240BF6@rubyforge.org> Patches item #10245, was opened at 2007-04-20 01:17 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=10245&group_id=797 Category: runner module Group: None >Status: Closed >Resolution: Accepted Priority: 3 Submitted By: Josh Knowles (joshknowles) >Assigned to: David Chelimsky (dchelimsky) Summary: Patch to HTML escape the behavior name when using HTML Formatter Initial Comment: This small patch HTML escapes the behavior name when using the HTML formatter. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-04-29 06:44 Message: Applied to trunk #1826. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=10245&group_id=797 From noreply at rubyforge.org Sun Apr 29 02:56:06 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 29 Apr 2007 02:56:06 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-10315 ] Patch to fix pre_commit (bug 10313) Message-ID: <20070429065606.C70FF5240BF5@rubyforge.org> Patches item #10315, was opened at 2007-04-23 15:22 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=10315&group_id=797 Category: None Group: None >Status: Closed >Resolution: Accepted Priority: 3 Submitted By: Antti Tarvainen (tarvaina) >Assigned to: David Chelimsky (dchelimsky) Summary: Patch to fix pre_commit (bug 10313) Initial Comment: Here's a patch for the bug I reported earlier today. Changes to the running code are: - fixed PreCommit#silent_sh. - ensured destroy_purchase is run every time at the end of PreCommit::RspecOnRails#rspec_pre_commit. I included some specs in the patch for regression testing. Note however that: - The specs are not run as part of the "rake pre_commit". - There is no rake task to run them. - The specs are not very good BDD. This is because pre_commit code didn't have any specs before and it isn't easily specsable in its current form. Instead of investing time to write exhaustive specs for the current implementation, I suggest we refactor the pre_commit code to make it more easily specsable, writing specs along the way. (Move shell-calls to a module of their own, etc.) (I can look into it this week, if you agree.) ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-04-29 06:56 Message: Applied to trunk rev 1830. If you're interested in refactoring and spec'ing pre_commit, that's great. The current form was a big step forward from everything just being in a rake file, but what you propose sounds even better. Thanks, David ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=10315&group_id=797 From noreply at rubyforge.org Sun Apr 29 02:57:29 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 29 Apr 2007 02:57:29 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-10313 ] pre_commit_rails: doesn't always build correctly Message-ID: <20070429065730.26D1A5240BF5@rubyforge.org> Bugs item #10313, was opened at 2007-04-23 12:38 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10313&group_id=797 Category: None Group: None >Status: Closed >Resolution: Accepted Priority: 3 Submitted By: Antti Tarvainen (tarvaina) >Assigned to: David Chelimsky (dchelimsky) Summary: pre_commit_rails: doesn't always build correctly Initial Comment: First the cause: The PreCommit#silent_sh method is supposed to return the output of the command it runs, but it always returns "". This is easily fixed: Index: pre_commit/lib/pre_commit/pre_commit.rb =================================================================== --- pre_commit/lib/pre_commit/pre_commit.rb (revision 1802) +++ pre_commit/lib/pre_commit/pre_commit.rb (working copy) @@ -20,10 +20,10 @@ def silent_sh(cmd, &block) output = nil IO.popen(cmd) do |io| - io.each_line do |line| + output = io.read + output.each_line do |line| block.call(line) if block end - output = io.read end output end The reason this is a bug report and not a patch is that fixing silent_sh breaks the build. Here is my understanding of what is happening: 1. Rake against Rails Edge fails. (This is ok.) Since it fails, destroy_purchase is not called, and generated rspec_resource files are left in the example_rails_app. 2. Rake starts to build agains Rails 1.2.3, but fails since it cannot create the rspec_resource files again. In the current trunk, the rake task doesn't notice that rspec_resource generation failed (since it doesn't get the output back from silent_sh), and continues the rake task. Thus, the rspec_resources in tests against 1.2.3 are actually created with Rails edge. Attached is a diff of not-very-bdd specs for repeating parts of this. You can run them in trunk root with ruby rspec/bin/spec pre_commit/spec I will look into this myself later today to see if I can patch it. I'll let you know. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-04-29 06:57 Message: Fixed with patch 10315. See http://rubyforge.org/tracker/index.php?func=detail&aid=10315&group_id=797&atid=3151 ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10313&group_id=797 From noreply at rubyforge.org Sun Apr 29 03:00:12 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 29 Apr 2007 03:00:12 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-9598 ] Change to Object.path2class to resolve conflicts with namespaced controllers Message-ID: <20070429070012.AF9AE5240BF6@rubyforge.org> Patches item #9598, was opened at 2007-03-26 20:10 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=9598&group_id=797 Category: rails plugin Group: None >Status: Closed >Resolution: Out of Date Priority: 3 Submitted By: bruno bornsztein (bborn) >Assigned to: David Chelimsky (dchelimsky) Summary: Change to Object.path2class to resolve conflicts with namespaced controllers Initial Comment: The RSpec on Rails plugin adds a path2class method to Object, which is intended to get a class from a string; however the existing implementation failed when using namespaced classes, for example: def self.path2class(klassname) klassname.split('::').inject(Object) { |k,n| k.const_get n } end "TenantsController".inject(Object) { |k,n| k.const_get n } => TenantsController "Admin::TenantsController".inject(Object) { |k,n| k.const_get n } => TenantsController This is a problem if you have two controllers with the same name in different namespaces. The solution uses Rails' Inflector.constantize instead: def self.path2class(klassname) klassname.constantize end "TenantsController".constantize => TenantsController "Admin::TenantsController".constantize => Admin::TenantsController This yields the expected result. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-04-29 07:00 Message: Closing this since we haven't gotten an updated patch that passes the other specs. Please feel free to reopen when you have a new patch to submit. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-08 14:39 Message: Applying this patch causes other failures when run against trunk rev 1727 (output below). Please be sure all specs are passing and resubmit. ============================================= rake spec:plugins 1) 'Given a controller spec running in isolation mode a spec in a context without controller_name set should fail with a useful warning' FAILED example block expected # but raised # ./vendor/plugins/rspec_on_rails/spec/rails/runner/controller_spec_spec.rb:83 2) 'Given a controller spec running in integration mode a spec in a context without controller_name set should fail with a useful warning' FAILED example block expected # but raised # ./vendor/plugins/rspec_on_rails/spec/rails/runner/controller_spec_spec.rb:83 ---------------------------------------------------------------------- Comment By: bruno bornsztein (bborn) Date: 2007-03-26 20:12 Message: Sorry... forgot to check the box when attaching files. ---------------------------------------------------------------------- Comment By: bruno bornsztein (bborn) Date: 2007-03-26 20:11 Message: Here's a spec. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=9598&group_id=797 From noreply at rubyforge.org Sun Apr 29 03:05:57 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 29 Apr 2007 03:05:57 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-7145 ] Hint for subversion users Message-ID: <20070429070557.EEA505240BF5@rubyforge.org> Bugs item #7145, was opened at 2006-12-07 09:28 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=7145&group_id=797 Category: rails plugin Group: None >Status: Closed >Resolution: Accepted Priority: 3 Submitted By: Stefan Saasen (attachr) >Assigned to: David Chelimsky (dchelimsky) Summary: Hint for subversion users Initial Comment: Hi, the revision based version information used in vendor/plugins/rspec/lib/spec/rails/version.rb causes trouble if subversion is used to manage the rails application. If svn:keywords is set to "Revision" on version.rb the Revision is updated to the local revision. This causes the rspec on rails plugin to fail. Maybe you can add a hint to the documentation to either disable svn:keywords (Revision) on version.rb or to manually change the REV constant to the original revision (1201 for the 0.7.4 plugin). best regards stefan saasen ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-04-29 07:05 Message: Fixed in trunk rev 1831. ---------------------------------------------------------------------- Comment By: Stefan Saasen (attachr) Date: 2007-04-17 08:48 Message: No, the problem only occurs if the plugin is installed without using svn:externals. The problem is as soon as you install the plugin and the rails project (including all the plugins) is managed using Subversion the RSpec Revision will be replaced. For example: version.rb in RSPec has Revision 15xx After installing the plugin the Revision number is set to whatever is used for the version.rb file in the Rails project. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-04-17 01:08 Message: I don't understand this. We have set the svn:keywords to "Revision" as you mentioned - in RSpec's own svn. I'm assuming you have installed RSpec as a plugin with svn:externals. Are you saying that RSpec's version.rb is updated with *your* repository's revision instead of *RSpec's* revision? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=7145&group_id=797 From dan at tastapod.com Sun Apr 29 13:15:09 2007 From: dan at tastapod.com (Dan North) Date: Sun, 29 Apr 2007 18:15:09 +0100 Subject: [rspec-devel] Multiple formatters In-Reply-To: <8d961d900704240141v5c318aaet449db2ab1f83ac7a@mail.gmail.com> References: <8d961d900704240141v5c318aaet449db2ab1f83ac7a@mail.gmail.com> Message-ID: <4634D29D.7090105@tastapod.com> +1. One thing I would add is html:*/*absolute/file/path vs rdoc:relative/path.rdoc. Also, can you guys check the file stuff works with windows paths too (e.g. html:/c:/temp/blah.html). Cheers, Dan aslak hellesoy wrote: > Hi all, > > RSpec supports multiple formatters, but currently you can only use one > at a time. I really need to use several at the same time. > > I'd like to make RSpec handle several --format options. However, that > would require some rethinking of how/where output is written - it > can't all go to the same stream (file or stdout). > > So I'm thinking of making --format take a composite argument: > > --format html:/path/to/index.html --format rdoc:/path/to/index.rdoc > --format progress > > If nothing comes after the format, output is STDOUT, so this would be > backwards compatible. > > If we do this, we could also get rid of --failures - it would just be > a special formatter. > > WDYT? > _______________________________________________ > 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/20070429/2fb1307c/attachment.html From aslak.hellesoy at gmail.com Sun Apr 29 15:22:26 2007 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Sun, 29 Apr 2007 21:22:26 +0200 Subject: [rspec-devel] Multiple formatters In-Reply-To: <4634D29D.7090105@tastapod.com> References: <8d961d900704240141v5c318aaet449db2ab1f83ac7a@mail.gmail.com> <4634D29D.7090105@tastapod.com> Message-ID: <8d961d900704291222m7b4d8ffdhe6b4a1444869b949@mail.gmail.com> On 4/29/07, Dan North wrote: > > +1. > > One thing I would add is html:/absolute/file/path vs > rdoc:relative/path.rdoc. > The feature was implemented on trunk last week. Whatever comes after the last colon is treated as a file name, and Ruby's File.new will handle both relative and absolute paths. No extra voodoo on our part is needed. > Also, can you guys check the file stuff works with windows paths too (e.g. > html:/c:/temp/blah.html). > Affirmative > Cheers, > Dan > > aslak hellesoy wrote: > Hi all, > > RSpec supports multiple formatters, but currently you can only use one > at a time. I really need to use several at the same time. > > I'd like to make RSpec handle several --format options. However, that > would require some rethinking of how/where output is written - it > can't all go to the same stream (file or stdout). > > So I'm thinking of making --format take a composite argument: > > --format html:/path/to/index.html --format rdoc:/path/to/index.rdoc > --format progress > > If nothing comes after the format, output is STDOUT, so this would be > backwards compatible. > > If we do this, we could also get rid of --failures - it would just be > a special formatter. > > WDYT? > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > > > > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From noreply at rubyforge.org Mon Apr 30 03:26:29 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 30 Apr 2007 03:26:29 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-10460 ] Make it easier to create default BehaviourRunner Message-ID: <20070430072629.5BE0B5240C3C@rubyforge.org> Feature Requests item #10460, was opened at 2007-04-30 00:26 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10460&group_id=797 Category: None Group: None Status: Open Priority: 3 Submitted By: Brian Takita (btakita) Assigned to: Nobody (None) Summary: Make it easier to create default BehaviourRunner Initial Comment: Right now, it is difficult to create a default BehaviourRunner in code. The easiest way to do so is to call create_behaviour_runner and pass in simulated command line args. It would be nice if one would instantiate a BehaviourRunner in a "default" state and work from there. So far I created a Spec::Runner::Options class to replace the OpenStruct implementation. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10460&group_id=797 From noreply at rubyforge.org Mon Apr 30 03:27:14 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 30 Apr 2007 03:27:14 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-10460 ] Make it easier to create default BehaviourRunner Message-ID: <20070430072714.BEF2B5240C3D@rubyforge.org> Feature Requests item #10460, was opened at 2007-04-30 00:26 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10460&group_id=797 Category: None Group: None Status: Open Priority: 3 Submitted By: Brian Takita (btakita) Assigned to: Nobody (None) Summary: Make it easier to create default BehaviourRunner Initial Comment: Right now, it is difficult to create a default BehaviourRunner in code. The easiest way to do so is to call create_behaviour_runner and pass in simulated command line args. It would be nice if one would instantiate a BehaviourRunner in a "default" state and work from there. So far I created a Spec::Runner::Options class to replace the OpenStruct implementation. ---------------------------------------------------------------------- >Comment By: Brian Takita (btakita) Date: 2007-04-30 00:27 Message: I'm thinking that the Spec::Runner::Options object can be instantiated with default values. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10460&group_id=797 From noreply at rubyforge.org Mon Apr 30 03:57:52 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 30 Apr 2007 03:57:52 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-10460 ] Make it easier to create default BehaviourRunner Message-ID: <20070430075752.818E05240C47@rubyforge.org> Feature Requests item #10460, was opened at 2007-04-30 03:26 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10460&group_id=797 Category: None Group: None Status: Open Priority: 3 Submitted By: Brian Takita (btakita) Assigned to: Nobody (None) Summary: Make it easier to create default BehaviourRunner Initial Comment: Right now, it is difficult to create a default BehaviourRunner in code. The easiest way to do so is to call create_behaviour_runner and pass in simulated command line args. It would be nice if one would instantiate a BehaviourRunner in a "default" state and work from there. So far I created a Spec::Runner::Options class to replace the OpenStruct implementation. ---------------------------------------------------------------------- >Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-04-30 03:57 Message: Did you mean to attach the code? ---------------------------------------------------------------------- Comment By: Brian Takita (btakita) Date: 2007-04-30 03:27 Message: I'm thinking that the Spec::Runner::Options object can be instantiated with default values. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10460&group_id=797 From noreply at rubyforge.org Mon Apr 30 04:40:54 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 30 Apr 2007 04:40:54 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-10460 ] Make it easier to create default BehaviourRunner Message-ID: <20070430084054.4A4F35240999@rubyforge.org> Feature Requests item #10460, was opened at 2007-04-30 00:26 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10460&group_id=797 Category: None Group: None Status: Open Priority: 3 Submitted By: Brian Takita (btakita) Assigned to: Nobody (None) Summary: Make it easier to create default BehaviourRunner Initial Comment: Right now, it is difficult to create a default BehaviourRunner in code. The easiest way to do so is to call create_behaviour_runner and pass in simulated command line args. It would be nice if one would instantiate a BehaviourRunner in a "default" state and work from there. So far I created a Spec::Runner::Options class to replace the OpenStruct implementation. ---------------------------------------------------------------------- >Comment By: Brian Takita (btakita) Date: 2007-04-30 01:40 Message: I already checked in the Options class. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-04-30 00:57 Message: Did you mean to attach the code? ---------------------------------------------------------------------- Comment By: Brian Takita (btakita) Date: 2007-04-30 00:27 Message: I'm thinking that the Spec::Runner::Options object can be instantiated with default values. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10460&group_id=797 From noreply at rubyforge.org Mon Apr 30 07:33:05 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 30 Apr 2007 07:33:05 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-10460 ] Make it easier to create default BehaviourRunner Message-ID: <20070430113305.5F80D52409F3@rubyforge.org> Feature Requests item #10460, was opened at 2007-04-30 07:26 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10460&group_id=797 Category: None Group: None Status: Open Priority: 3 Submitted By: Brian Takita (btakita) Assigned to: Nobody (None) Summary: Make it easier to create default BehaviourRunner Initial Comment: Right now, it is difficult to create a default BehaviourRunner in code. The easiest way to do so is to call create_behaviour_runner and pass in simulated command line args. It would be nice if one would instantiate a BehaviourRunner in a "default" state and work from there. So far I created a Spec::Runner::Options class to replace the OpenStruct implementation. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-04-30 11:33 Message: I like the idea of localizing the default settings like this, though it makes me think that Options should contain most of the decision making as well, passing command line args to methods on Options. That should make things more clear since right now we have the parsing and decision making all intermingled. ---------------------------------------------------------------------- Comment By: Brian Takita (btakita) Date: 2007-04-30 08:40 Message: I already checked in the Options class. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-04-30 07:57 Message: Did you mean to attach the code? ---------------------------------------------------------------------- Comment By: Brian Takita (btakita) Date: 2007-04-30 07:27 Message: I'm thinking that the Spec::Runner::Options object can be instantiated with default values. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10460&group_id=797 From noreply at rubyforge.org Mon Apr 30 08:53:19 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 30 Apr 2007 08:53:19 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-10465 ] Pre_commit method comments Message-ID: <20070430125319.ADF9F5240A2F@rubyforge.org> Patches item #10465, was opened at 2007-04-30 15:53 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=10465&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Antti Tarvainen (tarvaina) Assigned to: Nobody (None) Summary: Pre_commit method comments Initial Comment: As the first step to refactor the pre_commit code I reviewed it and added comments to reveal its (perceived) intention and tricky places of implementation. I didn't make any changes to the code but I did write some FIXMEs to wherever I noticed dead code or bugs. I plan to remove most of the comments after the specs and the code itself reveal intention better. BTW. Should we have a build category or something similar in the RubyForge tracker? This doesn't fall under any of the existing categories. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=10465&group_id=797 From noreply at rubyforge.org Mon Apr 30 09:35:59 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 30 Apr 2007 09:35:59 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-10465 ] Pre_commit method comments Message-ID: <20070430133559.B5C765240954@rubyforge.org> Patches item #10465, was opened at 2007-04-30 12:53 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=10465&group_id=797 >Category: build Group: None Status: Open Resolution: None Priority: 3 Submitted By: Antti Tarvainen (tarvaina) Assigned to: Nobody (None) Summary: Pre_commit method comments Initial Comment: As the first step to refactor the pre_commit code I reviewed it and added comments to reveal its (perceived) intention and tricky places of implementation. I didn't make any changes to the code but I did write some FIXMEs to wherever I noticed dead code or bugs. I plan to remove most of the comments after the specs and the code itself reveal intention better. BTW. Should we have a build category or something similar in the RubyForge tracker? This doesn't fall under any of the existing categories. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-04-30 13:35 Message: Added build category and set this accordingly. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=10465&group_id=797 From noreply at rubyforge.org Mon Apr 30 16:46:26 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 30 Apr 2007 16:46:26 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-10473 ] Add should exist (new matcher) Message-ID: <20070430204626.A80D45240A9F@rubyforge.org> Feature Requests item #10473, was opened at 2007-04-30 15:46 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10473&group_id=797 Category: expectation module Group: None Status: Open Priority: 3 Submitted By: Bret Pettichord (bret) Assigned to: Nobody (None) Summary: Add should exist (new matcher) Initial Comment: This would be particularly useful with Watir, which provides a frequently used exists?/exist? method. Index: C:/work/rspec/rspec/spec/spec/matchers/exist_spec.rb =================================================================== --- C:/work/rspec/rspec/spec/spec/matchers/exist_spec.rb (revision 0) +++ C:/work/rspec/rspec/spec/spec/matchers/exist_spec.rb (revision 0) @@ -0,0 +1,45 @@ +require File.dirname(__FILE__) + '/../../spec_helper.rb' + +class Substance + def initialize exists, description + @exists = exists + @description = description + end + def exist? + @exists + end + def inspect + @description + end +end + +describe "should exist" do + setup do + @real = Substance.new true, 'something real' + @imaginary = Substance.new false, 'something imaginary' + end + + it "should pass if target exists" do + @real.should exist + end + + it "should fail if target does not exist" do + lambda { @imaginary.should exist }. + should fail_with("expected something imaginary to exist, but it doesn't.") + end +end + +describe "should_not exist" do + setup do + @real = Substance.new true, 'something real' + @imaginary = Substance.new false, 'something imaginary' + end + it "should pass if target doesn't exist" do + @imaginary.should_not exist + end + it "should fail if target does exist" do + lambda { @real.should_not exist }. + should fail_with("expected something real to not exist, but it does.") + end +end + \ No newline at end of file Index: C:/work/rspec/rspec/lib/spec/matchers/exist.rb =================================================================== --- C:/work/rspec/rspec/lib/spec/matchers/exist.rb (revision 0) +++ C:/work/rspec/rspec/lib/spec/matchers/exist.rb (revision 0) @@ -0,0 +1,21 @@ +module Spec + module Matchers + + + class Exist + def matches? actual + @actual = actual + @actual.exist? + end + def failure_message + "expected #{@actual.inspect} to exist, but it doesn't." + end + def negative_failure_message + "expected #{@actual.inspect} to not exist, but it does." + end + end + + def exist; Exist.new; end + end +end + Index: C:/work/rspec/rspec/lib/spec/matchers.rb =================================================================== --- C:/work/rspec/rspec/lib/spec/matchers.rb (revision 1850) +++ C:/work/rspec/rspec/lib/spec/matchers.rb (working copy) @@ -2,6 +2,7 @@ require 'spec/matchers/be_close' require 'spec/matchers/change' require 'spec/matchers/eql' +require 'spec/matchers/exist' require 'spec/matchers/equal' require 'spec/matchers/has' require 'spec/matchers/have' ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10473&group_id=797 From noreply at rubyforge.org Mon Apr 30 17:46:06 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 30 Apr 2007 17:46:06 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-10473 ] Add should exist (new matcher) Message-ID: <20070430214606.7855E5240A87@rubyforge.org> Feature Requests item #10473, was opened at 2007-04-30 20:46 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10473&group_id=797 Category: expectation module Group: None >Status: Closed Priority: 3 Submitted By: Bret Pettichord (bret) >Assigned to: David Chelimsky (dchelimsky) Summary: Add should exist (new matcher) Initial Comment: This would be particularly useful with Watir, which provides a frequently used exists?/exist? method. Index: C:/work/rspec/rspec/spec/spec/matchers/exist_spec.rb =================================================================== --- C:/work/rspec/rspec/spec/spec/matchers/exist_spec.rb (revision 0) +++ C:/work/rspec/rspec/spec/spec/matchers/exist_spec.rb (revision 0) @@ -0,0 +1,45 @@ +require File.dirname(__FILE__) + '/../../spec_helper.rb' + +class Substance + def initialize exists, description + @exists = exists + @description = description + end + def exist? + @exists + end + def inspect + @description + end +end + +describe "should exist" do + setup do + @real = Substance.new true, 'something real' + @imaginary = Substance.new false, 'something imaginary' + end + + it "should pass if target exists" do + @real.should exist + end + + it "should fail if target does not exist" do + lambda { @imaginary.should exist }. + should fail_with("expected something imaginary to exist, but it doesn't.") + end +end + +describe "should_not exist" do + setup do + @real = Substance.new true, 'something real' + @imaginary = Substance.new false, 'something imaginary' + end + it "should pass if target doesn't exist" do + @imaginary.should_not exist + end + it "should fail if target does exist" do + lambda { @real.should_not exist }. + should fail_with("expected something real to not exist, but it does.") + end +end + \ No newline at end of file Index: C:/work/rspec/rspec/lib/spec/matchers/exist.rb =================================================================== --- C:/work/rspec/rspec/lib/spec/matchers/exist.rb (revision 0) +++ C:/work/rspec/rspec/lib/spec/matchers/exist.rb (revision 0) @@ -0,0 +1,21 @@ +module Spec + module Matchers + + + class Exist + def matches? actual + @actual = actual + @actual.exist? + end + def failure_message + "expected #{@actual.inspect} to exist, but it doesn't." + end + def negative_failure_message + "expected #{@actual.inspect} to not exist, but it does." + end + end + + def exist; Exist.new; end + end +end + Index: C:/work/rspec/rspec/lib/spec/matchers.rb =================================================================== --- C:/work/rspec/rspec/lib/spec/matchers.rb (revision 1850) +++ C:/work/rspec/rspec/lib/spec/matchers.rb (working copy) @@ -2,6 +2,7 @@ require 'spec/matchers/be_close' require 'spec/matchers/change' require 'spec/matchers/eql' +require 'spec/matchers/exist' require 'spec/matchers/equal' require 'spec/matchers/has' require 'spec/matchers/have' ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-04-30 21:46 Message: Applied to trunk rev 1852. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10473&group_id=797 From noreply at rubyforge.org Mon Apr 30 17:47:48 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 30 Apr 2007 17:47:48 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-10473 ] Add should exist (new matcher) Message-ID: <20070430214748.A03295240A96@rubyforge.org> Feature Requests item #10473, was opened at 2007-04-30 20:46 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10473&group_id=797 Category: expectation module Group: None Status: Closed Priority: 3 Submitted By: Bret Pettichord (bret) Assigned to: David Chelimsky (dchelimsky) Summary: Add should exist (new matcher) Initial Comment: This would be particularly useful with Watir, which provides a frequently used exists?/exist? method. Index: C:/work/rspec/rspec/spec/spec/matchers/exist_spec.rb =================================================================== --- C:/work/rspec/rspec/spec/spec/matchers/exist_spec.rb (revision 0) +++ C:/work/rspec/rspec/spec/spec/matchers/exist_spec.rb (revision 0) @@ -0,0 +1,45 @@ +require File.dirname(__FILE__) + '/../../spec_helper.rb' + +class Substance + def initialize exists, description + @exists = exists + @description = description + end + def exist? + @exists + end + def inspect + @description + end +end + +describe "should exist" do + setup do + @real = Substance.new true, 'something real' + @imaginary = Substance.new false, 'something imaginary' + end + + it "should pass if target exists" do + @real.should exist + end + + it "should fail if target does not exist" do + lambda { @imaginary.should exist }. + should fail_with("expected something imaginary to exist, but it doesn't.") + end +end + +describe "should_not exist" do + setup do + @real = Substance.new true, 'something real' + @imaginary = Substance.new false, 'something imaginary' + end + it "should pass if target doesn't exist" do + @imaginary.should_not exist + end + it "should fail if target does exist" do + lambda { @real.should_not exist }. + should fail_with("expected something real to not exist, but it does.") + end +end + \ No newline at end of file Index: C:/work/rspec/rspec/lib/spec/matchers/exist.rb =================================================================== --- C:/work/rspec/rspec/lib/spec/matchers/exist.rb (revision 0) +++ C:/work/rspec/rspec/lib/spec/matchers/exist.rb (revision 0) @@ -0,0 +1,21 @@ +module Spec + module Matchers + + + class Exist + def matches? actual + @actual = actual + @actual.exist? + end + def failure_message + "expected #{@actual.inspect} to exist, but it doesn't." + end + def negative_failure_message + "expected #{@actual.inspect} to not exist, but it does." + end + end + + def exist; Exist.new; end + end +end + Index: C:/work/rspec/rspec/lib/spec/matchers.rb =================================================================== --- C:/work/rspec/rspec/lib/spec/matchers.rb (revision 1850) +++ C:/work/rspec/rspec/lib/spec/matchers.rb (working copy) @@ -2,6 +2,7 @@ require 'spec/matchers/be_close' require 'spec/matchers/change' require 'spec/matchers/eql' +require 'spec/matchers/exist' require 'spec/matchers/equal' require 'spec/matchers/has' require 'spec/matchers/have' ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-04-30 21:47 Message: Nice patch. Thanks Bret. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-30 21:46 Message: Applied to trunk rev 1852. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10473&group_id=797 From noreply at rubyforge.org Mon Apr 30 19:53:04 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 30 Apr 2007 19:53:04 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-9882 ] 0.9 Beta 1 - translator bugs Message-ID: <20070430235304.B0B1A5240A87@rubyforge.org> Bugs item #9882, was opened at 2007-04-05 14:44 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=9882&group_id=797 Category: None Group: None >Status: Closed >Resolution: Rejected Priority: 3 Submitted By: David Chelimsky (dchelimsky) >Assigned to: Aslak Helles?y (aslak_hellesoy) Summary: 0.9 Beta 1 - translator bugs Initial Comment: >From email from Wincent Colaiuta to the rspec users list: The included translator did a pretty good job on a fairly large project ("svn diff" on the working copy after the translation yielded over 3,000 lines of diffs) with only a few minor issues for which I'll paste in samples. (Tried to post this to the RubyForge issue tracker but I can't stay logged in long enough to open the ticket because of an invisible anonymous proxy in place thanks to my ISP...) Whitespace between specs and comments eaten: - lambda { @instance.foo = foo }.should_raise NoMethodError # no writer defined + lambda { @instance.foo = foo }.should raise_error (NoMethodError)# no writer defined Incorrect parentheses around method invocations with parameters: - AndPredicate.new('foo').should_eql AndPredicate.new('foo') + AndPredicate.new('foo').should eql(AndPredicate.new)('foo') Unnecessary parens: - Node.subclass('FooNode').should_not_be_nil + Node.subclass('FooNode').should_not be_nil() Missing parentheses, yields "parenthesize argument(s) for future version" warnings when running specs: - lambda { sequence.parse ('bar') }.should_throw :ZeroWidthParseSuccess + lambda { sequence.parse('bar') }.should throw_symbol :ZeroWidthParseSuccess Another example: - @parslet.should_eql @parslet.clone + @parslet.should eql @parslet.clone Another case of misplaced parens: - @parslet.should_not_eql lambda { nil }.to_parseable + @parslet.should_not eql(lambda){ nil }.to_parseable Another: - results.should_be_kind_of SimpleASTLanguage::Identifier + results.should be_kind_of(SimpleASTLanguage)::Identifier Apart from that, no major issues. All specs continued to pass after 0.90, and the updated TextMate bundle works brilliantly. ---------------------------------------------------------------------- >Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-04-30 19:53 Message: Rejecting this - the translator is "good enough" ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-05 19:03 Message: Addressed all but the "whitespace before comment" issue in rev 1702 of branches/0.9-dev. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=9882&group_id=797 From noreply at rubyforge.org Mon Apr 30 19:54:30 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 30 Apr 2007 19:54:30 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-10333 ] can't load spec tasks from rakefiles with pluginized rspec [r1802] Message-ID: <20070430235430.E1CB25240A87@rubyforge.org> Bugs item #10333, was opened at 2007-04-24 05:54 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10333&group_id=797 Category: rails plugin Group: None >Status: Closed >Resolution: Rejected Priority: 3 Submitted By: Ian White (ianwhite) >Assigned to: Aslak Helles?y (aslak_hellesoy) Summary: can't load spec tasks from rakefiles with pluginized rspec [r1802] Initial Comment: When rspec itself is pluginized (a great idea), all of my custom rakefiles which include spec/rake/whatever don't work. The reason is noted in the rspec_on_rails tasks - the plugin libs don't get into the load path at this stage. So everyone could change all of their scripts to check for the presence of the plugin and load the appropriate rspec lib from the right place. But how about adding the rspec/lib to the load paths in a rake task in rspec/tasks? That way, if the rakefile in question is in Rails' purview, it will know about the rspec plugin lib. This works for me: in vendor/plugins/rspec/tasks/load_rspec.rake: $: << File.expand_path(File.join(File.dirname(__FILE__), '../lib')) Sorry if this isn't a bug - I figured that because it broke existing scripts it should be classified as one. Cheers, Ian White ---------------------------------------------------------------------- >Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-04-30 19:54 Message: Incomplete info. Feel free to reopen with more context info. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-04-24 06:27 Message: Before investigating this we need to know the versions of all relevant software, for example: * OS X 10.4.9 * Ruby 1.8.6 * RSpec 1.8.2 or RSpec trunk r1643 * Spec::Rails 1.8.2 or Spec::Rails tag r1234... * Rails 1.2.3 or Rails edge r5645 * Whatever other relevant software. Without this information it's like solving 1 equation (your question) with 5 unknown variables (the versions). ---------------------------------------------------------------------- Comment By: Ian White (ianwhite) Date: 2007-04-24 06:18 Message: Ok, so this works for me in lib/tasks/_load_rspec.rake if File.exist?(rspec_base = File.join(RAILS_ROOT, 'vendor/plugins/rspec')) $: << File.expand_path(File.join(rspec_base, 'lib')) end ---------------------------------------------------------------------- Comment By: Ian White (ianwhite) Date: 2007-04-24 06:10 Message: I just tried this approach for running a custom rcov task from RAILS_ROOT/lib/tasks and it didn't work as rails loads lib/tasks before vendor/plugins/**/tasks. So I just had to copy load_rspec into lib.tasks. This could be done when bootstrapping rspec_on_rails. Also, perhaps the following is better, to avoid duplication of the path $: |= [File.expand_path(File.join(File.dirname(__FILE__), '../lib'))] ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10333&group_id=797 From noreply at rubyforge.org Mon Apr 30 19:58:40 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 30 Apr 2007 19:58:40 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-10133 ] custom predicate matchers Message-ID: <20070430235841.0AB8D5240A87@rubyforge.org> Feature Requests item #10133, was opened at 2007-04-16 06:30 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10133&group_id=797 Category: expectation module Group: None >Status: Closed Priority: 3 Submitted By: David Chelimsky (dchelimsky) Assigned to: David Chelimsky (dchelimsky) Summary: custom predicate matchers Initial Comment: RSpec <= 0.8 let you do this: obj.should_predicate For example: obj.should_exist which would pass if obj.exist? returns true. In RSpec 0.9, there is no underscore-less parallel: obj.should exist This was excluded deliberately because when RSpec does not find the #exist method there are more than one reason that it might be missing: it could be a helper method that hasn't been written yet OR it could be a predicate on obj that hasn't been written yet. I still think this is the correct decision, however, the following would support easy creation of custom predicate matchers: Spec::Runner.configure do |config| config.predicate_matchers :exist end and/or describe Thing do predicate_matchers :exist it "should exist" do Thing.new.should exist end end ---------------------------------------------------------------------- >Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-04-30 19:58 Message: Fixed in (circa) r1858 ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10133&group_id=797 From mattaimonetti at gmail.com Mon Apr 30 19:18:43 2007 From: mattaimonetti at gmail.com (Matt Aimonetti) Date: Mon, 30 Apr 2007 16:18:43 -0700 Subject: [rspec-devel] names for setup and teardown methods In-Reply-To: <306e36aa0704181620m23edba0bn9ae388ca007402be@mail.gmail.com> References: <57c63afe0704110549x2c2a42f6l641e0c59e9de0afb@mail.gmail.com> <6cf2a94f0704111056s591105bfm92e32c5e88fb2dc4@mail.gmail.com> <306e36aa0704181620m23edba0bn9ae388ca007402be@mail.gmail.com> Message-ID: teardown :each and after :each don't seem to work for me. I had to move my function from "teardown :each" to "before" since the function was deleting the object created by the previous spec and the function didn't seem to be called. Maybe I didn't understand properly how teardown and after work. -Matt On 4/18/07, Matthew Heidemann wrote: > > I personally like before :each_example. The first time I read it I said, > "before :each what?". > > I think once people run the spec and see 1 example 0 failures, they know > that the 'it do' is an example > > On 4/11/07, Matt Aimonetti wrote: > > > > I fully agree with Dean and prefer the "before :each", "after :all" > > option, it reads better and is easier to understand for newbies. > > > > -Matt > > > > On 4/11/07, Dean Wampler wrote: > > > > > > Setup and teardown are more approachable to converts from Test::Unit, > > > but "before :all" and "after :each" read better, IMHO. > > > > > > "all_examples" might cause people to ask "what examples?" I'm not sure > > > > > > most people will think of the "it blocks" as examples. Still, you > > > could just accept any symbol that begins with "each" and "all", so > > > people can invent their own name ;) > > > > > > dean > > > > > > > > > On 4/11/07, David Chelimsky wrote: > > > > We're going to rename context_setup and context_teardown because > > > they > > > > no longer read well when using "describe/id". There are two ideas > > > > floating around about this. The first: > > > > > > > > setup :each #default - works like setup does now > > > > setup :all #replaces context_setup > > > > teardown :each #default - works like teardown does now > > > > teardown :all #replaces context teardown > > > > > > > > The second uses "before" and "after" in the same way: > > > > > > > > before :each #default - works like setup does now > > > > before :all #replaces context_setup > > > > after :each #default - works like teardown does now > > > > after :all #replaces context teardown > > > > > > > > In both cases, the default is :each, so you can just say "setup do" > > > or > > > > "before do" instead of "setup :each do" or "before :each do". > > > > > > > > == Examples > > > > > > > > describe Thing do > > > > setup :all { ... } > > > > setup :each { ... } > > > > it "should do something" { ... } > > > > it "should do something else" { ... } > > > > teardown :each { ... } > > > > teardown :all { ... } > > > > end > > > > > > > > describe Thing do > > > > before :all { ... } > > > > before :each { ... } > > > > it "should do something" { ... } > > > > it "should do something else" { ... } > > > > after :each { ... } > > > > after :all { ... } > > > > end > > > > > > > > describe Thing do > > > > before { ... } # works like before :each > > > > it "should do something" { ... } > > > > it "should do something else" { ... } > > > > after { ... } # works like after :each > > > > end > > > > > > > > One other thing that occurs to me is that "before :each" really > > > means > > > > "before each example" - so perhaps it should be "before > > > :each_example" > > > > and "before :all_examples" (or :each and :each_example could both be > > > > > > > supported, etc). > > > > > > > > WDYT? > > > > _______________________________________________ > > > > rspec-devel mailing list > > > > rspec-devel at rubyforge.org > > > > http://rubyforge.org/mailman/listinfo/rspec-devel > > > > > > > > > > > > > -- > > > Dean Wampler > > > http://www.objectmentor.com > > > http://www.aspectprogramming.com > > > http://www.contract4j.org > > > _______________________________________________ > > > rspec-devel mailing list > > > rspec-devel at rubyforge.org > > > http://rubyforge.org/mailman/listinfo/rspec-devel > > > > > > > > > _______________________________________________ > > rspec-devel mailing list > > rspec-devel at rubyforge.org > > http://rubyforge.org/mailman/listinfo/rspec-devel > > > > > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20070430/1da215d7/attachment.html From dchelimsky at gmail.com Mon Apr 30 20:26:51 2007 From: dchelimsky at gmail.com (David Chelimsky) Date: Mon, 30 Apr 2007 19:26:51 -0500 Subject: [rspec-devel] names for setup and teardown methods In-Reply-To: References: <57c63afe0704110549x2c2a42f6l641e0c59e9de0afb@mail.gmail.com> <6cf2a94f0704111056s591105bfm92e32c5e88fb2dc4@mail.gmail.com> <306e36aa0704181620m23edba0bn9ae388ca007402be@mail.gmail.com> Message-ID: <57c63afe0704301726n65e7ea4bvbd993c2e1cce723c@mail.gmail.com> On 4/30/07, Matt Aimonetti wrote: > teardown :each and after :each don't seem to work for me. > > I had to move my function from "teardown :each" to "before" since the > function was deleting the object created by the previous spec and the > function didn't seem to be called. Maybe I didn't understand properly how > teardown and after work. Each example (i.e. #it or #specify) gets run in its own object. It has no access to any state in the other examples. before(:each) is run before each example, in the same object as the example. after(:each) is run after each example, in the same object as the example. I'm a bit confused by your description of the problem. Can you post some code so we can talk about a specific example? > > -Matt > > > On 4/18/07, Matthew Heidemann wrote: > > I personally like before :each_example. The first time I read it I said, > "before :each what?". > > > > I think once people run the spec and see 1 example 0 failures, they know > that the 'it do' is an example > > > > > > > > On 4/11/07, Matt Aimonetti < matt at aimonetti.net> wrote: > > > I fully agree with Dean and prefer the "before :each", "after :all" > option, it reads better and is easier to understand for newbies. > > > > > > -Matt > > > > > > > > > > > > On 4/11/07, Dean Wampler wrote: > > > > Setup and teardown are more approachable to converts from Test::Unit, > > > > but "before :all" and "after :each" read better, IMHO. > > > > > > > > "all_examples" might cause people to ask "what examples?" I'm not sure > > > > most people will think of the "it blocks" as examples. Still, you > > > > could just accept any symbol that begins with "each" and "all", so > > > > people can invent their own name ;) > > > > > > > > dean > > > > > > > > > > > > On 4/11/07, David Chelimsky wrote: > > > > > We're going to rename context_setup and context_teardown because > they > > > > > no longer read well when using "describe/id". There are two ideas > > > > > floating around about this. The first: > > > > > > > > > > setup :each #default - works like setup does now > > > > > setup :all #replaces context_setup > > > > > teardown :each #default - works like teardown does now > > > > > teardown :all #replaces context teardown > > > > > > > > > > The second uses "before" and "after" in the same way: > > > > > > > > > > before :each #default - works like setup does now > > > > > before :all #replaces context_setup > > > > > after :each #default - works like teardown does now > > > > > after :all #replaces context teardown > > > > > > > > > > In both cases, the default is :each, so you can just say "setup do" > or > > > > > "before do" instead of "setup :each do" or "before :each do". > > > > > > > > > > == Examples > > > > > > > > > > describe Thing do > > > > > setup :all { ... } > > > > > setup :each { ... } > > > > > it "should do something" { ... } > > > > > it "should do something else" { ... } > > > > > teardown :each { ... } > > > > > teardown :all { ... } > > > > > end > > > > > > > > > > describe Thing do > > > > > before :all { ... } > > > > > before :each { ... } > > > > > it "should do something" { ... } > > > > > it "should do something else" { ... } > > > > > after :each { ... } > > > > > after :all { ... } > > > > > end > > > > > > > > > > describe Thing do > > > > > before { ... } # works like before :each > > > > > it "should do something" { ... } > > > > > it "should do something else" { ... } > > > > > after { ... } # works like after :each > > > > > end > > > > > > > > > > One other thing that occurs to me is that "before :each" really > means > > > > > "before each example" - so perhaps it should be "before > :each_example" > > > > > and "before :all_examples" (or :each and :each_example could both be > > > > > supported, etc). > > > > > > > > > > WDYT? > > > > > _______________________________________________ > > > > > rspec-devel mailing list > > > > > rspec-devel at rubyforge.org > > > > > http://rubyforge.org/mailman/listinfo/rspec-devel > > > > > > > > > > > > > > > > > -- > > > > Dean Wampler > > > > http://www.objectmentor.com > > > > http://www.aspectprogramming.com > > > > http://www.contract4j.org > > > > _______________________________________________ > > > > rspec-devel mailing list > > > > rspec-devel at rubyforge.org > > > > http://rubyforge.org/mailman/listinfo/rspec-devel > > > > > > > > > > > > > _______________________________________________ > > > rspec-devel mailing list > > > rspec-devel at rubyforge.org > > > http://rubyforge.org/mailman/listinfo/rspec-devel > > > > > > > > > _______________________________________________ > > rspec-devel mailing list > > rspec-devel at rubyforge.org > > http://rubyforge.org/mailman/listinfo/rspec-devel > > > > > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From noreply at rubyforge.org Mon Apr 30 20:52:52 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 30 Apr 2007 20:52:52 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-10434 ] Please Make -s synonymous with -e for autotest compat. Message-ID: <20070501005252.95CC05240A87@rubyforge.org> Feature Requests item #10434, was opened at 2007-04-28 18:33 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10434&group_id=797 Category: runner / command line Group: None Status: Closed Priority: 3 Submitted By: steve ross (cwd) Assigned to: David Chelimsky (dchelimsky) Summary: Please Make -s synonymous with -e for autotest compat. Initial Comment: Autotest uses -s to specify which specs to run. Rather than replacing -s, please make it synonymous with -e so as not to break autotest. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-05-01 00:52 Message: Looks like ZenTest 3.5.2 has been released without the patch that I submitted. For the time being, I've reinstated -s. As soon as we are able to get RSpec and ZenTest to play nice together, we'll be removing it. Cheers, David ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-28 19:31 Message: There were some other problems w/ rspec_autotest and I've already submitted a patch to Ryan (ZenTest's author), which includes using -e as well as some changes to the directories. Ryan indicated me that he'd be doing a 3.5.2 release very shortly. I expect that will be available before 0.9 is officially released. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10434&group_id=797