From noreply at rubyforge.org Thu Feb 1 08:33:25 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 1 Feb 2007 08:33:25 -0500 (EST) Subject: [rspec-devel] [ rspec-Patches-7461 ] [PATCH] Contexts don't call Module::included when they include a module Message-ID: <20070201133325.DC47D52411B9@rubyforge.org> Patches item #7461, was opened at 2006-12-26 16:41 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=7461&group_id=797 >Category: runner module Group: None >Status: Closed >Resolution: Accepted Priority: 3 Submitted By: Pat Maddox (pergesu) >Assigned to: David Chelimsky (dchelimsky) Summary: [PATCH] Contexts don't call Module::included when they include a module Initial Comment: module MyModule module ClassMethods def foo "foo" end end def self.included(receiver) receiver.extend ClassMethods end end context "Test context" do include MyModule foo end blows up because foo isn't defined. It turns out that the included method isn't being called at all. Now regardless of whether you think it's okay to use included like this to automatically extend a class, or you think that you should explicitly extend a class instead, Contexts shouldn't break Ruby's included callback method. This patch fixes it up. It just adds mod.send :included, self to Context and ContextEval. I included a spec for it, but it comes with a warning. The "mod.send" line is required in Context for the spec to pass. But if you just use that in code, then the code will fail. You have to have "mod.send" in ContextEval as well. However, the spec doesn't fail if you don't call it in ContextEval. So basically, the call in ContextEval is necessary for the desired behavior, but isn't covered by a spec. I haven't been able to come up with a failing spec for it...so hopefully someone who knows the RSpec internals better than I can come up with it. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-02-01 13:33 Message: I went ahead and applied this w/ a note in ContextEval re: the un-spec'd line of code. Applied in rev 1453. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-12-30 06:11 Message: That makes sense. It also leads me to believe that there should be a way to create a spec that fails without the line in ContextEval. Can you share a spec and code that only works if the line exists in ContextEval? That might help come up w/ a spec for it. ---------------------------------------------------------------------- Comment By: Pat Maddox (pergesu) Date: 2006-12-30 06:01 Message: I wrote the failing spec and implemented the code, which didn't require ContextEval. Then I used that in my project, and it didn't work. The error was an undefined method on a ContextEval instance. I then added the send to ContextEval, and it worked fine. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-12-30 05:54 Message: How do you know that this doesn't work without mod.send in ContextEval? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=7461&group_id=797 From noreply at rubyforge.org Thu Feb 1 12:37:55 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 1 Feb 2007 12:37:55 -0500 (EST) Subject: [rspec-devel] [ rspec-Feature Requests-8366 ] Structure for library specs in rspec_on_rails Message-ID: <20070201173755.A31105242D08@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: Open Priority: 3 Submitted By: Ashley Moran (ashley_moran) Assigned to: Nobody (None) 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! ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=8366&group_id=797 From noreply at rubyforge.org Thu Feb 1 15:08:38 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 1 Feb 2007 15:08:38 -0500 (EST) Subject: [rspec-devel] [ rspec-Feature Requests-8366 ] Structure for library specs in rspec_on_rails Message-ID: <20070201200838.DF8675242D2F@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: Open Priority: 3 Submitted By: Ashley Moran (ashley_moran) Assigned to: Nobody (None) 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: 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 Thu Feb 1 15:27:32 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 1 Feb 2007 15:27:32 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-8371 ] Mocking complaining about wrong number of arguments (odd) Message-ID: <20070201202732.E02CA5242D32@rubyforge.org> Bugs item #8371, was opened at 2007-02-01 18:27 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=8371&group_id=797 Category: mock module Group: None Status: Open Resolution: None Priority: 3 Submitted By: Rodrigo Kochenburger (divoxx) Assigned to: Nobody (None) Summary: Mocking complaining about wrong number of arguments (odd) Initial Comment: In this code http://pastie.caboo.se/37274 i'm trying to mock a model method while testing a controller. (Line 12) The error being raised is also pasted in there. If i comment that line out and actually call the create method, the model raises the exception and everything works just fine... I've already tried using .with(:any_args) ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=8371&group_id=797 From noreply at rubyforge.org Thu Feb 1 16:37:51 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 1 Feb 2007 16:37:51 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-8371 ] Mocking complaining about wrong number of arguments (odd) Message-ID: <20070201213752.057495242D52@rubyforge.org> Bugs item #8371, was opened at 2007-02-01 20:27 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=8371&group_id=797 Category: mock module Group: None Status: Open Resolution: None Priority: 3 Submitted By: Rodrigo Kochenburger (divoxx) Assigned to: Nobody (None) Summary: Mocking complaining about wrong number of arguments (odd) Initial Comment: In this code http://pastie.caboo.se/37274 i'm trying to mock a model method while testing a controller. (Line 12) The error being raised is also pasted in there. If i comment that line out and actually call the create method, the model raises the exception and everything works just fine... I've already tried using .with(:any_args) ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-02-01 21:37 Message: RSpec version? Rails version? Also - try running the specs w/ the -b argument so you can get a more thorough backtrace. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=8371&group_id=797 From dchelimsky at gmail.com Fri Feb 2 05:53:50 2007 From: dchelimsky at gmail.com (David Chelimsky) Date: Fri, 2 Feb 2007 04:53:50 -0600 Subject: [rspec-devel] Coming Soon... Message-ID: <57c63afe0702020253y5b5597f3odb63df0e8bbed1de@mail.gmail.com> Dear spec'ers, As many of you already know, we're gearing up for a pretty big 0.8 release of RSpec in the next couple of weeks. I'm writing in advance because I want to give you a heads up about upcoming changes and how they may impact your existing specs. Two important things to note first: 1. We will provide a translator that you'll be able to use to convert the majority of your existing specs to the new syntax before we remove deprecated methods. 2. The syntax changes described below will be the last major changes you'll see before a 1.0 release. Here is the plan, though the time line is not yet clear. == rspec-0.8.0-RC1 * Will be released within the next couple of weeks. * Will be fully backwards compatible with 0.7.5.1. * Will also support all of the new syntax using expectation matchers (see below). Because this is such a significant change, we want to do a Release Candidate first. == rspec-0.8.x Between 0.8.0 and 0.9.0, there will be at least one release that will include: * A pre-0.8 to 0.9 translator. * Noisy deprecation warnings that will let you know what methods will be going and what you should use instead. * A simple means of silencing those warnings (at your own peril!) == rspec-0.9 * Will remove all of the old syntax. ======================================= Here are some answers to some questions that some of you may have: == What is changing? All of the should_xyz methods will be losing an underscore and gaining a space: #before actual.should_equal(expected) actual.should_not_equal(expected) #after actual.should equal(expected) actual.should_not equal(expected) #equal, in this example, is a method that returns an expectation matcher, which Ruby passes to #should, which then interacts with the matcher to evaluate whether or not the expectation is met and report accordingly. All args to expectation matchers will require parens, and blocks must be expressed using curly braces. This has to do with ambiguity of arguments and operator precedence. Don't worry, if you do the wrong thing you'll get a warning. More on this below. == Why this change? The current syntax is supported by some very clever use of method_missing. I'm allowed to say it was clever because I didn't write it ;). At first it seemed awesome, but we've found that it conflicts with other frameworks that use metaprogramming techniques to late-bind to method_missing. So we had to make a choice between rethinking RSpec's implementation or commit to a future of monkey patching other frameworks as they introduce new uses of method_missing. Using expectation matchers means that we only need to add 4 methods to Object: #for expectation matchers should should_not #for mocks/stubs should_receive should_not_receive So it is much less invasive than it was before and, because we are not using method_missing on YOUR objects, is much less conflict/error prone. It also supports a clear entry point to writing custom expectation matchers, so if you have some domain-specific expectations like "should travel_more" or "should get_a_raise", you'll have a very easy means of doing so. == Will there be any existing expectations that will no longer be supported at all? Yes, but only a few, and only related to RSpec on Rails. We will NOT be supporting the following in the new syntax: controller.should_render controller.should_redirect_to You will be able to use instead: response.should render_template response.should render_text response.should redirect_to ... but only after the action. == For )(*&)(*'s sake, WHEN will you stop making changes like this? Right now. While we will not commit to 100% backwards compatibility, we on the RSpec Development Team are as anxious for this to stabilize as you are. We just feel that when we get to a 1.0 release we absolutely must have an API that is solid, easy to use, stable and maintainable. We just didn't see an end in sight to the problems we'd been seeing w/ the soon-to-be-ex-syntax, and we are very confident in this move and its potential to fulfill those requirements. == What's up w/ the parens and {} blocks? Parens: When you do this: a.b c d ... Ruby gives you the all familiar: "warning: parenthesize argument(s) for future version" If you can live w/ that, then have at it w/o the parens. Curly braces: This has to do w/ precedence. do/end has a lower precedence than {}, which means that in this expression: target.should satisfy do end ... the block will be passed to #should instead of #satisfy. We need the blocks to be passed to the matcher (#satisfy in this example), so curly braces are required. This will be enforced by RSpec. When #should or #should_not receive a block, the spec will fail with a warning telling you to use {} instead of do/end. So you won't have the opportunity to simply forget. ======================================= We're very excited about this release. I hope this email answers most of your questions. If you have others, please feel free, though I may punt on technical questions as many of those will be answered by documentation in the 0.8.0-RC1 release. Thanks for your patience with this and thanks especially to all of those who contribute to RSpec's evolution by participating with this list and submitting RFEs to the tracker. Cheers, David on behalf of The RSpec Development Team From noreply at rubyforge.org Fri Feb 2 07:04:00 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 2 Feb 2007 07:04:00 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-8241 ] "no id given" if controller method does not exist Message-ID: <20070202120400.26A1852426BC@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: Open >Resolution: Postponed Priority: 3 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-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 Fri Feb 2 07:04:53 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 2 Feb 2007 07:04:53 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-8241 ] "no id given" if controller method does not exist Message-ID: <20070202120453.9A16152426D4@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: Open Resolution: Postponed >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-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 bkeepers at gmail.com Fri Feb 2 09:31:33 2007 From: bkeepers at gmail.com (Brandon Keepers) Date: Fri, 2 Feb 2007 09:31:33 -0500 Subject: [rspec-devel] [rspec-users] Coming Soon... In-Reply-To: <57c63afe0702020253y5b5597f3odb63df0e8bbed1de@mail.gmail.com> References: <57c63afe0702020253y5b5597f3odb63df0e8bbed1de@mail.gmail.com> Message-ID: <1FB51DB3-E876-4B86-810E-AB3365140CC2@gmail.com> David & crew, On Feb 2, 2007, at 5:53 AM, David Chelimsky wrote: > == What's up w/ the parens and {} blocks? > > Parens: When you do this: > > a.b c d > > ... Ruby gives you the all familiar: > > "warning: parenthesize argument(s) for future version" > > If you can live w/ that, then have at it w/o the parens. > > Curly braces: This has to do w/ precedence. do/end has a lower > precedence than {}, which means that in this expression: > > target.should satisfy do > end > > ... the block will be passed to #should instead of #satisfy. We need > the blocks to be passed to the matcher (#satisfy in this example), so > curly braces are required. This will be enforced by RSpec. When > #should or #should_not receive a block, the spec will fail with a > warning telling you to use {} instead of do/end. So you won't have the > opportunity to simply forget. You could also do: target.should(satisfy do # block here end) It's not necessarily any cleaner, but it works. Good work! I like the new syntax and am looking forward to being able to write my own expectations. Brandon From noreply at rubyforge.org Fri Feb 2 10:39:56 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 2 Feb 2007 10:39:56 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-8240 ] Cryptic error message when no controller_name Message-ID: <20070202153956.D63BA5242C29@rubyforge.org> Bugs item #8240, was opened at 2007-01-29 03:26 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=8240&group_id=797 Category: rails plugin Group: None >Status: Closed >Resolution: Accepted Priority: 3 Submitted By: Fran?ois Beausoleil (fbos) >Assigned to: David Chelimsky (dchelimsky) Summary: Cryptic error message when no controller_name Initial Comment: In the following spec: context "A project owner" do specify "can assign roles to other users" do # ... end end I get the following cryptic error message: 1) NoMethodError in 'A project owner can assign roles to other users' undefined method `session=' for # /home/francois/src/smrty2/vendor/plugins/rspec_on_rails/lib/spec/rails/context/controller.rb:134:in `setup_extra' /home/francois/src/smrty2/vendor/plugins/rspec_on_rails/lib/spec/rails/functional_eval_context.rb:22:in `setup' /home/francois/src/smrty2/vendor/plugins/rspec_on_rails/lib/spec/rails/context/controller.rb:151:in `setup' Line 134 of controller.rb is: @controller.session = session We are probably only missing a check to ensure that @controller is somehow defined. Failing that should simply say "You forgot to define controller_name in your controller spec". This is on 0.7.5.1. Thanks ! -- Fran?ois Beausoleil ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-02-02 15:39 Message: Fixed in trunk rev 1456. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=8240&group_id=797 From noreply at rubyforge.org Fri Feb 2 10:46:03 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 2 Feb 2007 10:46:03 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-8027 ] should_change works but should_not_change appears not to. Message-ID: <20070202154603.714EA5242B32@rubyforge.org> Bugs item #8027, was opened at 2007-01-20 18:46 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=8027&group_id=797 >Category: expectation module Group: None >Status: Closed >Resolution: Rejected Priority: 3 Submitted By: steve ross (cwd) >Assigned to: David Chelimsky (dchelimsky) Summary: should_change works but should_not_change appears not to. Initial Comment: Rspec v. 0.8.0 (trunk) Given the code: context "Given a Bug (in general)" do specify "Should be able to add a valid record" do lambda { Bug.create(:title => 'a valid bug', :description => 'a valid description') }.should_change(Bug, :count).by(1) end specify "Should not be able to add an invalid record" do lambda { Bug.create(:description => 'a valid description') }.should_not_change(Bug, :count).by(1) end end The result is: 1) 'Given a Bug (in general) Should not be able to add an invalid record' FAILED count should have been changed by 1, but was changed by 0 ./spec/models/bug_spec.rb:18: Model code, bug.rb, is: class Bug < ActiveRecord::Base validates_presence_of :title end ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-02-02 15:46 Message: I added an explanation to the rdoc that should_not only supports the form without by, to or from. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-01-21 21:51 Message: You can add that to the Documentation tracker if you like, but be aware that this can become outdated when new expectations are added later. Also, there is a syntax change afoot (never fear, we'll be providing a translator) that you can read about here: http://blog.davidchelimsky.net/articles/2007/01/10/rspec-should-use_a_little_less_magic This will change things a bit and make it easy to ensure that expectations that don't support their negatives will tell you. ---------------------------------------------------------------------- Comment By: steve ross (cwd) Date: 2007-01-21 21:24 Message: Ok, how about we make this an RFE: Where a positive expectation exists without a corresponding negative one, a note in the docs should reflect that. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-01-21 21:21 Message: Sorry... that should have been "should_not_change(obj, :sym).by(1)" ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-01-21 21:20 Message: Steve, I agree that there are many cases where negative expectations make perfect sense. Generally, I think there should be a parallel negative. It's the weird ones like should_change(obj, :sym).by(1) that, in my view, make specs more confusing than explicit that make me think absolute parallelism is not a necessity. ---------------------------------------------------------------------- Comment By: steve ross (cwd) Date: 2007-01-21 20:29 Message: Let's talk about how something this obtuse comes about. Typically, I spec positive expectations first to make sure what I think will happen does indeed happen. Then I add negative expectations to weed out some corner cases. This may seem duplicative, but the specs might read: "should be able to add a valid record" and "should not be able to add an invalid record." Clearly copy/paste is a quick way to get this kind of template set up, but the change in sugar is why it doesn't work quite as simply as adding *not*. This is user error, but it might come up again. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-01-21 20:22 Message: I think it's OK to not be parallel. For example, these two mean the same thing: team.should_not have_at_least(4).players team.should have_at_most(3).players Would you EVER want to use the first? Talk about making specs unclear! Being able to say proc.should_not change(Model, :count).by(1) is like saying - it's OK for this to cause a change, but whatever you do, don't change it by 1. That's just a bit too non-deterministic for my stomach. ---------------------------------------------------------------------- Comment By: steve ross (cwd) Date: 2007-01-21 20:16 Message: It would seem that most expectations also have a negative expectation associated with them (i.e., should_nnn has a corresponding should_not_nnn). The expected behavior, then would be that if the object changed by any number other than the specified one, it would fail. Is there value to adding this? Am I right about the parallelism among expectations? ---------------------------------------------------------------------- Comment By: Wilson Bilkovich (wilson) Date: 2007-01-21 19:38 Message: I should have disallowed it originally, in my opinion, making this a real bug. However, if we assume for a moment that we wanted to support it, how would it work? given: lambda {}.should_not_change(Thing, :count) The current code 'knows' that that expectation should fail as soon as it can compare the before and after values. lambda {}.should_not_change(Thing, :count).by(2) would, I would expect, pass if the count changed by 1. This means that the bare version without 'by' would fail, but the 'by' version would pass. Given that the bare 'should_not_change' has no way of knowing whether it will have 'by' called on it, I don't see a way to implement that. Every other extension type makes the expectation MORE specific, not less. This would violate that guideline, and I'm not sure it is implementable. Any ideas? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-01-21 11:14 Message: should_not_change is only spec'd to work without any extensions. i.e. Bug.create(:description => 'a valid description') }.should_not_change(Bug, :count) (without to, from or by) We have two choices to deal w/ this: 1 - disallow use of to, from or by with should_not_change 2 - support it My feeling about this is that if you're using should_not_change you shouldn't be using the extensions, so I'd go for 1. Other opinions? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=8027&group_id=797 From noreply at rubyforge.org Fri Feb 2 11:10:37 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 2 Feb 2007 11:10:37 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-8392 ] should_have_tag :content => true fails to match correctly Message-ID: <20070202161037.BF99952417E7@rubyforge.org> Bugs item #8392, was opened at 2007-02-02 16:10 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=8392&group_id=797 Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: Jerry West (jjw) Assigned to: Nobody (None) Summary: should_have_tag :content => true fails to match correctly Initial Comment: The docs for assert_tag suggest that :content => true should match non-empty tags. Rspec.should_have_tag does not seem to honour this. In order: the failing spec; the rhtml file itself, and the spec run output ------ require File.dirname(__FILE__) + '/../../spec_helper' context 'a view spec' do specify 'should set a title' do render '/sessions/test.rhtml' response.should_have_tag 'title', :content => true end end ------ Hello ------ 'a view spec should set a title' FAILED Hello should include ["[\title\, {:content=>true}]"] .../vendor/plugins/rspec_on_rails/lib/spec/rails/tag_expectations.rb:15:in `raise_rspec_error' .../vendor/plugins/rspec_on_rails/lib/spec/rails/tag_expectations.rb:5:in `should_have_tag' .../vendor/plugins/rspec_on_rails/lib/spec/rails/extensions/action_controller/test_response.rb:30:in `should_have_tag' ./spec/views/sessions/test_rhtml_spec.rb:6: ------- I think I saw something about Rspec moving to assert_select, so feel free to close this if it's not worth fixing because of that. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=8392&group_id=797 From noreply at rubyforge.org Fri Feb 2 11:21:27 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 2 Feb 2007 11:21:27 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-8392 ] should_have_tag :content => true fails to match correctly Message-ID: <20070202162127.81B8952423A7@rubyforge.org> Bugs item #8392, was opened at 2007-02-02 16:10 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=8392&group_id=797 Category: rails plugin Group: None >Status: Closed >Resolution: Rejected Priority: 3 Submitted By: Jerry West (jjw) >Assigned to: David Chelimsky (dchelimsky) Summary: should_have_tag :content => true fails to match correctly Initial Comment: The docs for assert_tag suggest that :content => true should match non-empty tags. Rspec.should_have_tag does not seem to honour this. In order: the failing spec; the rhtml file itself, and the spec run output ------ require File.dirname(__FILE__) + '/../../spec_helper' context 'a view spec' do specify 'should set a title' do render '/sessions/test.rhtml' response.should_have_tag 'title', :content => true end end ------ Hello ------ 'a view spec should set a title' FAILED Hello should include ["[\title\, {:content=>true}]"] .../vendor/plugins/rspec_on_rails/lib/spec/rails/tag_expectations.rb:15:in `raise_rspec_error' .../vendor/plugins/rspec_on_rails/lib/spec/rails/tag_expectations.rb:5:in `should_have_tag' .../vendor/plugins/rspec_on_rails/lib/spec/rails/extensions/action_controller/test_response.rb:30:in `should_have_tag' ./spec/views/sessions/test_rhtml_spec.rb:6: ------- I think I saw something about Rspec moving to assert_select, so feel free to close this if it's not worth fixing because of that. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-02-02 16:21 Message: should_have_tag will be deprecated in the next release, replaced by a port of assert_select. The syntax will be: response.should have_tag() ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=8392&group_id=797 From noreply at rubyforge.org Fri Feb 2 12:08:00 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 2 Feb 2007 12:08:00 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-6896 ] should_render fails with respond_to Message-ID: <20070202170800.4F5E35242C4D@rubyforge.org> Bugs item #6896, was opened at 2006-11-26 23:40 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6896&group_id=797 Category: rails plugin Group: None >Status: Closed >Resolution: Accepted Priority: 3 Submitted By: Pat Maddox (pergesu) Assigned to: David Chelimsky (dchelimsky) Summary: should_render fails with respond_to Initial Comment: Spec: specify "should show the form" do controller.should_render :template => "people/new" end Controller code: def new @person = Person.new respond_to do |format| format.html end end Failure: {:template=>"people/new"} should == {:action=>"new", :content_type=>#} ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-02-02 17:08 Message: The new redirect_to matcher in 0.8 should support this fully including the separate issue presented by Francios. ---------------------------------------------------------------------- Comment By: Fran?ois Beausoleil (fbos) Date: 2007-01-29 04:05 Message: On a related note: context "A project owner" do controller_name :roles specify "can assign roles to other users" do post :create, :project_id => 27, :role => {:name => "user"}, :user => {:email => "jim at teksol.info"} response.should_redirect_to "/" end end Given this controller implementation: class RolesController < ApplicationController def create @target = User.find_by_email!(params[:user][:email]) @target.set_project_role(current_project, params[:role][:name]) respond_to do |wants| wants.js wants.html { redirect_to dashboard_path } end end end Fails like this: 1) 'A project owner can assign roles to other users' FAILED expected redirect to http://test.host/ but there was no redirect /home/francois/src/smrty2/vendor/plugins/rspec_on_rails/lib/spec/rails/extensions/action_controller/test_response.rb:55:in `should_redirect_to' ./spec/controllers/roles_spec.rb:27: ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-28 02:44 Message: I committed a first step towards this in trunk (rev 1160). It now supports format.html only. So far.... ---------------------------------------------------------------------- Comment By: Pat Maddox (pergesu) Date: 2006-11-27 00:20 Message: Edge rails, 0.7.3 ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-27 00:20 Message: versions???? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6896&group_id=797 From noreply at rubyforge.org Fri Feb 2 12:53:55 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 2 Feb 2007 12:53:55 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-7805 ] Stubs aren't being removed from modules Message-ID: <20070202175355.227DD5242C6F@rubyforge.org> Bugs item #7805, was opened at 2007-01-14 01:59 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=7805&group_id=797 Category: mock module Group: None >Status: Closed >Resolution: Accepted Priority: 3 Submitted By: Michal Kwiatkowski (infrared) >Assigned to: David Chelimsky (dchelimsky) Summary: Stubs aren't being removed from modules Initial Comment: Stubs aren't removed after running specs, which doesn't break things for modules begin tested, but can be source of bugs if you're stubbing classes from stdlib. Example code stubs File.open and manages to break RSpec code itself. Place attached Rakefile and spec in the same directory, then run "rake --trace" to see: undefined method `<' for nil:NilClass /usr/lib/ruby/gems/1.8/gems/rspec-0.7.5/lib/spec/rake/verify_rcov.rb:42:in `define' Source of this error is 'total_coverage' variable which doesn't get initialized because File.open doesn't yield nor return anything useful (because it's still stubbed). As you see in the stack report, I'm using rspec 0.7.5. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-02-02 17:53 Message: This was fixed when [#8302] was fixed. Trunk rev 1447. ---------------------------------------------------------------------- Comment By: Michal Kwiatkowski (infrared) Date: 2007-01-20 00:21 Message: Can anyone confirm this bug? I found even a simpler example: ----- $ ls mock_on_file_causes_error.rb Rakefile $ cat Rakefile require 'spec/rake/spectask' require 'spec/rake/verify_rcov' Spec::Rake::SpecTask.new(:spec_with_rcov) do |t| t.spec_files = FileList['mock_on_file_causes_error.rb'] t.rcov = true end RCov::VerifyTask.new(:verify_rcov => :spec_with_rcov) do |t| t.threshold = 100 end task :default => :verify_rcov $ cat mock_on_file_causes_error.rb require 'rubygems' require 'spec' context "mocks" do specify "mock the File class" do File.should_not_receive :open end end $ rake (in /tmp/blah) rm -r coverage /usr/bin/ruby1.8 -I"/usr/lib/ruby/gems/1.8/gems/rspec-0.7.5/lib" -S rcov --exclude lib\/spec,bin\/spec -o "coverage" "/usr/lib/ruby/gems/1.8/gems/rspec-0.7.5/bin/spec" -- "mock_on_file_causes_error.rb" . Finished in 0.002439 seconds 1 specification, 0 failures Coverage: % (threshold: 100%) rake aborted! undefined method `<' for nil:NilClass (See full trace by running task with --trace) ----- As you can see not only stubbing, but mocking as well causes errors. ---------------------------------------------------------------------- Comment By: Michal Kwiatkowski (infrared) Date: 2007-01-14 11:22 Message: The bug seems to occur only in conjunction with rake and/or rcov but stack trace originates from rspec code (file spec/rake/verify_rcov.rb, line 42), within define of VerifyTask, which is run by rake only *after* the spec task completes (see the attached Rakefile). So it's not true that this code is run during the spec. Error presented by me isn't the only one that can happen because of stubbing File.open. Let me show you another one: Spec file contains (attached as spec_that_coredumps.rb): require 'rubygems' require 'spec' context "stubs" do specify "1 - stub the open method" do puts "BEFORE spec 1" File.stub!(:open).and_return("something") File.open.should == "something" puts "AFTER spec 1" end specify "2 - use File.open to create example.txt" do puts "BEFORE spec 1" File.open.should == "something" puts "AFTER spec 2" end end After running "rake --trace" I get a core dump: $ rake --trace (in /tmp/foobar) ** Invoke default (first_time) ** Invoke verify_rcov (first_time) ** Invoke spec_with_rcov (first_time) ** Invoke clobber_spec_with_rcov (first_time) ** Execute clobber_spec_with_rcov rm -r coverage ** Execute spec_with_rcov /usr/bin/ruby1.8 -I"/usr/lib/ruby/gems/1.8/gems/rspec-0.7.5/lib" -S rcov --exclude lib\/spec,bin\/spec -o "coverage" "/usr/lib/ruby/gems/1.8/gems/rspec-0.7.5/bin/spec" -- "foo.rb" BEFORE spec 1 AFTER spec 1 .BEFORE spec 1 [BUG] Segmentation fault ruby 1.8.4 (2005-12-24) [i486-linux] rake aborted! Command failed with status (): [/usr/bin/ruby1.8 -I"/usr/lib/ruby/gems/1.8...] /usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:722:in `sh' /usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:729:in `sh' /usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:812:in `sh' /usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:807:in `sh' /usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:747:in `ruby' /usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:812:in `ruby' /usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:807:in `ruby' /usr/lib/ruby/gems/1.8/gems/rspec-0.7.5/lib/spec/rake/spectask.rb:131:in `define' /usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:831:in `verbose' /usr/lib/ruby/gems/1.8/gems/rspec-0.7.5/lib/spec/rake/spectask.rb:110:in `define' /usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:387:in `execute' /usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:387:in `execute' /usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:357:in `invoke' /usr/lib/ruby/1.8/thread.rb:135:in `synchronize' /usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:350:in `invoke' /usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:364:in `invoke_prerequisites' /usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:999:in `each' /usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:363:in `invoke_prerequisites' /usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:356:in `invoke' /usr/lib/ruby/1.8/thread.rb:135:in `synchronize' /usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:350:in `invoke' /usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:364:in `invoke_prerequisites' /usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:999:in `each' /usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:363:in `invoke_prerequisites' /usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:356:in `invoke' /usr/lib/ruby/1.8/thread.rb:135:in `synchronize' /usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:350:in `invoke' /usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:1906:in `run' /usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:1906:in `run' /usr/lib/ruby/gems/1.8/gems/rake-0.7.1/bin/rake:7 /usr/bin/rake:18 If stub would be removed and state in the begining of spec2 would be exactly the same as before running spec1 error should not happen. Making spec2 the first spec in context will yield expected result: ArgumentError from File.open. Also, changing a line in spec2 to other that doesn't involve File.open will stop rake from coredumping, but original "undefined method `<' for nil:NilClass" error will still be there. Any ideas? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-01-14 05:04 Message: There is a problem here but it is different from what you suggest. I created a file called stubs_should_restore_methods.rb (attached). Here's the code and the command line session: require 'spec' context "stubs" do specify "1 - stub the open method" do File.stub!(:open).and_return("something") File.open.should == "something" end specify "2 - use File.open to create example.txt" do filename = "example-#{Time.now.to_i}.txt" file = File.open(filename,'w') file << "some text" file.close end end [david at mac tmp]$ ls -al total 0 drwxr-xr-x 2 david david 68 Jan 13 23:01 . drwxr-xr-x 9 david david 306 Jan 13 23:01 .. [david at mac tmp]$ mv ../stubs_should_restore_methods.rb . [david at mac tmp]$ ls -al total 8 drwxr-xr-x 3 david david 102 Jan 13 23:02 . drwxr-xr-x 8 david david 272 Jan 13 23:02 .. -rw-r--r-- 1 david david 348 Jan 13 22:54 stubs_should_restore_methods.rb [david at mac tmp]$ ruby stubs_should_restore_methods.rb -fs stubs - 1 - stub the open method - 2 - use File.open to create example.txt Finished in 0.001414 seconds 2 specifications, 0 failures [david at mac tmp]$ ls -al total 16 drwxr-xr-x 4 david david 136 Jan 13 23:02 . drwxr-xr-x 8 david david 272 Jan 13 23:02 .. -rw-r--r-- 1 david david 9 Jan 13 23:02 example-1168750953.txt -rw-r--r-- 1 david david 348 Jan 13 22:54 stubs_should_restore_methods.rb [david at mac tmp]$ ruby stubs_should_restore_methods.rb -fs stubs - 1 - stub the open method - 2 - use File.open to create example.txt Finished in 0.001393 seconds 2 specifications, 0 failures [david at mac tmp]$ ls -al total 24 drwxr-xr-x 5 david david 170 Jan 13 23:02 . drwxr-xr-x 8 david david 272 Jan 13 23:02 .. -rw-r--r-- 1 david david 9 Jan 13 23:02 example-1168750953.txt -rw-r--r-- 1 david david 9 Jan 13 23:02 example-1168750963.txt -rw-r--r-- 1 david david 348 Jan 13 22:54 stubs_should_restore_methods.rb As you can see, each time the spec is run, the second spec creates a new file using File.open, even though File.open had been stubbed in the first spec. I think the problem is that rcov is trying to use File.open to create and/or write to a file DURING the spec. If that's correct, I don't see what we would be able to do about that from RSpec. What do you think? Cheers, David ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=7805&group_id=797 From noreply at rubyforge.org Fri Feb 2 13:21:25 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 2 Feb 2007 13:21:25 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-8218 ] heckle_runner.rb doesn't work with heckle >= 1.2.0 Message-ID: <20070202182125.763965242C6E@rubyforge.org> Bugs item #8218, was opened at 2007-01-27 18:45 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=8218&group_id=797 Category: runner module Group: None >Status: Closed >Resolution: Accepted Priority: 3 Submitted By: Michal Kwiatkowski (infrared) >Assigned to: David Chelimsky (dchelimsky) Summary: heckle_runner.rb doesn't work with heckle >= 1.2.0 Initial Comment: Heckle::Base class dissapeared in heckle 1.2, so definition of Heckler in heckle_runner.rb is invalid and yields an error. In 1.2 there is no Heckle module, just a global Heckle class. I've attached a patch (against current trunk) that fixes this issue. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-02-02 18:21 Message: Nice simple patch. Thanks! Applied in trunk rev 1458 ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=8218&group_id=797 From noreply at rubyforge.org Fri Feb 2 13:25:20 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 2 Feb 2007 13:25:20 -0500 (EST) Subject: [rspec-devel] [ rspec-Patches-6720 ] [PATCH] ActiveRecord has_many :through and has_and_belongs_to_many break 'should' Message-ID: <20070202182520.6E81F5242C4E@rubyforge.org> Patches item #6720, was opened at 2006-11-17 05:52 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=6720&group_id=797 Category: rails plugin Group: None >Status: Closed Resolution: None Priority: 3 Submitted By: Wilson Bilkovich (wilson) >Assigned to: David Chelimsky (dchelimsky) Summary: [PATCH] ActiveRecord has_many :through and has_and_belongs_to_many break 'should' Initial Comment: Here's a stack trace (not mine, it's from aniero's app): TypeError in 'An instance of a Report model should set the condition relationships based on the condition string on save' wrong argument type Condition (expected Module) ../vendor/rails/activerecord/lib/active_record/base.rb:1235:in `method_missing' ../vendor/rails/activerecord/lib/active_record/associations/has_many_through_association.rb:110:in `method_missing' ../vendor/rails/activerecord/lib/active_record/base.rb:943:in `with_scope' ../vendor/rails/activerecord/lib/active_record/associations/has_many_through_association.rb:110:in `method_missing' ./spec/models/report_spec.rb:36 After some digging with bitsweat's assistance, it turns out that there are four different method_missing implementations in ActiveRecord that can be invoked when calling methods on associations. 1. AssociationProxy, for has_one and belongs_to 2. HasManyAssociation, for has_many 3. HasAndBelongsToManyAssociation, for habtm 4. HasManyThroughAssociation, for has_many through AssociationProxy's method_missing is pretty simple, and doesn't need wrapping. The others, however, make some decisions using respond_to?, etc, etc, and need RSpec to step in ahead of them. This patch adds the other two necessary. An example of where this currently fails is: @record.has_many_association.include? fixtures(:something) The 'rspec_on_rails' sample app doesn't include any habtm or hmt associations, so I couldn't write any specs to cover this. It might be worth adding those, so we can catch this kind of fun. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-02-02 18:25 Message: This will be resolved with the 0.8 release, which won't conflict with method_missing in rails. ---------------------------------------------------------------------- Comment By: Wilson Bilkovich (wilson) Date: 2006-12-02 18:17 Message: I was referring to this one: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6980&group_id=797 ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-12-02 18:07 Message: I'm not sure what other ticket this relates to, but it's ok to fix two bugs in one patch. ---------------------------------------------------------------------- Comment By: Wilson Bilkovich (wilson) Date: 2006-12-02 18:00 Message: I haven't yet, but I'm starting a new project this week (using rspec), so I should get to it soon. Does this relate to the other recent ticket about the methods that AssociationProxy undefines? Do we want to fix both at once? ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-12-02 16:49 Message: Wilson, did you get a chance to write new models and patch the app? If you add new files, make sure to svn add them locally before generating the patch. ---------------------------------------------------------------------- Comment By: Wilson Bilkovich (wilson) Date: 2006-11-17 15:07 Message: OK. I will do that today. I guess it will need a couple of new models. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-17 14:35 Message: Would you like to patch the sample app so we have those specs? The sample app specs get run during the build, and serve as acceptance level tests. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=6720&group_id=797 From noreply at rubyforge.org Fri Feb 2 13:33:58 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 2 Feb 2007 13:33:58 -0500 (EST) Subject: [rspec-devel] [ rspec-Patches-8332 ] [PATCH] Update views documentation Message-ID: <20070202183358.636ED5242C82@rubyforge.org> Patches item #8332, was opened at 2007-01-31 12:51 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=8332&group_id=797 Category: rails plugin Group: None >Status: Closed >Resolution: Accepted Priority: 3 Submitted By: Jerry West (jjw) >Assigned to: David Chelimsky (dchelimsky) Summary: [PATCH] Update views documentation Initial Comment: Add section to views documentation (http://rspec.rubyforge.org/documentation/rails/writing/views.html) describing use of flash[:key]. Patch (diff -c) attached. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-02-02 18:33 Message: Thanks for the patch. We use webgen to generate the website, so we can't just use the patch you provided. I did, however, use it as a basis to update the docs. Added to trunk rev 1459. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=8332&group_id=797 From noreply at rubyforge.org Fri Feb 2 14:42:18 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 2 Feb 2007 14:42:18 -0500 (EST) Subject: [rspec-devel] [ rspec-Feature Requests-8393 ] [PATCH?] Could an unhelpful error message be improved? Message-ID: <20070202194218.C68DB5242C8C@rubyforge.org> Feature Requests item #8393, was opened at 2007-02-02 19:42 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=8393&group_id=797 Category: rails plugin Group: None Status: Open Priority: 3 Submitted By: Jerry West (jjw) Assigned to: Nobody (None) Summary: [PATCH?] Could an unhelpful error message be improved? Initial Comment: Missing out the controller_name declaration from a controller spec context raises this unhelpful error for each spec in the context: NoMethodError in 'GET /assessments (:index) should render index.rhtml' undefined method `session=' for # .../vendor/plugins/rspec_on_rails/lib/spec/rails/context/controller.rb:134:in `setup_extra' .../vendor/plugins/rspec_on_rails/lib/spec/rails/functional_eval_context.rb:22:in `setup' .../vendor/plugins/rspec_on_rails/lib/spec/rails/context/controller.rb:151:in `setup' A trivial fix (submitted by someone who doesn't fully understand the implications of meddling with code they did not write) would be to insert something like raise Exception.new('context requires controller name!') if @controller_class_name.blank? immediately before the call to super in class ControllerEvalContext#setup() - around line 151 of rspec_on_rails/lib/spec/rails/functional_eval_context.rb Rgds, Jerry ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=8393&group_id=797 From noreply at rubyforge.org Fri Feb 2 14:43:01 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 2 Feb 2007 14:43:01 -0500 (EST) Subject: [rspec-devel] [ rspec-Feature Requests-8393 ] [PATCH?] Could an unhelpful error message be improved? Message-ID: <20070202194301.909B55242C90@rubyforge.org> Feature Requests item #8393, was opened at 2007-02-02 19:42 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=8393&group_id=797 Category: rails plugin Group: None Status: Open Priority: 3 Submitted By: Jerry West (jjw) Assigned to: Nobody (None) Summary: [PATCH?] Could an unhelpful error message be improved? Initial Comment: Missing out the controller_name declaration from a controller spec context raises this unhelpful error for each spec in the context: NoMethodError in 'GET /assessments (:index) should render index.rhtml' undefined method `session=' for # .../vendor/plugins/rspec_on_rails/lib/spec/rails/context/controller.rb:134:in `setup_extra' .../vendor/plugins/rspec_on_rails/lib/spec/rails/functional_eval_context.rb:22:in `setup' .../vendor/plugins/rspec_on_rails/lib/spec/rails/context/controller.rb:151:in `setup' A trivial fix (submitted by someone who doesn't fully understand the implications of meddling with code they did not write) would be to insert something like raise Exception.new('context requires controller name!') if @controller_class_name.blank? immediately before the call to super in class ControllerEvalContext#setup() - around line 151 of rspec_on_rails/lib/spec/rails/functional_eval_context.rb Rgds, Jerry ---------------------------------------------------------------------- >Comment By: Jerry West (jjw) Date: 2007-02-02 19:43 Message: Sorry, this is 0.7.5.1 (r1395) ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=8393&group_id=797 From noreply at rubyforge.org Fri Feb 2 16:18:48 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 2 Feb 2007 16:18:48 -0500 (EST) Subject: [rspec-devel] [ rspec-Feature Requests-8393 ] [PATCH?] Could an unhelpful error message be improved? Message-ID: <20070202211848.1C14B5242CA8@rubyforge.org> Feature Requests item #8393, was opened at 2007-02-02 19:42 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=8393&group_id=797 Category: rails plugin Group: None >Status: Closed Priority: 3 Submitted By: Jerry West (jjw) Assigned to: Nobody (None) Summary: [PATCH?] Could an unhelpful error message be improved? Initial Comment: Missing out the controller_name declaration from a controller spec context raises this unhelpful error for each spec in the context: NoMethodError in 'GET /assessments (:index) should render index.rhtml' undefined method `session=' for # .../vendor/plugins/rspec_on_rails/lib/spec/rails/context/controller.rb:134:in `setup_extra' .../vendor/plugins/rspec_on_rails/lib/spec/rails/functional_eval_context.rb:22:in `setup' .../vendor/plugins/rspec_on_rails/lib/spec/rails/context/controller.rb:151:in `setup' A trivial fix (submitted by someone who doesn't fully understand the implications of meddling with code they did not write) would be to insert something like raise Exception.new('context requires controller name!') if @controller_class_name.blank? immediately before the call to super in class ControllerEvalContext#setup() - around line 151 of rspec_on_rails/lib/spec/rails/functional_eval_context.rb Rgds, Jerry ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-02-02 21:18 Message: Duplicate w/ 8240 which was just resolved earlier today. ---------------------------------------------------------------------- Comment By: Jerry West (jjw) Date: 2007-02-02 19:43 Message: Sorry, this is 0.7.5.1 (r1395) ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=8393&group_id=797 From noreply at rubyforge.org Sat Feb 3 07:00:20 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sat, 3 Feb 2007 07:00:20 -0500 (EST) Subject: [rspec-devel] [ rspec-Feature Requests-8149 ] specify_negatively Message-ID: <20070203120020.2A25F5240AB8@rubyforge.org> Feature Requests item #8149, was opened at 2007-01-25 20:55 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=8149&group_id=797 Category: runner module Group: None Status: Closed Priority: 3 Submitted By: Yurii Rashkovskii (yrashk) Assigned to: Aslak Helles?y (aslak_hellesoy) Summary: specify_negatively Initial Comment: The idea is pretty simple: to let declare some specifications as those that _should_ fail: context "Math behaviour" do specify "addition should give you the right answer" do (2+2).should == 4 end specify_negatively "addition should not give you the wrong answer (should fail)" do (2+2).should == 5 end specify_negatively "addition should not give you the wrong answer (bad negative test)"" do (2+2).should == 4 end end Math behaviour - addition should give you the right answer - addition should not give you the wrong answer (should fail) - addition should not give you the wrong answer (bad negative test) (FAILED - 1) 1) 'addition should not give you the wrong answer (bad negative test)' FAILED This specification was expected to fail, but nothing failed Finished in 0.041288 seconds 3 specifications, 1 failure You can read discussion here: http://rashkovskii.com/articles/2007/1/25/rspec-specify_negatively ---------------------------------------------------------------------- >Comment By: Yurii Rashkovskii (yrashk) Date: 2007-02-03 14:00 Message: http://rashkovskii.com/articles/2007/2/3/specify_negatively-updated ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-01-27 12:19 Message: I'm closing this since Proc.should_raise can be used to achieve a similar effect ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-01-25 21:08 Message: Maybe I'm missing something here, but would this work for you? (already supported) lambda do (2+2).should == 5 end.should_raise ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=8149&group_id=797 From noreply at rubyforge.org Sun Feb 4 01:12:53 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 4 Feb 2007 01:12:53 -0500 (EST) Subject: [rspec-devel] [ rspec-Feature Requests-8414 ] Place for Rails specs for library code, not M/V/C component. Message-ID: <20070204061254.0C5DA5242BBE@rubyforge.org> Feature Requests item #8414, was opened at 2007-02-03 22:12 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=8414&group_id=797 Category: rails plugin Group: None Status: Open Priority: 3 Submitted By: Steve Jorgensen (stevej) Assigned to: Nobody (None) Summary: Place for Rails specs for library code, not M/V/C component. Initial Comment: It could just be that I'm not understanding the some philosophical concept, but I recently came up with a requirement, the core of which looks to me like it should be a library module, not a Model, View or Controller. Still, it's part of a Ruby on Rails application, and ought to have formal specs. Where am I supposed to put the specs for this kind of code in a Rails application? Shouldn't there be a spec/libs directory or something? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=8414&group_id=797 From noreply at rubyforge.org Sun Feb 4 01:39:48 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 4 Feb 2007 01:39:48 -0500 (EST) Subject: [rspec-devel] [ rspec-Feature Requests-8414 ] Place for Rails specs for library code, not M/V/C component. Message-ID: <20070204063948.A8C625242BF3@rubyforge.org> Feature Requests item #8414, was opened at 2007-02-04 06:12 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=8414&group_id=797 Category: rails plugin Group: None >Status: Closed Priority: 3 Submitted By: Steve Jorgensen (stevej) >Assigned to: David Chelimsky (dchelimsky) Summary: Place for Rails specs for library code, not M/V/C component. Initial Comment: It could just be that I'm not understanding the some philosophical concept, but I recently came up with a requirement, the core of which looks to me like it should be a library module, not a Model, View or Controller. Still, it's part of a Ruby on Rails application, and ought to have formal specs. Where am I supposed to put the specs for this kind of code in a Rails application? Shouldn't there be a spec/libs directory or something? ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-02-04 06:39 Message: Duplicate of 8366: http://rubyforge.org/tracker/index.php?func=detail&aid=8366&group_id=797&atid=3152 ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=8414&group_id=797 From noreply at rubyforge.org Sun Feb 4 01:43:24 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 4 Feb 2007 01:43:24 -0500 (EST) Subject: [rspec-devel] [ rspec-Documentation-6897 ] better explanation about should_render Message-ID: <20070204064324.48D8A5242BF4@rubyforge.org> Documentation item #6897, was opened at 2006-11-26 23:47 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=9738&aid=6897&group_id=797 Category: None Group: None >Status: Closed Priority: 3 Submitted By: David Chelimsky (dchelimsky) Assigned to: David Chelimsky (dchelimsky) Summary: better explanation about should_render Initial Comment: When should you use which form of controller.should_render? ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-02-04 06:43 Message: controller.should_render is deprecated. After 0.8.0 you should use response.should render_template response.should have_text ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=9738&aid=6897&group_id=797 From noreply at rubyforge.org Sun Feb 4 17:03:19 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 4 Feb 2007 17:03:19 -0500 (EST) Subject: [rspec-devel] [ rspec-Feature Requests-8424 ] more integrated email spec'ing support Message-ID: <20070204220319.772165242A69@rubyforge.org> Feature Requests item #8424, was opened at 2007-02-04 22:03 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=8424&group_id=797 Category: rails plugin Group: None Status: Open Priority: 3 Submitted By: David Chelimsky (dchelimsky) Assigned to: David Chelimsky (dchelimsky) Summary: more integrated email spec'ing support Initial Comment: Version: trunk rev 1461 Current support for email is based on assert_select. It allows you to specify html email but does not cover the following: 1. plain-text email 2. headers 3. isolation of individual email among many delivered It also requires some special setup/teardown. It would be nice if a simple declaration like intercept_email or something like that would take care of that for you. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=8424&group_id=797 From noreply at rubyforge.org Sun Feb 4 17:21:36 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 4 Feb 2007 17:21:36 -0500 (EST) Subject: [rspec-devel] [ rspec-Feature Requests-8126 ] Nested specify blocks Message-ID: <20070204222136.7666D5242A70@rubyforge.org> Feature Requests item #8126, was opened at 2007-01-25 01:25 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=8126&group_id=797 Category: expectation module Group: None Status: Open Priority: 3 Submitted By: Wincent Colaiuta (wincent) Assigned to: Nobody (None) Summary: Nested specify blocks Initial Comment: I know that the idea of nested contexts has come up on the devel list before (Google for "pipermail rspec nested contexts") and most were not in favor of the idea. For me, more useful than nested contexts would be nested specifications ("specify" blocks). Currently I have specs which look like this: context 'outer' do specify 'inner' do this.should == that end end If a spec is not satisfied then rspec prints a message of the form "outer inner". I sometimes find myself wishing that I could nest the specify blocks to fine tune the failure message: context 'outer' do specify 'inner' do specify 'innermost' do this.should == that end end end In this case rspec would print "outer inner innermost" on failure. Let me flesh it out a bit with more of a concrete example; basically I often find myself wanting to write this: context 'applying a regexp to a string' do specify 'should be able to match "zero or more" times' do specify 'with input that matches zero times' do # test zero-match case end specify 'with input that matches one time' do # test one-match case end specify 'with input that matches two times' do # test two-match case end end end Because I can't be bothered writing this: context 'applying a regexp to a string' do specify 'should be able to match "zero or more" times (with input that matches zero times)' do # test zero-match case end specify 'should be able to match "zero or more" times (with input that matches one time)' do # test one-match case end specify 'should be able to match "zero or more" times (with input that matches two times)' do # test two-match case end end But I end up writing this: context 'applying a regexp to a string' do specify 'should be able to match "zero or more" times' do # test zero-match case # test one-match case # test two-match case end end This isn't ideal because if the first assertion fails then the others aren't even tested. I'd rather keep the number of assertions in each specify block a bit lower, and the ability to nest specify blocks would help me to do that. What do people think? ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-02-04 22:21 Message: Thinking about this some more - I think that there are many structures that could prove useful. We've named "context/specify/example", but there is also "story/scenario" for acceptance level spec'ing, "behaviour/specify/example" when the context is not so much a system state, but rather an aspect of behaviour like "error messages". This is leading me to this thought: what if the structure was simply a tree? We could have a method #rspec_node(*args, &block) that returns an RSpecNode. This would be implemented in Kernel, aliased with names like #context, #behaviour and #story. It would also be implemented in RSpecNode, aliased with names like #specify, #example and #scenario. Nested nodes would have access to state in any of its ancestor nodes, supporting the long sought-after "nested context", but siblings would not have access to each other's state. Command line options could load a file which defines custom aliases that you want to use that don't ship with RSpec, so you could things like "project/iteration/story/scenario" if that made you happy. I've taken a look at this and it would require a lot of work, but there's no reason it shouldn't be 100% backwards compatible (except for monkey patching), and it's something we can probably introduce gradually, starting w/ nested specify blocks, and working up to unifying Context and Specification into a single RSpecNode. WDYT of that? ---------------------------------------------------------------------- Comment By: Wincent Colaiuta (wincent) Date: 2007-01-27 16:42 Message: Yes, I think that "context/specify/example" would be a great way to split things up, and the language you've proposed maps well onto the behaviour-driven way of thinking about software development ("in this context ... this should happen ... example ..."). About the only thing I would change in your example is that I would start each example with the word "for" so that when the three strings are chained together they would read like, "applying a regexp to a string should be able to match 'zero or more' times for the zero-match case" etc: context 'applying a regexp to a string' do specify 'should be able to match "zero or more" times' do example 'for the zero-match case' do ... end example 'for the one-match case' do ... end example 'for the two-match case' do ... end end end This has the added benefit that the line introducing each example in the specification reads as "example for zero- match case" etc, which is highly readable and descriptive. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-01-27 15:53 Message: I love this idea, but I think nesting specify would be confusing to look at. How about this: context specify example context 'applying a regexp to a string' do specify 'should be able to match "zero or more" times' do example "zero-match case" do example "one-match case" do example "two-match case" do end end ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=8126&group_id=797 From noreply at rubyforge.org Sun Feb 4 17:29:10 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 4 Feb 2007 17:29:10 -0500 (EST) Subject: [rspec-devel] [ rspec-Feature Requests-8126 ] Nested specify blocks Message-ID: <20070204222910.A6D125242A79@rubyforge.org> Feature Requests item #8126, was opened at 2007-01-25 12:25 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=8126&group_id=797 Category: expectation module Group: None Status: Open Priority: 3 Submitted By: Wincent Colaiuta (wincent) Assigned to: Nobody (None) Summary: Nested specify blocks Initial Comment: I know that the idea of nested contexts has come up on the devel list before (Google for "pipermail rspec nested contexts") and most were not in favor of the idea. For me, more useful than nested contexts would be nested specifications ("specify" blocks). Currently I have specs which look like this: context 'outer' do specify 'inner' do this.should == that end end If a spec is not satisfied then rspec prints a message of the form "outer inner". I sometimes find myself wishing that I could nest the specify blocks to fine tune the failure message: context 'outer' do specify 'inner' do specify 'innermost' do this.should == that end end end In this case rspec would print "outer inner innermost" on failure. Let me flesh it out a bit with more of a concrete example; basically I often find myself wanting to write this: context 'applying a regexp to a string' do specify 'should be able to match "zero or more" times' do specify 'with input that matches zero times' do # test zero-match case end specify 'with input that matches one time' do # test one-match case end specify 'with input that matches two times' do # test two-match case end end end Because I can't be bothered writing this: context 'applying a regexp to a string' do specify 'should be able to match "zero or more" times (with input that matches zero times)' do # test zero-match case end specify 'should be able to match "zero or more" times (with input that matches one time)' do # test one-match case end specify 'should be able to match "zero or more" times (with input that matches two times)' do # test two-match case end end But I end up writing this: context 'applying a regexp to a string' do specify 'should be able to match "zero or more" times' do # test zero-match case # test one-match case # test two-match case end end This isn't ideal because if the first assertion fails then the others aren't even tested. I'd rather keep the number of assertions in each specify block a bit lower, and the ability to nest specify blocks would help me to do that. What do people think? ---------------------------------------------------------------------- Comment By: Lachie Cox (lachie) Date: 2007-02-05 09:29 Message: I this given-when-then by different names? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-02-05 09:21 Message: Thinking about this some more - I think that there are many structures that could prove useful. We've named "context/specify/example", but there is also "story/scenario" for acceptance level spec'ing, "behaviour/specify/example" when the context is not so much a system state, but rather an aspect of behaviour like "error messages". This is leading me to this thought: what if the structure was simply a tree? We could have a method #rspec_node(*args, &block) that returns an RSpecNode. This would be implemented in Kernel, aliased with names like #context, #behaviour and #story. It would also be implemented in RSpecNode, aliased with names like #specify, #example and #scenario. Nested nodes would have access to state in any of its ancestor nodes, supporting the long sought-after "nested context", but siblings would not have access to each other's state. Command line options could load a file which defines custom aliases that you want to use that don't ship with RSpec, so you could things like "project/iteration/story/scenario" if that made you happy. I've taken a look at this and it would require a lot of work, but there's no reason it shouldn't be 100% backwards compatible (except for monkey patching), and it's something we can probably introduce gradually, starting w/ nested specify blocks, and working up to unifying Context and Specification into a single RSpecNode. WDYT of that? ---------------------------------------------------------------------- Comment By: Wincent Colaiuta (wincent) Date: 2007-01-28 03:42 Message: Yes, I think that "context/specify/example" would be a great way to split things up, and the language you've proposed maps well onto the behaviour-driven way of thinking about software development ("in this context ... this should happen ... example ..."). About the only thing I would change in your example is that I would start each example with the word "for" so that when the three strings are chained together they would read like, "applying a regexp to a string should be able to match 'zero or more' times for the zero-match case" etc: context 'applying a regexp to a string' do specify 'should be able to match "zero or more" times' do example 'for the zero-match case' do ... end example 'for the one-match case' do ... end example 'for the two-match case' do ... end end end This has the added benefit that the line introducing each example in the specification reads as "example for zero- match case" etc, which is highly readable and descriptive. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-01-28 02:53 Message: I love this idea, but I think nesting specify would be confusing to look at. How about this: context specify example context 'applying a regexp to a string' do specify 'should be able to match "zero or more" times' do example "zero-match case" do example "one-match case" do example "two-match case" do end end ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=8126&group_id=797 From noreply at rubyforge.org Mon Feb 5 05:12:21 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 5 Feb 2007 05:12:21 -0500 (EST) Subject: [rspec-devel] [ rspec-Feature Requests-8126 ] Nested specify blocks Message-ID: <20070205101221.7D0FE5240965@rubyforge.org> Feature Requests item #8126, was opened at 2007-01-25 01:25 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=8126&group_id=797 Category: expectation module Group: None Status: Open Priority: 3 Submitted By: Wincent Colaiuta (wincent) Assigned to: Nobody (None) Summary: Nested specify blocks Initial Comment: I know that the idea of nested contexts has come up on the devel list before (Google for "pipermail rspec nested contexts") and most were not in favor of the idea. For me, more useful than nested contexts would be nested specifications ("specify" blocks). Currently I have specs which look like this: context 'outer' do specify 'inner' do this.should == that end end If a spec is not satisfied then rspec prints a message of the form "outer inner". I sometimes find myself wishing that I could nest the specify blocks to fine tune the failure message: context 'outer' do specify 'inner' do specify 'innermost' do this.should == that end end end In this case rspec would print "outer inner innermost" on failure. Let me flesh it out a bit with more of a concrete example; basically I often find myself wanting to write this: context 'applying a regexp to a string' do specify 'should be able to match "zero or more" times' do specify 'with input that matches zero times' do # test zero-match case end specify 'with input that matches one time' do # test one-match case end specify 'with input that matches two times' do # test two-match case end end end Because I can't be bothered writing this: context 'applying a regexp to a string' do specify 'should be able to match "zero or more" times (with input that matches zero times)' do # test zero-match case end specify 'should be able to match "zero or more" times (with input that matches one time)' do # test one-match case end specify 'should be able to match "zero or more" times (with input that matches two times)' do # test two-match case end end But I end up writing this: context 'applying a regexp to a string' do specify 'should be able to match "zero or more" times' do # test zero-match case # test one-match case # test two-match case end end This isn't ideal because if the first assertion fails then the others aren't even tested. I'd rather keep the number of assertions in each specify block a bit lower, and the ability to nest specify blocks would help me to do that. What do people think? ---------------------------------------------------------------------- >Comment By: Wincent Colaiuta (wincent) Date: 2007-02-05 10:12 Message: > Command line options could load a file which defines > custom aliases that you want to use that don't ship > with RSpec, so you could things like > "project/iteration/story/scenario" if that made you > happy. Above all, I think *some kind* of nesting support would be a wonderful improvement in terms of readability/expressiveness and also in terms of saved typing; these are the reasons why I filed the feature request. I am also sure that the ability to basically twist RSpec into any shape you want and use any terminology you want would be popular. BUT I also think that it might be a bit dangerous to give people too much free reign. One of the things about BDD in general and specifically RSpec is that the language that it imposes ("context"/"specify") helps developers to do the right thing and follow best testing practice. If people could use any terminology at all then some of that benefit might be lost. Also, in the same way that overuse of C preprocessor macros can make it harder to read other people's source code, if the terminology for specifying behaviour is made too flexible then it might become more difficult to read other people's specs. So I'm not saying that you shouldn't do it, but that if you do decide to go down this path I think your idea of doing so in an incremental fashion is a good one; it will give time to really think about it and be sure of why/how/if it should be done. I like the idea of using "story" for acceptance level testing. I am not sure whether "behaviour" is the best term for cases where "the context is not so much a system state, but rather an aspect of behaviour"; I think the word that you used right there, "aspect", is probably a better choice. That's just my initial gut feeling; I'd need to think about it more to be sure. ---------------------------------------------------------------------- Comment By: Lachie Cox (lachie) Date: 2007-02-04 22:29 Message: I this given-when-then by different names? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-02-04 22:21 Message: Thinking about this some more - I think that there are many structures that could prove useful. We've named "context/specify/example", but there is also "story/scenario" for acceptance level spec'ing, "behaviour/specify/example" when the context is not so much a system state, but rather an aspect of behaviour like "error messages". This is leading me to this thought: what if the structure was simply a tree? We could have a method #rspec_node(*args, &block) that returns an RSpecNode. This would be implemented in Kernel, aliased with names like #context, #behaviour and #story. It would also be implemented in RSpecNode, aliased with names like #specify, #example and #scenario. Nested nodes would have access to state in any of its ancestor nodes, supporting the long sought-after "nested context", but siblings would not have access to each other's state. Command line options could load a file which defines custom aliases that you want to use that don't ship with RSpec, so you could things like "project/iteration/story/scenario" if that made you happy. I've taken a look at this and it would require a lot of work, but there's no reason it shouldn't be 100% backwards compatible (except for monkey patching), and it's something we can probably introduce gradually, starting w/ nested specify blocks, and working up to unifying Context and Specification into a single RSpecNode. WDYT of that? ---------------------------------------------------------------------- Comment By: Wincent Colaiuta (wincent) Date: 2007-01-27 16:42 Message: Yes, I think that "context/specify/example" would be a great way to split things up, and the language you've proposed maps well onto the behaviour-driven way of thinking about software development ("in this context ... this should happen ... example ..."). About the only thing I would change in your example is that I would start each example with the word "for" so that when the three strings are chained together they would read like, "applying a regexp to a string should be able to match 'zero or more' times for the zero-match case" etc: context 'applying a regexp to a string' do specify 'should be able to match "zero or more" times' do example 'for the zero-match case' do ... end example 'for the one-match case' do ... end example 'for the two-match case' do ... end end end This has the added benefit that the line introducing each example in the specification reads as "example for zero- match case" etc, which is highly readable and descriptive. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-01-27 15:53 Message: I love this idea, but I think nesting specify would be confusing to look at. How about this: context specify example context 'applying a regexp to a string' do specify 'should be able to match "zero or more" times' do example "zero-match case" do example "one-match case" do example "two-match case" do end end ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=8126&group_id=797 From noreply at rubyforge.org Mon Feb 5 06:46:14 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 5 Feb 2007 06:46:14 -0500 (EST) Subject: [rspec-devel] [ rspec-Feature Requests-8126 ] Nested specify blocks Message-ID: <20070205114614.304F95240D77@rubyforge.org> Feature Requests item #8126, was opened at 2007-01-25 01:25 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=8126&group_id=797 Category: expectation module Group: None Status: Open Priority: 3 Submitted By: Wincent Colaiuta (wincent) Assigned to: Nobody (None) Summary: Nested specify blocks Initial Comment: I know that the idea of nested contexts has come up on the devel list before (Google for "pipermail rspec nested contexts") and most were not in favor of the idea. For me, more useful than nested contexts would be nested specifications ("specify" blocks). Currently I have specs which look like this: context 'outer' do specify 'inner' do this.should == that end end If a spec is not satisfied then rspec prints a message of the form "outer inner". I sometimes find myself wishing that I could nest the specify blocks to fine tune the failure message: context 'outer' do specify 'inner' do specify 'innermost' do this.should == that end end end In this case rspec would print "outer inner innermost" on failure. Let me flesh it out a bit with more of a concrete example; basically I often find myself wanting to write this: context 'applying a regexp to a string' do specify 'should be able to match "zero or more" times' do specify 'with input that matches zero times' do # test zero-match case end specify 'with input that matches one time' do # test one-match case end specify 'with input that matches two times' do # test two-match case end end end Because I can't be bothered writing this: context 'applying a regexp to a string' do specify 'should be able to match "zero or more" times (with input that matches zero times)' do # test zero-match case end specify 'should be able to match "zero or more" times (with input that matches one time)' do # test one-match case end specify 'should be able to match "zero or more" times (with input that matches two times)' do # test two-match case end end But I end up writing this: context 'applying a regexp to a string' do specify 'should be able to match "zero or more" times' do # test zero-match case # test one-match case # test two-match case end end This isn't ideal because if the first assertion fails then the others aren't even tested. I'd rather keep the number of assertions in each specify block a bit lower, and the ability to nest specify blocks would help me to do that. What do people think? ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-02-05 11:46 Message: Lachie: yes, you could view it that way, and given/when/then should be supported keywords (when and then would have to be munged in some way as they are already Ruby keywords). Wincent: we've gone a long way to keep things simple and from what I've seen, some people will go out of their way to complicate things no matter how simple you make them. Including us!!!! (e.g. controller.should_render) If/when we do this, it will likely be introduced gradually. It's not the first priority at the moment ;) Also - looking back at your initial submission - you could do this in the mean time: context 'applying a regexp to a string should be able to match "zero or more" times' do specify 'with input that matches zero times' do end specify 'with input that matches one time' do end specify 'with input that matches two times' do end end I realize that the context name is more than context - it's a declaration of an aspect of behaviour. That's probably not such a bad thing. And it would result in the same readable output on failures. FFT. ---------------------------------------------------------------------- Comment By: Wincent Colaiuta (wincent) Date: 2007-02-05 10:12 Message: > Command line options could load a file which defines > custom aliases that you want to use that don't ship > with RSpec, so you could things like > "project/iteration/story/scenario" if that made you > happy. Above all, I think *some kind* of nesting support would be a wonderful improvement in terms of readability/expressiveness and also in terms of saved typing; these are the reasons why I filed the feature request. I am also sure that the ability to basically twist RSpec into any shape you want and use any terminology you want would be popular. BUT I also think that it might be a bit dangerous to give people too much free reign. One of the things about BDD in general and specifically RSpec is that the language that it imposes ("context"/"specify") helps developers to do the right thing and follow best testing practice. If people could use any terminology at all then some of that benefit might be lost. Also, in the same way that overuse of C preprocessor macros can make it harder to read other people's source code, if the terminology for specifying behaviour is made too flexible then it might become more difficult to read other people's specs. So I'm not saying that you shouldn't do it, but that if you do decide to go down this path I think your idea of doing so in an incremental fashion is a good one; it will give time to really think about it and be sure of why/how/if it should be done. I like the idea of using "story" for acceptance level testing. I am not sure whether "behaviour" is the best term for cases where "the context is not so much a system state, but rather an aspect of behaviour"; I think the word that you used right there, "aspect", is probably a better choice. That's just my initial gut feeling; I'd need to think about it more to be sure. ---------------------------------------------------------------------- Comment By: Lachie Cox (lachie) Date: 2007-02-04 22:29 Message: I this given-when-then by different names? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-02-04 22:21 Message: Thinking about this some more - I think that there are many structures that could prove useful. We've named "context/specify/example", but there is also "story/scenario" for acceptance level spec'ing, "behaviour/specify/example" when the context is not so much a system state, but rather an aspect of behaviour like "error messages". This is leading me to this thought: what if the structure was simply a tree? We could have a method #rspec_node(*args, &block) that returns an RSpecNode. This would be implemented in Kernel, aliased with names like #context, #behaviour and #story. It would also be implemented in RSpecNode, aliased with names like #specify, #example and #scenario. Nested nodes would have access to state in any of its ancestor nodes, supporting the long sought-after "nested context", but siblings would not have access to each other's state. Command line options could load a file which defines custom aliases that you want to use that don't ship with RSpec, so you could things like "project/iteration/story/scenario" if that made you happy. I've taken a look at this and it would require a lot of work, but there's no reason it shouldn't be 100% backwards compatible (except for monkey patching), and it's something we can probably introduce gradually, starting w/ nested specify blocks, and working up to unifying Context and Specification into a single RSpecNode. WDYT of that? ---------------------------------------------------------------------- Comment By: Wincent Colaiuta (wincent) Date: 2007-01-27 16:42 Message: Yes, I think that "context/specify/example" would be a great way to split things up, and the language you've proposed maps well onto the behaviour-driven way of thinking about software development ("in this context ... this should happen ... example ..."). About the only thing I would change in your example is that I would start each example with the word "for" so that when the three strings are chained together they would read like, "applying a regexp to a string should be able to match 'zero or more' times for the zero-match case" etc: context 'applying a regexp to a string' do specify 'should be able to match "zero or more" times' do example 'for the zero-match case' do ... end example 'for the one-match case' do ... end example 'for the two-match case' do ... end end end This has the added benefit that the line introducing each example in the specification reads as "example for zero- match case" etc, which is highly readable and descriptive. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-01-27 15:53 Message: I love this idea, but I think nesting specify would be confusing to look at. How about this: context specify example context 'applying a regexp to a string' do specify 'should be able to match "zero or more" times' do example "zero-match case" do example "one-match case" do example "two-match case" do end end ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=8126&group_id=797 From noreply at rubyforge.org Wed Feb 7 06:40:26 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 7 Feb 2007 06:40:26 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-7344 ] Failing spec in HTML formatter Message-ID: <20070207114026.B8F755240F0C@rubyforge.org> Bugs item #7344, was opened at 2006-12-18 18:33 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=7344&group_id=797 Category: runner module Group: None Status: Open Resolution: None Priority: 2 Submitted By: Bob Cotton (bcotton) Assigned to: Nobody (None) Summary: Failing spec in HTML formatter Initial Comment: This is revision 1322 ruby -v ruby 1.8.5 (2006-08-25) [powerpc-darwin8.8.0] (build with all gcc optimizations off, ruby crashes on gem installs otherwise) 1) 'HtmlFormatter should produce HTML identical to the one we designed manually' FAILED [...HTML DELETED...] Diff: @@ -119,9 +119,7 @@ 
Mock 'poke me' expected :poke with (any args) once, but received it 0 times
./failing_examples/mocking_example.rb:13:
 ./spec/spec/runner/formatter/html_formatter_spec.rb:16:
-./spec/spec/runner/formatter/html_formatter_spec.rb:12:in `chdir'
 ./spec/spec/runner/formatter/html_formatter_spec.rb:12:
-./spec/spec/runner/formatter/html_formatter_spec.rb:11:in `each'
 ./spec/spec/runner/formatter/html_formatter_spec.rb:11:
@@ -135,9 +133,7 @@ 
(eval):3:in `three'
 ./failing_examples/mocking_example.rb:22:
 ./spec/spec/runner/formatter/html_formatter_spec.rb:16:
-./spec/spec/runner/formatter/html_formatter_spec.rb:12:in `chdir'
 ./spec/spec/runner/formatter/html_formatter_spec.rb:12:
-./spec/spec/runner/formatter/html_formatter_spec.rb:11:in `each'
 ./spec/spec/runner/formatter/html_formatter_spec.rb:11:
@@ -150,9 +146,7 @@ 
Mock 'don't talk to me' expected :any_message_at_all with (any args) 0 times, but received it once
./failing_examples/mocking_example.rb:28:
 ./spec/spec/runner/formatter/html_formatter_spec.rb:16:
-./spec/spec/runner/formatter/html_formatter_spec.rb:12:in `chdir'
 ./spec/spec/runner/formatter/html_formatter_spec.rb:12:
-./spec/spec/runner/formatter/html_formatter_spec.rb:11:in `each'
 ./spec/spec/runner/formatter/html_formatter_spec.rb:11:
@@ -177,9 +171,7 @@ 
./failing_examples/diffing_spec.rb:13:
 ./spec/spec/runner/formatter/html_formatter_spec.rb:16:
-./spec/spec/runner/formatter/html_formatter_spec.rb:12:in `chdir'
 ./spec/spec/runner/formatter/html_formatter_spec.rb:12:
-./spec/spec/runner/formatter/html_formatter_spec.rb:11:in `each'
 ./spec/spec/runner/formatter/html_formatter_spec.rb:11:
@@ -208,9 +200,7 @@ 
./failing_examples/diffing_spec.rb:34:
 ./spec/spec/runner/formatter/html_formatter_spec.rb:16:
-./spec/spec/runner/formatter/html_formatter_spec.rb:12:in `chdir'
 ./spec/spec/runner/formatter/html_formatter_spec.rb:12:
-./spec/spec/runner/formatter/html_formatter_spec.rb:11:in `each'
 ./spec/spec/runner/formatter/html_formatter_spec.rb:11:
/Users/bcotton/projects/rspec/lib/spec/expectations.rb:20:in `fail_with' /Users/bcotton/projects/rspec/lib/spec/expectations/should/base.rb:35:in `fail_with_message' /Users/bcotton/projects/rspec/lib/spec/expectations/should/should.rb:49:in `__delegate_method_missing_to_target' /Users/bcotton/projects/rspec/lib/spec/expectations/should/base.rb:15:in `==' ./spec/spec/runner/formatter/html_formatter_spec.rb:31: ./spec/spec/runner/formatter/html_formatter_spec.rb:12:in `chdir' ./spec/spec/runner/formatter/html_formatter_spec.rb:12: ./spec/spec/runner/formatter/html_formatter_spec.rb:11:in `each' ./spec/spec/runner/formatter/html_formatter_spec.rb:11: /Users/bcotton/projects/rspec/lib/spec/runner/specification.rb:55:in `instance_eval' /Users/bcotton/projects/rspec/lib/spec/runner/specification.rb:55:in `execute_spec' /Users/bcotton/projects/rspec/lib/spec/runner/specification.rb:30:in `run' /Users/bcotton/projects/rspec/lib/spec/runner/context.rb:57:in `run' /Users/bcotton/projects/rspec/lib/spec/runner/context.rb:54:in `each' /Users/bcotton/projects/rspec/lib/spec/runner/context.rb:54:in `run' /Users/bcotton/projects/rspec/lib/spec/runner/context_runner.rb:23:in `run' /Users/bcotton/projects/rspec/lib/spec/runner/context_runner.rb:22:in `each' /Users/bcotton/projects/rspec/lib/spec/runner/context_runner.rb:22:in `run' /Users/bcotton/projects/rspec/lib/spec/runner/command_line.rb:26:in `run' /Users/bcotton/projects/rspec/bin/spec:4: /usr/local/lib/ruby/gems/1.8/gems/rcov-0.7.0.1/bin/rcov:493:in `load' /usr/local/lib/ruby/gems/1.8/gems/rcov-0.7.0.1/bin/rcov:493: /usr/local/bin/rcov:18:in `load' /usr/local/bin/rcov:18: Finished in 5.943487 seconds 497 specifications, 1 failure ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-02-07 11:40 Message: We need a solution that supports 1.8.4 and 1.8.5. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-12-18 18:46 Message: I cannot reproduce this on Ruby 1.8.4. Looks like Ruby 1.8.5 (which I don't have yet) is adding more backtrace info. You can just ignore this. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=7344&group_id=797 From noreply at rubyforge.org Wed Feb 7 06:52:31 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 7 Feb 2007 06:52:31 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-7344 ] Failing spec in HTML formatter Message-ID: <20070207115231.449A7524266D@rubyforge.org> Bugs item #7344, was opened at 2006-12-18 13:33 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=7344&group_id=797 Category: runner module Group: None Status: Open Resolution: None Priority: 2 Submitted By: Bob Cotton (bcotton) Assigned to: Nobody (None) Summary: Failing spec in HTML formatter Initial Comment: This is revision 1322 ruby -v ruby 1.8.5 (2006-08-25) [powerpc-darwin8.8.0] (build with all gcc optimizations off, ruby crashes on gem installs otherwise) 1) 'HtmlFormatter should produce HTML identical to the one we designed manually' FAILED [...HTML DELETED...] Diff: @@ -119,9 +119,7 @@ 
Mock 'poke me' expected :poke with (any args) once, but received it 0 times
./failing_examples/mocking_example.rb:13:
 ./spec/spec/runner/formatter/html_formatter_spec.rb:16:
-./spec/spec/runner/formatter/html_formatter_spec.rb:12:in `chdir'
 ./spec/spec/runner/formatter/html_formatter_spec.rb:12:
-./spec/spec/runner/formatter/html_formatter_spec.rb:11:in `each'
 ./spec/spec/runner/formatter/html_formatter_spec.rb:11:
@@ -135,9 +133,7 @@ 
(eval):3:in `three'
 ./failing_examples/mocking_example.rb:22:
 ./spec/spec/runner/formatter/html_formatter_spec.rb:16:
-./spec/spec/runner/formatter/html_formatter_spec.rb:12:in `chdir'
 ./spec/spec/runner/formatter/html_formatter_spec.rb:12:
-./spec/spec/runner/formatter/html_formatter_spec.rb:11:in `each'
 ./spec/spec/runner/formatter/html_formatter_spec.rb:11:
@@ -150,9 +146,7 @@ 
Mock 'don't talk to me' expected :any_message_at_all with (any args) 0 times, but received it once
./failing_examples/mocking_example.rb:28:
 ./spec/spec/runner/formatter/html_formatter_spec.rb:16:
-./spec/spec/runner/formatter/html_formatter_spec.rb:12:in `chdir'
 ./spec/spec/runner/formatter/html_formatter_spec.rb:12:
-./spec/spec/runner/formatter/html_formatter_spec.rb:11:in `each'
 ./spec/spec/runner/formatter/html_formatter_spec.rb:11:
@@ -177,9 +171,7 @@ 
./failing_examples/diffing_spec.rb:13:
 ./spec/spec/runner/formatter/html_formatter_spec.rb:16:
-./spec/spec/runner/formatter/html_formatter_spec.rb:12:in `chdir'
 ./spec/spec/runner/formatter/html_formatter_spec.rb:12:
-./spec/spec/runner/formatter/html_formatter_spec.rb:11:in `each'
 ./spec/spec/runner/formatter/html_formatter_spec.rb:11:
@@ -208,9 +200,7 @@ 
./failing_examples/diffing_spec.rb:34:
 ./spec/spec/runner/formatter/html_formatter_spec.rb:16:
-./spec/spec/runner/formatter/html_formatter_spec.rb:12:in `chdir'
 ./spec/spec/runner/formatter/html_formatter_spec.rb:12:
-./spec/spec/runner/formatter/html_formatter_spec.rb:11:in `each'
 ./spec/spec/runner/formatter/html_formatter_spec.rb:11:
/Users/bcotton/projects/rspec/lib/spec/expectations.rb:20:in `fail_with' /Users/bcotton/projects/rspec/lib/spec/expectations/should/base.rb:35:in `fail_with_message' /Users/bcotton/projects/rspec/lib/spec/expectations/should/should.rb:49:in `__delegate_method_missing_to_target' /Users/bcotton/projects/rspec/lib/spec/expectations/should/base.rb:15:in `==' ./spec/spec/runner/formatter/html_formatter_spec.rb:31: ./spec/spec/runner/formatter/html_formatter_spec.rb:12:in `chdir' ./spec/spec/runner/formatter/html_formatter_spec.rb:12: ./spec/spec/runner/formatter/html_formatter_spec.rb:11:in `each' ./spec/spec/runner/formatter/html_formatter_spec.rb:11: /Users/bcotton/projects/rspec/lib/spec/runner/specification.rb:55:in `instance_eval' /Users/bcotton/projects/rspec/lib/spec/runner/specification.rb:55:in `execute_spec' /Users/bcotton/projects/rspec/lib/spec/runner/specification.rb:30:in `run' /Users/bcotton/projects/rspec/lib/spec/runner/context.rb:57:in `run' /Users/bcotton/projects/rspec/lib/spec/runner/context.rb:54:in `each' /Users/bcotton/projects/rspec/lib/spec/runner/context.rb:54:in `run' /Users/bcotton/projects/rspec/lib/spec/runner/context_runner.rb:23:in `run' /Users/bcotton/projects/rspec/lib/spec/runner/context_runner.rb:22:in `each' /Users/bcotton/projects/rspec/lib/spec/runner/context_runner.rb:22:in `run' /Users/bcotton/projects/rspec/lib/spec/runner/command_line.rb:26:in `run' /Users/bcotton/projects/rspec/bin/spec:4: /usr/local/lib/ruby/gems/1.8/gems/rcov-0.7.0.1/bin/rcov:493:in `load' /usr/local/lib/ruby/gems/1.8/gems/rcov-0.7.0.1/bin/rcov:493: /usr/local/bin/rcov:18:in `load' /usr/local/bin/rcov:18: Finished in 5.943487 seconds 497 specifications, 1 failure ---------------------------------------------------------------------- >Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-02-07 06:52 Message: html_formatted_1.8.4.html, html_formatted_1.8.5.html etc. The spec will compare against one of them depending on Ruby's version (VERSION) ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-02-07 06:40 Message: We need a solution that supports 1.8.4 and 1.8.5. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-12-18 13:46 Message: I cannot reproduce this on Ruby 1.8.4. Looks like Ruby 1.8.5 (which I don't have yet) is adding more backtrace info. You can just ignore this. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=7344&group_id=797 From noreply at rubyforge.org Wed Feb 7 14:28:04 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 7 Feb 2007 14:28:04 -0500 (EST) Subject: [rspec-devel] [ rspec-Feature Requests-8484 ] should_receive with blocks and cardinality Message-ID: <20070207192804.E616B52426D2@rubyforge.org> Feature Requests item #8484, was opened at 2007-02-07 13:28 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=8484&group_id=797 Category: mock module Group: None Status: Open Priority: 3 Submitted By: Micah Martin (slagyr) Assigned to: Nobody (None) Summary: should_receive with blocks and cardinality Initial Comment: the mock.should_receive method should accept cardinatliy along with blocks. specify "mock should receive call twice with block" do my_mock = mock("my mock") calls = 0 my_mock.should_receive(:foo).twice { calls = calls + 1 } my_mock.foo my_mock.foo calls.should_eql 2 end specify "mock should receive exactly 10 times with param" do my_mock = mock("my mock") sum = 0 my_mock.should_receive(:foo).exactly(10).times { |i| sum = sum + i } 10.times { |i| my_mock.foo(i) } sum.should_eql 45 end ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=8484&group_id=797 From noreply at rubyforge.org Wed Feb 7 14:59:45 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 7 Feb 2007 14:59:45 -0500 (EST) Subject: [rspec-devel] [ rspec-Feature Requests-8484 ] should_receive with blocks and cardinality Message-ID: <20070207195945.97E1152426C5@rubyforge.org> Feature Requests item #8484, was opened at 2007-02-07 19:28 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=8484&group_id=797 Category: mock module Group: None Status: Open Priority: 3 Submitted By: Micah Martin (slagyr) >Assigned to: David Chelimsky (dchelimsky) Summary: should_receive with blocks and cardinality Initial Comment: the mock.should_receive method should accept cardinatliy along with blocks. specify "mock should receive call twice with block" do my_mock = mock("my mock") calls = 0 my_mock.should_receive(:foo).twice { calls = calls + 1 } my_mock.foo my_mock.foo calls.should_eql 2 end specify "mock should receive exactly 10 times with param" do my_mock = mock("my mock") sum = 0 my_mock.should_receive(:foo).exactly(10).times { |i| sum = sum + i } 10.times { |i| my_mock.foo(i) } sum.should_eql 45 end ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=8484&group_id=797 From noreply at rubyforge.org Wed Feb 7 20:48:37 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 7 Feb 2007 20:48:37 -0500 (EST) Subject: [rspec-devel] [ rspec-Feature Requests-8484 ] should_receive with blocks and cardinality Message-ID: <20070208014838.11A4352426FF@rubyforge.org> Feature Requests item #8484, was opened at 2007-02-07 19:28 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=8484&group_id=797 Category: mock module Group: None >Status: Closed Priority: 3 Submitted By: Micah Martin (slagyr) Assigned to: David Chelimsky (dchelimsky) Summary: should_receive with blocks and cardinality Initial Comment: the mock.should_receive method should accept cardinatliy along with blocks. specify "mock should receive call twice with block" do my_mock = mock("my mock") calls = 0 my_mock.should_receive(:foo).twice { calls = calls + 1 } my_mock.foo my_mock.foo calls.should_eql 2 end specify "mock should receive exactly 10 times with param" do my_mock = mock("my mock") sum = 0 my_mock.should_receive(:foo).exactly(10).times { |i| sum = sum + i } 10.times { |i| my_mock.foo(i) } sum.should_eql 45 end ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-02-08 01:48 Message: Added to trunk rev 1478. a mock message receiving a block - should call the block after #should_receive - should call the block after #once - should call the block after #twice - should call the block after #times - should call the block after #any_number_of_times - should call the block after #with - should call the block after #ordered ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=8484&group_id=797 From noreply at rubyforge.org Wed Feb 7 23:11:22 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 7 Feb 2007 23:11:22 -0500 (EST) Subject: [rspec-devel] [ rspec-Feature Requests-7613 ] context#include should add constants into the context Message-ID: <20070208041122.850C1524270A@rubyforge.org> Feature Requests item #7613, was opened at 2007-01-06 01:25 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=7613&group_id=797 Category: None Group: None Status: Open Priority: 3 Submitted By: Brian Takita (btakita) Assigned to: Nobody (None) Summary: context#include should add constants into the context Initial Comment: dir = File.dirname(__FILE__) require "#{dir}/spec_helper" module Foo class Bar end end context "A Context include statement" do include Foo specify "should add constants accessable in the context" do b = Bar.new end end ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-02-08 04:11 Message: >From the ruby-talk list: module TestHelper CONSTANT = "constant" end context "A context" do include TestHelper specify "should allow unqualified access to included constants" do CONSTANT.should_eql "constant" #fails end specify "should allow qualified access to all constants" do TestHelper::CONSTANT.should_eql "constant" # passes w/ fully qualified reference end end ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=7613&group_id=797 From noreply at rubyforge.org Thu Feb 8 00:21:41 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 8 Feb 2007 00:21:41 -0500 (EST) Subject: [rspec-devel] [ rspec-Feature Requests-7613 ] context#include should add constants into the context Message-ID: <20070208052141.31B10524271F@rubyforge.org> Feature Requests item #7613, was opened at 2007-01-06 01:25 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=7613&group_id=797 Category: None Group: None Status: Open Priority: 3 Submitted By: Brian Takita (btakita) Assigned to: Nobody (None) Summary: context#include should add constants into the context Initial Comment: dir = File.dirname(__FILE__) require "#{dir}/spec_helper" module Foo class Bar end end context "A Context include statement" do include Foo specify "should add constants accessable in the context" do b = Bar.new end end ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-02-08 05:21 Message: This gets even better: module Helpers CONSTANT = "constant" class Helper end end context "context#include" do include Helpers specify "should include qualified constants" do Helpers::CONSTANT.should == "constant" Helpers::Helper.new end specify "should include unqualified constants" do self.class.constants.should include("CONSTANT") CONSTANT.should == "constant" Helper.new end end The second spec bails on CONSTANT.should == "constant", but passes self.class.constants.should include("CONSTANT"). ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-02-08 04:11 Message: >From the ruby-talk list: module TestHelper CONSTANT = "constant" end context "A context" do include TestHelper specify "should allow unqualified access to included constants" do CONSTANT.should_eql "constant" #fails end specify "should allow qualified access to all constants" do TestHelper::CONSTANT.should_eql "constant" # passes w/ fully qualified reference end end ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=7613&group_id=797 From noreply at rubyforge.org Thu Feb 8 05:33:19 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 8 Feb 2007 05:33:19 -0500 (EST) Subject: [rspec-devel] [ rspec-Feature Requests-7613 ] context#include should add constants into the context Message-ID: <20070208103320.1B6205240A57@rubyforge.org> Feature Requests item #7613, was opened at 2007-01-05 20:25 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=7613&group_id=797 Category: None Group: None Status: Open Priority: 3 Submitted By: Brian Takita (btakita) Assigned to: Nobody (None) Summary: context#include should add constants into the context Initial Comment: dir = File.dirname(__FILE__) require "#{dir}/spec_helper" module Foo class Bar end end context "A Context include statement" do include Foo specify "should add constants accessable in the context" do b = Bar.new end end ---------------------------------------------------------------------- >Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-02-08 05:33 Message: Are we facing the challenge of reimplementing Ruby's class system here? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-02-08 00:21 Message: This gets even better: module Helpers CONSTANT = "constant" class Helper end end context "context#include" do include Helpers specify "should include qualified constants" do Helpers::CONSTANT.should == "constant" Helpers::Helper.new end specify "should include unqualified constants" do self.class.constants.should include("CONSTANT") CONSTANT.should == "constant" Helper.new end end The second spec bails on CONSTANT.should == "constant", but passes self.class.constants.should include("CONSTANT"). ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-02-07 23:11 Message: >From the ruby-talk list: module TestHelper CONSTANT = "constant" end context "A context" do include TestHelper specify "should allow unqualified access to included constants" do CONSTANT.should_eql "constant" #fails end specify "should allow qualified access to all constants" do TestHelper::CONSTANT.should_eql "constant" # passes w/ fully qualified reference end end ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=7613&group_id=797 From noreply at rubyforge.org Thu Feb 8 05:56:14 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 8 Feb 2007 05:56:14 -0500 (EST) Subject: [rspec-devel] [ rspec-Feature Requests-7613 ] context#include should add constants into the context Message-ID: <20070208105614.BBBF252409C3@rubyforge.org> Feature Requests item #7613, was opened at 2007-01-06 01:25 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=7613&group_id=797 Category: None Group: None Status: Open Priority: 3 Submitted By: Brian Takita (btakita) Assigned to: Nobody (None) Summary: context#include should add constants into the context Initial Comment: dir = File.dirname(__FILE__) require "#{dir}/spec_helper" module Foo class Bar end end context "A Context include statement" do include Foo specify "should add constants accessable in the context" do b = Bar.new end end ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-02-08 10:56 Message: Seems like it! FUN! ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-02-08 10:33 Message: Are we facing the challenge of reimplementing Ruby's class system here? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-02-08 05:21 Message: This gets even better: module Helpers CONSTANT = "constant" class Helper end end context "context#include" do include Helpers specify "should include qualified constants" do Helpers::CONSTANT.should == "constant" Helpers::Helper.new end specify "should include unqualified constants" do self.class.constants.should include("CONSTANT") CONSTANT.should == "constant" Helper.new end end The second spec bails on CONSTANT.should == "constant", but passes self.class.constants.should include("CONSTANT"). ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-02-08 04:11 Message: >From the ruby-talk list: module TestHelper CONSTANT = "constant" end context "A context" do include TestHelper specify "should allow unqualified access to included constants" do CONSTANT.should_eql "constant" #fails end specify "should allow qualified access to all constants" do TestHelper::CONSTANT.should_eql "constant" # passes w/ fully qualified reference end end ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=7613&group_id=797 From noreply at rubyforge.org Thu Feb 8 06:35:36 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 8 Feb 2007 06:35:36 -0500 (EST) Subject: [rspec-devel] [ rspec-Feature Requests-7613 ] context#include should add constants into the context Message-ID: <20070208113536.768F95240A5E@rubyforge.org> Feature Requests item #7613, was opened at 2007-01-06 01:25 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=7613&group_id=797 Category: None Group: None Status: Open Priority: 3 Submitted By: Brian Takita (btakita) Assigned to: Nobody (None) Summary: context#include should add constants into the context Initial Comment: dir = File.dirname(__FILE__) require "#{dir}/spec_helper" module Foo class Bar end end context "A Context include statement" do include Foo specify "should add constants accessable in the context" do b = Bar.new end end ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-02-08 11:35 Message: I've narrowed this down to our own use of instance_eval when running specs. Apparently Ruby doesn't allow access to instance constants from instance eval: irb(main):001:0> class Foo irb(main):002:1> BAR = "bar" irb(main):003:1> def get_bar irb(main):004:2> BAR irb(main):005:2> end irb(main):006:1> end => nil irb(main):007:0> foo = Foo.new => # irb(main):008:0> foo.instance_eval { "bar" } => "bar" irb(main):009:0> foo.instance_eval { get_bar } => "bar" irb(main):010:0> foo.instance_eval { BAR } NameError: uninitialized constant BAR from (irb):10 from (irb):10:in `instance_eval' from (irb):10 ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-02-08 10:56 Message: Seems like it! FUN! ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-02-08 10:33 Message: Are we facing the challenge of reimplementing Ruby's class system here? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-02-08 05:21 Message: This gets even better: module Helpers CONSTANT = "constant" class Helper end end context "context#include" do include Helpers specify "should include qualified constants" do Helpers::CONSTANT.should == "constant" Helpers::Helper.new end specify "should include unqualified constants" do self.class.constants.should include("CONSTANT") CONSTANT.should == "constant" Helper.new end end The second spec bails on CONSTANT.should == "constant", but passes self.class.constants.should include("CONSTANT"). ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-02-08 04:11 Message: >From the ruby-talk list: module TestHelper CONSTANT = "constant" end context "A context" do include TestHelper specify "should allow unqualified access to included constants" do CONSTANT.should_eql "constant" #fails end specify "should allow qualified access to all constants" do TestHelper::CONSTANT.should_eql "constant" # passes w/ fully qualified reference end end ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=7613&group_id=797 From noreply at rubyforge.org Thu Feb 8 07:55:16 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 8 Feb 2007 07:55:16 -0500 (EST) Subject: [rspec-devel] [ rspec-Feature Requests-7613 ] context#include should add constants into the context Message-ID: <20070208125517.010945242365@rubyforge.org> Feature Requests item #7613, was opened at 2007-01-06 01:25 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=7613&group_id=797 Category: None Group: None >Status: Closed Priority: 3 Submitted By: Brian Takita (btakita) Assigned to: Nobody (None) Summary: context#include should add constants into the context Initial Comment: dir = File.dirname(__FILE__) require "#{dir}/spec_helper" module Foo class Bar end end context "A Context include statement" do include Foo specify "should add constants accessable in the context" do b = Bar.new end end ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-02-08 12:55 Message: Following up, there doesn't appear to be a way to give a block passed to instance_eval access to the instance's class's constants. It seems that this is simply the state of things and not likely to change in Ruby. I think the real problem we overloaded a Ruby keyword (include) to give the feeling of doing something that Ruby does, but in fact doesn't work the way it would therefore be expected. We've had a couple of bugs that have come up as a result of this perception. I'm going to propose that we change the name to something that better describes the intent (in a separate RFE). In the mean time I'm closing this. To get this to work it would seem to require a complete re-implementation of the runner. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-02-08 11:35 Message: I've narrowed this down to our own use of instance_eval when running specs. Apparently Ruby doesn't allow access to instance constants from instance eval: irb(main):001:0> class Foo irb(main):002:1> BAR = "bar" irb(main):003:1> def get_bar irb(main):004:2> BAR irb(main):005:2> end irb(main):006:1> end => nil irb(main):007:0> foo = Foo.new => # irb(main):008:0> foo.instance_eval { "bar" } => "bar" irb(main):009:0> foo.instance_eval { get_bar } => "bar" irb(main):010:0> foo.instance_eval { BAR } NameError: uninitialized constant BAR from (irb):10 from (irb):10:in `instance_eval' from (irb):10 ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-02-08 10:56 Message: Seems like it! FUN! ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-02-08 10:33 Message: Are we facing the challenge of reimplementing Ruby's class system here? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-02-08 05:21 Message: This gets even better: module Helpers CONSTANT = "constant" class Helper end end context "context#include" do include Helpers specify "should include qualified constants" do Helpers::CONSTANT.should == "constant" Helpers::Helper.new end specify "should include unqualified constants" do self.class.constants.should include("CONSTANT") CONSTANT.should == "constant" Helper.new end end The second spec bails on CONSTANT.should == "constant", but passes self.class.constants.should include("CONSTANT"). ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-02-08 04:11 Message: >From the ruby-talk list: module TestHelper CONSTANT = "constant" end context "A context" do include TestHelper specify "should allow unqualified access to included constants" do CONSTANT.should_eql "constant" #fails end specify "should allow qualified access to all constants" do TestHelper::CONSTANT.should_eql "constant" # passes w/ fully qualified reference end end ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=7613&group_id=797 From noreply at rubyforge.org Thu Feb 8 08:20:03 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 8 Feb 2007 08:20:03 -0500 (EST) Subject: [rspec-devel] [ rspec-Feature Requests-8507 ] change #include to some other name Message-ID: <20070208132003.D6E205242522@rubyforge.org> Feature Requests item #8507, was opened at 2007-02-08 13:20 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=8507&group_id=797 Category: runner module Group: None Status: Open Priority: 3 Submitted By: David Chelimsky (dchelimsky) Assigned to: Nobody (None) Summary: change #include to some other name Initial Comment: RSpec supports inclusion of a module in a context: context "some context" do include SomeModule end The initial intent of this was to enable state sharing across contexts and/or introduce helper methods that might be used across contexts. Unfortunately, the use of the name "include" has led to some perception problems. It does NOT work exactly like Ruby's include does, but the name leads to the expectation that it should. I'd like to propose that we deprecate the name "include" and replace it with some other name like "include_methods_from" or something like that (suggestions please!!!), which indicates that methods from the module will be made available, but it should not otherwise be expected to behave as Module#include behaves. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=8507&group_id=797 From noreply at rubyforge.org Thu Feb 8 09:13:39 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 8 Feb 2007 09:13:39 -0500 (EST) Subject: [rspec-devel] [ rspec-Patches-8509 ] Enhance controller docs Message-ID: <20070208141339.EBF665242365@rubyforge.org> Patches item #8509, was opened at 2007-02-08 14:13 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=8509&group_id=797 Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: Jerry West (jjw) Assigned to: Nobody (None) Summary: Enhance controller docs Initial Comment: The controller spec docs assume some familiarity with Rails unit testing concepts . This assumption is increasingly in-appropriate as newcomers to Rails start with RSpec as their prefered development 'test' tool. An immediate request is to update the controller specs documentation to include something like this: Triggering controller actions Once the expectations have been established, the controller action must be invoked. Three helper routines are provided to emulate the HTTP GET and POST expected by the controller: get :action, [params] post :action, params xhr :get, :action, [params] xhr :post, :action, params The #xhr method emulates an AJAX (xml_http_request) call. 'params' is a hash to be placed in the params[] accessor in the controller (e.g. :id => 99, :name => 'fred', etc). The 'action' can be either a symbol or a string. ------- The example at the end might also be enhanced to illustrate usage. xhr :post, :update, :id => 3, :name => 'fred' ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=8509&group_id=797 From noreply at rubyforge.org Thu Feb 8 09:21:55 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 8 Feb 2007 09:21:55 -0500 (EST) Subject: [rspec-devel] [ rspec-Patches-8509 ] Enhance controller docs Message-ID: <20070208142155.D167E524252B@rubyforge.org> Patches item #8509, was opened at 2007-02-08 14:13 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=8509&group_id=797 Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: Jerry West (jjw) Assigned to: Nobody (None) Summary: Enhance controller docs Initial Comment: The controller spec docs assume some familiarity with Rails unit testing concepts . This assumption is increasingly in-appropriate as newcomers to Rails start with RSpec as their prefered development 'test' tool. An immediate request is to update the controller specs documentation to include something like this: Triggering controller actions Once the expectations have been established, the controller action must be invoked. Three helper routines are provided to emulate the HTTP GET and POST expected by the controller: get :action, [params] post :action, params xhr :get, :action, [params] xhr :post, :action, params The #xhr method emulates an AJAX (xml_http_request) call. 'params' is a hash to be placed in the params[] accessor in the controller (e.g. :id => 99, :name => 'fred', etc). The 'action' can be either a symbol or a string. ------- The example at the end might also be enhanced to illustrate usage. xhr :post, :update, :id => 3, :name => 'fred' ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-02-08 14:21 Message: Where's the patch? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=8509&group_id=797 From noreply at rubyforge.org Thu Feb 8 09:26:29 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 8 Feb 2007 09:26:29 -0500 (EST) Subject: [rspec-devel] [ rspec-Feature Requests-5485 ] proc#should_raise and proc#should_not_raise output Message-ID: <20070208142630.1034A5242535@rubyforge.org> Feature Requests item #5485, was opened at 2006-08-21 20:57 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=5485&group_id=797 Category: None Group: None Status: Open Priority: 3 Submitted By: Judson Lester (nyarly) Assigned to: Nobody (None) Summary: proc#should_raise and proc#should_not_raise output Initial Comment: Currently lamba do raise "Dumb example" end.should_not_raise outputs the backtrace of the Spec::Api::ExpectationNotMet exception. Which isn't very useful. It'd rock if instead it output the exception that was raised in the Proc that broke the expectation. Likewise, should_raise doesn't print the backtrace of wrong exceptions. More detail as I understand how to post them. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-02-08 14:26 Message: The simplest thing would be to simply re-raise ANY errors that are raised that don't match the expectation, but you would lose the "expected x, got y" information. We could document that this expectation behaves slightly differently from the rest. Would that be acceptable? ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-08-21 22:48 Message: I think I understand what you mean. A more illustrative and realistic example would be to have the spec invoke a method defined somewhere else - and have that method raise "Dumb example". And you want to see the stack trace of that exception so you can find the source. Makes sense! ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=5485&group_id=797 From noreply at rubyforge.org Thu Feb 8 09:29:54 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 8 Feb 2007 09:29:54 -0500 (EST) Subject: [rspec-devel] [ rspec-Patches-8509 ] Enhance controller docs Message-ID: <20070208142955.1BB055242534@rubyforge.org> Patches item #8509, was opened at 2007-02-08 14:13 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=8509&group_id=797 Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: Jerry West (jjw) Assigned to: Nobody (None) Summary: Enhance controller docs Initial Comment: The controller spec docs assume some familiarity with Rails unit testing concepts . This assumption is increasingly in-appropriate as newcomers to Rails start with RSpec as their prefered development 'test' tool. An immediate request is to update the controller specs documentation to include something like this: Triggering controller actions Once the expectations have been established, the controller action must be invoked. Three helper routines are provided to emulate the HTTP GET and POST expected by the controller: get :action, [params] post :action, params xhr :get, :action, [params] xhr :post, :action, params The #xhr method emulates an AJAX (xml_http_request) call. 'params' is a hash to be placed in the params[] accessor in the controller (e.g. :id => 99, :name => 'fred', etc). The 'action' can be either a symbol or a string. ------- The example at the end might also be enhanced to illustrate usage. xhr :post, :update, :id => 3, :name => 'fred' ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-02-08 14:29 Message: Jerry - you submitted the request to Patches, but I think you intended for us to make a change rather than you submitting a patch. If this is correct, this belongs over in the Documentation tracker. If so, please try to move it there. If you have any trouble, add a comment here and I'll move it. Cheers, David ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-02-08 14:21 Message: Where's the patch? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=8509&group_id=797 From noreply at rubyforge.org Thu Feb 8 09:41:57 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 8 Feb 2007 09:41:57 -0500 (EST) Subject: [rspec-devel] [ rspec-Patches-8509 ] Enhance controller docs Message-ID: <20070208144159.6A76952416B0@rubyforge.org> Patches item #8509, was opened at 2007-02-08 14:13 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=8509&group_id=797 Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: Jerry West (jjw) Assigned to: Nobody (None) Summary: Enhance controller docs Initial Comment: The controller spec docs assume some familiarity with Rails unit testing concepts . This assumption is increasingly in-appropriate as newcomers to Rails start with RSpec as their prefered development 'test' tool. An immediate request is to update the controller specs documentation to include something like this: Triggering controller actions Once the expectations have been established, the controller action must be invoked. Three helper routines are provided to emulate the HTTP GET and POST expected by the controller: get :action, [params] post :action, params xhr :get, :action, [params] xhr :post, :action, params The #xhr method emulates an AJAX (xml_http_request) call. 'params' is a hash to be placed in the params[] accessor in the controller (e.g. :id => 99, :name => 'fred', etc). The 'action' can be either a symbol or a string. ------- The example at the end might also be enhanced to illustrate usage. xhr :post, :update, :id => 3, :name => 'fred' ---------------------------------------------------------------------- >Comment By: Jerry West (jjw) Date: 2007-02-08 14:41 Message: Apologies. Where can I find the documentation tracker, please? My RubyForge Tracker tab only lists Bugs; Support Requests; Patches and Feature Requests. None of these have a documentation category so far as I can see. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-02-08 14:29 Message: Jerry - you submitted the request to Patches, but I think you intended for us to make a change rather than you submitting a patch. If this is correct, this belongs over in the Documentation tracker. If so, please try to move it there. If you have any trouble, add a comment here and I'll move it. Cheers, David ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-02-08 14:21 Message: Where's the patch? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=8509&group_id=797 From noreply at rubyforge.org Thu Feb 8 09:49:02 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 8 Feb 2007 09:49:02 -0500 (EST) Subject: [rspec-devel] [ rspec-Documentation-8509 ] Enhance controller docs Message-ID: <20070208144902.F10BA524251F@rubyforge.org> Documentation item #8509, was opened at 2007-02-08 14:13 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=9738&aid=8509&group_id=797 >Category: None Group: None Status: Open Priority: 3 Submitted By: Jerry West (jjw) Assigned to: Nobody (None) Summary: Enhance controller docs Initial Comment: The controller spec docs assume some familiarity with Rails unit testing concepts . This assumption is increasingly in-appropriate as newcomers to Rails start with RSpec as their prefered development 'test' tool. An immediate request is to update the controller specs documentation to include something like this: Triggering controller actions Once the expectations have been established, the controller action must be invoked. Three helper routines are provided to emulate the HTTP GET and POST expected by the controller: get :action, [params] post :action, params xhr :get, :action, [params] xhr :post, :action, params The #xhr method emulates an AJAX (xml_http_request) call. 'params' is a hash to be placed in the params[] accessor in the controller (e.g. :id => 99, :name => 'fred', etc). The 'action' can be either a symbol or a string. ------- The example at the end might also be enhanced to illustrate usage. xhr :post, :update, :id => 3, :name => 'fred' ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-02-08 14:49 Message: Lame, lame, lame. For whatever reason, if you're logged when you view http://rubyforge.org/tracker/?group_id=797, you see a Documentation tracker. If you're not, you don't. I'll go ahead and move it myself. Please email the list if you are unable to view this item now that it's moved. ---------------------------------------------------------------------- Comment By: Jerry West (jjw) Date: 2007-02-08 14:41 Message: Apologies. Where can I find the documentation tracker, please? My RubyForge Tracker tab only lists Bugs; Support Requests; Patches and Feature Requests. None of these have a documentation category so far as I can see. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-02-08 14:29 Message: Jerry - you submitted the request to Patches, but I think you intended for us to make a change rather than you submitting a patch. If this is correct, this belongs over in the Documentation tracker. If so, please try to move it there. If you have any trouble, add a comment here and I'll move it. Cheers, David ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-02-08 14:21 Message: Where's the patch? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=9738&aid=8509&group_id=797 From noreply at rubyforge.org Thu Feb 8 10:16:07 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 8 Feb 2007 10:16:07 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-8371 ] Mocking complaining about wrong number of arguments (odd) Message-ID: <20070208151607.776905242446@rubyforge.org> Bugs item #8371, was opened at 2007-02-01 20:27 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=8371&group_id=797 Category: mock module Group: None >Status: Closed >Resolution: Rejected Priority: 3 Submitted By: Rodrigo Kochenburger (divoxx) Assigned to: Nobody (None) Summary: Mocking complaining about wrong number of arguments (odd) Initial Comment: In this code http://pastie.caboo.se/37274 i'm trying to mock a model method while testing a controller. (Line 12) The error being raised is also pasted in there. If i comment that line out and actually call the create method, the model raises the exception and everything works just fine... I've already tried using .with(:any_args) ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-02-08 15:16 Message: When you call this: Person.should_receive(:create).and_raise(ActiveRecord::RecordInvalid) the mock tries to create an instance of ActiveRecord::RecordInvalid) by calling #new. As it turns out, ActiveRecord::RecordInvalid.new requires that an ActiveRecord model instance gets passed in, which is not supported by RSpec. The docs indicate that you can supply an instantiated exception or a class. I'll update the docs to say that if supply the class that it must be able to be initialized with no args. So you need to change your spec so that you pass in an instance of ActiveRecord::RecordInvalid, not just the class name. Beware that the initializer of ActiveRecord::RecordInvalid looks like this: def initialize(record) @record = record super("Validation failed: #{@record.errors.full_messages.join(", ")}") end So you have to supply a chain of stubs to satisfy the chain of calls: model = mock("model") errors = mock("errors") model.stub!(:errors).and_return(errors) errors.stub!(:full_messages).and_return([]) Person.should_receive(:create).and_raise(ActiveRecord::RecordInvalid.new(model)) This is one of those tradeoffs that you have to deal with in rails. It violates OO principles (Law of Demeter in this case) in order to provide you w/ something that's really easy to *use*, but makes it really difficult to *test* in the process. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-02-01 21:37 Message: RSpec version? Rails version? Also - try running the specs w/ the -b argument so you can get a more thorough backtrace. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=8371&group_id=797 From noreply at rubyforge.org Thu Feb 8 10:23:06 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 8 Feb 2007 10:23:06 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-7636 ] drbspec not managing db connections appropriately Message-ID: <20070208152306.A0A50524253E@rubyforge.org> Bugs item #7636, was opened at 2007-01-07 00:17 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=7636&group_id=797 Category: runner module Group: None Status: Open Resolution: None Priority: 3 Submitted By: Chris Anderson (jchris) Assigned to: Nobody (None) Summary: drbspec not managing db connections appropriately Initial Comment: I'm using the rails_spec_server and drbspec spec/ - the lastest versions (gem 0.7.6) - just generated from trunk yesterday. Running drbspec spec/ works as expected for about 30 runs, and then I start getting too many client errors from Postgres (gem 0.7.1). The same thing happens with the spec:autotest plugin - but it is just running drbspec repeatedly, as well. PGError in 'Given a generated source_report_spec.rb with fixtures loaded fixtures should load two SourceReports' FATAL: sorry, too many clients already script/rails_spec_server:16:in `run' script/rails_spec_server:37: I don't know if this is a specific to Postgres, but I do know I've never seen Postgres raise a too many clients error before in all my Rails work. Let me know if I can help with more information. jchris :: mfdz : com ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-02-08 15: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 09: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-07 01:05 Message: Have you had a similar experience just running 'rake spec'? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=7636&group_id=797 From noreply at rubyforge.org Thu Feb 8 10:25:15 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 8 Feb 2007 10:25:15 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-7344 ] Failing spec in HTML formatter Message-ID: <20070208152515.EE6E9524253E@rubyforge.org> Bugs item #7344, was opened at 2006-12-18 18:33 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=7344&group_id=797 Category: runner module Group: None >Status: Closed >Resolution: Accepted Priority: 2 Submitted By: Bob Cotton (bcotton) >Assigned to: David Chelimsky (dchelimsky) Summary: Failing spec in HTML formatter Initial Comment: This is revision 1322 ruby -v ruby 1.8.5 (2006-08-25) [powerpc-darwin8.8.0] (build with all gcc optimizations off, ruby crashes on gem installs otherwise) 1) 'HtmlFormatter should produce HTML identical to the one we designed manually' FAILED [...HTML DELETED...] Diff: @@ -119,9 +119,7 @@ 
Mock 'poke me' expected :poke with (any args) once, but received it 0 times
./failing_examples/mocking_example.rb:13:
 ./spec/spec/runner/formatter/html_formatter_spec.rb:16:
-./spec/spec/runner/formatter/html_formatter_spec.rb:12:in `chdir'
 ./spec/spec/runner/formatter/html_formatter_spec.rb:12:
-./spec/spec/runner/formatter/html_formatter_spec.rb:11:in `each'
 ./spec/spec/runner/formatter/html_formatter_spec.rb:11:
@@ -135,9 +133,7 @@ 
(eval):3:in `three'
 ./failing_examples/mocking_example.rb:22:
 ./spec/spec/runner/formatter/html_formatter_spec.rb:16:
-./spec/spec/runner/formatter/html_formatter_spec.rb:12:in `chdir'
 ./spec/spec/runner/formatter/html_formatter_spec.rb:12:
-./spec/spec/runner/formatter/html_formatter_spec.rb:11:in `each'
 ./spec/spec/runner/formatter/html_formatter_spec.rb:11:
@@ -150,9 +146,7 @@ 
Mock 'don't talk to me' expected :any_message_at_all with (any args) 0 times, but received it once
./failing_examples/mocking_example.rb:28:
 ./spec/spec/runner/formatter/html_formatter_spec.rb:16:
-./spec/spec/runner/formatter/html_formatter_spec.rb:12:in `chdir'
 ./spec/spec/runner/formatter/html_formatter_spec.rb:12:
-./spec/spec/runner/formatter/html_formatter_spec.rb:11:in `each'
 ./spec/spec/runner/formatter/html_formatter_spec.rb:11:
@@ -177,9 +171,7 @@ 
./failing_examples/diffing_spec.rb:13:
 ./spec/spec/runner/formatter/html_formatter_spec.rb:16:
-./spec/spec/runner/formatter/html_formatter_spec.rb:12:in `chdir'
 ./spec/spec/runner/formatter/html_formatter_spec.rb:12:
-./spec/spec/runner/formatter/html_formatter_spec.rb:11:in `each'
 ./spec/spec/runner/formatter/html_formatter_spec.rb:11:
@@ -208,9 +200,7 @@ 
./failing_examples/diffing_spec.rb:34:
 ./spec/spec/runner/formatter/html_formatter_spec.rb:16:
-./spec/spec/runner/formatter/html_formatter_spec.rb:12:in `chdir'
 ./spec/spec/runner/formatter/html_formatter_spec.rb:12:
-./spec/spec/runner/formatter/html_formatter_spec.rb:11:in `each'
 ./spec/spec/runner/formatter/html_formatter_spec.rb:11:
/Users/bcotton/projects/rspec/lib/spec/expectations.rb:20:in `fail_with' /Users/bcotton/projects/rspec/lib/spec/expectations/should/base.rb:35:in `fail_with_message' /Users/bcotton/projects/rspec/lib/spec/expectations/should/should.rb:49:in `__delegate_method_missing_to_target' /Users/bcotton/projects/rspec/lib/spec/expectations/should/base.rb:15:in `==' ./spec/spec/runner/formatter/html_formatter_spec.rb:31: ./spec/spec/runner/formatter/html_formatter_spec.rb:12:in `chdir' ./spec/spec/runner/formatter/html_formatter_spec.rb:12: ./spec/spec/runner/formatter/html_formatter_spec.rb:11:in `each' ./spec/spec/runner/formatter/html_formatter_spec.rb:11: /Users/bcotton/projects/rspec/lib/spec/runner/specification.rb:55:in `instance_eval' /Users/bcotton/projects/rspec/lib/spec/runner/specification.rb:55:in `execute_spec' /Users/bcotton/projects/rspec/lib/spec/runner/specification.rb:30:in `run' /Users/bcotton/projects/rspec/lib/spec/runner/context.rb:57:in `run' /Users/bcotton/projects/rspec/lib/spec/runner/context.rb:54:in `each' /Users/bcotton/projects/rspec/lib/spec/runner/context.rb:54:in `run' /Users/bcotton/projects/rspec/lib/spec/runner/context_runner.rb:23:in `run' /Users/bcotton/projects/rspec/lib/spec/runner/context_runner.rb:22:in `each' /Users/bcotton/projects/rspec/lib/spec/runner/context_runner.rb:22:in `run' /Users/bcotton/projects/rspec/lib/spec/runner/command_line.rb:26:in `run' /Users/bcotton/projects/rspec/bin/spec:4: /usr/local/lib/ruby/gems/1.8/gems/rcov-0.7.0.1/bin/rcov:493:in `load' /usr/local/lib/ruby/gems/1.8/gems/rcov-0.7.0.1/bin/rcov:493: /usr/local/bin/rcov:18:in `load' /usr/local/bin/rcov:18: Finished in 5.943487 seconds 497 specifications, 1 failure ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-02-08 15:25 Message: Fixed in trunk rev 1478 Added html_formatted_1.8.4.html and html_formatted_1.8.5.html and updated the spec to use the correct one per Aslak's suggestion. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-02-07 11:52 Message: html_formatted_1.8.4.html, html_formatted_1.8.5.html etc. The spec will compare against one of them depending on Ruby's version (VERSION) ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-02-07 11:40 Message: We need a solution that supports 1.8.4 and 1.8.5. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-12-18 18:46 Message: I cannot reproduce this on Ruby 1.8.4. Looks like Ruby 1.8.5 (which I don't have yet) is adding more backtrace info. You can just ignore this. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=7344&group_id=797 From noreply at rubyforge.org Thu Feb 8 10:36:29 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 8 Feb 2007 10:36:29 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-8371 ] Mocking complaining about wrong number of arguments (odd) Message-ID: <20070208153629.BF6C05242496@rubyforge.org> Bugs item #8371, was opened at 2007-02-01 18:27 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=8371&group_id=797 Category: mock module Group: None Status: Closed Resolution: Rejected Priority: 3 Submitted By: Rodrigo Kochenburger (divoxx) Assigned to: Nobody (None) Summary: Mocking complaining about wrong number of arguments (odd) Initial Comment: In this code http://pastie.caboo.se/37274 i'm trying to mock a model method while testing a controller. (Line 12) The error being raised is also pasted in there. If i comment that line out and actually call the create method, the model raises the exception and everything works just fine... I've already tried using .with(:any_args) ---------------------------------------------------------------------- >Comment By: Rodrigo Kochenburger (divoxx) Date: 2007-02-08 13:36 Message: Thanks David. I've already fixed that but i forgot to close this ticket, though. :) Sorry about you wasting your time investigating it. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-02-08 13:16 Message: When you call this: Person.should_receive(:create).and_raise(ActiveRecord::RecordInvalid) the mock tries to create an instance of ActiveRecord::RecordInvalid) by calling #new. As it turns out, ActiveRecord::RecordInvalid.new requires that an ActiveRecord model instance gets passed in, which is not supported by RSpec. The docs indicate that you can supply an instantiated exception or a class. I'll update the docs to say that if supply the class that it must be able to be initialized with no args. So you need to change your spec so that you pass in an instance of ActiveRecord::RecordInvalid, not just the class name. Beware that the initializer of ActiveRecord::RecordInvalid looks like this: def initialize(record) @record = record super("Validation failed: #{@record.errors.full_messages.join(", ")}") end So you have to supply a chain of stubs to satisfy the chain of calls: model = mock("model") errors = mock("errors") model.stub!(:errors).and_return(errors) errors.stub!(:full_messages).and_return([]) Person.should_receive(:create).and_raise(ActiveRecord::RecordInvalid.new(model)) This is one of those tradeoffs that you have to deal with in rails. It violates OO principles (Law of Demeter in this case) in order to provide you w/ something that's really easy to *use*, but makes it really difficult to *test* in the process. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-02-01 19:37 Message: RSpec version? Rails version? Also - try running the specs w/ the -b argument so you can get a more thorough backtrace. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=8371&group_id=797 From noreply at rubyforge.org Thu Feb 8 10:39:24 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 8 Feb 2007 10:39:24 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-8371 ] Mocking complaining about wrong number of arguments (odd) Message-ID: <20070208153924.E2A8752424C0@rubyforge.org> Bugs item #8371, was opened at 2007-02-01 20:27 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=8371&group_id=797 Category: mock module Group: None Status: Closed Resolution: Rejected Priority: 3 Submitted By: Rodrigo Kochenburger (divoxx) Assigned to: Nobody (None) Summary: Mocking complaining about wrong number of arguments (odd) Initial Comment: In this code http://pastie.caboo.se/37274 i'm trying to mock a model method while testing a controller. (Line 12) The error being raised is also pasted in there. If i comment that line out and actually call the create method, the model raises the exception and everything works just fine... I've already tried using .with(:any_args) ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-02-08 15:39 Message: No worries. I learned something in the process. Cheers, David ---------------------------------------------------------------------- Comment By: Rodrigo Kochenburger (divoxx) Date: 2007-02-08 15:36 Message: Thanks David. I've already fixed that but i forgot to close this ticket, though. :) Sorry about you wasting your time investigating it. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-02-08 15:16 Message: When you call this: Person.should_receive(:create).and_raise(ActiveRecord::RecordInvalid) the mock tries to create an instance of ActiveRecord::RecordInvalid) by calling #new. As it turns out, ActiveRecord::RecordInvalid.new requires that an ActiveRecord model instance gets passed in, which is not supported by RSpec. The docs indicate that you can supply an instantiated exception or a class. I'll update the docs to say that if supply the class that it must be able to be initialized with no args. So you need to change your spec so that you pass in an instance of ActiveRecord::RecordInvalid, not just the class name. Beware that the initializer of ActiveRecord::RecordInvalid looks like this: def initialize(record) @record = record super("Validation failed: #{@record.errors.full_messages.join(", ")}") end So you have to supply a chain of stubs to satisfy the chain of calls: model = mock("model") errors = mock("errors") model.stub!(:errors).and_return(errors) errors.stub!(:full_messages).and_return([]) Person.should_receive(:create).and_raise(ActiveRecord::RecordInvalid.new(model)) This is one of those tradeoffs that you have to deal with in rails. It violates OO principles (Law of Demeter in this case) in order to provide you w/ something that's really easy to *use*, but makes it really difficult to *test* in the process. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-02-01 21:37 Message: RSpec version? Rails version? Also - try running the specs w/ the -b argument so you can get a more thorough backtrace. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=8371&group_id=797 From noreply at rubyforge.org Thu Feb 8 12:00:58 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 8 Feb 2007 12:00:58 -0500 (EST) Subject: [rspec-devel] [ rspec-Feature Requests-8507 ] change #include to some other name Message-ID: <20070208170058.1CBDD5242549@rubyforge.org> Feature Requests item #8507, was opened at 2007-02-08 05:20 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=8507&group_id=797 Category: runner module Group: None Status: Open Priority: 3 Submitted By: David Chelimsky (dchelimsky) Assigned to: Nobody (None) Summary: change #include to some other name Initial Comment: RSpec supports inclusion of a module in a context: context "some context" do include SomeModule end The initial intent of this was to enable state sharing across contexts and/or introduce helper methods that might be used across contexts. Unfortunately, the use of the name "include" has led to some perception problems. It does NOT work exactly like Ruby's include does, but the name leads to the expectation that it should. I'd like to propose that we deprecate the name "include" and replace it with some other name like "include_methods_from" or something like that (suggestions please!!!), which indicates that methods from the module will be made available, but it should not otherwise be expected to behave as Module#include behaves. ---------------------------------------------------------------------- Comment By: Ian Dees (undees) Date: 2007-02-08 09:00 Message: Hmmmm.... a few ideas: * Most of the RSpec examples use names like MyContextHelper. So how about "helper" or some permutation? * The context is using methods from the module -- maybe "use", "uses", "using", etc.? * I like your "include_methods_from" because it's nice and specific, but could we use a shorter variation, like "methods_from"? * Is there any way to salvage the old "include" method, but make it act more like the Ruby one? Maybe with clever usage of const_get (which _does_ work inside instance_eval)? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=8507&group_id=797 From noreply at rubyforge.org Thu Feb 8 12:43:54 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 8 Feb 2007 12:43:54 -0500 (EST) Subject: [rspec-devel] [ rspec-Feature Requests-8507 ] change #include to some other name Message-ID: <20070208174354.10B9B524235A@rubyforge.org> Feature Requests item #8507, was opened at 2007-02-08 13:20 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=8507&group_id=797 Category: runner module Group: None Status: Open Priority: 3 Submitted By: David Chelimsky (dchelimsky) Assigned to: Nobody (None) Summary: change #include to some other name Initial Comment: RSpec supports inclusion of a module in a context: context "some context" do include SomeModule end The initial intent of this was to enable state sharing across contexts and/or introduce helper methods that might be used across contexts. Unfortunately, the use of the name "include" has led to some perception problems. It does NOT work exactly like Ruby's include does, but the name leads to the expectation that it should. I'd like to propose that we deprecate the name "include" and replace it with some other name like "include_methods_from" or something like that (suggestions please!!!), which indicates that methods from the module will be made available, but it should not otherwise be expected to behave as Module#include behaves. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-02-08 17:43 Message: Ian - thanks for responding. As for keeping #include, that's possible, and might be the right course. This is really a starting point for a discussion. My concern is not a specific bug (constants), but rather that there is an expectation that it operate exactly like Module#include. Right now we see the problem with constants, but what else we see later? Also, re: constants - I've been banging my head against a wall with it, and really don't see a way to make it work, even using const_get/set. But, my meta-fu is, well, let's say "still evolving". So if you (or anyone) has a patch to make it work, have at it!!!! Cheers, David ---------------------------------------------------------------------- Comment By: Ian Dees (undees) Date: 2007-02-08 17:00 Message: Hmmmm.... a few ideas: * Most of the RSpec examples use names like MyContextHelper. So how about "helper" or some permutation? * The context is using methods from the module -- maybe "use", "uses", "using", etc.? * I like your "include_methods_from" because it's nice and specific, but could we use a shorter variation, like "methods_from"? * Is there any way to salvage the old "include" method, but make it act more like the Ruby one? Maybe with clever usage of const_get (which _does_ work inside instance_eval)? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=8507&group_id=797 From noreply at rubyforge.org Thu Feb 8 13:24:08 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 8 Feb 2007 13:24:08 -0500 (EST) Subject: [rspec-devel] [ rspec-Feature Requests-8509 ] Enhance controller docs Message-ID: <20070208182408.92A77524252A@rubyforge.org> Feature Requests item #8509, was opened at 2007-02-08 14:13 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=8509&group_id=797 Category: None Group: None Status: Open Priority: 3 Submitted By: Jerry West (jjw) Assigned to: Nobody (None) Summary: Enhance controller docs Initial Comment: The controller spec docs assume some familiarity with Rails unit testing concepts . This assumption is increasingly in-appropriate as newcomers to Rails start with RSpec as their prefered development 'test' tool. An immediate request is to update the controller specs documentation to include something like this: Triggering controller actions Once the expectations have been established, the controller action must be invoked. Three helper routines are provided to emulate the HTTP GET and POST expected by the controller: get :action, [params] post :action, params xhr :get, :action, [params] xhr :post, :action, params The #xhr method emulates an AJAX (xml_http_request) call. 'params' is a hash to be placed in the params[] accessor in the controller (e.g. :id => 99, :name => 'fred', etc). The 'action' can be either a symbol or a string. ------- The example at the end might also be enhanced to illustrate usage. xhr :post, :update, :id => 3, :name => 'fred' ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-02-08 18:24 Message: When I created the Documentation tracker it looks like it got created as "not publicly available". Furthermore it seems that there is a bug already submitted to Rubyforge that you can't set it to public once it is set private. http://rubyforge.org/tracker/index.php?func=detail&aid=8406&group_id=5&atid=101 So, until that bug is resolved, I'm going to move this request over to Feature Requests and we'll use that for the time being for documentation-related requests. Cheers, David ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-02-08 14:49 Message: Lame, lame, lame. For whatever reason, if you're logged when you view http://rubyforge.org/tracker/?group_id=797, you see a Documentation tracker. If you're not, you don't. I'll go ahead and move it myself. Please email the list if you are unable to view this item now that it's moved. ---------------------------------------------------------------------- Comment By: Jerry West (jjw) Date: 2007-02-08 14:41 Message: Apologies. Where can I find the documentation tracker, please? My RubyForge Tracker tab only lists Bugs; Support Requests; Patches and Feature Requests. None of these have a documentation category so far as I can see. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-02-08 14:29 Message: Jerry - you submitted the request to Patches, but I think you intended for us to make a change rather than you submitting a patch. If this is correct, this belongs over in the Documentation tracker. If so, please try to move it there. If you have any trouble, add a comment here and I'll move it. Cheers, David ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-02-08 14:21 Message: Where's the patch? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=8509&group_id=797 From noreply at rubyforge.org Fri Feb 9 09:23:57 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 9 Feb 2007 09:23:57 -0500 (EST) Subject: [rspec-devel] [ rspec-Feature Requests-6178 ] should_return Message-ID: <20070209142357.B9E5C52423F4@rubyforge.org> Feature Requests item #6178, was opened at 2006-10-16 11:18 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6178&group_id=797 Category: None Group: None >Status: Closed Priority: 3 Submitted By: David Chelimsky (dchelimsky) Assigned to: David Chelimsky (dchelimsky) Summary: should_return Initial Comment: I'd like to add should_return as an alias for should_equal for lambdas: lambda { expression }.should_return value reads more intuitively than lambda { expression }.should_equal value ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-02-09 14:23 Message: Withdrawing this. Why would you even want to wrap expectations up in a block when you could just set them directly. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-01-31 00:04 Message: And now it should probably be... lambda { expression }.should return_value(value) Or maybe we should just kill the idea? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-08 22:46 Message: Yes. This was initially submitted a while back. So... lambda { expression }.should_return value reads more intuitively than lambda { expression }.should_eql value or lambda { expression }.should == value ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-08 22:37 Message: I think you mean an alias for should_eql or should == ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6178&group_id=797 From noreply at rubyforge.org Fri Feb 9 11:08:49 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 9 Feb 2007 11:08:49 -0500 (EST) Subject: [rspec-devel] [ rspec-Feature Requests-5485 ] proc#should_raise and proc#should_not_raise output Message-ID: <20070209160849.99C5D5242409@rubyforge.org> Feature Requests item #5485, was opened at 2006-08-21 20:57 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=5485&group_id=797 Category: None Group: None >Status: Closed Priority: 3 Submitted By: Judson Lester (nyarly) Assigned to: Nobody (None) Summary: proc#should_raise and proc#should_not_raise output Initial Comment: Currently lamba do raise "Dumb example" end.should_not_raise outputs the backtrace of the Spec::Api::ExpectationNotMet exception. Which isn't very useful. It'd rock if instead it output the exception that was raised in the Proc that broke the expectation. Likewise, should_raise doesn't print the backtrace of wrong exceptions. More detail as I understand how to post them. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-02-09 16:08 Message: Trunk rev 1482 I went ahead and set it up to re-raise any errors that don't match the expectation. So now if you say "should_raise" and it doesn't, you'll get a typical message like "expected Error but nothing was raised". However, any time an error is caught that doesn't match the expectation it will be re-raised. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-02-08 14:26 Message: The simplest thing would be to simply re-raise ANY errors that are raised that don't match the expectation, but you would lose the "expected x, got y" information. We could document that this expectation behaves slightly differently from the rest. Would that be acceptable? ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-08-21 22:48 Message: I think I understand what you mean. A more illustrative and realistic example would be to have the spec invoke a method defined somewhere else - and have that method raise "Dumb example". And you want to see the stack trace of that exception so you can find the source. Makes sense! ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=5485&group_id=797 From hughes.james at gmail.com Fri Feb 9 18:05:57 2007 From: hughes.james at gmail.com (James Hughes) Date: Fri, 9 Feb 2007 15:05:57 -0800 Subject: [rspec-devel] Will it be "response.should_have" or "response.body.should_have"? Message-ID: <765a2c230702091505x1531084avbf3d0c148c3fe47d@mail.gmail.com> Hi all, I know the assert_select functionality is not a stable part of the api yet, but was just wondering where this will end up? I ask because the little bit I've seen this mentioned on the list, people seem to be using the first option (response.should_have "div.header"), but I had to use the second option to get things to work (response.body.should_have "div.header"). Thanks, James From hughes.james at gmail.com Fri Feb 9 18:35:39 2007 From: hughes.james at gmail.com (James Hughes) Date: Fri, 9 Feb 2007 15:35:39 -0800 Subject: [rspec-devel] Will it be "response.should_have" or "response.body.should_have"?..never mind Message-ID: <765a2c230702091535w7c32fc87n6730a32a5dc7735d@mail.gmail.com> Sorry. I had some misplaced quotes in my html which were causing "response.should_have" to die with some incomprehensible error messages: "expected > (got "" for
"list_table'>"})" (huh?) So then I got all excited when everything passed with response.body.should_have, but I see now that by calling should_have on body I wasn't calling the should_have method I should have. jh On 2/9/07, James Hughes wrote: > Hi all, > > I know the assert_select functionality is not a stable part of the api > yet, but was just wondering where this will end up? I ask because the > little bit I've seen this mentioned on the list, people seem to be > using the first option (response.should_have "div.header"), but I had > to use the second option to get things to work > (response.body.should_have "div.header"). > > Thanks, > > James > From dchelimsky at gmail.com Fri Feb 9 22:05:01 2007 From: dchelimsky at gmail.com (David Chelimsky) Date: Fri, 9 Feb 2007 21:05:01 -0600 Subject: [rspec-devel] Will it be "response.should_have" or "response.body.should_have"? In-Reply-To: <765a2c230702091505x1531084avbf3d0c148c3fe47d@mail.gmail.com> References: <765a2c230702091505x1531084avbf3d0c148c3fe47d@mail.gmail.com> Message-ID: <57c63afe0702091905n32b9155j579646068b79fdb5@mail.gmail.com> The next release (coming soon) will do everything assert_select does but with rspec syntax. Take a look at this: http://blog.davidchelimsky.net/articles/2007/01/20/view-specs-are-about-to-get-a-whole-lot-easier Cheers, David On 2/9/07, James Hughes wrote: > Hi all, > > I know the assert_select functionality is not a stable part of the api > yet, but was just wondering where this will end up? I ask because the > little bit I've seen this mentioned on the list, people seem to be > using the first option (response.should_have "div.header"), but I had > to use the second option to get things to work > (response.body.should_have "div.header"). > > Thanks, > > James > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From noreply at rubyforge.org Sun Feb 11 11:14:20 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 11 Feb 2007 11:14:20 -0500 (EST) Subject: [rspec-devel] [ rspec-Documentation-8572 ] Old Google result Message-ID: <20070211161420.F35055241AA4@rubyforge.org> Documentation item #8572, was opened at 2007-02-11 11:14 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=9738&aid=8572&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Aslak Helles?y (aslak_hellesoy) Assigned to: Nobody (None) Summary: Old Google result Initial Comment: Thanks for the heads up Richard We need to make sure that before a new website is uploaded - the old one is entirely deleted. Google will automatically remove hits for dead pages. On 2/11/07, Richard Musiol wrote: > Hi, > > > > I just want to mention that when using Google to search for "RSpec" the second result is > > http://rspec.rubyforge.org/tools/rails.html > > This page seems to be outdated, so maybe a redirection would be nice to avoid confusion. > > > > Thx and Bye > > Richard > ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=9738&aid=8572&group_id=797 From hughes.james at gmail.com Tue Feb 13 17:30:22 2007 From: hughes.james at gmail.com (James Hughes) Date: Tue, 13 Feb 2007 14:30:22 -0800 Subject: [rspec-devel] Will it be "response.should_have" or "response.body.should_have"? In-Reply-To: <57c63afe0702091905n32b9155j579646068b79fdb5@mail.gmail.com> References: <765a2c230702091505x1531084avbf3d0c148c3fe47d@mail.gmail.com> <57c63afe0702091905n32b9155j579646068b79fdb5@mail.gmail.com> Message-ID: <765a2c230702131430p2d7d9b95h12c53176f077a719@mail.gmail.com> On 2/9/07, David Chelimsky wrote: > The next release (coming soon) will do everything assert_select does > but with rspec syntax. Take a look at this: > > >http://blog.davidchelimsky.net/articles/2007/01/20/view-specs-are-about-to-get-a-whole-lot-easier > Thanks, David. assert_select supports using substitution values in selectors, eg.: assert_select "ol>li#?", /item-\d+/ Is there a way to do this with should have_tag? James From noreply at rubyforge.org Tue Feb 13 17:49:00 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 13 Feb 2007 17:49:00 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-8646 ] Context Runner does not report on Non standard exceptions and return a 0 return code Message-ID: <20070213224900.37FF1524208E@rubyforge.org> Bugs item #8646, was opened at 2007-02-13 14:48 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=8646&group_id=797 Category: runner module Group: None Status: Open Resolution: None Priority: 3 Submitted By: Brian Takita (btakita) Assigned to: Nobody (None) Summary: Context Runner does not report on Non standard exceptions and return a 0 return code Initial Comment: This is a major bug. This spec demonstrats the problem. context "A Context Runner receiving an Exception" do specify "should report on it and return a 0 return code" do raise Exception end end ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=8646&group_id=797 From dchelimsky at gmail.com Tue Feb 13 19:34:06 2007 From: dchelimsky at gmail.com (David Chelimsky) Date: Tue, 13 Feb 2007 17:34:06 -0700 Subject: [rspec-devel] Will it be "response.should_have" or "response.body.should_have"? In-Reply-To: <765a2c230702131430p2d7d9b95h12c53176f077a719@mail.gmail.com> References: <765a2c230702091505x1531084avbf3d0c148c3fe47d@mail.gmail.com> <57c63afe0702091905n32b9155j579646068b79fdb5@mail.gmail.com> <765a2c230702131430p2d7d9b95h12c53176f077a719@mail.gmail.com> Message-ID: <57c63afe0702131634r78787095t4b7f414b34e8223a@mail.gmail.com> On 2/13/07, James Hughes wrote: > On 2/9/07, David Chelimsky wrote: > > The next release (coming soon) will do everything assert_select does > > but with rspec syntax. Take a look at this: > > > > >http://blog.davidchelimsky.net/articles/2007/01/20/view-specs-are-about-to-get-a-whole-lot-easier > > > > Thanks, David. assert_select supports using substitution values in > selectors, eg.: > > assert_select "ol>li#?", /item-\d+/ > > Is there a way to do this with should have_tag? response.should have_tag("ol>li#?", /item-\d+/) It's really just a wrapper of everything in assert_select w/ some more rspec-ish syntax. This includes assert_select_rjs (should have_rjs) and assert_select_email (should be_email). Cheers, David > > James > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From noreply at rubyforge.org Wed Feb 14 00:20:09 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 14 Feb 2007 00:20:09 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-8646 ] Context Runner does not report on Non standard exceptions and return a 0 return code Message-ID: <20070214052010.08C5A52420B1@rubyforge.org> Bugs item #8646, was opened at 2007-02-13 22:48 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=8646&group_id=797 Category: runner module Group: None Status: Open Resolution: None Priority: 3 Submitted By: Brian Takita (btakita) Assigned to: Nobody (None) Summary: Context Runner does not report on Non standard exceptions and return a 0 return code Initial Comment: This is a major bug. This spec demonstrats the problem. context "A Context Runner receiving an Exception" do specify "should report on it and return a 0 return code" do raise Exception end end ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-02-14 05:20 Message: This seems to be how Ruby behaves: irb(main):001:0> def trap(&block) irb(main):002:1> block.call irb(main):003:1> rescue => e irb(main):004:1> puts e irb(main):005:1> end => nil irb(main):006:0> trap { raise "some error" } some error => nil irb(main):007:0> trap { raise RuntimeError.new } RuntimeError => nil irb(main):008:0> trap { raise Exception.new } (irb):8:in `irb_binding': Exception (Exception) from (irb):2:in `call' from (irb):2:in `trap' from (irb):8:in `irb_binding' from /usr/local/lib/ruby/1.8/irb/workspace.rb:52:in `irb_binding' from /usr/local/lib/ruby/1.8/irb/workspace.rb:52 Not sure what we could do about it. Any ideas? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=8646&group_id=797 From noreply at rubyforge.org Wed Feb 14 00:22:17 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 14 Feb 2007 00:22:17 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-8646 ] Context Runner does not report on Non standard exceptions and return a 0 return code Message-ID: <20070214052217.DC83452420AF@rubyforge.org> Bugs item #8646, was opened at 2007-02-13 22:48 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=8646&group_id=797 Category: runner module Group: None Status: Open Resolution: None Priority: 3 Submitted By: Brian Takita (btakita) Assigned to: Nobody (None) Summary: Context Runner does not report on Non standard exceptions and return a 0 return code Initial Comment: This is a major bug. This spec demonstrats the problem. context "A Context Runner receiving an Exception" do specify "should report on it and return a 0 return code" do raise Exception end end ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-02-14 05:22 Message: Actually - I see how to handle it now: irb(main):001:0> def trap(&block) irb(main):002:1> block.call irb(main):003:1> rescue Exception => e irb(main):004:1> puts e irb(main):005:1> end => nil irb(main):006:0> trap { raise RuntimeError.new } RuntimeError => nil irb(main):007:0> trap { raise Exception } Exception => nil irb(main):008:0> trap { raise Exception.new } Exception => nil Fix coming soon. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-02-14 05:20 Message: This seems to be how Ruby behaves: irb(main):001:0> def trap(&block) irb(main):002:1> block.call irb(main):003:1> rescue => e irb(main):004:1> puts e irb(main):005:1> end => nil irb(main):006:0> trap { raise "some error" } some error => nil irb(main):007:0> trap { raise RuntimeError.new } RuntimeError => nil irb(main):008:0> trap { raise Exception.new } (irb):8:in `irb_binding': Exception (Exception) from (irb):2:in `call' from (irb):2:in `trap' from (irb):8:in `irb_binding' from /usr/local/lib/ruby/1.8/irb/workspace.rb:52:in `irb_binding' from /usr/local/lib/ruby/1.8/irb/workspace.rb:52 Not sure what we could do about it. Any ideas? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=8646&group_id=797 From noreply at rubyforge.org Wed Feb 14 00:36:32 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 14 Feb 2007 00:36:32 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-8646 ] Context Runner does not report on Non standard exceptions and return a 0 return code Message-ID: <20070214053633.3DB6152420AF@rubyforge.org> Bugs item #8646, was opened at 2007-02-13 22:48 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=8646&group_id=797 Category: runner module Group: None >Status: Closed >Resolution: Accepted Priority: 3 Submitted By: Brian Takita (btakita) >Assigned to: David Chelimsky (dchelimsky) Summary: Context Runner does not report on Non standard exceptions and return a 0 return code Initial Comment: This is a major bug. This spec demonstrats the problem. context "A Context Runner receiving an Exception" do specify "should report on it and return a 0 return code" do raise Exception end end ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-02-14 05:36 Message: Fixed in trunk 1494 ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-02-14 05:22 Message: Actually - I see how to handle it now: irb(main):001:0> def trap(&block) irb(main):002:1> block.call irb(main):003:1> rescue Exception => e irb(main):004:1> puts e irb(main):005:1> end => nil irb(main):006:0> trap { raise RuntimeError.new } RuntimeError => nil irb(main):007:0> trap { raise Exception } Exception => nil irb(main):008:0> trap { raise Exception.new } Exception => nil Fix coming soon. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-02-14 05:20 Message: This seems to be how Ruby behaves: irb(main):001:0> def trap(&block) irb(main):002:1> block.call irb(main):003:1> rescue => e irb(main):004:1> puts e irb(main):005:1> end => nil irb(main):006:0> trap { raise "some error" } some error => nil irb(main):007:0> trap { raise RuntimeError.new } RuntimeError => nil irb(main):008:0> trap { raise Exception.new } (irb):8:in `irb_binding': Exception (Exception) from (irb):2:in `call' from (irb):2:in `trap' from (irb):8:in `irb_binding' from /usr/local/lib/ruby/1.8/irb/workspace.rb:52:in `irb_binding' from /usr/local/lib/ruby/1.8/irb/workspace.rb:52 Not sure what we could do about it. Any ideas? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=8646&group_id=797 From noreply at rubyforge.org Wed Feb 14 02:07:55 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 14 Feb 2007 02:07:55 -0500 (EST) Subject: [rspec-devel] [ rspec-Feature Requests-8654 ] Aspects Message-ID: <20070214070755.E4CD7524209A@rubyforge.org> Feature Requests item #8654, was opened at 2007-02-14 09:07 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=8654&group_id=797 Category: runner module Group: None Status: Open Priority: 3 Submitted By: Yurii Rashkovskii (yrashk) Assigned to: Nobody (None) Summary: Aspects Initial Comment: Specifications become a bit messy in large applications. What if implementing aspects for rspec? context "New Document instance" do setup do @document = Document.new end aspect "versioning" do specify "should have no versions" do @document.should_have(0).versions end end aspect "printing" do aspect "pdf" do ... end end end New Document instance - (versioning) should have no versions - (printing/pdf) ... Initial implementation (requires ActiveSupport, but could be easily ported to pure Ruby) and more details are available at http://rashkovskii.com/articles/2007/2/13/rspec-aspects ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=8654&group_id=797 From noreply at rubyforge.org Wed Feb 14 09:02:58 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 14 Feb 2007 09:02:58 -0500 (EST) Subject: [rspec-devel] [ rspec-Feature Requests-8654 ] Aspects Message-ID: <20070214140258.CA2EA5240945@rubyforge.org> Feature Requests item #8654, was opened at 2007-02-14 07:07 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=8654&group_id=797 Category: runner module Group: None Status: Open Priority: 3 Submitted By: Yurii Rashkovskii (yrashk) Assigned to: Nobody (None) Summary: Aspects Initial Comment: Specifications become a bit messy in large applications. What if implementing aspects for rspec? context "New Document instance" do setup do @document = Document.new end aspect "versioning" do specify "should have no versions" do @document.should_have(0).versions end end aspect "printing" do aspect "pdf" do ... end end end New Document instance - (versioning) should have no versions - (printing/pdf) ... Initial implementation (requires ActiveSupport, but could be easily ported to pure Ruby) and more details are available at http://rashkovskii.com/articles/2007/2/13/rspec-aspects ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-02-14 14:02 Message: Thanks Yurii. This is pretty sweet. Please take a look at http://rubyforge.org/tracker/index.php?func=detail&aid=8126&group_id=797&atid=3152. The direction that one is going is that we'd have nested specify blocks that you could invoke using arbitrary names (like "sub_context" or "aspect"). You'd end up being able to do exactly what you propose in your specs, but you'd have to wrap "versioning" in parens to get the output you're looking for: context "New Document instance" do aspect "(versioning)" do specify "should have no versions" do ... WDYT? Also, if you're going to submit implementations, please do so in the form of patches here in the this Tracker. Not to suggest that you shouldn't put it on your blog also, but it would be better to have the history of this conversation in one place. Lastly, regardless of whether we use your suggestion or what I've just described, I'd recommend coming up with another word besides "aspect" to avoid confusion w/ Aspect Oriented Programming. Cheers, David ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=8654&group_id=797 From hughes.james at gmail.com Wed Feb 14 15:08:37 2007 From: hughes.james at gmail.com (James Hughes) Date: Wed, 14 Feb 2007 12:08:37 -0800 Subject: [rspec-devel] Will it be "response.should_have" or "response.body.should_have"? In-Reply-To: <57c63afe0702131634r78787095t4b7f414b34e8223a@mail.gmail.com> References: <765a2c230702091505x1531084avbf3d0c148c3fe47d@mail.gmail.com> <57c63afe0702091905n32b9155j579646068b79fdb5@mail.gmail.com> <765a2c230702131430p2d7d9b95h12c53176f077a719@mail.gmail.com> <57c63afe0702131634r78787095t4b7f414b34e8223a@mail.gmail.com> Message-ID: <765a2c230702141208i540b97b7p22daf9c5592138a8@mail.gmail.com> On 2/13/07, David Chelimsky wrote: > On 2/13/07, James Hughes wrote: > > On 2/9/07, David Chelimsky wrote: > > > The next release (coming soon) will do everything assert_select does > > > but with rspec syntax. Take a look at this: > > > > > > >http://blog.davidchelimsky.net/articles/2007/01/20/view-specs-are-about-to-get-a-whole-lot-easier > > > > > > > Thanks, David. assert_select supports using substitution values in > > selectors, eg.: > > > > assert_select "ol>li#?", /item-\d+/ > > > > Is there a way to do this with should have_tag? > > response.should have_tag("ol>li#?", /item-\d+/) That's what I've been trying, with the difference that I'm providing a hash as the third parameter: response.should have_tag("a[href*=users/edit/user?]", /\d/, {:text => "Edit"}) to test the contents of the tag. I'm just now noticing that the assert_select docs provide no examples like this so perhaps this isn't possible. However, I've also tried response.should have_tag("a[href*=users/edit/?]", /user\d/) with no luck. Here's the respective stack traces for the example above: response.should have_tag("a[href*=users/edit/user?]", /\d/, {:text => "Edit"}) 'Given a list with three users the users/list view should list some users and provide an edit link for each' FAILED textEdit /usr/lib/ruby/gems/1.8/gems/rspec-0.8.0/lib/spec/expectations.rb:98:in `fail_with' /usr/lib/ruby/gems/1.8/gems/rspec-0.8.0/lib/spec/expectations/handler.rb:8:in `initialize' /usr/lib/ruby/gems/1.8/gems/rspec-0.8.0/lib/spec/expectations/extensions/object.rb:18:in `should' ./spec/views/users/list_view_spec.rb:49: /usr/lib/ruby/gems/1.8/gems/rspec-0.8.0/lib/spec/runner/specification.rb:55:in `execute_spec' /usr/lib/ruby/gems/1.8/gems/rspec-0.8.0/lib/spec/runner/specification.rb:30:in `run' /usr/lib/ruby/gems/1.8/gems/rspec-0.8.0/lib/spec/runner/context.rb:58:in `run' /usr/lib/ruby/gems/1.8/gems/rspec-0.8.0/lib/spec/runner/context.rb:55:in `run' /usr/lib/ruby/gems/1.8/gems/rspec-0.8.0/lib/spec/runner/context_runner.rb:23:in `run' /usr/lib/ruby/gems/1.8/gems/rspec-0.8.0/lib/spec/runner/context_runner.rb:22:in `run' /usr/lib/ruby/gems/1.8/gems/rspec-0.8.0/lib/spec/runner/command_line.rb:27:in `run' /usr/lib/ruby/gems/1.8/gems/rspec-0.8.0/bin/spec:4: /usr/bin/spec:18: and response.should have_tag("a[href*=users/edit/?]", /user\d/) gives: 'Given a list with three users the users/list view should list some users and provide an edit link for each' FAILED Expected at least 1 tag, found 0 /usr/lib/ruby/gems/1.8/gems/rspec-0.8.0/lib/spec/expectations.rb:98:in `fail_with' /usr/lib/ruby/gems/1.8/gems/rspec-0.8.0/lib/spec/expectations/handler.rb:8:in `initialize' /usr/lib/ruby/gems/1.8/gems/rspec-0.8.0/lib/spec/expectations/extensions/object.rb:18:in `should' ./spec/views/users/list_view_spec.rb:50: /usr/lib/ruby/gems/1.8/gems/rspec-0.8.0/lib/spec/runner/specification.rb:55:in `execute_spec' /usr/lib/ruby/gems/1.8/gems/rspec-0.8.0/lib/spec/runner/specification.rb:30:in `run' /usr/lib/ruby/gems/1.8/gems/rspec-0.8.0/lib/spec/runner/context.rb:58:in `run' /usr/lib/ruby/gems/1.8/gems/rspec-0.8.0/lib/spec/runner/context.rb:55:in `run' /usr/lib/ruby/gems/1.8/gems/rspec-0.8.0/lib/spec/runner/context_runner.rb:23:in `run' /usr/lib/ruby/gems/1.8/gems/rspec-0.8.0/lib/spec/runner/context_runner.rb:22:in `run' /usr/lib/ruby/gems/1.8/gems/rspec-0.8.0/lib/spec/runner/command_line.rb:27:in `run' /usr/lib/ruby/gems/1.8/gems/rspec-0.8.0/bin/spec:4: /usr/bin/spec:18: From dchelimsky at gmail.com Thu Feb 15 11:21:45 2007 From: dchelimsky at gmail.com (David Chelimsky) Date: Thu, 15 Feb 2007 10:21:45 -0600 Subject: [rspec-devel] Will it be "response.should_have" or "response.body.should_have"? In-Reply-To: <765a2c230702141208i540b97b7p22daf9c5592138a8@mail.gmail.com> References: <765a2c230702091505x1531084avbf3d0c148c3fe47d@mail.gmail.com> <57c63afe0702091905n32b9155j579646068b79fdb5@mail.gmail.com> <765a2c230702131430p2d7d9b95h12c53176f077a719@mail.gmail.com> <57c63afe0702131634r78787095t4b7f414b34e8223a@mail.gmail.com> <765a2c230702141208i540b97b7p22daf9c5592138a8@mail.gmail.com> Message-ID: <57c63afe0702150821p1a86cf8j5c53eeee886a917a@mail.gmail.com> On 2/14/07, James Hughes wrote: > On 2/13/07, David Chelimsky wrote: > > On 2/13/07, James Hughes wrote: > > > On 2/9/07, David Chelimsky wrote: > > > > The next release (coming soon) will do everything assert_select does > > > > but with rspec syntax. Take a look at this: > > > > > > > > >http://blog.davidchelimsky.net/articles/2007/01/20/view-specs-are-about-to-get-a-whole-lot-easier > > > > > > > > > > Thanks, David. assert_select supports using substitution values in > > > selectors, eg.: > > > > > > assert_select "ol>li#?", /item-\d+/ > > > > > > Is there a way to do this with should have_tag? > > > > response.should have_tag("ol>li#?", /item-\d+/) > > That's what I've been trying, with the difference that I'm providing a > hash as the third parameter: > > response.should have_tag("a[href*=users/edit/user?]", /\d/, {:text > => "Edit"}) > > to test the contents of the tag. I'm just now noticing that the > assert_select docs provide no examples like this so perhaps this isn't > possible. However, I've also tried > > response.should have_tag("a[href*=users/edit/?]", /user\d/) > > with no luck. James - would you mind adding this: puts response.body to your spec and showing us what actually gets rendered? Thx, David > > Here's the respective stack traces for the example above: > > response.should have_tag("a[href*=users/edit/user?]", /\d/, {:text > => "Edit"}) > 'Given a list with three users the users/list view should list some > users and provide an edit link for each' FAILED > textEdit > /usr/lib/ruby/gems/1.8/gems/rspec-0.8.0/lib/spec/expectations.rb:98:in > `fail_with' > /usr/lib/ruby/gems/1.8/gems/rspec-0.8.0/lib/spec/expectations/handler.rb:8:in > `initialize' > /usr/lib/ruby/gems/1.8/gems/rspec-0.8.0/lib/spec/expectations/extensions/object.rb:18:in > `should' > ./spec/views/users/list_view_spec.rb:49: > /usr/lib/ruby/gems/1.8/gems/rspec-0.8.0/lib/spec/runner/specification.rb:55:in > `execute_spec' > /usr/lib/ruby/gems/1.8/gems/rspec-0.8.0/lib/spec/runner/specification.rb:30:in > `run' > /usr/lib/ruby/gems/1.8/gems/rspec-0.8.0/lib/spec/runner/context.rb:58:in `run' > /usr/lib/ruby/gems/1.8/gems/rspec-0.8.0/lib/spec/runner/context.rb:55:in `run' > /usr/lib/ruby/gems/1.8/gems/rspec-0.8.0/lib/spec/runner/context_runner.rb:23:in > `run' > /usr/lib/ruby/gems/1.8/gems/rspec-0.8.0/lib/spec/runner/context_runner.rb:22:in > `run' > /usr/lib/ruby/gems/1.8/gems/rspec-0.8.0/lib/spec/runner/command_line.rb:27:in > `run' > /usr/lib/ruby/gems/1.8/gems/rspec-0.8.0/bin/spec:4: > /usr/bin/spec:18: > > and > > response.should have_tag("a[href*=users/edit/?]", /user\d/) > gives: > 'Given a list with three users the users/list view should list some > users and provide an edit link for each' FAILED > Expected at least 1 tag, found 0 > /usr/lib/ruby/gems/1.8/gems/rspec-0.8.0/lib/spec/expectations.rb:98:in > `fail_with' > /usr/lib/ruby/gems/1.8/gems/rspec-0.8.0/lib/spec/expectations/handler.rb:8:in > `initialize' > /usr/lib/ruby/gems/1.8/gems/rspec-0.8.0/lib/spec/expectations/extensions/object.rb:18:in > `should' > ./spec/views/users/list_view_spec.rb:50: > /usr/lib/ruby/gems/1.8/gems/rspec-0.8.0/lib/spec/runner/specification.rb:55:in > `execute_spec' > /usr/lib/ruby/gems/1.8/gems/rspec-0.8.0/lib/spec/runner/specification.rb:30:in > `run' > /usr/lib/ruby/gems/1.8/gems/rspec-0.8.0/lib/spec/runner/context.rb:58:in `run' > /usr/lib/ruby/gems/1.8/gems/rspec-0.8.0/lib/spec/runner/context.rb:55:in `run' > /usr/lib/ruby/gems/1.8/gems/rspec-0.8.0/lib/spec/runner/context_runner.rb:23:in > `run' > /usr/lib/ruby/gems/1.8/gems/rspec-0.8.0/lib/spec/runner/context_runner.rb:22:in > `run' > /usr/lib/ruby/gems/1.8/gems/rspec-0.8.0/lib/spec/runner/command_line.rb:27:in > `run' > /usr/lib/ruby/gems/1.8/gems/rspec-0.8.0/bin/spec:4: > /usr/bin/spec:18: > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From hughes.james at gmail.com Thu Feb 15 18:35:51 2007 From: hughes.james at gmail.com (James Hughes) Date: Thu, 15 Feb 2007 15:35:51 -0800 Subject: [rspec-devel] Will it be "response.should_have" or "response.body.should_have"? In-Reply-To: <57c63afe0702150821p1a86cf8j5c53eeee886a917a@mail.gmail.com> References: <765a2c230702091505x1531084avbf3d0c148c3fe47d@mail.gmail.com> <57c63afe0702091905n32b9155j579646068b79fdb5@mail.gmail.com> <765a2c230702131430p2d7d9b95h12c53176f077a719@mail.gmail.com> <57c63afe0702131634r78787095t4b7f414b34e8223a@mail.gmail.com> <765a2c230702141208i540b97b7p22daf9c5592138a8@mail.gmail.com> <57c63afe0702150821p1a86cf8j5c53eeee886a917a@mail.gmail.com> Message-ID: <765a2c230702151535n69d7cbfbt8b4327f07a1f5002@mail.gmail.com> On 2/15/07, David Chelimsky wrote: > On 2/14/07, James Hughes wrote: > > On 2/13/07, David Chelimsky wrote: > > > On 2/13/07, James Hughes wrote: > > > > On 2/9/07, David Chelimsky wrote: > > > > > The next release (coming soon) will do everything assert_select does > > > > > but with rspec syntax. Take a look at this: > > > > > > > > > > >http://blog.davidchelimsky.net/articles/2007/01/20/view-specs-are-about-to-get-a-whole-lot-easier > > > > > > > > > > > > > Thanks, David. assert_select supports using substitution values in > > > > selectors, eg.: > > > > > > > > assert_select "ol>li#?", /item-\d+/ > > > > > > > > Is there a way to do this with should have_tag? > > > > > > response.should have_tag("ol>li#?", /item-\d+/) > > > > That's what I've been trying, with the difference that I'm providing a > > hash as the third parameter: > > > > response.should have_tag("a[href*=users/edit/user?]", /\d/, {:text > > => "Edit"}) > > > > to test the contents of the tag. I'm just now noticing that the > > assert_select docs provide no examples like this so perhaps this isn't > > possible. However, I've also tried > > > > response.should have_tag("a[href*=users/edit/?]", /user\d/) > > > > with no luck. > > James - would you mind adding this: > > puts response.body > > to your spec and showing us what actually gets rendered? > The relevant bit follows, but I got this to pass with the following syntax: response.should have_tag("a[href=?]", /\/users\/edit\/user\d/) whereas # response.should have_tag("a[href=/users/edit/user?]", /\d/) fails. I think there's something subtle about the substitution operator (the '?') that I'm not understanding. It seems to only work in proximity to the "=", "#", and "." characters? I don't think this is really an rspec issue. example user 0 user0 at test.com 604-777-8888 Edit example user 1 user1 at test.com 604-777-8888 Edit example user 2 user2 at test.com 604-777-8888 Edit From noreply at rubyforge.org Fri Feb 16 07:23:31 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 16 Feb 2007 07:23:31 -0500 (EST) Subject: [rspec-devel] [ rspec-Feature Requests-8696 ] --order option Message-ID: <20070216122331.0F06E52409C7@rubyforge.org> Feature Requests item #8696, was opened at 2007-02-16 07:23 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=8696&group_id=797 Category: runner / command line Group: None Status: Open Priority: 3 Submitted By: Aslak Helles?y (aslak_hellesoy) Assigned to: Aslak Helles?y (aslak_hellesoy) Summary: --order option Initial Comment: Right now, when spec is executed with a directory, the spec files are run in alphabetical order. I would like to be able to specify a custom order for several reasons: First, because being able to run specs in say, reverse alphabetical order would allow me to identify potential dependencies between specs. Second, because I sometimes want to run the most recently modified spec files first, so I can get early feedback. This is especially important for slow-running specs (such as Watir ones). At work we have monkey-patched Spec::Runner::Reporter to turn on a lamp at the first failure. Unless someone wants more ordering options than alphabetical/timestamp and ascending/descending, I think it can be done like this: --order alphabetical:ascending (default) --order alphabetical:descending --order timestamp:ascending --order timestamp:descending ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=8696&group_id=797 From noreply at rubyforge.org Fri Feb 16 07:49:05 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 16 Feb 2007 07:49:05 -0500 (EST) Subject: [rspec-devel] [ rspec-Feature Requests-8654 ] Aspects Message-ID: <20070216124905.3CF1752409B9@rubyforge.org> Feature Requests item #8654, was opened at 2007-02-14 09:07 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=8654&group_id=797 Category: runner module Group: None Status: Open Priority: 3 Submitted By: Yurii Rashkovskii (yrashk) Assigned to: Nobody (None) Summary: Aspects Initial Comment: Specifications become a bit messy in large applications. What if implementing aspects for rspec? context "New Document instance" do setup do @document = Document.new end aspect "versioning" do specify "should have no versions" do @document.should_have(0).versions end end aspect "printing" do aspect "pdf" do ... end end end New Document instance - (versioning) should have no versions - (printing/pdf) ... Initial implementation (requires ActiveSupport, but could be easily ported to pure Ruby) and more details are available at http://rashkovskii.com/articles/2007/2/13/rspec-aspects ---------------------------------------------------------------------- >Comment By: Yurii Rashkovskii (yrashk) Date: 2007-02-16 14:49 Message: David, basically your idea about nested blocks with arbitrary names is nice, but I foresee one problem. My current implementation supports nested aspects and joins their names like "(versioning/backup)" for nested versioning -> backup aspects. WDYT? I will surely be able to rework any of my proof-of-concept implementation of rspec extensions as a patch with tests once it will be agreed with rspec maintainers. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-02-14 16:02 Message: Thanks Yurii. This is pretty sweet. Please take a look at http://rubyforge.org/tracker/index.php?func=detail&aid=8126&group_id=797&atid=3152. The direction that one is going is that we'd have nested specify blocks that you could invoke using arbitrary names (like "sub_context" or "aspect"). You'd end up being able to do exactly what you propose in your specs, but you'd have to wrap "versioning" in parens to get the output you're looking for: context "New Document instance" do aspect "(versioning)" do specify "should have no versions" do ... WDYT? Also, if you're going to submit implementations, please do so in the form of patches here in the this Tracker. Not to suggest that you shouldn't put it on your blog also, but it would be better to have the history of this conversation in one place. Lastly, regardless of whether we use your suggestion or what I've just described, I'd recommend coming up with another word besides "aspect" to avoid confusion w/ Aspect Oriented Programming. Cheers, David ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=8654&group_id=797 From noreply at rubyforge.org Fri Feb 16 07:49:51 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 16 Feb 2007 07:49:51 -0500 (EST) Subject: [rspec-devel] [ rspec-Feature Requests-8698 ] --snippet option Message-ID: <20070216124951.3F9E152409B8@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: Open 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. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=8698&group_id=797 From noreply at rubyforge.org Fri Feb 16 07:57:51 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 16 Feb 2007 07:57:51 -0500 (EST) Subject: [rspec-devel] [ rspec-Feature Requests-8654 ] Aspects Message-ID: <20070216125752.12F245240954@rubyforge.org> Feature Requests item #8654, was opened at 2007-02-14 09:07 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=8654&group_id=797 Category: runner module Group: None Status: Open Priority: 3 Submitted By: Yurii Rashkovskii (yrashk) Assigned to: Nobody (None) Summary: Aspects Initial Comment: Specifications become a bit messy in large applications. What if implementing aspects for rspec? context "New Document instance" do setup do @document = Document.new end aspect "versioning" do specify "should have no versions" do @document.should_have(0).versions end end aspect "printing" do aspect "pdf" do ... end end end New Document instance - (versioning) should have no versions - (printing/pdf) ... Initial implementation (requires ActiveSupport, but could be easily ported to pure Ruby) and more details are available at http://rashkovskii.com/articles/2007/2/13/rspec-aspects ---------------------------------------------------------------------- >Comment By: Yurii Rashkovskii (yrashk) Date: 2007-02-16 14:57 Message: Also, I think that sub_context isn't good name for aspect. In my understanding aspects to be _quite_ orthogonal to context. It's kind of protocol in Smalltalk, or something like that. ---------------------------------------------------------------------- Comment By: Yurii Rashkovskii (yrashk) Date: 2007-02-16 14:49 Message: David, basically your idea about nested blocks with arbitrary names is nice, but I foresee one problem. My current implementation supports nested aspects and joins their names like "(versioning/backup)" for nested versioning -> backup aspects. WDYT? I will surely be able to rework any of my proof-of-concept implementation of rspec extensions as a patch with tests once it will be agreed with rspec maintainers. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-02-14 16:02 Message: Thanks Yurii. This is pretty sweet. Please take a look at http://rubyforge.org/tracker/index.php?func=detail&aid=8126&group_id=797&atid=3152. The direction that one is going is that we'd have nested specify blocks that you could invoke using arbitrary names (like "sub_context" or "aspect"). You'd end up being able to do exactly what you propose in your specs, but you'd have to wrap "versioning" in parens to get the output you're looking for: context "New Document instance" do aspect "(versioning)" do specify "should have no versions" do ... WDYT? Also, if you're going to submit implementations, please do so in the form of patches here in the this Tracker. Not to suggest that you shouldn't put it on your blog also, but it would be better to have the history of this conversation in one place. Lastly, regardless of whether we use your suggestion or what I've just described, I'd recommend coming up with another word besides "aspect" to avoid confusion w/ Aspect Oriented Programming. Cheers, David ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=8654&group_id=797 From noreply at rubyforge.org Fri Feb 16 10:34:46 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 16 Feb 2007 10:34:46 -0500 (EST) Subject: [rspec-devel] [ rspec-Feature Requests-8126 ] Nested specify blocks Message-ID: <20070216153446.D7C2B5240A11@rubyforge.org> Feature Requests item #8126, was opened at 2007-01-25 02:25 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=8126&group_id=797 Category: expectation module Group: None Status: Open Priority: 3 Submitted By: Wincent Colaiuta (wincent) Assigned to: Nobody (None) Summary: Nested specify blocks Initial Comment: I know that the idea of nested contexts has come up on the devel list before (Google for "pipermail rspec nested contexts") and most were not in favor of the idea. For me, more useful than nested contexts would be nested specifications ("specify" blocks). Currently I have specs which look like this: context 'outer' do specify 'inner' do this.should == that end end If a spec is not satisfied then rspec prints a message of the form "outer inner". I sometimes find myself wishing that I could nest the specify blocks to fine tune the failure message: context 'outer' do specify 'inner' do specify 'innermost' do this.should == that end end end In this case rspec would print "outer inner innermost" on failure. Let me flesh it out a bit with more of a concrete example; basically I often find myself wanting to write this: context 'applying a regexp to a string' do specify 'should be able to match "zero or more" times' do specify 'with input that matches zero times' do # test zero-match case end specify 'with input that matches one time' do # test one-match case end specify 'with input that matches two times' do # test two-match case end end end Because I can't be bothered writing this: context 'applying a regexp to a string' do specify 'should be able to match "zero or more" times (with input that matches zero times)' do # test zero-match case end specify 'should be able to match "zero or more" times (with input that matches one time)' do # test one-match case end specify 'should be able to match "zero or more" times (with input that matches two times)' do # test two-match case end end But I end up writing this: context 'applying a regexp to a string' do specify 'should be able to match "zero or more" times' do # test zero-match case # test one-match case # test two-match case end end This isn't ideal because if the first assertion fails then the others aren't even tested. I'd rather keep the number of assertions in each specify block a bit lower, and the ability to nest specify blocks would help me to do that. What do people think? ---------------------------------------------------------------------- Comment By: Daniel Schierbeck (dasch) Date: 2007-02-16 16:34 Message: Why not also nest the output? 

  Applying a regexp to a string
  - should be able to match "zero or more" times
     * with input that matches zero times
     * with input that matches one time
     * with input that matches two times
---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-02-05 12:46 Message: Lachie: yes, you could view it that way, and given/when/then should be supported keywords (when and then would have to be munged in some way as they are already Ruby keywords). Wincent: we've gone a long way to keep things simple and from what I've seen, some people will go out of their way to complicate things no matter how simple you make them. Including us!!!! (e.g. controller.should_render) If/when we do this, it will likely be introduced gradually. It's not the first priority at the moment ;) Also - looking back at your initial submission - you could do this in the mean time: context 'applying a regexp to a string should be able to match "zero or more" times' do specify 'with input that matches zero times' do end specify 'with input that matches one time' do end specify 'with input that matches two times' do end end I realize that the context name is more than context - it's a declaration of an aspect of behaviour. That's probably not such a bad thing. And it would result in the same readable output on failures. FFT. ---------------------------------------------------------------------- Comment By: Wincent Colaiuta (wincent) Date: 2007-02-05 11:12 Message: > Command line options could load a file which defines > custom aliases that you want to use that don't ship > with RSpec, so you could things like > "project/iteration/story/scenario" if that made you > happy. Above all, I think *some kind* of nesting support would be a wonderful improvement in terms of readability/expressiveness and also in terms of saved typing; these are the reasons why I filed the feature request. I am also sure that the ability to basically twist RSpec into any shape you want and use any terminology you want would be popular. BUT I also think that it might be a bit dangerous to give people too much free reign. One of the things about BDD in general and specifically RSpec is that the language that it imposes ("context"/"specify") helps developers to do the right thing and follow best testing practice. If people could use any terminology at all then some of that benefit might be lost. Also, in the same way that overuse of C preprocessor macros can make it harder to read other people's source code, if the terminology for specifying behaviour is made too flexible then it might become more difficult to read other people's specs. So I'm not saying that you shouldn't do it, but that if you do decide to go down this path I think your idea of doing so in an incremental fashion is a good one; it will give time to really think about it and be sure of why/how/if it should be done. I like the idea of using "story" for acceptance level testing. I am not sure whether "behaviour" is the best term for cases where "the context is not so much a system state, but rather an aspect of behaviour"; I think the word that you used right there, "aspect", is probably a better choice. That's just my initial gut feeling; I'd need to think about it more to be sure. ---------------------------------------------------------------------- Comment By: Lachie Cox (lachie) Date: 2007-02-04 23:29 Message: I this given-when-then by different names? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-02-04 23:21 Message: Thinking about this some more - I think that there are many structures that could prove useful. We've named "context/specify/example", but there is also "story/scenario" for acceptance level spec'ing, "behaviour/specify/example" when the context is not so much a system state, but rather an aspect of behaviour like "error messages". This is leading me to this thought: what if the structure was simply a tree? We could have a method #rspec_node(*args, &block) that returns an RSpecNode. This would be implemented in Kernel, aliased with names like #context, #behaviour and #story. It would also be implemented in RSpecNode, aliased with names like #specify, #example and #scenario. Nested nodes would have access to state in any of its ancestor nodes, supporting the long sought-after "nested context", but siblings would not have access to each other's state. Command line options could load a file which defines custom aliases that you want to use that don't ship with RSpec, so you could things like "project/iteration/story/scenario" if that made you happy. I've taken a look at this and it would require a lot of work, but there's no reason it shouldn't be 100% backwards compatible (except for monkey patching), and it's something we can probably introduce gradually, starting w/ nested specify blocks, and working up to unifying Context and Specification into a single RSpecNode. WDYT of that? ---------------------------------------------------------------------- Comment By: Wincent Colaiuta (wincent) Date: 2007-01-27 17:42 Message: Yes, I think that "context/specify/example" would be a great way to split things up, and the language you've proposed maps well onto the behaviour-driven way of thinking about software development ("in this context ... this should happen ... example ..."). About the only thing I would change in your example is that I would start each example with the word "for" so that when the three strings are chained together they would read like, "applying a regexp to a string should be able to match 'zero or more' times for the zero-match case" etc: context 'applying a regexp to a string' do specify 'should be able to match "zero or more" times' do example 'for the zero-match case' do ... end example 'for the one-match case' do ... end example 'for the two-match case' do ... end end end This has the added benefit that the line introducing each example in the specification reads as "example for zero- match case" etc, which is highly readable and descriptive. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-01-27 16:53 Message: I love this idea, but I think nesting specify would be confusing to look at. How about this: context specify example context 'applying a regexp to a string' do specify 'should be able to match "zero or more" times' do example "zero-match case" do example "one-match case" do example "two-match case" do end end ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=8126&group_id=797 From noreply at rubyforge.org Fri Feb 16 10:54:18 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 16 Feb 2007 10:54:18 -0500 (EST) Subject: [rspec-devel] [ rspec-Feature Requests-8126 ] Nested specify blocks Message-ID: <20070216155419.0ADEB52409DB@rubyforge.org> Feature Requests item #8126, was opened at 2007-01-25 01:25 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=8126&group_id=797 Category: expectation module Group: None Status: Open Priority: 3 Submitted By: Wincent Colaiuta (wincent) Assigned to: Nobody (None) Summary: Nested specify blocks Initial Comment: I know that the idea of nested contexts has come up on the devel list before (Google for "pipermail rspec nested contexts") and most were not in favor of the idea. For me, more useful than nested contexts would be nested specifications ("specify" blocks). Currently I have specs which look like this: context 'outer' do specify 'inner' do this.should == that end end If a spec is not satisfied then rspec prints a message of the form "outer inner". I sometimes find myself wishing that I could nest the specify blocks to fine tune the failure message: context 'outer' do specify 'inner' do specify 'innermost' do this.should == that end end end In this case rspec would print "outer inner innermost" on failure. Let me flesh it out a bit with more of a concrete example; basically I often find myself wanting to write this: context 'applying a regexp to a string' do specify 'should be able to match "zero or more" times' do specify 'with input that matches zero times' do # test zero-match case end specify 'with input that matches one time' do # test one-match case end specify 'with input that matches two times' do # test two-match case end end end Because I can't be bothered writing this: context 'applying a regexp to a string' do specify 'should be able to match "zero or more" times (with input that matches zero times)' do # test zero-match case end specify 'should be able to match "zero or more" times (with input that matches one time)' do # test one-match case end specify 'should be able to match "zero or more" times (with input that matches two times)' do # test two-match case end end But I end up writing this: context 'applying a regexp to a string' do specify 'should be able to match "zero or more" times' do # test zero-match case # test one-match case # test two-match case end end This isn't ideal because if the first assertion fails then the others aren't even tested. I'd rather keep the number of assertions in each specify block a bit lower, and the ability to nest specify blocks would help me to do that. What do people think? ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-02-16 15:54 Message: Daniel - I think nesting the output should be an option, but so should not nesting it. I'm not sure of the best way to allow that option (suggestions?) or which should be the default, but I can imagine scenarios in which I'd prefer it each way. WDYT? ---------------------------------------------------------------------- Comment By: Daniel Schierbeck (dasch) Date: 2007-02-16 15:34 Message: Why not also nest the output? 

  Applying a regexp to a string
  - should be able to match "zero or more" times
     * with input that matches zero times
     * with input that matches one time
     * with input that matches two times
---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-02-05 11:46 Message: Lachie: yes, you could view it that way, and given/when/then should be supported keywords (when and then would have to be munged in some way as they are already Ruby keywords). Wincent: we've gone a long way to keep things simple and from what I've seen, some people will go out of their way to complicate things no matter how simple you make them. Including us!!!! (e.g. controller.should_render) If/when we do this, it will likely be introduced gradually. It's not the first priority at the moment ;) Also - looking back at your initial submission - you could do this in the mean time: context 'applying a regexp to a string should be able to match "zero or more" times' do specify 'with input that matches zero times' do end specify 'with input that matches one time' do end specify 'with input that matches two times' do end end I realize that the context name is more than context - it's a declaration of an aspect of behaviour. That's probably not such a bad thing. And it would result in the same readable output on failures. FFT. ---------------------------------------------------------------------- Comment By: Wincent Colaiuta (wincent) Date: 2007-02-05 10:12 Message: > Command line options could load a file which defines > custom aliases that you want to use that don't ship > with RSpec, so you could things like > "project/iteration/story/scenario" if that made you > happy. Above all, I think *some kind* of nesting support would be a wonderful improvement in terms of readability/expressiveness and also in terms of saved typing; these are the reasons why I filed the feature request. I am also sure that the ability to basically twist RSpec into any shape you want and use any terminology you want would be popular. BUT I also think that it might be a bit dangerous to give people too much free reign. One of the things about BDD in general and specifically RSpec is that the language that it imposes ("context"/"specify") helps developers to do the right thing and follow best testing practice. If people could use any terminology at all then some of that benefit might be lost. Also, in the same way that overuse of C preprocessor macros can make it harder to read other people's source code, if the terminology for specifying behaviour is made too flexible then it might become more difficult to read other people's specs. So I'm not saying that you shouldn't do it, but that if you do decide to go down this path I think your idea of doing so in an incremental fashion is a good one; it will give time to really think about it and be sure of why/how/if it should be done. I like the idea of using "story" for acceptance level testing. I am not sure whether "behaviour" is the best term for cases where "the context is not so much a system state, but rather an aspect of behaviour"; I think the word that you used right there, "aspect", is probably a better choice. That's just my initial gut feeling; I'd need to think about it more to be sure. ---------------------------------------------------------------------- Comment By: Lachie Cox (lachie) Date: 2007-02-04 22:29 Message: I this given-when-then by different names? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-02-04 22:21 Message: Thinking about this some more - I think that there are many structures that could prove useful. We've named "context/specify/example", but there is also "story/scenario" for acceptance level spec'ing, "behaviour/specify/example" when the context is not so much a system state, but rather an aspect of behaviour like "error messages". This is leading me to this thought: what if the structure was simply a tree? We could have a method #rspec_node(*args, &block) that returns an RSpecNode. This would be implemented in Kernel, aliased with names like #context, #behaviour and #story. It would also be implemented in RSpecNode, aliased with names like #specify, #example and #scenario. Nested nodes would have access to state in any of its ancestor nodes, supporting the long sought-after "nested context", but siblings would not have access to each other's state. Command line options could load a file which defines custom aliases that you want to use that don't ship with RSpec, so you could things like "project/iteration/story/scenario" if that made you happy. I've taken a look at this and it would require a lot of work, but there's no reason it shouldn't be 100% backwards compatible (except for monkey patching), and it's something we can probably introduce gradually, starting w/ nested specify blocks, and working up to unifying Context and Specification into a single RSpecNode. WDYT of that? ---------------------------------------------------------------------- Comment By: Wincent Colaiuta (wincent) Date: 2007-01-27 16:42 Message: Yes, I think that "context/specify/example" would be a great way to split things up, and the language you've proposed maps well onto the behaviour-driven way of thinking about software development ("in this context ... this should happen ... example ..."). About the only thing I would change in your example is that I would start each example with the word "for" so that when the three strings are chained together they would read like, "applying a regexp to a string should be able to match 'zero or more' times for the zero-match case" etc: context 'applying a regexp to a string' do specify 'should be able to match "zero or more" times' do example 'for the zero-match case' do ... end example 'for the one-match case' do ... end example 'for the two-match case' do ... end end end This has the added benefit that the line introducing each example in the specification reads as "example for zero- match case" etc, which is highly readable and descriptive. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-01-27 15:53 Message: I love this idea, but I think nesting specify would be confusing to look at. How about this: context specify example context 'applying a regexp to a string' do specify 'should be able to match "zero or more" times' do example "zero-match case" do example "one-match case" do example "two-match case" do end end ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=8126&group_id=797 From dchelimsky at gmail.com Fri Feb 16 11:39:01 2007 From: dchelimsky at gmail.com (David Chelimsky) Date: Fri, 16 Feb 2007 10:39:01 -0600 Subject: [rspec-devel] Will it be "response.should_have" or "response.body.should_have"? In-Reply-To: <765a2c230702151535n69d7cbfbt8b4327f07a1f5002@mail.gmail.com> References: <765a2c230702091505x1531084avbf3d0c148c3fe47d@mail.gmail.com> <57c63afe0702091905n32b9155j579646068b79fdb5@mail.gmail.com> <765a2c230702131430p2d7d9b95h12c53176f077a719@mail.gmail.com> <57c63afe0702131634r78787095t4b7f414b34e8223a@mail.gmail.com> <765a2c230702141208i540b97b7p22daf9c5592138a8@mail.gmail.com> <57c63afe0702150821p1a86cf8j5c53eeee886a917a@mail.gmail.com> <765a2c230702151535n69d7cbfbt8b4327f07a1f5002@mail.gmail.com> Message-ID: <57c63afe0702160839v22a14094h430af6fe2130d5cc@mail.gmail.com> On 2/15/07, James Hughes wrote: > On 2/15/07, David Chelimsky wrote: > > On 2/14/07, James Hughes wrote: > > > On 2/13/07, David Chelimsky wrote: > > > > On 2/13/07, James Hughes wrote: > > > > > On 2/9/07, David Chelimsky wrote: > > > > > > The next release (coming soon) will do everything assert_select does > > > > > > but with rspec syntax. Take a look at this: > > > > > > > > > > > > >http://blog.davidchelimsky.net/articles/2007/01/20/view-specs-are-about-to-get-a-whole-lot-easier > > > > > > > > > > > > > > > > Thanks, David. assert_select supports using substitution values in > > > > > selectors, eg.: > > > > > > > > > > assert_select "ol>li#?", /item-\d+/ > > > > > > > > > > Is there a way to do this with should have_tag? > > > > > > > > response.should have_tag("ol>li#?", /item-\d+/) > > > > > > That's what I've been trying, with the difference that I'm providing a > > > hash as the third parameter: > > > > > > response.should have_tag("a[href*=users/edit/user?]", /\d/, {:text > > > => "Edit"}) > > > > > > to test the contents of the tag. I'm just now noticing that the > > > assert_select docs provide no examples like this so perhaps this isn't > > > possible. However, I've also tried > > > > > > response.should have_tag("a[href*=users/edit/?]", /user\d/) > > > > > > with no luck. > > > > James - would you mind adding this: > > > > puts response.body > > > > to your spec and showing us what actually gets rendered? > > > > The relevant bit follows, but I got this to pass with the following syntax: > > response.should have_tag("a[href=?]", /\/users\/edit\/user\d/) > whereas > > # response.should have_tag("a[href=/users/edit/user?]", /\d/) > > fails. > > I think there's something subtle about the substitution operator (the > '?') that I'm not understanding. It seems to only work in proximity to > the "=", "#", and "." characters? I don't think this is really an > rspec issue. I think you're right - this is just how assert select works: http://labnotes.org/svn/public/ruby/rails_plugins/assert_select/cheat/assert_select.html >From what I can tell... # is for IDs . is for classes ^, $ and * are for substring matching ? is for regexps Thanks for following up. Cheers, David > > example user 0 > user0 at test.com > 604-777-8888 > Edit > > > example user 1 > user1 at test.com > 604-777-8888 > Edit > > > example user 2 > user2 at test.com > 604-777-8888 > Edit > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From yrashk at gmail.com Fri Feb 16 14:06:09 2007 From: yrashk at gmail.com (Yurii Rashkovskii) Date: Fri, 16 Feb 2007 21:06:09 +0200 Subject: [rspec-devel] [ANN] rspec-ext 0.0.1 Message-ID: Hello, I've just released rspec-ext 0.0.1 (http://rubyforge.org/projects/ rspec-ext/) It is gem-installable (rspec-ext gem) It is simply two _experimental_ (and may be not well tested) extensions of rspec as for now: * specify_negatively (http://rashkovskii.com/articles/2007/1/25/rspec- specify_negatively, http://rashkovskii.com/articles/2007/2/3/ specify_negatively-updated) * aspects (http://rashkovskii.com/articles/2007/2/13/rspec-aspects) As I've said above, all this stuff is pretty much experimental, though I use it in some real projects now. I plan to work on these and other ideas to make at least my own spec- ing even more better. Thank you for your attention, Yurii. From evgeny.zislis at gmail.com Fri Feb 16 15:39:48 2007 From: evgeny.zislis at gmail.com (Evgeny) Date: Fri, 16 Feb 2007 22:39:48 +0200 Subject: [rspec-devel] Meta specifications or spec. helpers available? Message-ID: Greetings All, Is there some way that I could do this : module UserSpecHelper def required_valid_user_attributes { :login => 'monika', :email => 'monika at levinski.com', :password => 'kinky', :password_confirmation => 'kinky', :gender => 'f', :name => 'Monika Levinski' } end end context "A user (in general)" do include UserSpecHelper setup do @user = User.new end required_valid_user_attributes.keys.each do |attribute| self.class_eval <<-EOT specify "should be invalid without #{attribute}" do @user.attributes = required_valid_user_attributes.except(#{attribute}) @user.should_not_be_valid @user.errors.on(#{attribute}).should == 'is require' @user.#{attribute} = required_valid_user_attributes[attribute.to_sym] @user.should_be_valid end EOT end end Because typing the same 7 lines 6 or more times does not look very DRY to me ... Or is there some way to write "specify" helpers or something? Regards, Evgeny -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20070216/fce91fad/attachment.html From evgeny.zislis at gmail.com Fri Feb 16 15:56:36 2007 From: evgeny.zislis at gmail.com (Evgeny) Date: Fri, 16 Feb 2007 22:56:36 +0200 Subject: [rspec-devel] Meta specifications or spec. helpers available? In-Reply-To: References: Message-ID: Or perhaps there is a simple way to add my own specifications, like: specify "should be invalid without login" do @user.should_be_invalid_without :login end On 2/16/07, Evgeny wrote: > > Greetings All, > > Is there some way that I could do this : > > module UserSpecHelper > def required_valid_user_attributes > { :login => 'monika', > :email => 'monika at levinski.com', > :password => 'kinky', > :password_confirmation => ' kinky', > :gender => 'f', > :name => 'Monika Levinski' > } > end > end > > context "A user (in general)" do > include UserSpecHelper > > setup do > @user = User.new > end > > required_valid_user_attributes.keys.each do |attribute| > self.class_eval <<-EOT > specify "should be invalid without #{attribute}" do > @user.attributes = > required_valid_user_attributes.except(#{attribute}) > @user.should_not_be_valid > @user.errors.on(#{attribute}).should == 'is require' > @user.#{attribute} = required_valid_user_attributes[attribute.to_sym > ] > @user.should_be_valid > end > EOT > end > end > > > > Because typing the same 7 lines 6 or more times does not look very DRY to > me ... > > Or is there some way to write "specify" helpers or something? > > > > Regards, > > Evgeny > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20070216/b6173978/attachment.html From dchelimsky at gmail.com Fri Feb 16 18:27:53 2007 From: dchelimsky at gmail.com (David Chelimsky) Date: Fri, 16 Feb 2007 17:27:53 -0600 Subject: [rspec-devel] Meta specifications or spec. helpers available? In-Reply-To: References: Message-ID: <57c63afe0702161527j32b234acs34222e69260f0cbf@mail.gmail.com> On 2/16/07, Evgeny wrote: > Or perhaps there is a simple way to add my own specifications, like: > > specify "should be invalid without login" do > @user.should_be_invalid_without :login > end There will be in a day or two w/ the 0.8-RC1 release. You can do this now w/ trunk. Here's how I would do it - different names, etc - but you can certainly extrapolate your version from this: module UserSpecHelper def require(attr) return Class.new do def initialize(attr) @attr = attr end def matches?(model) @model = model model.send("#{@attr.to_s}=".to_sym, nil) return !model.valid? end def failure_message "expected #{@model.inspect} to require #{@attr.inspect}" end end end end context "A user (in general)" do include UserSpecHelper setup do @user = User.new(:attr1 => value1, :attr2 => value2) end specify "should require :attr1" do @user.should require(:attr1) end end specify "should require :attr2" do @user.should require(:attr2) end end The idea is that you instantiate @user with ALL of its required attributes set. The the expectation matcher (the class created in #require) sets the one you're interested in to nil. It would probably perform better if you defined the class separately, but I was feeling sneaky when I wrote it ;) You can do this today w/ the trunk, and within a few days w/ 0.8-RC1. Cheers, David > > > > On 2/16/07, Evgeny wrote: > > Greetings All, > > > > Is there some way that I could do this : > > > > module UserSpecHelper > > def required_valid_user_attributes > > { :login => 'monika', > > :email => 'monika at levinski.com', > > :password => 'kinky', > > :password_confirmation => ' kinky', > > :gender => 'f', > > :name => 'Monika Levinski' > > } > > end > > end > > > > context "A user (in general)" do > > include UserSpecHelper > > > > setup do > > @user = User.new > > end > > > > required_valid_user_attributes.keys.each do |attribute| > > self.class_eval <<-EOT > > specify "should be invalid without #{attribute}" do > > @user.attributes = > required_valid_user_attributes.except(#{attribute}) > > @user.should_not_be_valid > > @user.errors.on(#{attribute}).should == 'is require' > > @user.#{attribute} = > required_valid_user_attributes[attribute.to_sym] > > @user.should_be_valid > > end > > EOT > > end > > end > > > > > > > > Because typing the same 7 lines 6 or more times does not look very DRY to > me ... > > > > Or is there some way to write "specify" helpers or something? > > > > > > > > Regards, > > > > Evgeny > > > > > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From dchelimsky at gmail.com Fri Feb 16 18:32:57 2007 From: dchelimsky at gmail.com (David Chelimsky) Date: Fri, 16 Feb 2007 17:32:57 -0600 Subject: [rspec-devel] Meta specifications or spec. helpers available? In-Reply-To: <57c63afe0702161527j32b234acs34222e69260f0cbf@mail.gmail.com> References: <57c63afe0702161527j32b234acs34222e69260f0cbf@mail.gmail.com> Message-ID: <57c63afe0702161532l6d24064ek4d541b55a6064a3a@mail.gmail.com> On 2/16/07, David Chelimsky wrote: > On 2/16/07, Evgeny wrote: > > Or perhaps there is a simple way to add my own specifications, like: > > > > specify "should be invalid without login" do > > @user.should_be_invalid_without :login > > end > > There will be in a day or two w/ the 0.8-RC1 release. You can do this > now w/ trunk. Here's how I would do it - different names, etc - but > you can certainly extrapolate your version from this: > > module UserSpecHelper > def require(attr) > return Class.new do > def initialize(attr) > @attr = attr > end > > def matches?(model) > @model = model > model.send("#{@attr.to_s}=".to_sym, nil) > return !model.valid? > end > > def failure_message > "expected #{@model.inspect} to require #{@attr.inspect}" > end > > end > end > end > > context "A user (in general)" do > include UserSpecHelper > > setup do > @user = User.new(:attr1 => value1, :attr2 => value2) > end > > specify "should require :attr1" do > @user.should require(:attr1) > end > end > > specify "should require :attr2" do > @user.should require(:attr2) > end > end > > The idea is that you instantiate @user with ALL of its required > attributes set. The the expectation matcher (the class created in > #require) sets the one you're interested in to nil. > > It would probably perform better if you defined the class separately, > but I was feeling sneaky when I wrote it ;) > > You can do this today w/ the trunk, and within a few days w/ 0.8-RC1. > > Cheers, > David Actually - this is a GREAT example of a useful custom expectation - Evegny - do you mind if I blog about it? I'll certainly give you credit for suggesting it. > > > > > > > > > On 2/16/07, Evgeny wrote: > > > Greetings All, > > > > > > Is there some way that I could do this : > > > > > > module UserSpecHelper > > > def required_valid_user_attributes > > > { :login => 'monika', > > > :email => 'monika at levinski.com', > > > :password => 'kinky', > > > :password_confirmation => ' kinky', > > > :gender => 'f', > > > :name => 'Monika Levinski' > > > } > > > end > > > end > > > > > > context "A user (in general)" do > > > include UserSpecHelper > > > > > > setup do > > > @user = User.new > > > end > > > > > > required_valid_user_attributes.keys.each do |attribute| > > > self.class_eval <<-EOT > > > specify "should be invalid without #{attribute}" do > > > @user.attributes = > > required_valid_user_attributes.except(#{attribute}) > > > @user.should_not_be_valid > > > @user.errors.on(#{attribute}).should == 'is require' > > > @user.#{attribute} = > > required_valid_user_attributes[attribute.to_sym] > > > @user.should_be_valid > > > end > > > EOT > > > end > > > end > > > > > > > > > > > > Because typing the same 7 lines 6 or more times does not look very DRY to > > me ... > > > > > > Or is there some way to write "specify" helpers or something? > > > > > > > > > > > > Regards, > > > > > > Evgeny > > > > > > > > > _______________________________________________ > > rspec-devel mailing list > > rspec-devel at rubyforge.org > > http://rubyforge.org/mailman/listinfo/rspec-devel > > > From dchelimsky at gmail.com Sat Feb 17 12:10:46 2007 From: dchelimsky at gmail.com (David Chelimsky) Date: Sat, 17 Feb 2007 11:10:46 -0600 Subject: [rspec-devel] [ANN] RSpec 0.8.0-RC1 Message-ID: <57c63afe0702170910j76331701ka66f9d1de73fc26c@mail.gmail.com> The RSpec Development Team is pleased to announce Release Candidate 1 of RSpec 0.8.0. Since we're doing a Release Candidate and we don't really have a separate gem server set up, everything you need is tagged in subversion. See the install instructions below. As we noted a few weeks back, this release comprises a new approach to RSpec's expectation syntax using Expectation Matchers, as well as dozens of new features and bug fixes. The new and old syntax are living side by side for the moment, and will do so until we release 0.9, at which point the old syntax will no longer be supported. In subsequent 0.8.x releases, we'll provide both deprecation warnings and a translator tool that will help you to convert your old specs to the new format well in advance of the 0.9 release. Please note that this is a Release Candidate, which means it is subject to changes before the official release. We do hope, however, that many of you will install this release so we can get a lot of feedback and get to the official release quickly. For those who do, please prefix any RFEs with "[0.8.0-RC1]" so we can easily separate them out from the rest. Many thanks to all who are using RSpec, whether just experimenting or really using it on your business critical projects! Cheers, The RSpec Development Team ============================== Installing the gem svn co svn://rubyforge.org/var/svn/rspec/tags/REL_0_8_0_RC1/gem gem install gem/rspec-0.8.0-RC1.gem ============================== Get the docs svn co svn://rubyforge.org/var/svn/rspec/tags/REL_0_8_0_RC1/doc/output doc open doc/index.html NOTE that most of the stuff in the website docs is deprecated. What you want to look at is the RDoc for both RSpec and Spec::Rails. ============================== Installing Spec::Rails (the rails plugin) script/plugin install svn://rubyforge.org/var/svn/rspec/tags/REL_0_8_0_RC1/rspec_on_rails/vendor/plugins/rspec_on_rails ============================== From evgeny.zislis at gmail.com Sun Feb 18 02:18:56 2007 From: evgeny.zislis at gmail.com (Evgeny) Date: Sun, 18 Feb 2007 09:18:56 +0200 Subject: [rspec-devel] Meta specifications or spec. helpers available? In-Reply-To: <57c63afe0702161532l6d24064ek4d541b55a6064a3a@mail.gmail.com> References: <57c63afe0702161527j32b234acs34222e69260f0cbf@mail.gmail.com> <57c63afe0702161532l6d24064ek4d541b55a6064a3a@mail.gmail.com> Message-ID: Certainly - I would LOVE to see that blog with this example. Just be sure to mention that I actually wrote what I wrote based on this : http://www.lukeredpath.co.uk/2006/8/29/developing-a-rails-model-using-bdd-and-rspec-part-1 Keep up the great work! :) - evgeny On 2/17/07, David Chelimsky wrote: > > On 2/16/07, David Chelimsky wrote: > > On 2/16/07, Evgeny wrote: > > > Or perhaps there is a simple way to add my own specifications, like: > > > > > > specify "should be invalid without login" do > > > @user.should_be_invalid_without :login > > > end > > > > There will be in a day or two w/ the 0.8-RC1 release. You can do this > > now w/ trunk. Here's how I would do it - different names, etc - but > > you can certainly extrapolate your version from this: > > > > module UserSpecHelper > > def require(attr) > > return Class.new do > > def initialize(attr) > > @attr = attr > > end > > > > def matches?(model) > > @model = model > > model.send("#{@attr.to_s}=".to_sym, nil) > > return !model.valid? > > end > > > > def failure_message > > "expected #{@model.inspect} to require #{@attr.inspect}" > > end > > > > end > > end > > end > > > > context "A user (in general)" do > > include UserSpecHelper > > > > setup do > > @user = User.new(:attr1 => value1, :attr2 => value2) > > end > > > > specify "should require :attr1" do > > @user.should require(:attr1) > > end > > end > > > > specify "should require :attr2" do > > @user.should require(:attr2) > > end > > end > > > > The idea is that you instantiate @user with ALL of its required > > attributes set. The the expectation matcher (the class created in > > #require) sets the one you're interested in to nil. > > > > It would probably perform better if you defined the class separately, > > but I was feeling sneaky when I wrote it ;) > > > > You can do this today w/ the trunk, and within a few days w/ 0.8-RC1. > > > > Cheers, > > David > > Actually - this is a GREAT example of a useful custom expectation - > Evegny - do you mind if I blog about it? I'll certainly give you > credit for suggesting it. > > > > > > > > > > > > > > > On 2/16/07, Evgeny wrote: > > > > Greetings All, > > > > > > > > Is there some way that I could do this : > > > > > > > > module UserSpecHelper > > > > def required_valid_user_attributes > > > > { :login => 'monika', > > > > :email => 'monika at levinski.com', > > > > :password => 'kinky', > > > > :password_confirmation => ' kinky', > > > > :gender => 'f', > > > > :name => 'Monika Levinski' > > > > } > > > > end > > > > end > > > > > > > > context "A user (in general)" do > > > > include UserSpecHelper > > > > > > > > setup do > > > > @user = User.new > > > > end > > > > > > > > required_valid_user_attributes.keys.each do |attribute| > > > > self.class_eval <<-EOT > > > > specify "should be invalid without #{attribute}" do > > > > @user.attributes = > > > required_valid_user_attributes.except(#{attribute}) > > > > @user.should_not_be_valid > > > > @user.errors.on(#{attribute}).should == 'is require' > > > > @user.#{attribute} = > > > required_valid_user_attributes[attribute.to_sym] > > > > @user.should_be_valid > > > > end > > > > EOT > > > > end > > > > end > > > > > > > > > > > > > > > > Because typing the same 7 lines 6 or more times does not look very > DRY to > > > me ... > > > > > > > > Or is there some way to write "specify" helpers or something? > > > > > > > > > > > > > > > > Regards, > > > > > > > > Evgeny > > > > > > > > > > > > > _______________________________________________ > > > 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/20070218/45d02781/attachment.html From dchelimsky at gmail.com Sun Feb 18 10:18:49 2007 From: dchelimsky at gmail.com (David Chelimsky) Date: Sun, 18 Feb 2007 09:18:49 -0600 Subject: [rspec-devel] Meta specifications or spec. helpers available? In-Reply-To: References: <57c63afe0702161527j32b234acs34222e69260f0cbf@mail.gmail.com> <57c63afe0702161532l6d24064ek4d541b55a6064a3a@mail.gmail.com> Message-ID: <57c63afe0702180718o61be5260y8e40daa1b694de59@mail.gmail.com> On 2/18/07, Evgeny wrote: > Certainly - I would LOVE to see that blog with this example. http://blog.davidchelimsky.net/articles/2007/02/18/custom-expectation-matchers > Just be sure to mention that I actually wrote what I wrote based on this : > http://www.lukeredpath.co.uk/2006/8/29/developing-a-rails-model-using-bdd-and-rspec-part-1 Cool. Luke really has a lot of great ideas about RSpec, Rails and design in general. I encourage everyone to check out his blog: http://www.lukeredpath.co.uk Cheers, David > > Keep up the great work! :) > > > - evgeny > > > On 2/17/07, David Chelimsky wrote: > > On 2/16/07, David Chelimsky wrote: > > > On 2/16/07, Evgeny wrote: > > > > Or perhaps there is a simple way to add my own specifications, like: > > > > > > > > specify "should be invalid without login" do > > > > @user.should_be_invalid_without :login > > > > end > > > > > > There will be in a day or two w/ the 0.8-RC1 release. You can do this > > > now w/ trunk. Here's how I would do it - different names, etc - but > > > you can certainly extrapolate your version from this: > > > > > > module UserSpecHelper > > > def require(attr) > > > return Class.new do > > > def initialize(attr) > > > @attr = attr > > > end > > > > > > def matches?(model) > > > @model = model > > > model.send("#{@attr.to_s}=".to_sym, nil) > > > return !model.valid? > > > end > > > > > > def failure_message > > > "expected #{@model.inspect} to require #{@attr.inspect}" > > > end > > > > > > end > > > end > > > end > > > > > > context "A user (in general)" do > > > include UserSpecHelper > > > > > > setup do > > > @user = User.new(:attr1 => value1, :attr2 => value2) > > > end > > > > > > specify "should require :attr1" do > > > @user.should require(:attr1) > > > end > > > end > > > > > > specify "should require :attr2" do > > > @user.should require(:attr2) > > > end > > > end > > > > > > The idea is that you instantiate @user with ALL of its required > > > attributes set. The the expectation matcher (the class created in > > > #require) sets the one you're interested in to nil. > > > > > > It would probably perform better if you defined the class separately, > > > but I was feeling sneaky when I wrote it ;) > > > > > > You can do this today w/ the trunk, and within a few days w/ 0.8-RC1 . > > > > > > Cheers, > > > David > > > > Actually - this is a GREAT example of a useful custom expectation - > > Evegny - do you mind if I blog about it? I'll certainly give you > > credit for suggesting it. > > > > > > > > > > > > > > > > > > > > > On 2/16/07, Evgeny wrote: > > > > > Greetings All, > > > > > > > > > > Is there some way that I could do this : > > > > > > > > > > module UserSpecHelper > > > > > def required_valid_user_attributes > > > > > { :login => 'monika', > > > > > :email => ' monika at levinski.com', > > > > > :password => 'kinky', > > > > > :password_confirmation => ' kinky', > > > > > :gender => 'f', > > > > > :name => 'Monika Levinski' > > > > > } > > > > > end > > > > > end > > > > > > > > > > context "A user (in general)" do > > > > > include UserSpecHelper > > > > > > > > > > setup do > > > > > @user = User.new > > > > > end > > > > > > > > > > required_valid_user_attributes.keys.each do > |attribute| > > > > > self.class_eval <<-EOT > > > > > specify "should be invalid without #{attribute}" do > > > > > @user.attributes = > > > > required_valid_user_attributes.except(#{attribute}) > > > > > @user.should_not_be_valid > > > > > @user.errors.on(#{attribute}).should == 'is require' > > > > > @user.#{attribute} = > > > > required_valid_user_attributes[attribute.to_sym] > > > > > @user.should_be_valid > > > > > end > > > > > EOT > > > > > end > > > > > end > > > > > > > > > > > > > > > > > > > > Because typing the same 7 lines 6 or more times does not look very > DRY to > > > > me ... > > > > > > > > > > Or is there some way to write "specify" helpers or something? > > > > > > > > > > > > > > > > > > > > Regards, > > > > > > > > > > Evgeny > > > > > > > > > > > > > > > > > _______________________________________________ > > > > 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 evgeny.zislis at gmail.com Sun Feb 18 10:33:58 2007 From: evgeny.zislis at gmail.com (Evgeny) Date: Sun, 18 Feb 2007 17:33:58 +0200 Subject: [rspec-devel] Meta specifications or spec. helpers available? In-Reply-To: <57c63afe0702180718o61be5260y8e40daa1b694de59@mail.gmail.com> References: <57c63afe0702161527j32b234acs34222e69260f0cbf@mail.gmail.com> <57c63afe0702161532l6d24064ek4d541b55a6064a3a@mail.gmail.com> <57c63afe0702180718o61be5260y8e40daa1b694de59@mail.gmail.com> Message-ID: I am thinking about writing a plugin for rspec_on_rails for all the standard validate_x helpers in AR. For example: @user.should_validate_presence_of :login @user.should_validate_uniqueness_of :email etc... On 2/18/07, David Chelimsky wrote: > > On 2/18/07, Evgeny wrote: > > Certainly - I would LOVE to see that blog with this example. > > > http://blog.davidchelimsky.net/articles/2007/02/18/custom-expectation-matchers > > > Just be sure to mention that I actually wrote what I wrote based on this > : > > > http://www.lukeredpath.co.uk/2006/8/29/developing-a-rails-model-using-bdd-and-rspec-part-1 > > Cool. Luke really has a lot of great ideas about RSpec, Rails and > design in general. I encourage everyone to check out his blog: > http://www.lukeredpath.co.uk > > Cheers, > David > > > > > Keep up the great work! :) > > > > > > - evgeny > > > > > > On 2/17/07, David Chelimsky wrote: > > > On 2/16/07, David Chelimsky wrote: > > > > On 2/16/07, Evgeny wrote: > > > > > Or perhaps there is a simple way to add my own specifications, > like: > > > > > > > > > > specify "should be invalid without login" do > > > > > @user.should_be_invalid_without :login > > > > > end > > > > > > > > There will be in a day or two w/ the 0.8-RC1 release. You can do > this > > > > now w/ trunk. Here's how I would do it - different names, etc - but > > > > you can certainly extrapolate your version from this: > > > > > > > > module UserSpecHelper > > > > def require(attr) > > > > return Class.new do > > > > def initialize(attr) > > > > @attr = attr > > > > end > > > > > > > > def matches?(model) > > > > @model = model > > > > model.send("#{@attr.to_s}=".to_sym, nil) > > > > return !model.valid? > > > > end > > > > > > > > def failure_message > > > > "expected #{@model.inspect} to require #{@attr.inspect}" > > > > end > > > > > > > > end > > > > end > > > > end > > > > > > > > context "A user (in general)" do > > > > include UserSpecHelper > > > > > > > > setup do > > > > @user = User.new(:attr1 => value1, :attr2 => value2) > > > > end > > > > > > > > specify "should require :attr1" do > > > > @user.should require(:attr1) > > > > end > > > > end > > > > > > > > specify "should require :attr2" do > > > > @user.should require(:attr2) > > > > end > > > > end > > > > > > > > The idea is that you instantiate @user with ALL of its required > > > > attributes set. The the expectation matcher (the class created in > > > > #require) sets the one you're interested in to nil. > > > > > > > > It would probably perform better if you defined the class > separately, > > > > but I was feeling sneaky when I wrote it ;) > > > > > > > > You can do this today w/ the trunk, and within a few days w/ 0.8-RC1. > > > > > > > > Cheers, > > > > David > > > > > > Actually - this is a GREAT example of a useful custom expectation - > > > Evegny - do you mind if I blog about it? I'll certainly give you > > > credit for suggesting it. > > > > > > > > > > > > > > > > > > > > > > > > > > > On 2/16/07, Evgeny wrote: > > > > > > Greetings All, > > > > > > > > > > > > Is there some way that I could do this : > > > > > > > > > > > > module UserSpecHelper > > > > > > def required_valid_user_attributes > > > > > > { :login => 'monika', > > > > > > :email => ' monika at levinski.com', > > > > > > :password => 'kinky', > > > > > > :password_confirmation => ' kinky', > > > > > > :gender => 'f', > > > > > > :name => 'Monika Levinski' > > > > > > } > > > > > > end > > > > > > end > > > > > > > > > > > > context "A user (in general)" do > > > > > > include UserSpecHelper > > > > > > > > > > > > setup do > > > > > > @user = User.new > > > > > > end > > > > > > > > > > > > required_valid_user_attributes.keys.each do > > |attribute| > > > > > > self.class_eval <<-EOT > > > > > > specify "should be invalid without #{attribute}" do > > > > > > @user.attributes = > > > > > required_valid_user_attributes.except(#{attribute}) > > > > > > @user.should_not_be_valid > > > > > > @user.errors.on(#{attribute}).should == 'is require' > > > > > > @user.#{attribute} = > > > > > required_valid_user_attributes[attribute.to_sym] > > > > > > @user.should_be_valid > > > > > > end > > > > > > EOT > > > > > > end > > > > > > end > > > > > > > > > > > > > > > > > > > > > > > > Because typing the same 7 lines 6 or more times does not look > very > > DRY to > > > > > me ... > > > > > > > > > > > > Or is there some way to write "specify" helpers or something? > > > > > > > > > > > > > > > > > > > > > > > > Regards, > > > > > > > > > > > > Evgeny > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20070218/669008e4/attachment-0001.html From dchelimsky at gmail.com Sun Feb 18 10:54:45 2007 From: dchelimsky at gmail.com (David Chelimsky) Date: Sun, 18 Feb 2007 09:54:45 -0600 Subject: [rspec-devel] Meta specifications or spec. helpers available? In-Reply-To: References: <57c63afe0702161527j32b234acs34222e69260f0cbf@mail.gmail.com> <57c63afe0702161532l6d24064ek4d541b55a6064a3a@mail.gmail.com> <57c63afe0702180718o61be5260y8e40daa1b694de59@mail.gmail.com> Message-ID: <57c63afe0702180754n109b3341p895d7a2e1b2caf56@mail.gmail.com> On 2/18/07, Evgeny wrote: > I am thinking about writing a plugin for rspec_on_rails for all the standard > validate_x helpers in AR. > > For example: > @user.should_validate_presence_of :login > @user.should_validate_uniqueness_of :email Cool. Please be sure to use the expectation matcher syntax if you do: model.should validate_presence_of(:login) model.should validate_uniqueness_of(:email) Cheers, David From noreply at rubyforge.org Sun Feb 18 16:44:07 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 18 Feb 2007 16:44:07 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-8750 ] should[_not]_include backwards compatibility between 0.8.0-RC1 and 0.7.5.1 broken Message-ID: <20070218214407.9B90D5240ADC@rubyforge.org> Bugs item #8750, was opened at 2007-02-18 23:44 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=8750&group_id=797 Category: expectation module Group: None Status: Open Resolution: None Priority: 3 Submitted By: Yurii Rashkovskii (yrashk) Assigned to: Nobody (None) Summary: should[_not]_include backwards compatibility between 0.8.0-RC1 and 0.7.5.1 broken Initial Comment: should_include and should_not_include seems to not to be backwards compatible in 0.8.0-RC1 in case if executing this expectation against has_many: class Document has_many :authors end @document.authors.should_include @homer_simpson will fail with wrong argument type Author (expected Module) While it is easily fixed by moving to new syntax (@document.authors.should include(@homer_simpson)) it seems to not to be backwards compatible with 0.7.5.1 0.8.0-RC1 was declared to be backwards compatible with 0.7.5.1, that's why it is filed as a bug. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=8750&group_id=797 From noreply at rubyforge.org Sun Feb 18 18:08:38 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 18 Feb 2007 18:08:38 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-8750 ] should[_not]_include backwards compatibility between 0.8.0-RC1 and 0.7.5.1 broken Message-ID: <20070218230838.EC4D85240B72@rubyforge.org> Bugs item #8750, was opened at 2007-02-18 21:44 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=8750&group_id=797 >Category: rails plugin Group: None >Status: Closed >Resolution: Accepted Priority: 3 Submitted By: Yurii Rashkovskii (yrashk) >Assigned to: David Chelimsky (dchelimsky) Summary: should[_not]_include backwards compatibility between 0.8.0-RC1 and 0.7.5.1 broken Initial Comment: should_include and should_not_include seems to not to be backwards compatible in 0.8.0-RC1 in case if executing this expectation against has_many: class Document has_many :authors end @document.authors.should_include @homer_simpson will fail with wrong argument type Author (expected Module) While it is easily fixed by moving to new syntax (@document.authors.should include(@homer_simpson)) it seems to not to be backwards compatible with 0.7.5.1 0.8.0-RC1 was declared to be backwards compatible with 0.7.5.1, that's why it is filed as a bug. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-02-18 23:08 Message: Fixed in trunk rev 1504 I moved this over to the rails module category because this is one of those unfortunate Rails-Only problems (for normal collections, should_include was working fine). ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=8750&group_id=797 From noreply at rubyforge.org Mon Feb 19 19:07:55 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 19 Feb 2007 19:07:55 -0500 (EST) Subject: [rspec-devel] [ rspec-Feature Requests-8771 ] Spec::Mocks::BaseExpectation#with converts hash params to array of arrays with #collect Message-ID: <20070220000755.CED655240B87@rubyforge.org> Feature Requests item #8771, was opened at 2007-02-20 00:07 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=8771&group_id=797 Category: mock module Group: None Status: Open Priority: 3 Submitted By: James Hughes (jpath) Assigned to: Nobody (None) Summary: Spec::Mocks::BaseExpectation#with converts hash params to array of arrays with #collect Initial Comment: This setup block: setup do @user = mock("user") User.stub!(:find).and_return(@user) @params = {:cn => "Bilbo Baggins", :telephoneNumber => "416-277-4418", :mail => "bilbo at baggins.com"} end with this spec: specify "should update and save the attributes for user" do @user.should_receive(:update_attributes).with(@params).and_return(true) post :update, :id => "jhughes", :user => @params end and this controller action: def update @user = User.find params[:id] @user.update_attributes params[:user] redirect_to :action => 'list' end results in this failure: Mock 'user' expected :update_attributes with ([:telephoneNumber, "416-277-4418"], [:mail, "bilbo at baggins.com"], [:cn, "Bilbo Baggins"]) but received it with ({"cn"=>"Bilbo Baggins", "telephoneNumber"=>"416-277-4418", "mail"=>"bilbo at baggins.com" }) As pointed out by Jerry West on rspec-users, the hash that is passed to #with is getting Enumerable#collect called on it and converted to an array of arrays. To quote Jerry: "If you check out $GEM_DIR/rspec-0.7.5.1/lib/spec/mocks/message_expectation.rb you will see that #with() passes your hash to a new instance of ArgumentExpectation, which is defined in $GEM_DIR/rspec-0.7.5.1/lib/spec/mocks/argument_expectation.rb . There you will see that a hash is a LiteralArgConstraint (as opposed to :anything, :numeric, and the other parameters that #with() accepts). The interesting code is around line 89 in #process_arg_constraints() where your hash is converted one item at a time using the normal Ruby Enumerable routine #collect(). Which is where the side-effect happens." I'm running off of trunk, rev. 1514 as of this writing. Note that I attempted to do a "bug reduction" with this, distilling things down to the simplest thing that would produce the same error (i.e. without all the rails stuff), and I couldn't get it to work. This is what I came up with: class Test def Test.amethod params true end end context "passing a hash to #with" do specify "should pass a hash to #with" do @params = { :param1 => "foo", :param2 => "bar"} Test.should_receive(:amethod).with(@params).and_return(true) Test.amethod @params end end This passes. My rspec/mock object-fu is not sufficient to spot the difference between the two examples. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=8771&group_id=797 From noreply at rubyforge.org Tue Feb 20 06:03:22 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 20 Feb 2007 06:03:22 -0500 (EST) Subject: [rspec-devel] [ rspec-Feature Requests-8771 ] Spec::Mocks::BaseExpectation#with converts hash params to array of arrays with #collect Message-ID: <20070220110322.70CE652408DC@rubyforge.org> Feature Requests item #8771, was opened at 2007-02-20 00:07 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=8771&group_id=797 Category: mock module Group: None >Status: Closed Priority: 3 Submitted By: James Hughes (jpath) >Assigned to: David Chelimsky (dchelimsky) Summary: Spec::Mocks::BaseExpectation#with converts hash params to array of arrays with #collect Initial Comment: This setup block: setup do @user = mock("user") User.stub!(:find).and_return(@user) @params = {:cn => "Bilbo Baggins", :telephoneNumber => "416-277-4418", :mail => "bilbo at baggins.com"} end with this spec: specify "should update and save the attributes for user" do @user.should_receive(:update_attributes).with(@params).and_return(true) post :update, :id => "jhughes", :user => @params end and this controller action: def update @user = User.find params[:id] @user.update_attributes params[:user] redirect_to :action => 'list' end results in this failure: Mock 'user' expected :update_attributes with ([:telephoneNumber, "416-277-4418"], [:mail, "bilbo at baggins.com"], [:cn, "Bilbo Baggins"]) but received it with ({"cn"=>"Bilbo Baggins", "telephoneNumber"=>"416-277-4418", "mail"=>"bilbo at baggins.com" }) As pointed out by Jerry West on rspec-users, the hash that is passed to #with is getting Enumerable#collect called on it and converted to an array of arrays. To quote Jerry: "If you check out $GEM_DIR/rspec-0.7.5.1/lib/spec/mocks/message_expectation.rb you will see that #with() passes your hash to a new instance of ArgumentExpectation, which is defined in $GEM_DIR/rspec-0.7.5.1/lib/spec/mocks/argument_expectation.rb . There you will see that a hash is a LiteralArgConstraint (as opposed to :anything, :numeric, and the other parameters that #with() accepts). The interesting code is around line 89 in #process_arg_constraints() where your hash is converted one item at a time using the normal Ruby Enumerable routine #collect(). Which is where the side-effect happens." I'm running off of trunk, rev. 1514 as of this writing. Note that I attempted to do a "bug reduction" with this, distilling things down to the simplest thing that would produce the same error (i.e. without all the rails stuff), and I couldn't get it to work. This is what I came up with: class Test def Test.amethod params true end end context "passing a hash to #with" do specify "should pass a hash to #with" do @params = { :param1 => "foo", :param2 => "bar"} Test.should_receive(:amethod).with(@params).and_return(true) Test.amethod @params end end This passes. My rspec/mock object-fu is not sufficient to spot the difference between the two examples. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-02-20 11:03 Message: Fixed in trunk rev (1515) The problem has two parts. Pass/Fail and message. It turns out that pass/fail is working correctly. The spec is failing because Rails stringifies the keys in the Hash. The RSpec bug here is in the message, not whether or not it passes or fails. I've fixed the message so it will show you the two hashes (expected and actual), but I think that getting RSpec to make decisions about stringifying keys would be a mistake. To that end, I think the right thing is for you to change your spec to expect a Hash with stringy keys. Feel free to take this up on the mailing list if you disagree. Cheers, David ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=8771&group_id=797 From noreply at rubyforge.org Wed Feb 21 06:28:29 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 21 Feb 2007 06:28:29 -0500 (EST) Subject: [rspec-devel] [ rspec-Feature Requests-8783 ] auto generate spec names from last expectation Message-ID: <20070221112829.4162B5240A00@rubyforge.org> Feature Requests item #8783, was opened at 2007-02-21 11:28 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=8783&group_id=797 Category: expectation module Group: None Status: Open Priority: 3 Submitted By: David Chelimsky (dchelimsky) Assigned to: David Chelimsky (dchelimsky) Summary: auto generate spec names from last expectation Initial Comment: Two specs from the stack example: specify "should not be empty" do @stack.should_not be_empty end specify "should remain not empty after #peek" do @stack.peek @stack.should_not be_empty end In the second spec, the name "should remain not empty after #peek" adds value because it is different from the actual expectation, but the first one is obvious duplication between the spec name and the expectation. That one should be auto generated: specify do @stack.should_not be_empty end ... A stack with one item - should not be empty For that to work, should and should_not will both need to be involved (since they are the only ones who know whether it should or should_not). Perhaps something like: if matcher.responds_to?(name) magic_autogeneration_callback("should #{matcher.name}") end or something like that... ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=8783&group_id=797 From noreply at rubyforge.org Wed Feb 21 08:38:22 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 21 Feb 2007 08:38:22 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-8786 ] 0.8.0-RC1 rake tasks seems to behave unobvious if test database does not exist Message-ID: <20070221133822.70D305240987@rubyforge.org> Bugs item #8786, was opened at 2007-02-21 15:38 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=8786&group_id=797 Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: Yurii Rashkovskii (yrashk) Assigned to: Nobody (None) Summary: 0.8.0-RC1 rake tasks seems to behave unobvious if test database does not exist Initial Comment: If there is no test database, rake spec just tells nothing about this: $ rake spec /opt/local/bin/rake:17:Warning: require_gem is obsolete. Use gem instead. (in /Users/yrashk/somewhere/) rake aborted! RSpec failures (See full trace by running task with --trace) It seems to be not a major bug, but a kind of an unobvious behavior. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=8786&group_id=797 From noreply at rubyforge.org Wed Feb 21 10:05:35 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 21 Feb 2007 10:05:35 -0500 (EST) Subject: [rspec-devel] [ rspec-Feature Requests-8783 ] auto generate spec names from last expectation Message-ID: <20070221150535.51C63524211A@rubyforge.org> Feature Requests item #8783, was opened at 2007-02-21 11:28 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=8783&group_id=797 Category: expectation module Group: None Status: Open Priority: 3 Submitted By: David Chelimsky (dchelimsky) Assigned to: David Chelimsky (dchelimsky) Summary: auto generate spec names from last expectation Initial Comment: Two specs from the stack example: specify "should not be empty" do @stack.should_not be_empty end specify "should remain not empty after #peek" do @stack.peek @stack.should_not be_empty end In the second spec, the name "should remain not empty after #peek" adds value because it is different from the actual expectation, but the first one is obvious duplication between the spec name and the expectation. That one should be auto generated: specify do @stack.should_not be_empty end ... A stack with one item - should not be empty For that to work, should and should_not will both need to be involved (since they are the only ones who know whether it should or should_not). Perhaps something like: if matcher.responds_to?(name) magic_autogeneration_callback("should #{matcher.name}") end or something like that... ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-02-21 15:05 Message: Got this started - works for the following as of trunk(1518): context "37" do specify do 37.should equal(37) end end output: 37 - should equal(37) ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=8783&group_id=797 From noreply at rubyforge.org Wed Feb 21 10:27:08 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 21 Feb 2007 10:27:08 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-8789 ] --line and --spec not working when the context has parenhesis in the name Message-ID: <20070221152708.DBC595242125@rubyforge.org> Bugs item #8789, was opened at 2007-02-21 10:27 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=8789&group_id=797 Category: runner module Group: None Status: Open Resolution: None Priority: 3 Submitted By: Aslak Helles?y (aslak_hellesoy) Assigned to: David Chelimsky (dchelimsky) Summary: --line and --spec not working when the context has parenhesis in the name Initial Comment: Failing spec attached. One failure: ruby bin/spec spec/spec/runner/spec_matcher_spec.rb ...F..... 1) 'SpecMatcher should match spec only with parentheses in context name' FAILED expected true, got false (using .equal?) ./spec/spec/runner/spec_matcher_spec.rb:24: Finished in 0.003095 seconds 9 specifications, 1 failure ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=8789&group_id=797 From noreply at rubyforge.org Wed Feb 21 11:11:17 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 21 Feb 2007 11:11:17 -0500 (EST) Subject: [rspec-devel] [ rspec-Feature Requests-8783 ] auto generate spec names from last expectation Message-ID: <20070221161117.9D3945242124@rubyforge.org> Feature Requests item #8783, was opened at 2007-02-21 11:28 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=8783&group_id=797 Category: expectation module Group: None >Status: Closed Priority: 3 Submitted By: David Chelimsky (dchelimsky) Assigned to: David Chelimsky (dchelimsky) Summary: auto generate spec names from last expectation Initial Comment: Two specs from the stack example: specify "should not be empty" do @stack.should_not be_empty end specify "should remain not empty after #peek" do @stack.peek @stack.should_not be_empty end In the second spec, the name "should remain not empty after #peek" adds value because it is different from the actual expectation, but the first one is obvious duplication between the spec name and the expectation. That one should be auto generated: specify do @stack.should_not be_empty end ... A stack with one item - should not be empty For that to work, should and should_not will both need to be involved (since they are the only ones who know whether it should or should_not). Perhaps something like: if matcher.responds_to?(name) magic_autogeneration_callback("should #{matcher.name}") end or something like that... ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-02-21 16:11 Message: Fixed in trunk (rev 1519) OK - this works now for everything but "should change" and "should satisfy", which both take blocks, rendering them pretty useless for autogeneration. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-02-21 15:05 Message: Got this started - works for the following as of trunk(1518): context "37" do specify do 37.should equal(37) end end output: 37 - should equal(37) ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=8783&group_id=797 From noreply at rubyforge.org Thu Feb 22 14:42:00 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 22 Feb 2007 14:42:00 -0500 (EST) Subject: [rspec-devel] [ rspec-Feature Requests-8815 ] should_receive(:method).with('val') should report the arg it actually received instead of saying it received it 0 times. Message-ID: <20070222194200.D6EAF5241556@rubyforge.org> Feature Requests item #8815, was opened at 2007-02-22 12:42 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=8815&group_id=797 Category: mock module Group: None Status: Open Priority: 3 Submitted By: Martin Emde (zraii) Assigned to: Nobody (None) Summary: should_receive(:method).with('val') should report the arg it actually received instead of saying it received it 0 times. Initial Comment: Right now, if you have a should_receive(:method).with(:any_arg_here) and the method receives the message but with a different arg, it just says: Mock 'object' expected method with (:any_arg_here) once, but received it 0 times This is not very useful when you're trying to figure out if it's not being called at all, or if it's being called with the wrong arg. A spec that shows this would be something like this: context "A Mock Object" do setup do @m = mock('object') end specify "should receive :method with 'value'" do @m.should_receive(:method).with('value') @m.method('other value') end end This spec will fail obviously, but the failure message will not tell you anything besides that the 'should receive' was not received, not that it *was* in fact received, just with the wrong arguments. Quite a bit of difference when you're trying to debug some code. I appreciate everyone on rspec's hard work. Keep it up. -Martin ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=8815&group_id=797 From noreply at rubyforge.org Thu Feb 22 15:58:12 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 22 Feb 2007 15:58:12 -0500 (EST) Subject: [rspec-devel] [ rspec-Feature Requests-8815 ] should_receive(:method).with('val') should report the arg it actually received instead of saying it received it 0 times. Message-ID: <20070222205812.8518A52421B8@rubyforge.org> Feature Requests item #8815, was opened at 2007-02-22 19:42 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=8815&group_id=797 Category: mock module Group: None >Status: Closed Priority: 3 Submitted By: Martin Emde (zraii) >Assigned to: David Chelimsky (dchelimsky) Summary: should_receive(:method).with('val') should report the arg it actually received instead of saying it received it 0 times. Initial Comment: Right now, if you have a should_receive(:method).with(:any_arg_here) and the method receives the message but with a different arg, it just says: Mock 'object' expected method with (:any_arg_here) once, but received it 0 times This is not very useful when you're trying to figure out if it's not being called at all, or if it's being called with the wrong arg. A spec that shows this would be something like this: context "A Mock Object" do setup do @m = mock('object') end specify "should receive :method with 'value'" do @m.should_receive(:method).with('value') @m.method('other value') end end This spec will fail obviously, but the failure message will not tell you anything besides that the 'should receive' was not received, not that it *was* in fact received, just with the wrong arguments. Quite a bit of difference when you're trying to debug some code. I appreciate everyone on rspec's hard work. Keep it up. -Martin ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-02-22 20:58 Message: Actually, this is already fixed in 0.8.0-RC1. Here's the output from your example: $ spec bug8815.rb F 1) Spec::Mocks::MockExpectationError in 'A Mock Object should receive :method with 'value'' Mock 'object' expected :method with ("value") but received it with ("other value") ./bug8815.rb:8: Finished in 0.001214 seconds 1 specification, 1 failure Cheers, David ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=8815&group_id=797 From noreply at rubyforge.org Fri Feb 23 09:15:34 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 23 Feb 2007 09:15:34 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-8786 ] 0.8.0-RC1 rake tasks seems to behave unobvious if test database does not exist Message-ID: <20070223141535.04F3F52421D6@rubyforge.org> Bugs item #8786, was opened at 2007-02-21 13:38 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=8786&group_id=797 Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: Yurii Rashkovskii (yrashk) Assigned to: Nobody (None) Summary: 0.8.0-RC1 rake tasks seems to behave unobvious if test database does not exist Initial Comment: If there is no test database, rake spec just tells nothing about this: $ rake spec /opt/local/bin/rake:17:Warning: require_gem is obsolete. Use gem instead. (in /Users/yrashk/somewhere/) rake aborted! RSpec failures (See full trace by running task with --trace) It seems to be not a major bug, but a kind of an unobvious behavior. ---------------------------------------------------------------------- Comment By: James Hughes (jpath) Date: 2007-02-23 14:15 Message: I can confirm this. I have the require lines for ActiveRecord commented out in my local rspec_on_rails in rails.rb. The rake task just dies when it gets to running the model tests. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=8786&group_id=797 From noreply at rubyforge.org Fri Feb 23 19:03:37 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 23 Feb 2007 19:03:37 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-8843 ] Broken link to rails svn repository, on website Message-ID: <20070224000337.69F0E52421E0@rubyforge.org> Bugs item #8843, was opened at 2007-02-24 00:03 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=8843&group_id=797 Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: Scott Taylor (smtlaissezfaire) Assigned to: Nobody (None) Summary: Broken link to rails svn repository, on website Initial Comment: One of the links to the subversion repository is wrong (at http://rspec.rubyforge.org/documentation/rails/install.html). Under the heading which starts: "If your own project is in Subversion and you?d like RSpec on Rails to always follow HEAD, install with -x:" the second link: "ruby script/plugin install -x svn://rubyforge.org/var/svn/rspec/trunk/ rspec_on_rails/vendor/plugin/rspec_on_rails" should be: "ruby script/plugin install -x svn://rubyforge.org/var/svn/rspec/trunk/ rspec_on_rails/vendor/plugins/rspec_on_rails" (The "plugins" is missing an "s") ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=8843&group_id=797 From noreply at rubyforge.org Sat Feb 24 06:41:58 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sat, 24 Feb 2007 06:41:58 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-8843 ] Broken link to rails svn repository, on website Message-ID: <20070224114159.07F955240B9E@rubyforge.org> Bugs item #8843, was opened at 2007-02-23 19:03 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=8843&group_id=797 Category: rails plugin Group: None >Status: Closed >Resolution: Accepted Priority: 3 Submitted By: Scott Taylor (smtlaissezfaire) >Assigned to: Aslak Helles?y (aslak_hellesoy) Summary: Broken link to rails svn repository, on website Initial Comment: One of the links to the subversion repository is wrong (at http://rspec.rubyforge.org/documentation/rails/install.html). Under the heading which starts: "If your own project is in Subversion and you?d like RSpec on Rails to always follow HEAD, install with -x:" the second link: "ruby script/plugin install -x svn://rubyforge.org/var/svn/rspec/trunk/ rspec_on_rails/vendor/plugin/rspec_on_rails" should be: "ruby script/plugin install -x svn://rubyforge.org/var/svn/rspec/trunk/ rspec_on_rails/vendor/plugins/rspec_on_rails" (The "plugins" is missing an "s") ---------------------------------------------------------------------- >Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-02-24 06:41 Message: This has been fixed in svn and will be corrected the next time the website is published. Currently this only happens at the same time as a release is made. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=8843&group_id=797 From noreply at rubyforge.org Mon Feb 26 07:07:29 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 26 Feb 2007 07:07:29 -0500 (EST) Subject: [rspec-devel] [ rspec-Feature Requests-8139 ] & quot; not implemented& quot; message for specs yet to be implemented Message-ID: <20070226120729.69F8652409A1@rubyforge.org> Feature Requests item #8139, was opened at 2007-01-25 11:28 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=8139&group_id=797 Category: runner module Group: None Status: Open Priority: 3 Submitted By: David Chelimsky (dchelimsky) Assigned to: Nobody (None) Summary: &quot;not implemented&quot; message for specs yet to be implemented Initial Comment: If I am defining the behaviour of a class, I might make a list like this: Money behaviour: - should parse - should add - should subtract - should multiply - should handle division by 0 - should handle conversion I may not know what all of those mean yet, but that is a starting point. I'd like to be able to put that right into specs and have RSpec tell me that I have yet to implement them: context "Money behaviour" do specify "should parse" specify "should add" specify "should subtract" specify "should multiply" specify "should handle division by 0" specify "should handle conversion" end Note that each specify message has no block. Given some command line option, RSpec would collect these during a spec run and add the count to the summary: ===== Finished in 3.212354 seconds 647 specifications, 0 failures, 25 not yet implemented ===== Combined with the --format specdoc (or -fs) option, the report would look like this: ===== Money behaviour: - should parse - should add - should subtract - should multiply - should handle division by 0 (NOT IMPLEMENTED - should handle conversion (NOT IMPLEMENTED) Finished in 0.212354 seconds 6 specifications, 0 failures, 2 not yet implemented ===== This would a great aid in monitoring progress during an iteration. ---------------------------------------------------------------------- Comment By: Ashley Moran (ashley_moran) Date: 2007-02-26 12:07 Message: I'd really like this feature. I sometimes get into a situation where I need to leave failing specs and work on something else, and the noise is distracting. I'm tempted to suggest that 4 statuses would be useful: pass, fail, not yet implemented, needs fixing. I don't know if that would be a good idea, or over-complex. ---------------------------------------------------------------------- Comment By: Ian Dees (undees) Date: 2007-01-28 22:48 Message: At work, we have a tool that generates context/specify blocks from our test case descriptions. Here's what we use: 1) A NonImplementedTest class with an "implemented?" method returning false. 2) A module-level this_test method returning an instance of NonImplementedTest. So our tool can generate blocks that look like this: context "A widget" do specify "should foobar the frobnitz" do # Text from test case: # 1) Click the widget button. # 2) Make sure the frobnitz is foobar'ed. this_test.should_be_implemented end end That way, we start off red until all the tests are implemented and the software passes them. ---------------------------------------------------------------------- Comment By: Brian Takita (btakita) Date: 2007-01-28 04:41 Message: This looks like a good feature. I like the idea of being able to specify what the software is supposed to do before implementing it. The specify method without a block transition s naturally to implementing a full spec. I remember the conclusion of the other feature request was to use a TODO statement, which in my opinion in not very semantic. ---------------------------------------------------------------------- Comment By: Wilson Bilkovich (wilson) Date: 2007-01-27 00:12 Message: Hi David, I was just giving you a hard time. I remain highly in favor of this feature. I would be happy to help implement it, and/or stuff people who don't like it into trashcans at RailsConf. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-01-26 11:29 Message: Hi Wilson, Funny - I forgot about that. OK - first of all these requests aren't the same. What [#6396] is asking for is a way to stop code from being executed using a keyword disable_specify. What I'm proposing here is different. It's a non-code place-holder right in the spec so I don't have to keep it elsewhere. Now, reading through the comments on that thread, I see that this idea was already proposed (by me, as it turns out - I'm a bit too young for senility - perhaps a vacation is in order), however even in that proposal I was talking about a special keyword. This proposal is a little different. It lets me do the same thing but with something that feels more integrated to me - it's the same keyword (specify), and it is noted as something different only by the absence of the block. So to resolve the un-implemented specs I have to add a block and add code, not change keywords. I guess you could argue that the keyword would make things more obvious when looking at the code, but if we're adding keywords I'd rather have them be more aligned w/ the BDD message - things like "story" and "behaviour". ---------------------------------------------------------------------- Comment By: Wilson Bilkovich (wilson) Date: 2007-01-26 06:32 Message: Duplicate? :) http://rubyforge.org/tracker/index.php?func=detail&aid=6396&group_id=797&atid=3152 ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=8139&group_id=797 From noreply at rubyforge.org Mon Feb 26 07:47:22 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 26 Feb 2007 07:47:22 -0500 (EST) Subject: [rspec-devel] [ rspec-Feature Requests-8139 ] & amp; quot; not implemented& amp; quot; message for specs yet to be implemented Message-ID: <20070226124723.15E6E5242136@rubyforge.org> Feature Requests item #8139, was opened at 2007-01-25 11:28 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=8139&group_id=797 Category: runner module Group: None Status: Open Priority: 3 Submitted By: David Chelimsky (dchelimsky) Assigned to: Nobody (None) >Summary: &amp;quot;not implemented&amp;quot; message for specs yet to be implemented Initial Comment: If I am defining the behaviour of a class, I might make a list like this: Money behaviour: - should parse - should add - should subtract - should multiply - should handle division by 0 - should handle conversion I may not know what all of those mean yet, but that is a starting point. I'd like to be able to put that right into specs and have RSpec tell me that I have yet to implement them: context "Money behaviour" do specify "should parse" specify "should add" specify "should subtract" specify "should multiply" specify "should handle division by 0" specify "should handle conversion" end Note that each specify message has no block. Given some command line option, RSpec would collect these during a spec run and add the count to the summary: ===== Finished in 3.212354 seconds 647 specifications, 0 failures, 25 not yet implemented ===== Combined with the --format specdoc (or -fs) option, the report would look like this: ===== Money behaviour: - should parse - should add - should subtract - should multiply - should handle division by 0 (NOT IMPLEMENTED - should handle conversion (NOT IMPLEMENTED) Finished in 0.212354 seconds 6 specifications, 0 failures, 2 not yet implemented ===== This would a great aid in monitoring progress during an iteration. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-02-26 12:47 Message: Ashley - between your suggestion of 4 states and Yurii's specify_negatively, I think perhaps something like this might work: specify "description", :state => state Where, for now, state could be any of the 4 you suggested. Also, the default state would be "pass" when there is a block (but no state submitted) and "fail" when there is no block (and no state submitted). WDYT? ---------------------------------------------------------------------- Comment By: Ashley Moran (ashley_moran) Date: 2007-02-26 12:07 Message: I'd really like this feature. I sometimes get into a situation where I need to leave failing specs and work on something else, and the noise is distracting. I'm tempted to suggest that 4 statuses would be useful: pass, fail, not yet implemented, needs fixing. I don't know if that would be a good idea, or over-complex. ---------------------------------------------------------------------- Comment By: Ian Dees (undees) Date: 2007-01-28 22:48 Message: At work, we have a tool that generates context/specify blocks from our test case descriptions. Here's what we use: 1) A NonImplementedTest class with an "implemented?" method returning false. 2) A module-level this_test method returning an instance of NonImplementedTest. So our tool can generate blocks that look like this: context "A widget" do specify "should foobar the frobnitz" do # Text from test case: # 1) Click the widget button. # 2) Make sure the frobnitz is foobar'ed. this_test.should_be_implemented end end That way, we start off red until all the tests are implemented and the software passes them. ---------------------------------------------------------------------- Comment By: Brian Takita (btakita) Date: 2007-01-28 04:41 Message: This looks like a good feature. I like the idea of being able to specify what the software is supposed to do before implementing it. The specify method without a block transition s naturally to implementing a full spec. I remember the conclusion of the other feature request was to use a TODO statement, which in my opinion in not very semantic. ---------------------------------------------------------------------- Comment By: Wilson Bilkovich (wilson) Date: 2007-01-27 00:12 Message: Hi David, I was just giving you a hard time. I remain highly in favor of this feature. I would be happy to help implement it, and/or stuff people who don't like it into trashcans at RailsConf. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-01-26 11:29 Message: Hi Wilson, Funny - I forgot about that. OK - first of all these requests aren't the same. What [#6396] is asking for is a way to stop code from being executed using a keyword disable_specify. What I'm proposing here is different. It's a non-code place-holder right in the spec so I don't have to keep it elsewhere. Now, reading through the comments on that thread, I see that this idea was already proposed (by me, as it turns out - I'm a bit too young for senility - perhaps a vacation is in order), however even in that proposal I was talking about a special keyword. This proposal is a little different. It lets me do the same thing but with something that feels more integrated to me - it's the same keyword (specify), and it is noted as something different only by the absence of the block. So to resolve the un-implemented specs I have to add a block and add code, not change keywords. I guess you could argue that the keyword would make things more obvious when looking at the code, but if we're adding keywords I'd rather have them be more aligned w/ the BDD message - things like "story" and "behaviour". ---------------------------------------------------------------------- Comment By: Wilson Bilkovich (wilson) Date: 2007-01-26 06:32 Message: Duplicate? :) http://rubyforge.org/tracker/index.php?func=detail&aid=6396&group_id=797&atid=3152 ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=8139&group_id=797 From noreply at rubyforge.org Mon Feb 26 07:48:54 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 26 Feb 2007 07:48:54 -0500 (EST) Subject: [rspec-devel] [ rspec-Feature Requests-8139 ] & amp; amp; quot; not implemented& amp; amp; quot; message for specs yet to be implemented Message-ID: <20070226124854.98E215242135@rubyforge.org> Feature Requests item #8139, was opened at 2007-01-25 11:28 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=8139&group_id=797 Category: runner module Group: None Status: Open Priority: 3 Submitted By: David Chelimsky (dchelimsky) Assigned to: Nobody (None) >Summary: &amp;amp;quot;not implemented&amp;amp;quot; message for specs yet to be implemented Initial Comment: If I am defining the behaviour of a class, I might make a list like this: Money behaviour: - should parse - should add - should subtract - should multiply - should handle division by 0 - should handle conversion I may not know what all of those mean yet, but that is a starting point. I'd like to be able to put that right into specs and have RSpec tell me that I have yet to implement them: context "Money behaviour" do specify "should parse" specify "should add" specify "should subtract" specify "should multiply" specify "should handle division by 0" specify "should handle conversion" end Note that each specify message has no block. Given some command line option, RSpec would collect these during a spec run and add the count to the summary: ===== Finished in 3.212354 seconds 647 specifications, 0 failures, 25 not yet implemented ===== Combined with the --format specdoc (or -fs) option, the report would look like this: ===== Money behaviour: - should parse - should add - should subtract - should multiply - should handle division by 0 (NOT IMPLEMENTED - should handle conversion (NOT IMPLEMENTED) Finished in 0.212354 seconds 6 specifications, 0 failures, 2 not yet implemented ===== This would a great aid in monitoring progress during an iteration. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-02-26 12:48 Message: Sorry - "not implemented" when there is no block or state specified (not "fail"). ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-02-26 12:47 Message: Ashley - between your suggestion of 4 states and Yurii's specify_negatively, I think perhaps something like this might work: specify "description", :state => state Where, for now, state could be any of the 4 you suggested. Also, the default state would be "pass" when there is a block (but no state submitted) and "fail" when there is no block (and no state submitted). WDYT? ---------------------------------------------------------------------- Comment By: Ashley Moran (ashley_moran) Date: 2007-02-26 12:07 Message: I'd really like this feature. I sometimes get into a situation where I need to leave failing specs and work on something else, and the noise is distracting. I'm tempted to suggest that 4 statuses would be useful: pass, fail, not yet implemented, needs fixing. I don't know if that would be a good idea, or over-complex. ---------------------------------------------------------------------- Comment By: Ian Dees (undees) Date: 2007-01-28 22:48 Message: At work, we have a tool that generates context/specify blocks from our test case descriptions. Here's what we use: 1) A NonImplementedTest class with an "implemented?" method returning false. 2) A module-level this_test method returning an instance of NonImplementedTest. So our tool can generate blocks that look like this: context "A widget" do specify "should foobar the frobnitz" do # Text from test case: # 1) Click the widget button. # 2) Make sure the frobnitz is foobar'ed. this_test.should_be_implemented end end That way, we start off red until all the tests are implemented and the software passes them. ---------------------------------------------------------------------- Comment By: Brian Takita (btakita) Date: 2007-01-28 04:41 Message: This looks like a good feature. I like the idea of being able to specify what the software is supposed to do before implementing it. The specify method without a block transition s naturally to implementing a full spec. I remember the conclusion of the other feature request was to use a TODO statement, which in my opinion in not very semantic. ---------------------------------------------------------------------- Comment By: Wilson Bilkovich (wilson) Date: 2007-01-27 00:12 Message: Hi David, I was just giving you a hard time. I remain highly in favor of this feature. I would be happy to help implement it, and/or stuff people who don't like it into trashcans at RailsConf. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-01-26 11:29 Message: Hi Wilson, Funny - I forgot about that. OK - first of all these requests aren't the same. What [#6396] is asking for is a way to stop code from being executed using a keyword disable_specify. What I'm proposing here is different. It's a non-code place-holder right in the spec so I don't have to keep it elsewhere. Now, reading through the comments on that thread, I see that this idea was already proposed (by me, as it turns out - I'm a bit too young for senility - perhaps a vacation is in order), however even in that proposal I was talking about a special keyword. This proposal is a little different. It lets me do the same thing but with something that feels more integrated to me - it's the same keyword (specify), and it is noted as something different only by the absence of the block. So to resolve the un-implemented specs I have to add a block and add code, not change keywords. I guess you could argue that the keyword would make things more obvious when looking at the code, but if we're adding keywords I'd rather have them be more aligned w/ the BDD message - things like "story" and "behaviour". ---------------------------------------------------------------------- Comment By: Wilson Bilkovich (wilson) Date: 2007-01-26 06:32 Message: Duplicate? :) http://rubyforge.org/tracker/index.php?func=detail&aid=6396&group_id=797&atid=3152 ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=8139&group_id=797 From noreply at rubyforge.org Mon Feb 26 09:53:36 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 26 Feb 2007 09:53:36 -0500 (EST) Subject: [rspec-devel] [ rspec-Feature Requests-8139 ] & amp; amp; quot; not implemented& amp; amp; quot; message for specs yet to be implemented Message-ID: <20070226145337.142315241B60@rubyforge.org> Feature Requests item #8139, was opened at 2007-01-25 11:28 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=8139&group_id=797 Category: runner module Group: None Status: Open Priority: 3 Submitted By: David Chelimsky (dchelimsky) Assigned to: Nobody (None) Summary: &amp;amp;quot;not implemented&amp;amp;quot; message for specs yet to be implemented Initial Comment: If I am defining the behaviour of a class, I might make a list like this: Money behaviour: - should parse - should add - should subtract - should multiply - should handle division by 0 - should handle conversion I may not know what all of those mean yet, but that is a starting point. I'd like to be able to put that right into specs and have RSpec tell me that I have yet to implement them: context "Money behaviour" do specify "should parse" specify "should add" specify "should subtract" specify "should multiply" specify "should handle division by 0" specify "should handle conversion" end Note that each specify message has no block. Given some command line option, RSpec would collect these during a spec run and add the count to the summary: ===== Finished in 3.212354 seconds 647 specifications, 0 failures, 25 not yet implemented ===== Combined with the --format specdoc (or -fs) option, the report would look like this: ===== Money behaviour: - should parse - should add - should subtract - should multiply - should handle division by 0 (NOT IMPLEMENTED - should handle conversion (NOT IMPLEMENTED) Finished in 0.212354 seconds 6 specifications, 0 failures, 2 not yet implemented ===== This would a great aid in monitoring progress during an iteration. ---------------------------------------------------------------------- Comment By: Ashley Moran (ashley_moran) Date: 2007-02-26 14:53 Message: David, I like that - it puts all the ideas in one consistent way. Not implemented would definitely be best for a spec with no block. Being a TextMate whore, I'm interested to know what the HTML output should be like. (I live off command-R .) I think for the individual specs, fail->red, pass->green, needs fixing->orange, not implemented->blue would be helpful. What I'm not sure about is whether the presence of a "not implemented" or "needs fixing" spec should constitute a failure of the whole spec file. Possibly something like this would help: specify "some unimportant features", :state => :needs_fixing, :blocker => false do # some failing specs end Not sure if this is over-engineering or not - it might be useful for continous integration (we we sadly don't use yet for rails) ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-02-26 12:48 Message: Sorry - "not implemented" when there is no block or state specified (not "fail"). ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-02-26 12:47 Message: Ashley - between your suggestion of 4 states and Yurii's specify_negatively, I think perhaps something like this might work: specify "description", :state => state Where, for now, state could be any of the 4 you suggested. Also, the default state would be "pass" when there is a block (but no state submitted) and "fail" when there is no block (and no state submitted). WDYT? ---------------------------------------------------------------------- Comment By: Ashley Moran (ashley_moran) Date: 2007-02-26 12:07 Message: I'd really like this feature. I sometimes get into a situation where I need to leave failing specs and work on something else, and the noise is distracting. I'm tempted to suggest that 4 statuses would be useful: pass, fail, not yet implemented, needs fixing. I don't know if that would be a good idea, or over-complex. ---------------------------------------------------------------------- Comment By: Ian Dees (undees) Date: 2007-01-28 22:48 Message: At work, we have a tool that generates context/specify blocks from our test case descriptions. Here's what we use: 1) A NonImplementedTest class with an "implemented?" method returning false. 2) A module-level this_test method returning an instance of NonImplementedTest. So our tool can generate blocks that look like this: context "A widget" do specify "should foobar the frobnitz" do # Text from test case: # 1) Click the widget button. # 2) Make sure the frobnitz is foobar'ed. this_test.should_be_implemented end end That way, we start off red until all the tests are implemented and the software passes them. ---------------------------------------------------------------------- Comment By: Brian Takita (btakita) Date: 2007-01-28 04:41 Message: This looks like a good feature. I like the idea of being able to specify what the software is supposed to do before implementing it. The specify method without a block transition s naturally to implementing a full spec. I remember the conclusion of the other feature request was to use a TODO statement, which in my opinion in not very semantic. ---------------------------------------------------------------------- Comment By: Wilson Bilkovich (wilson) Date: 2007-01-27 00:12 Message: Hi David, I was just giving you a hard time. I remain highly in favor of this feature. I would be happy to help implement it, and/or stuff people who don't like it into trashcans at RailsConf. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-01-26 11:29 Message: Hi Wilson, Funny - I forgot about that. OK - first of all these requests aren't the same. What [#6396] is asking for is a way to stop code from being executed using a keyword disable_specify. What I'm proposing here is different. It's a non-code place-holder right in the spec so I don't have to keep it elsewhere. Now, reading through the comments on that thread, I see that this idea was already proposed (by me, as it turns out - I'm a bit too young for senility - perhaps a vacation is in order), however even in that proposal I was talking about a special keyword. This proposal is a little different. It lets me do the same thing but with something that feels more integrated to me - it's the same keyword (specify), and it is noted as something different only by the absence of the block. So to resolve the un-implemented specs I have to add a block and add code, not change keywords. I guess you could argue that the keyword would make things more obvious when looking at the code, but if we're adding keywords I'd rather have them be more aligned w/ the BDD message - things like "story" and "behaviour". ---------------------------------------------------------------------- Comment By: Wilson Bilkovich (wilson) Date: 2007-01-26 06:32 Message: Duplicate? :) http://rubyforge.org/tracker/index.php?func=detail&aid=6396&group_id=797&atid=3152 ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=8139&group_id=797 From noreply at rubyforge.org Mon Feb 26 10:13:07 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 26 Feb 2007 10:13:07 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-8887 ] Should have RJS matches DOM IDs as substrings Message-ID: <20070226151308.044C45241B60@rubyforge.org> Bugs item #8887, was opened at 2007-02-26 15:13 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=8887&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Ashley Moran (ashley_moran) Assigned to: Nobody (None) Summary: Should have RJS matches DOM IDs as substrings Initial Comment: In RSpec 0.7.5.1, given:
and RJS to insert a partial at the bottom of the div, the following spec passes: response.should_have_rjs :insert_html, :bottom, "my_div" but so does this: response.should_have_rjs :insert_html, :bottom, "y_di" because the string "y_di" is a substring of the ID. Is this intended? To create robust specs, you need to do this: response.should_have_rjs :insert_html, :bottom, /^my_div$/ which seems unintuitive. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=8887&group_id=797 From noreply at rubyforge.org Mon Feb 26 12:09:43 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 26 Feb 2007 12:09:43 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-8887 ] Should have RJS matches DOM IDs as substrings Message-ID: <20070226170943.37270524121E@rubyforge.org> Bugs item #8887, was opened at 2007-02-26 15:13 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=8887&group_id=797 >Category: rails plugin Group: None >Status: Closed >Resolution: Rejected Priority: 3 Submitted By: Ashley Moran (ashley_moran) >Assigned to: David Chelimsky (dchelimsky) Summary: Should have RJS matches DOM IDs as substrings Initial Comment: In RSpec 0.7.5.1, given:
and RJS to insert a partial at the bottom of the div, the following spec passes: response.should_have_rjs :insert_html, :bottom, "my_div" but so does this: response.should_have_rjs :insert_html, :bottom, "y_di" because the string "y_di" is a substring of the ID. Is this intended? To create robust specs, you need to do this: response.should_have_rjs :insert_html, :bottom, /^my_div$/ which seems unintuitive. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-02-26 17:09 Message: should_have_rjs wraps a port of ARTS. This is how ARTS works. Additionally, should_have_rjs is deprecated in favor of "should have_rjs" (no underscore between should and have), which is in the current trunk, in 0.8.0-RC1, and will be part of the 0.8 release, so we won't be making this change to improve "should_have_rjs". "should have_rjs" wraps assert_select and will behave as you suggest that it should. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=8887&group_id=797 From noreply at rubyforge.org Mon Feb 26 15:50:28 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 26 Feb 2007 15:50:28 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-8897 ] Error when mixing controller spec with/without integrated views and using template system other than rhtml Message-ID: <20070226205029.093A7524216D@rubyforge.org> Bugs item #8897, was opened at 26/02/2007 21:50 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=8897&group_id=797 Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: Jonathan Tron (jonathant) Assigned to: Nobody (None) Summary: Error when mixing controller spec with/without integrated views and using template system other than rhtml Initial Comment: Whooo what a title !! The problem is RoR does caching of template/template extension in test mode. So when RSpec stub ActionView methods, to run controller specs in isolation mode, it faint Rails about the presence of a template with an rhtml extension. Now, if you mix, for the same controller, specs in isolation mode and spec with integrated views or even for different controllers which shares some templates AND you use a template system using an extension other than rhtml you're in some trouble. One solution is to disable caching in environment/test.rb : config.action_view.cache_template_extensions = false An other solution would probably be to do it in Spec::Rails::Runner::ControllerContext only when running with integrated views, but it probably means clearing the cache in some way (stubbing ?). ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=8897&group_id=797 From noreply at rubyforge.org Mon Feb 26 18:05:38 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 26 Feb 2007 18:05:38 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-8789 ] --line and --spec not working when the context has parenhesis in the name Message-ID: <20070226230539.00F49524215D@rubyforge.org> Bugs item #8789, was opened at 2007-02-21 15:27 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=8789&group_id=797 Category: runner module Group: None Status: Open Resolution: None Priority: 3 Submitted By: Aslak Helles?y (aslak_hellesoy) Assigned to: David Chelimsky (dchelimsky) Summary: --line and --spec not working when the context has parenhesis in the name Initial Comment: Failing spec attached. One failure: ruby bin/spec spec/spec/runner/spec_matcher_spec.rb ...F..... 1) 'SpecMatcher should match spec only with parentheses in context name' FAILED expected true, got false (using .equal?) ./spec/spec/runner/spec_matcher_spec.rb:24: Finished in 0.003095 seconds 9 specifications, 1 failure ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-02-26 23:05 Message: Fixed in trunk rev 1538 ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=8789&group_id=797 From noreply at rubyforge.org Mon Feb 26 18:05:56 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 26 Feb 2007 18:05:56 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-8789 ] --line and --spec not working when the context has parenthesis in the name Message-ID: <20070226230556.D3A86524215D@rubyforge.org> Bugs item #8789, was opened at 2007-02-21 15:27 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=8789&group_id=797 Category: runner module Group: None >Status: Closed >Resolution: Accepted Priority: 3 Submitted By: Aslak Helles?y (aslak_hellesoy) Assigned to: David Chelimsky (dchelimsky) >Summary: --line and --spec not working when the context has parenthesis in the name Initial Comment: Failing spec attached. One failure: ruby bin/spec spec/spec/runner/spec_matcher_spec.rb ...F..... 1) 'SpecMatcher should match spec only with parentheses in context name' FAILED expected true, got false (using .equal?) ./spec/spec/runner/spec_matcher_spec.rb:24: Finished in 0.003095 seconds 9 specifications, 1 failure ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-02-26 23:05 Message: Fixed in trunk rev 1538 ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=8789&group_id=797 From noreply at rubyforge.org Mon Feb 26 18:20:06 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 26 Feb 2007 18:20:06 -0500 (EST) Subject: [rspec-devel] [ rspec-Patches-8132 ] [PATCH] RSpec breaks "rake db:sessions:create" in a rails project that has the rspec_on_rails plugin Message-ID: <20070226232006.F31475242178@rubyforge.org> Patches item #8132, was opened at 2007-01-25 06:26 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=8132&group_id=797 Category: None Group: None >Status: Closed >Resolution: Accepted Priority: 3 Submitted By: Erik Kastner (kastner) >Assigned to: David Chelimsky (dchelimsky) >Summary: [PATCH] RSpec breaks "rake db:sessions:create" in a rails project that has the rspec_on_rails plugin Initial Comment: running rake db:sessions:create (to create the migration for ActiveRecord based sessions) in a project that has the rspec_on_rails plugin causes this error: undefined local variable or method `file_name' for # The problem is that spectask.rb (in lib/spec/rake) has a method "file_list". Changing that method name (and all calls to it) seems to fix the problem. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-02-26 23:20 Message: Applied in rev 1539. Thanks Erik! ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=8132&group_id=797 From noreply at rubyforge.org Mon Feb 26 22:57:05 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 26 Feb 2007 22:57:05 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-8905 ] Bug w/ spec --drb in RC1 0.8.0 Message-ID: <20070227035705.D2AB95240C7C@rubyforge.org> Bugs item #8905, was opened at 2007-02-27 03:57 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=8905&group_id=797 Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: Scott Taylor (smtlaissezfaire) Assigned to: Nobody (None) Summary: Bug w/ spec --drb in RC1 0.8.0 Initial Comment: The bug occurs when running spec --drb in a rails project. If the drb server is started, and then the spec --drb command issued, the command fails, saying "No server running", even though the server *is* running. This bug does not occur all of the time - so far, I've only seen it in this version with a controller spec (I haven't tried view specs, but models seem to work). Here is how I reproduced it (with a new rails project): uninstall the rspec gem svn co svn://rubyforge.org/var/svn/rspec/tags/REL_0_8_0_RC1/gem gem install gem/rspec-0.8.0-RC1.gem create new rails project edit config/database.yml for sqlite3, adding a development and test database rake rails:freeze:edge ./script/plugin install svn://rubyforge.org/var/svn/rspec/trunk/rspec ./script/plugin install svn://rubyforge.org/var/svn/rspec/trunk/ rspec_on_rails/vendor/plugins/rspec_on_rails ./script/generate rspec ./script/generate rspec_controller MyController rake db:migrate (notice that I have no tables in the database, although I don't think that it matters...) rake db:test:prepare ./script/rails_script/server spec --drb spec/controllers/my_controller_controller_spec.rb => "No server running" I've also created a screen cast of this, but my G4 is slow (the screencast is 6 minutes long)...so you might want to skip ahead of the downloading of edge rails, etc... http://railsnewbie.com/files/screencasts/rspec_on_rails- no_server_running2.mov I notice that if I delete all specify's and the corresponding spec's in the spec file, the error is no longer present. Look at this screen cast for an example: http://railsnewbie.com/files/screencasts/rspec_on_rails- no_server_running2_part2.mov My setup: rails edge, Mac OS X.4.8 ruby 1.8.5 (2006-12-25 patchlevel 12) [powerpc-darwin8.8.0] RSpec-0.8.0 (r1497) - BDD for Ruby ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=8905&group_id=797 From noreply at rubyforge.org Tue Feb 27 05:54:43 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 27 Feb 2007 05:54:43 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-8914 ] [Controller] stubbed render_file on @template causes problems with rails -r6253 Message-ID: <20070227105443.DCB025241FFD@rubyforge.org> Bugs item #8914, was opened at 2007-02-27 10:54 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=8914&group_id=797 Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: Ian White (ianwhite) Assigned to: Nobody (None) Summary: [Controller] stubbed render_file on @template causes problems with rails -r6253 Initial Comment: Since upgrading to r6253 of rails my controller specs are failing with the following problem: undefined method `size' for true:TrueClass This is raised by the following method in (rails) action_controller/response.rb:72-74 def set_content_length! self.headers["Content-Length"] = body.size unless body.respond_to?(:call) end This is caused by line 47 in (rspec_on_rails) rails/context/controller.rb:47 @template.stub!(:render_file).and_return(true) response.body is set to true by render_file, which can't respond to size. It's fixed for me by replacing line 47 with @template.stub!(:render_file).and_return("") Cheers, Ian White ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=8914&group_id=797 From noreply at rubyforge.org Tue Feb 27 08:03:34 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 27 Feb 2007 08:03:34 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-8914 ] [Controller] stubbed render_file on @template causes problems with rails -r6253 Message-ID: <20070227130335.0C9BE5242150@rubyforge.org> Bugs item #8914, was opened at 2007-02-27 10:54 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=8914&group_id=797 Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: Ian White (ianwhite) >Assigned to: David Chelimsky (dchelimsky) Summary: [Controller] stubbed render_file on @template causes problems with rails -r6253 Initial Comment: Since upgrading to r6253 of rails my controller specs are failing with the following problem: undefined method `size' for true:TrueClass This is raised by the following method in (rails) action_controller/response.rb:72-74 def set_content_length! self.headers["Content-Length"] = body.size unless body.respond_to?(:call) end This is caused by line 47 in (rspec_on_rails) rails/context/controller.rb:47 @template.stub!(:render_file).and_return(true) response.body is set to true by render_file, which can't respond to size. It's fixed for me by replacing line 47 with @template.stub!(:render_file).and_return("") Cheers, Ian White ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=8914&group_id=797 From noreply at rubyforge.org Tue Feb 27 08:46:14 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 27 Feb 2007 08:46:14 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-8914 ] [Controller] stubbed render_file on @template causes problems with rails -r6253 Message-ID: <20070227134614.B19FA5242145@rubyforge.org> Bugs item #8914, was opened at 2007-02-27 10:54 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=8914&group_id=797 Category: rails plugin Group: None >Status: Closed >Resolution: Out of Date Priority: 3 Submitted By: Ian White (ianwhite) Assigned to: David Chelimsky (dchelimsky) Summary: [Controller] stubbed render_file on @template causes problems with rails -r6253 Initial Comment: Since upgrading to r6253 of rails my controller specs are failing with the following problem: undefined method `size' for true:TrueClass This is raised by the following method in (rails) action_controller/response.rb:72-74 def set_content_length! self.headers["Content-Length"] = body.size unless body.respond_to?(:call) end This is caused by line 47 in (rspec_on_rails) rails/context/controller.rb:47 @template.stub!(:render_file).and_return(true) response.body is set to true by render_file, which can't respond to size. It's fixed for me by replacing line 47 with @template.stub!(:render_file).and_return("") Cheers, Ian White ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-02-27 13:46 Message: Please include RSpec version numbers when submitting bug reports. This is already fixed in 0.8.0-RC1, as we no longer stub #render_file. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=8914&group_id=797 From noreply at rubyforge.org Tue Feb 27 09:25:37 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 27 Feb 2007 09:25:37 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-8914 ] [Controller] stubbed render_file on @template causes problems with rails -r6253 Message-ID: <20070227142537.35AC25242145@rubyforge.org> Bugs item #8914, was opened at 2007-02-27 10:54 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=8914&group_id=797 Category: rails plugin Group: None Status: Closed Resolution: Out of Date Priority: 3 Submitted By: Ian White (ianwhite) Assigned to: David Chelimsky (dchelimsky) Summary: [Controller] stubbed render_file on @template causes problems with rails -r6253 Initial Comment: Since upgrading to r6253 of rails my controller specs are failing with the following problem: undefined method `size' for true:TrueClass This is raised by the following method in (rails) action_controller/response.rb:72-74 def set_content_length! self.headers["Content-Length"] = body.size unless body.respond_to?(:call) end This is caused by line 47 in (rspec_on_rails) rails/context/controller.rb:47 @template.stub!(:render_file).and_return(true) response.body is set to true by render_file, which can't respond to size. It's fixed for me by replacing line 47 with @template.stub!(:render_file).and_return("") Cheers, Ian White ---------------------------------------------------------------------- >Comment By: Ian White (ianwhite) Date: 2007-02-27 14:25 Message: Sorry about that, will submit v numbers in future. Thanks ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-02-27 13:46 Message: Please include RSpec version numbers when submitting bug reports. This is already fixed in 0.8.0-RC1, as we no longer stub #render_file. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=8914&group_id=797 From noreply at rubyforge.org Tue Feb 27 09:44:43 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 27 Feb 2007 09:44:43 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-8917 ] Cannot checkout repository Message-ID: <20070227144443.1A75D5242069@rubyforge.org> Bugs item #8917, was opened at 2007-02-27 14:44 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=8917&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Scott Taylor (smtlaissezfaire) Assigned to: Nobody (None) Summary: Cannot checkout repository Initial Comment: Running the command: svn checkout svn://rubyforge.org/var/svn/rspec fails... here is a tail of the process: A rspec/oldtrunk/vendor/jruby/jruby/tool A rspec/oldtrunk/vendor/jruby/jruby/tool/yarvinsns.rb A rspec/oldtrunk/vendor/jruby/jruby/.settings A rspec/oldtrunk/vendor/jruby/jruby/.settings/org.eclipse.jdt.core.prefs A rspec/oldtrunk/vendor/jruby/jruby/.settings/org.eclipse.jdt.ui.prefs U rspec/oldtrunk/vendor/jruby/jruby Fetching external item into 'rspec/oldtrunk/vendor/jruby/jruby/test/externals/bfts' svn: URL 'svn://rubyforge.org/var/svn/bfts/bfts/trunk' doesn't exist ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=8917&group_id=797 From noreply at rubyforge.org Tue Feb 27 09:48:09 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 27 Feb 2007 09:48:09 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-8905 ] Bug w/ spec --drb in RC1 0.8.0 Message-ID: <20070227144809.6FBE7524215C@rubyforge.org> Bugs item #8905, was opened at 2007-02-27 03:57 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=8905&group_id=797 Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: Scott Taylor (smtlaissezfaire) Assigned to: Nobody (None) Summary: Bug w/ spec --drb in RC1 0.8.0 Initial Comment: The bug occurs when running spec --drb in a rails project. If the drb server is started, and then the spec --drb command issued, the command fails, saying "No server running", even though the server *is* running. This bug does not occur all of the time - so far, I've only seen it in this version with a controller spec (I haven't tried view specs, but models seem to work). Here is how I reproduced it (with a new rails project): uninstall the rspec gem svn co svn://rubyforge.org/var/svn/rspec/tags/REL_0_8_0_RC1/gem gem install gem/rspec-0.8.0-RC1.gem create new rails project edit config/database.yml for sqlite3, adding a development and test database rake rails:freeze:edge ./script/plugin install svn://rubyforge.org/var/svn/rspec/trunk/rspec ./script/plugin install svn://rubyforge.org/var/svn/rspec/trunk/ rspec_on_rails/vendor/plugins/rspec_on_rails ./script/generate rspec ./script/generate rspec_controller MyController rake db:migrate (notice that I have no tables in the database, although I don't think that it matters...) rake db:test:prepare ./script/rails_script/server spec --drb spec/controllers/my_controller_controller_spec.rb => "No server running" I've also created a screen cast of this, but my G4 is slow (the screencast is 6 minutes long)...so you might want to skip ahead of the downloading of edge rails, etc... http://railsnewbie.com/files/screencasts/rspec_on_rails- no_server_running2.mov I notice that if I delete all specify's and the corresponding spec's in the spec file, the error is no longer present. Look at this screen cast for an example: http://railsnewbie.com/files/screencasts/rspec_on_rails- no_server_running2_part2.mov My setup: rails edge, Mac OS X.4.8 ruby 1.8.5 (2006-12-25 patchlevel 12) [powerpc-darwin8.8.0] RSpec-0.8.0 (r1497) - BDD for Ruby ---------------------------------------------------------------------- >Comment By: Scott Taylor (smtlaissezfaire) Date: 2007-02-27 14:48 Message: The checked-out rspec and rspec_on_rails were at release 1536. Since I was running r1497 as a gem, but had a different version checked out, I'm going to close the bug (or request that it be closed by the admins). ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=8905&group_id=797 From noreply at rubyforge.org Tue Feb 27 09:48:29 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 27 Feb 2007 09:48:29 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-8905 ] Bug w/ spec --drb in RC1 0.8.0 Message-ID: <20070227144829.EDCC5524215C@rubyforge.org> Bugs item #8905, was opened at 2007-02-27 03:57 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=8905&group_id=797 Category: rails plugin Group: None Status: Open >Resolution: Rejected Priority: 3 Submitted By: Scott Taylor (smtlaissezfaire) Assigned to: Nobody (None) Summary: Bug w/ spec --drb in RC1 0.8.0 Initial Comment: The bug occurs when running spec --drb in a rails project. If the drb server is started, and then the spec --drb command issued, the command fails, saying "No server running", even though the server *is* running. This bug does not occur all of the time - so far, I've only seen it in this version with a controller spec (I haven't tried view specs, but models seem to work). Here is how I reproduced it (with a new rails project): uninstall the rspec gem svn co svn://rubyforge.org/var/svn/rspec/tags/REL_0_8_0_RC1/gem gem install gem/rspec-0.8.0-RC1.gem create new rails project edit config/database.yml for sqlite3, adding a development and test database rake rails:freeze:edge ./script/plugin install svn://rubyforge.org/var/svn/rspec/trunk/rspec ./script/plugin install svn://rubyforge.org/var/svn/rspec/trunk/ rspec_on_rails/vendor/plugins/rspec_on_rails ./script/generate rspec ./script/generate rspec_controller MyController rake db:migrate (notice that I have no tables in the database, although I don't think that it matters...) rake db:test:prepare ./script/rails_script/server spec --drb spec/controllers/my_controller_controller_spec.rb => "No server running" I've also created a screen cast of this, but my G4 is slow (the screencast is 6 minutes long)...so you might want to skip ahead of the downloading of edge rails, etc... http://railsnewbie.com/files/screencasts/rspec_on_rails- no_server_running2.mov I notice that if I delete all specify's and the corresponding spec's in the spec file, the error is no longer present. Look at this screen cast for an example: http://railsnewbie.com/files/screencasts/rspec_on_rails- no_server_running2_part2.mov My setup: rails edge, Mac OS X.4.8 ruby 1.8.5 (2006-12-25 patchlevel 12) [powerpc-darwin8.8.0] RSpec-0.8.0 (r1497) - BDD for Ruby ---------------------------------------------------------------------- Comment By: Scott Taylor (smtlaissezfaire) Date: 2007-02-27 14:48 Message: The checked-out rspec and rspec_on_rails were at release 1536. Since I was running r1497 as a gem, but had a different version checked out, I'm going to close the bug (or request that it be closed by the admins). ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=8905&group_id=797 From noreply at rubyforge.org Tue Feb 27 10:11:39 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 27 Feb 2007 10:11:39 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-8917 ] Cannot checkout repository Message-ID: <20070227151140.222A85242150@rubyforge.org> Bugs item #8917, was opened at 2007-02-27 14:44 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=8917&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Scott Taylor (smtlaissezfaire) Assigned to: Nobody (None) Summary: Cannot checkout repository Initial Comment: Running the command: svn checkout svn://rubyforge.org/var/svn/rspec fails... here is a tail of the process: A rspec/oldtrunk/vendor/jruby/jruby/tool A rspec/oldtrunk/vendor/jruby/jruby/tool/yarvinsns.rb A rspec/oldtrunk/vendor/jruby/jruby/.settings A rspec/oldtrunk/vendor/jruby/jruby/.settings/org.eclipse.jdt.core.prefs A rspec/oldtrunk/vendor/jruby/jruby/.settings/org.eclipse.jdt.ui.prefs U rspec/oldtrunk/vendor/jruby/jruby Fetching external item into 'rspec/oldtrunk/vendor/jruby/jruby/test/externals/bfts' svn: URL 'svn://rubyforge.org/var/svn/bfts/bfts/trunk' doesn't exist ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-02-27 15:11 Message: Scott - try this instead: svn checkout svn://rubyforge.org/var/svn/rspec/trunk ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=8917&group_id=797 From noreply at rubyforge.org Tue Feb 27 10:41:54 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 27 Feb 2007 10:41:54 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-8905 ] Bug w/ spec --drb in RC1 0.8.0 Message-ID: <20070227154155.045AA5242153@rubyforge.org> Bugs item #8905, was opened at 2007-02-27 03:57 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=8905&group_id=797 Category: rails plugin Group: None >Status: Closed Resolution: Rejected Priority: 3 Submitted By: Scott Taylor (smtlaissezfaire) Assigned to: Nobody (None) Summary: Bug w/ spec --drb in RC1 0.8.0 Initial Comment: The bug occurs when running spec --drb in a rails project. If the drb server is started, and then the spec --drb command issued, the command fails, saying "No server running", even though the server *is* running. This bug does not occur all of the time - so far, I've only seen it in this version with a controller spec (I haven't tried view specs, but models seem to work). Here is how I reproduced it (with a new rails project): uninstall the rspec gem svn co svn://rubyforge.org/var/svn/rspec/tags/REL_0_8_0_RC1/gem gem install gem/rspec-0.8.0-RC1.gem create new rails project edit config/database.yml for sqlite3, adding a development and test database rake rails:freeze:edge ./script/plugin install svn://rubyforge.org/var/svn/rspec/trunk/rspec ./script/plugin install svn://rubyforge.org/var/svn/rspec/trunk/ rspec_on_rails/vendor/plugins/rspec_on_rails ./script/generate rspec ./script/generate rspec_controller MyController rake db:migrate (notice that I have no tables in the database, although I don't think that it matters...) rake db:test:prepare ./script/rails_script/server spec --drb spec/controllers/my_controller_controller_spec.rb => "No server running" I've also created a screen cast of this, but my G4 is slow (the screencast is 6 minutes long)...so you might want to skip ahead of the downloading of edge rails, etc... http://railsnewbie.com/files/screencasts/rspec_on_rails- no_server_running2.mov I notice that if I delete all specify's and the corresponding spec's in the spec file, the error is no longer present. Look at this screen cast for an example: http://railsnewbie.com/files/screencasts/rspec_on_rails- no_server_running2_part2.mov My setup: rails edge, Mac OS X.4.8 ruby 1.8.5 (2006-12-25 patchlevel 12) [powerpc-darwin8.8.0] RSpec-0.8.0 (r1497) - BDD for Ruby ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-02-27 15:41 Message: Done. Thanks for following up Scott. Cheers, David ---------------------------------------------------------------------- Comment By: Scott Taylor (smtlaissezfaire) Date: 2007-02-27 14:48 Message: The checked-out rspec and rspec_on_rails were at release 1536. Since I was running r1497 as a gem, but had a different version checked out, I'm going to close the bug (or request that it be closed by the admins). ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=8905&group_id=797 From noreply at rubyforge.org Tue Feb 27 12:33:19 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 27 Feb 2007 12:33:19 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-8786 ] 0.8.0-RC1 rake tasks seems to behave unobvious if test database does not exist Message-ID: <20070227173319.EF9D6524216B@rubyforge.org> Bugs item #8786, was opened at 2007-02-21 13:38 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=8786&group_id=797 Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: Yurii Rashkovskii (yrashk) Assigned to: Nobody (None) Summary: 0.8.0-RC1 rake tasks seems to behave unobvious if test database does not exist Initial Comment: If there is no test database, rake spec just tells nothing about this: $ rake spec /opt/local/bin/rake:17:Warning: require_gem is obsolete. Use gem instead. (in /Users/yrashk/somewhere/) rake aborted! RSpec failures (See full trace by running task with --trace) It seems to be not a major bug, but a kind of an unobvious behavior. ---------------------------------------------------------------------- Comment By: Scott Taylor (smtlaissezfaire) Date: 2007-02-27 17:33 Message: I believe the same thing happens with Test::Unit. This would require modifying the rake task db:test:prepare, which comes standard with rails. I'm sure that if a modified version was written, it should be submitted to rails core and not rspec. ---------------------------------------------------------------------- Comment By: James Hughes (jpath) Date: 2007-02-23 14:15 Message: I can confirm this. I have the require lines for ActiveRecord commented out in my local rspec_on_rails in rails.rb. The rake task just dies when it gets to running the model tests. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=8786&group_id=797 From mailing_lists at railsnewbie.com Tue Feb 27 12:27:33 2007 From: mailing_lists at railsnewbie.com (Scott Taylor) Date: Tue, 27 Feb 2007 12:27:33 -0500 Subject: [rspec-devel] [ rspec-Bugs-8917 ] Cannot checkout repository In-Reply-To: <20070227151140.222A85242150@rubyforge.org> References: <20070227151140.222A85242150@rubyforge.org> Message-ID: <5BA29784-7EC4-4A53-AD98-F9238D89E663@railsnewbie.com> I actually don't want to check out trunk, but the latest RC1 "tagged" version. What would the appropriate path be for that? Scott On Feb 27, 2007, at 10:11 AM, wrote: > Bugs item #8917, was opened at 2007-02-27 14:44 > You can respond by visiting: > http://rubyforge.org/tracker/? > func=detail&atid=3149&aid=8917&group_id=797 > > Category: None > Group: None > Status: Open > Resolution: None > Priority: 3 > Submitted By: Scott Taylor (smtlaissezfaire) > Assigned to: Nobody (None) > Summary: Cannot checkout repository > > Initial Comment: > > Running the command: > > svn checkout svn://rubyforge.org/var/svn/rspec > > fails... here is a tail of the process: > > A rspec/oldtrunk/vendor/jruby/jruby/tool > A rspec/oldtrunk/vendor/jruby/jruby/tool/yarvinsns.rb > A rspec/oldtrunk/vendor/jruby/jruby/.settings > A rspec/oldtrunk/vendor/jruby/jruby/.settings/ > org.eclipse.jdt.core.prefs > A rspec/oldtrunk/vendor/jruby/jruby/.settings/ > org.eclipse.jdt.ui.prefs > U rspec/oldtrunk/vendor/jruby/jruby > > Fetching external item into 'rspec/oldtrunk/vendor/jruby/jruby/test/ > externals/bfts' > svn: URL 'svn://rubyforge.org/var/svn/bfts/bfts/trunk' doesn't exist > > > > ---------------------------------------------------------------------- > >> Comment By: David Chelimsky (dchelimsky) > Date: 2007-02-27 15:11 > > Message: > Scott - try this instead: > > svn checkout svn://rubyforge.org/var/svn/rspec/trunk > > ---------------------------------------------------------------------- > > You can respond by visiting: > http://rubyforge.org/tracker/? > func=detail&atid=3149&aid=8917&group_id=797 > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel From noreply at rubyforge.org Tue Feb 27 12:54:44 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 27 Feb 2007 12:54:44 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-8917 ] Cannot checkout repository Message-ID: <20070227175444.877315242188@rubyforge.org> Bugs item #8917, was opened at 2007-02-27 14:44 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=8917&group_id=797 Category: None Group: None >Status: Closed >Resolution: Accepted Priority: 3 Submitted By: Scott Taylor (smtlaissezfaire) Assigned to: Nobody (None) Summary: Cannot checkout repository Initial Comment: Running the command: svn checkout svn://rubyforge.org/var/svn/rspec fails... here is a tail of the process: A rspec/oldtrunk/vendor/jruby/jruby/tool A rspec/oldtrunk/vendor/jruby/jruby/tool/yarvinsns.rb A rspec/oldtrunk/vendor/jruby/jruby/.settings A rspec/oldtrunk/vendor/jruby/jruby/.settings/org.eclipse.jdt.core.prefs A rspec/oldtrunk/vendor/jruby/jruby/.settings/org.eclipse.jdt.ui.prefs U rspec/oldtrunk/vendor/jruby/jruby Fetching external item into 'rspec/oldtrunk/vendor/jruby/jruby/test/externals/bfts' svn: URL 'svn://rubyforge.org/var/svn/bfts/bfts/trunk' doesn't exist ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-02-27 17:54 Message: The problem was related to an svn:external to jruby in oldtrunk. Both have been removed from svn so the problem should be gone. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-02-27 15:11 Message: Scott - try this instead: svn checkout svn://rubyforge.org/var/svn/rspec/trunk ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=8917&group_id=797 From noreply at rubyforge.org Tue Feb 27 13:41:30 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 27 Feb 2007 13:41:30 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-8786 ] 0.8.0-RC1 rake tasks seems to behave unobvious if test database does not exist Message-ID: <20070227184131.537285242256@rubyforge.org> Bugs item #8786, was opened at 2007-02-21 13:38 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=8786&group_id=797 Category: rails plugin Group: None >Status: Closed >Resolution: Rejected Priority: 3 Submitted By: Yurii Rashkovskii (yrashk) Assigned to: Nobody (None) Summary: 0.8.0-RC1 rake tasks seems to behave unobvious if test database does not exist Initial Comment: If there is no test database, rake spec just tells nothing about this: $ rake spec /opt/local/bin/rake:17:Warning: require_gem is obsolete. Use gem instead. (in /Users/yrashk/somewhere/) rake aborted! RSpec failures (See full trace by running task with --trace) It seems to be not a major bug, but a kind of an unobvious behavior. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-02-27 18:41 Message: I believe that Scott is correct, so closing this. Following verifies: $ rails experiment create ... $ cd experiment/ $ script/generate model Toy exists app/models/ exists test/unit/ exists test/fixtures/ create app/models/toy.rb create test/unit/toy_test.rb create test/fixtures/toys.yml create db/migrate create db/migrate/001_create_toys.rb 9$ rake (in /Users/david/projects/ruby/experiment) /usr/local/bin/ruby -Ilib:test "/usr/local/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake/rake_test_loader.rb" /usr/local/bin/ruby -Ilib:test "/usr/local/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake/rake_test_loader.rb" rake aborted! Test failures (See full trace by running task with --trace) ---------------------------------------------------------------------- Comment By: Scott Taylor (smtlaissezfaire) Date: 2007-02-27 17:33 Message: I believe the same thing happens with Test::Unit. This would require modifying the rake task db:test:prepare, which comes standard with rails. I'm sure that if a modified version was written, it should be submitted to rails core and not rspec. ---------------------------------------------------------------------- Comment By: James Hughes (jpath) Date: 2007-02-23 14:15 Message: I can confirm this. I have the require lines for ActiveRecord commented out in my local rspec_on_rails in rails.rb. The rake task just dies when it gets to running the model tests. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=8786&group_id=797 From aslak.hellesoy at gmail.com Tue Feb 27 15:58:14 2007 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Tue, 27 Feb 2007 21:58:14 +0100 Subject: [rspec-devel] [ rspec-Bugs-8917 ] Cannot checkout repository In-Reply-To: <5BA29784-7EC4-4A53-AD98-F9238D89E663@railsnewbie.com> References: <20070227151140.222A85242150@rubyforge.org> <5BA29784-7EC4-4A53-AD98-F9238D89E663@railsnewbie.com> Message-ID: <8d961d900702271258s6b83b864o8adaf60aaf184f47@mail.gmail.com> On 2/27/07, Scott Taylor wrote: > > > I actually don't want to check out trunk, but the latest RC1 "tagged" > version. What would the appropriate path be for that? > svn ls svn://rubyforge.org/var/svn/rspec/tags so: svn://rubyforge.org/var/svn/rspec/tags/REL_0_8_0_RC1 Aslak > > Scott > > > On Feb 27, 2007, at 10:11 AM, > wrote: > > > Bugs item #8917, was opened at 2007-02-27 14:44 > > You can respond by visiting: > > http://rubyforge.org/tracker/? > > func=detail&atid=3149&aid=8917&group_id=797 > > > > Category: None > > Group: None > > Status: Open > > Resolution: None > > Priority: 3 > > Submitted By: Scott Taylor (smtlaissezfaire) > > Assigned to: Nobody (None) > > Summary: Cannot checkout repository > > > > Initial Comment: > > > > Running the command: > > > > svn checkout svn://rubyforge.org/var/svn/rspec > > > > fails... here is a tail of the process: > > > > A rspec/oldtrunk/vendor/jruby/jruby/tool > > A rspec/oldtrunk/vendor/jruby/jruby/tool/yarvinsns.rb > > A rspec/oldtrunk/vendor/jruby/jruby/.settings > > A rspec/oldtrunk/vendor/jruby/jruby/.settings/ > > org.eclipse.jdt.core.prefs > > A rspec/oldtrunk/vendor/jruby/jruby/.settings/ > > org.eclipse.jdt.ui.prefs > > U rspec/oldtrunk/vendor/jruby/jruby > > > > Fetching external item into 'rspec/oldtrunk/vendor/jruby/jruby/test/ > > externals/bfts' > > svn: URL 'svn://rubyforge.org/var/svn/bfts/bfts/trunk' doesn't exist > > > > > > > > ---------------------------------------------------------------------- > > > >> Comment By: David Chelimsky (dchelimsky) > > Date: 2007-02-27 15:11 > > > > Message: > > Scott - try this instead: > > > > svn checkout svn://rubyforge.org/var/svn/rspec/trunk > > > > ---------------------------------------------------------------------- > > > > You can respond by visiting: > > http://rubyforge.org/tracker/? > > func=detail&atid=3149&aid=8917&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 mailing_lists at railsnewbie.com Tue Feb 27 16:16:42 2007 From: mailing_lists at railsnewbie.com (Scott Taylor) Date: Tue, 27 Feb 2007 16:16:42 -0500 Subject: [rspec-devel] [ rspec-Bugs-8917 ] Cannot checkout repository In-Reply-To: <8d961d900702271258s6b83b864o8adaf60aaf184f47@mail.gmail.com> References: <20070227151140.222A85242150@rubyforge.org> <5BA29784-7EC4-4A53-AD98-F9238D89E663@railsnewbie.com> <8d961d900702271258s6b83b864o8adaf60aaf184f47@mail.gmail.com> Message-ID: Thanks guys. I actually didn't know that an "ls" feature was built into svn. I've only used the http interface in the past, but I should have done more exploring before wasting your time. Thanks again, Scott On Feb 27, 2007, at 3:58 PM, aslak hellesoy wrote: > On 2/27/07, Scott Taylor wrote: >> >> >> I actually don't want to check out trunk, but the latest RC1 "tagged" >> version. What would the appropriate path be for that? >> > > svn ls svn://rubyforge.org/var/svn/rspec/tags > > so: > > svn://rubyforge.org/var/svn/rspec/tags/REL_0_8_0_RC1 > > Aslak > >> >> Scott >> >> >> On Feb 27, 2007, at 10:11 AM, >> wrote: >> >>> Bugs item #8917, was opened at 2007-02-27 14:44 >>> You can respond by visiting: >>> http://rubyforge.org/tracker/? >>> func=detail&atid=3149&aid=8917&group_id=797 >>> >>> Category: None >>> Group: None >>> Status: Open >>> Resolution: None >>> Priority: 3 >>> Submitted By: Scott Taylor (smtlaissezfaire) >>> Assigned to: Nobody (None) >>> Summary: Cannot checkout repository >>> >>> Initial Comment: >>> >>> Running the command: >>> >>> svn checkout svn://rubyforge.org/var/svn/rspec >>> >>> fails... here is a tail of the process: >>> >>> A rspec/oldtrunk/vendor/jruby/jruby/tool >>> A rspec/oldtrunk/vendor/jruby/jruby/tool/yarvinsns.rb >>> A rspec/oldtrunk/vendor/jruby/jruby/.settings >>> A rspec/oldtrunk/vendor/jruby/jruby/.settings/ >>> org.eclipse.jdt.core.prefs >>> A rspec/oldtrunk/vendor/jruby/jruby/.settings/ >>> org.eclipse.jdt.ui.prefs >>> U rspec/oldtrunk/vendor/jruby/jruby >>> >>> Fetching external item into 'rspec/oldtrunk/vendor/jruby/jruby/test/ >>> externals/bfts' >>> svn: URL 'svn://rubyforge.org/var/svn/bfts/bfts/trunk' doesn't exist >>> >>> >>> >>> -------------------------------------------------------------------- >>> -- >>> >>>> Comment By: David Chelimsky (dchelimsky) >>> Date: 2007-02-27 15:11 >>> >>> Message: >>> Scott - try this instead: >>> >>> svn checkout svn://rubyforge.org/var/svn/rspec/trunk >>> >>> -------------------------------------------------------------------- >>> -- >>> >>> You can respond by visiting: >>> http://rubyforge.org/tracker/? >>> func=detail&atid=3149&aid=8917&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 >> > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel From noreply at rubyforge.org Tue Feb 27 20:23:56 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 27 Feb 2007 20:23:56 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-8925 ] Documentation bug in 0.8.0RC1 rspec website Message-ID: <20070228012356.A0DB35242264@rubyforge.org> Bugs item #8925, was opened at 2007-02-28 01:23 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=8925&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Scott Taylor (smtlaissezfaire) Assigned to: Nobody (None) Summary: Documentation bug in 0.8.0RC1 rspec website Initial Comment: The documentation for RC1 generated by the gem, under: Home > Documentation > Rails Plugin > Runners says: "Now you can run specs with the ?drb flag. If you?re using Rake you should add ?drb to the spec/spec.opts file." The drb option should have *two* dashes, not one, so it should be: "Now you can run specs with the --drb flag. If you?re using Rake you should add --drb to the spec/spec.opts file." ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=8925&group_id=797 From noreply at rubyforge.org Tue Feb 27 21:12:27 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 27 Feb 2007 21:12:27 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-8928 ] rspec_on_rails 0.8.0-RC1 controller tests make double call to setup_with_fixtures Message-ID: <20070228021227.31C6F5241585@rubyforge.org> Bugs item #8928, was opened at 2007-02-28 04:12 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=8928&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Nikolai Lugovoi (meadow) Assigned to: Nobody (None) Summary: rspec_on_rails 0.8.0-RC1 controller tests make double call to setup_with_fixtures Initial Comment: call to super in Spec::Rails::Runner::FunctionalEvalContext#setup results in double call to setup_with_fixtures. The problem is described in details at http://rubyforge.org/tracker/index.php?func=detail&aid=8894&group_id=797&atid=3150 and http://dev.rubyonrails.org/ticket/7665 So, here's my understanding (Mx are labels to distinguish methods): first, active_record/fixtures.rb redefine TestCase#setup as TestCase#setup_with_fixtures (M1). next, defining "setup" method in FunctionalEvalContext (M2) triggers TestCase.method_added, which makes M2 to be "setup_without_fixtures" and creates new "setup" method (M3) as def setup setup_with_fixtures # (M1) setup_without_fixtures #(M2) end last, ControllerEvalContext also defines "setup" method (M4) and finally we have in runtime: ControllerEvalContext#setup: (M4) calls super -> FunctionalEvalContext#setup (M3) FunctionalEvalContext#setup: (M3) calls setup_with_fixtures -> method from fixtures.rb (M1) calls setup_without_fixtures -> method from context/functional.rb (M2) But #setup defined in context/functional.rb (M2) calls super -> that is again setup_with_fixtures (M1) So, is call to "super" necessary in FunctionalEvalContext#setup or it can be safely removed? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=8928&group_id=797 From noreply at rubyforge.org Tue Feb 27 21:16:43 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 27 Feb 2007 21:16:43 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-8928 ] rspec_on_rails 0.8.0-RC1 controller tests make double call to setup_with_fixtures Message-ID: <20070228021643.9DC25524226B@rubyforge.org> Bugs item #8928, was opened at 2007-02-28 04:12 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=8928&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Nikolai Lugovoi (meadow) Assigned to: Nobody (None) Summary: rspec_on_rails 0.8.0-RC1 controller tests make double call to setup_with_fixtures Initial Comment: call to super in Spec::Rails::Runner::FunctionalEvalContext#setup results in double call to setup_with_fixtures. The problem is described in details at http://rubyforge.org/tracker/index.php?func=detail&aid=8894&group_id=797&atid=3150 and http://dev.rubyonrails.org/ticket/7665 So, here's my understanding (Mx are labels to distinguish methods): first, active_record/fixtures.rb redefine TestCase#setup as TestCase#setup_with_fixtures (M1). next, defining "setup" method in FunctionalEvalContext (M2) triggers TestCase.method_added, which makes M2 to be "setup_without_fixtures" and creates new "setup" method (M3) as def setup setup_with_fixtures # (M1) setup_without_fixtures #(M2) end last, ControllerEvalContext also defines "setup" method (M4) and finally we have in runtime: ControllerEvalContext#setup: (M4) calls super -> FunctionalEvalContext#setup (M3) FunctionalEvalContext#setup: (M3) calls setup_with_fixtures -> method from fixtures.rb (M1) calls setup_without_fixtures -> method from context/functional.rb (M2) But #setup defined in context/functional.rb (M2) calls super -> that is again setup_with_fixtures (M1) So, is call to "super" necessary in FunctionalEvalContext#setup or it can be safely removed? ---------------------------------------------------------------------- >Comment By: Nikolai Lugovoi (meadow) Date: 2007-02-28 04:16 Message: oops, rails trac ticket on my problem is at http://dev.rubyonrails.org/ticket/7672 ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=8928&group_id=797 From noreply at rubyforge.org Tue Feb 27 22:39:05 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 27 Feb 2007 22:39:05 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-8925 ] Documentation bug in 0.8.0RC1 rspec website Message-ID: <20070228033906.1C17C5242271@rubyforge.org> Bugs item #8925, was opened at 2007-02-28 01:23 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=8925&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Scott Taylor (smtlaissezfaire) Assigned to: Nobody (None) Summary: Documentation bug in 0.8.0RC1 rspec website Initial Comment: The documentation for RC1 generated by the gem, under: Home > Documentation > Rails Plugin > Runners says: "Now you can run specs with the ?drb flag. If you?re using Rake you should add ?drb to the spec/spec.opts file." The drb option should have *two* dashes, not one, so it should be: "Now you can run specs with the --drb flag. If you?re using Rake you should add --drb to the spec/spec.opts file." ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-02-28 03:39 Message: The text is actually two dashes. You wouldn't happen to be running this on Windows would you? Somehow the two dashes are getting converted to a "smart" character. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=8925&group_id=797 From noreply at rubyforge.org Tue Feb 27 22:41:42 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 27 Feb 2007 22:41:42 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-8925 ] Documentation bug in 0.8.0RC1 rspec website Message-ID: <20070228034142.87372524225F@rubyforge.org> Bugs item #8925, was opened at 2007-02-28 01:23 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=8925&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Scott Taylor (smtlaissezfaire) Assigned to: Nobody (None) Summary: Documentation bug in 0.8.0RC1 rspec website Initial Comment: The documentation for RC1 generated by the gem, under: Home > Documentation > Rails Plugin > Runners says: "Now you can run specs with the ?drb flag. If you?re using Rake you should add ?drb to the spec/spec.opts file." The drb option should have *two* dashes, not one, so it should be: "Now you can run specs with the --drb flag. If you?re using Rake you should add --drb to the spec/spec.opts file." ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-02-28 03:41 Message: Never mind. That is how it's getting generated on my Mac, which is doing the evil "smart" conversion. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-02-28 03:39 Message: The text is actually two dashes. You wouldn't happen to be running this on Windows would you? Somehow the two dashes are getting converted to a "smart" character. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=8925&group_id=797 From noreply at rubyforge.org Tue Feb 27 22:49:00 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 27 Feb 2007 22:49:00 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-8925 ] Documentation bug in 0.8.0RC1 rspec website Message-ID: <20070228034900.52898524226B@rubyforge.org> Bugs item #8925, was opened at 2007-02-28 01:23 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=8925&group_id=797 Category: None Group: None >Status: Closed >Resolution: Accepted Priority: 3 Submitted By: Scott Taylor (smtlaissezfaire) Assigned to: Nobody (None) Summary: Documentation bug in 0.8.0RC1 rspec website Initial Comment: The documentation for RC1 generated by the gem, under: Home > Documentation > Rails Plugin > Runners says: "Now you can run specs with the ?drb flag. If you?re using Rake you should add ?drb to the spec/spec.opts file." The drb option should have *two* dashes, not one, so it should be: "Now you can run specs with the --drb flag. If you?re using Rake you should add --drb to the spec/spec.opts file." ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-02-28 03:49 Message: Fixed in trunk 1548. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-02-28 03:41 Message: Never mind. That is how it's getting generated on my Mac, which is doing the evil "smart" conversion. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-02-28 03:39 Message: The text is actually two dashes. You wouldn't happen to be running this on Windows would you? Somehow the two dashes are getting converted to a "smart" character. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=8925&group_id=797 From noreply at rubyforge.org Tue Feb 27 22:59:15 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 27 Feb 2007 22:59:15 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-8928 ] rspec_on_rails 0.8.0-RC1 controller tests make double call to setup_with_fixtures Message-ID: <20070228035915.3D1675242272@rubyforge.org> Bugs item #8928, was opened at 2007-02-28 02:12 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=8928&group_id=797 >Category: rails plugin Group: None >Status: Closed >Resolution: Accepted Priority: 3 Submitted By: Nikolai Lugovoi (meadow) >Assigned to: David Chelimsky (dchelimsky) Summary: rspec_on_rails 0.8.0-RC1 controller tests make double call to setup_with_fixtures Initial Comment: call to super in Spec::Rails::Runner::FunctionalEvalContext#setup results in double call to setup_with_fixtures. The problem is described in details at http://rubyforge.org/tracker/index.php?func=detail&aid=8894&group_id=797&atid=3150 and http://dev.rubyonrails.org/ticket/7665 So, here's my understanding (Mx are labels to distinguish methods): first, active_record/fixtures.rb redefine TestCase#setup as TestCase#setup_with_fixtures (M1). next, defining "setup" method in FunctionalEvalContext (M2) triggers TestCase.method_added, which makes M2 to be "setup_without_fixtures" and creates new "setup" method (M3) as def setup setup_with_fixtures # (M1) setup_without_fixtures #(M2) end last, ControllerEvalContext also defines "setup" method (M4) and finally we have in runtime: ControllerEvalContext#setup: (M4) calls super -> FunctionalEvalContext#setup (M3) FunctionalEvalContext#setup: (M3) calls setup_with_fixtures -> method from fixtures.rb (M1) calls setup_without_fixtures -> method from context/functional.rb (M2) But #setup defined in context/functional.rb (M2) calls super -> that is again setup_with_fixtures (M1) So, is call to "super" necessary in FunctionalEvalContext#setup or it can be safely removed? ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-02-28 03:59 Message: It turns out that it is not necessary (I removed it and all specs passed), so it has been removed as of trunk rev 1549. ---------------------------------------------------------------------- Comment By: Nikolai Lugovoi (meadow) Date: 2007-02-28 02:16 Message: oops, rails trac ticket on my problem is at http://dev.rubyonrails.org/ticket/7672 ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=8928&group_id=797 From noreply at rubyforge.org Tue Feb 27 23:03:33 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 27 Feb 2007 23:03:33 -0500 (EST) Subject: [rspec-devel] [ rspec-Feature Requests-8509 ] Enhance controller docs Message-ID: <20070228040333.7CC8A524226B@rubyforge.org> Feature Requests item #8509, was opened at 2007-02-08 14:13 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=8509&group_id=797 Category: None Group: None Status: Open Priority: 3 Submitted By: Jerry West (jjw) Assigned to: Nobody (None) Summary: Enhance controller docs Initial Comment: The controller spec docs assume some familiarity with Rails unit testing concepts . This assumption is increasingly in-appropriate as newcomers to Rails start with RSpec as their prefered development 'test' tool. An immediate request is to update the controller specs documentation to include something like this: Triggering controller actions Once the expectations have been established, the controller action must be invoked. Three helper routines are provided to emulate the HTTP GET and POST expected by the controller: get :action, [params] post :action, params xhr :get, :action, [params] xhr :post, :action, params The #xhr method emulates an AJAX (xml_http_request) call. 'params' is a hash to be placed in the params[] accessor in the controller (e.g. :id => 99, :name => 'fred', etc). The 'action' can be either a symbol or a string. ------- The example at the end might also be enhanced to illustrate usage. xhr :post, :update, :id => 3, :name => 'fred' ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-02-28 04:03 Message: I'm inclined to reference the rails test docs rather than duplicating them in RSpec. WDYT? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-02-08 18:24 Message: When I created the Documentation tracker it looks like it got created as "not publicly available". Furthermore it seems that there is a bug already submitted to Rubyforge that you can't set it to public once it is set private. http://rubyforge.org/tracker/index.php?func=detail&aid=8406&group_id=5&atid=101 So, until that bug is resolved, I'm going to move this request over to Feature Requests and we'll use that for the time being for documentation-related requests. Cheers, David ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-02-08 14:49 Message: Lame, lame, lame. For whatever reason, if you're logged when you view http://rubyforge.org/tracker/?group_id=797, you see a Documentation tracker. If you're not, you don't. I'll go ahead and move it myself. Please email the list if you are unable to view this item now that it's moved. ---------------------------------------------------------------------- Comment By: Jerry West (jjw) Date: 2007-02-08 14:41 Message: Apologies. Where can I find the documentation tracker, please? My RubyForge Tracker tab only lists Bugs; Support Requests; Patches and Feature Requests. None of these have a documentation category so far as I can see. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-02-08 14:29 Message: Jerry - you submitted the request to Patches, but I think you intended for us to make a change rather than you submitting a patch. If this is correct, this belongs over in the Documentation tracker. If so, please try to move it there. If you have any trouble, add a comment here and I'll move it. Cheers, David ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-02-08 14:21 Message: Where's the patch? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=8509&group_id=797 From noreply at rubyforge.org Tue Feb 27 23:07:12 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 27 Feb 2007 23:07:12 -0500 (EST) Subject: [rspec-devel] [ rspec-Feature Requests-6508 ] Proper stacktrace for mocks Message-ID: <20070228040712.9DC36524225F@rubyforge.org> Feature Requests item #6508, was opened at 2006-11-06 01:42 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6508&group_id=797 Category: mock module Group: None >Status: Closed Priority: 3 Submitted By: Aslak Helles?y (aslak_hellesoy) Assigned to: Nobody (None) Summary: Proper stacktrace for mocks Initial Comment: run failing_examples/mocking_example.rb This produces something like: should fail when messages are received out of order Mock 'one two three' received :three out of order (eval):3:in `three' /Users/aslakhellesoy/scm/rspec/trunk/failing_examples/mocking_example.rb:22:in `should fail when messages are received out of order' The first line of the backtrace is bad. It shouldn't be there at all. When --backtrace is on it should show the line in RSpec's code. Can be achieved with extra args to eval (or is it class_eval) ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-02-28 04:07 Message: This was addressed some time ago. Here's the output I get now (rev 1549): $ bin/spec failing_examples/mocking_example.rb .FFF 1) Spec::Mocks::MockExpectationError in 'Mocker should fail when expected message not received' Mock 'poke me' expected :poke with (any args) once, but received it 0 times ./failing_examples/mocking_example.rb:13: 2) Spec::Mocks::MockExpectationError in 'Mocker should fail when messages are received out of order' Mock 'one two three' received :three out of order ./failing_examples/mocking_example.rb:22: 3) Spec::Mocks::MockExpectationError in 'Mocker should get yelled at when sending unexpected messages' Mock 'don't talk to me' expected :any_message_at_all with (any args) 0 times, but received it once ./failing_examples/mocking_example.rb:28: Finished in 0.003184 seconds 4 specifications, 3 failures ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6508&group_id=797 From dchelimsky at gmail.com Wed Feb 28 14:30:30 2007 From: dchelimsky at gmail.com (David Chelimsky) Date: Wed, 28 Feb 2007 13:30:30 -0600 Subject: [rspec-devel] [ANN] RSpec-0.8.0 Message-ID: <57c63afe0702281130n2eae9f29j1e3d11a6da0f252b@mail.gmail.com> The RSpec Development Team is pleased to announce the release of RSpec-0.8.0. This release introduces a new approach to handling expectations using Expression Matchers. It also improves the spec command line by adding DRb support and making it possible to store command line options in a file. This means a more flexible RSpec experience with Rails, Rake and editor plugins like TextMate. It also sports myriad new features, bug fixes, patches and general goodness. Please see the following for details: http://rspec.rubyforge.org/index.html http://rspec.rubyforge.org/upgrade.html http://rspec.rubyforge.org/changes.html Happy Spec'ing! The RSpec Development Team