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