Re: [rspec-users] Autotest doesn't load up rspec (rspec2, rails3, ruby 1.9.2)

[David Chelimsky]

On Aug 18, 2010, at 3:56 AM, Nils Riedemann wrote:

> 
> On 18 Aug., 07:29, David Chelimsky  wrote:
>> On Aug 17, 2010, at 3:18 AM, Nils Riedemann wrote:
>> 
>> 
>> 
>> 
>> 
>>> Hi there,
>> 
>>> When i run `rspec --drb spec` everything works fine. Yet, when i want
>>> to use `autotest` it outputs the following:
>> 
>>>~/code/ffr[master]% autotest
>>>/Users/nilsriedemann/.rvm/rubies/ruby-1.9.2-rc2/lib/ruby/1.9.1/
>>> rubygems.rb:1051: warning: method redefined; discarding old gem
>>>:15: warning: previous definition of gem was
>>> here
>>>loading autotest/rails
>> 
>>> The contents of my ./autotest/discover.rb:
>> 
>>>Autotest.add_discovery { "rspec2" }
>>>Autotest.add_discovery { "rails" }
>> 
>>> (btw: `autospec` does not work at all… but that's a different story i
>>> think.)
>> 
>> Autospec is gone. 
>> Seehttp://blog.davidchelimsky.net/2010/03/15/rspec-2-and-autotest/.
>> 
>> Have you installed the autotest-rails gem? What's in your Gemfile?
>> 
>> ___
>> rspec-users mailing list
>> rspec-us...@rubyforge.orghttp://rubyforge.org/mailman/listinfo/rspec-users
> 
> I have autotest-rails (4.1.0) installed. My Gemfile:
> 
> source 'http://rubygems.org'
> 
> gem 'rails', '3.0.0.rc'
> 
> # Bundle edge Rails instead:
> # gem 'rails', :git => 'git://github.com/rails/rails.git'
> 
> gem 'mysql'
> # gem 'sqlite3-ruby', :require => 'sqlite3'
> 
> # Use unicorn as the web server
> # gem 'unicorn'
> 
> # Deploy with Capistrano
> gem 'capistrano'
> 
> # To use debugger
> # gem 'ruby-debug'
> 
> # Bundle the extra gems:
> # gem 'bj'
> # gem 'nokogiri', '1.4.1'
> # gem 'sqlite3-ruby', :require => 'sqlite3'
> # gem 'aws-s3', :require => 'aws/s3'
> gem "geokit", '>= 1.5.0'
> 
> # Bundle gems for the local environment. Make sure to
> # put test-only gems in this group so their generators
> # and rake tasks are available in development mode:
> group :development, :test do
>  gem 'rspec', ">= 2.0.0.beta.18"
>  gem 'rspec-rails', ">= 2.0.0.beta.18"
>  gem 'factory_girl_rails'
>  gem 'shoulda'
>  gem 'spork'
>  gem 'webrat'
> end
> 
> group :test do
>  gem 'rspec', ">= 2.0.0.beta.18"
>  gem 'rspec-rails', ">= 2.0.0.beta.18"
>  gem 'factory_girl_rails'
>  gem 'shoulda'
>  gem 'spork'
>  gem 'webrat'
> end

I don't think this is the source of your issue, but why do you have all of the 
testing related gems duplicated? Also, beta 18 doesn't work with 
rails-3.0.0.rc, so that should say ">= 2.0.0.beta.19"

As for this issue, I'm not sure what else is up. Is anybody else on this list 
having a similar issue?
___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users

Re: [rspec-users] Autotest doesn't load up rspec (rspec2, rails3, ruby 1.9.2)

[David Chelimsky]

On Aug 17, 2010, at 3:18 AM, Nils Riedemann wrote:

> Hi there,
> 
> When i run `rspec --drb spec` everything works fine. Yet, when i want
> to use `autotest` it outputs the following:
> 
>~/code/ffr[master]% autotest
>/Users/nilsriedemann/.rvm/rubies/ruby-1.9.2-rc2/lib/ruby/1.9.1/
> rubygems.rb:1051: warning: method redefined; discarding old gem
>:15: warning: previous definition of gem was
> here
>loading autotest/rails
> 
> The contents of my ./autotest/discover.rb:
> 
>Autotest.add_discovery { "rspec2" }
>Autotest.add_discovery { "rails" }
> 
> 
> (btw: `autospec` does not work at all… but that's a different story i
> think.)

Autospec is gone. See 
http://blog.davidchelimsky.net/2010/03/15/rspec-2-and-autotest/.

Have you installed the autotest-rails gem? What's in your Gemfile?

___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users

Re: [rspec-users] 2.0.0.beta.19 installation problem

[David Chelimsky]

On Aug 13, 2010, at 11:33 PM, Craig Castelaz wrote:

> I purchased the beta version of the PragBook yesterday, but didn't get
> a chance to begin reading until tonight.  I'm currently stuck on
> installing rspec.
> 
> ~$ sudo gem install rspec --version 2.0.0.beta.19
> **
>  Thank you for installing rspec-core-2.0.0.beta.19
>  Please be sure to look at Upgrade.markdown to see what might have changed
>  since the last release.
> **
> **
>  Thank you for installing rspec-expectations-2.0.0.beta.19
> **
> **
>  Thank you for installing rspec-mocks-2.0.0.beta.19
> **
> ERROR:  Error installing rspec:
>   rspec requires rspec-core (= 2.0.0.beta.19, runtime)
> 
> I'm a bit mystified because the process begins by installing
> rspec-core-2.0.0.beta.19, but ends by telling me rspec-core
> (2.0.0.beta.19) is required.  I'm running Ruby 1.8.7 on OS 10.6.4 if
> that's of any help.

What version of rubygems do you have installed? If anything less than 1.3.7, 
please upgrade. Previous versions had some issues related to prerelease 
dependencies, but they've all been fixed in 1.3.7.

HTH,
David

> Thanks,
> Craig
> ___
> rspec-users mailing list
> rspec-users@rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users

___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users

Re: [rspec-users] rspec command for rspec-2.0.0.beta.19

[David Chelimsky]

On Tue, Aug 10, 2010 at 11:17 AM, Brad Pauly  wrote:
> I've just uninstalled all versions of rspec and installed
> rspec-2.0.0.beta.19 and rspec-rails-2.0.0.beta.19 for a rails project
> and I can't find the rspec command. Based on what bundler is telling
> me, I think it should be in: /usr/local/lib/ruby/gems/1.8/gems/bin/
> but it isn't.
>
> $ bundle show rspec
> /usr/local/lib/ruby/gems/1.8/gems/rspec-2.0.0.beta.19
>
> Everything seems to have installed properly with "bundle install"
>
> $ bundle show | grep rspec
>  * rspec (2.0.0.beta.19)
>  * rspec-core (2.0.0.beta.19)
>  * rspec-expectations (2.0.0.beta.19)
>  * rspec-mocks (2.0.0.beta.19)
>  * rspec-rails (2.0.0.beta.19)
>
> Anyone have ideas on where I should be looking or a direction to go?

If bundler installs it, then you have to run it under 'bundle exec':

  bundle exec rspec

I've got an alias set up so I can say:

  be rspec spec

There's something metaphysically pleasing about that.

HTH,
David

>
> Cheers,
> Brad
> ___
> rspec-users mailing list
> rspec-users@rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>
___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users

Re: [rspec-users] Specifying which spec types helper modules get included into in the RSpec.configure block

[David Chelimsky]

On Tue, Aug 10, 2010 at 3:47 PM, John Firebaugh
 wrote:
> On Jul 30, 9:14 am, S Bennett  wrote:
>> Am I doing something wrong or has the syntax for specifying which spec
>> types the modules get included into changed?
>
> I have the same problem. I filed an issue:
>
> http://github.com/rspec/rspec-rails/issues/issue/159

It's been fixed, and the fix will be part of the next release (next week or so).
___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users

Re: [rspec-users] Including modules for view test in RSpec 2.0.0.beta.19

[David Chelimsky]

On Tue, Aug 10, 2010 at 9:21 AM, Dane Harrigan  wrote:
> Hey guys,
>
> I used RSpec 1.3 quite a bit and wanted to move to 2.0. I'm having
> some trouble, but I think I'm just missing something.
>
> On this pastie you'll see my spec/support/view_helpers.rb, spec/
> spec_helper.rb file and header.haml spec file., http://pastie.org/1081962
>
> On line 11 of the spec_helper.rb I include my ViewHelpers module in
> the views, but my "should_have_a_link" doesn't exist in the
> header.haml spec file until I include it there on line 4 of the file.
> I'm sure I'm missing something, but I see what it is.
>
> Thanks in advance everyone,

Known issue: http://github.com/rspec/rspec-rails/issues/closed#issue/159

Fixed just a day or two ago and will be part of the next release (beta
20) which will be sometime in the next week or so. Would have been
sooner, but I just got the book back from indexing (wt) and I have
some work to do before it goes off to the copyeditor (double w0t).

In the mean time, you can point your Gemfile at github and get the
latest and greatest (keep in mind this has its own costs because
you're dealing with a moving target) - see "Living on edge" on
http://github.com/rspec/rspec-rails.

HTH,
David

> -Dane
> ___
> rspec-users mailing list
> rspec-users@rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>
___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users

Re: [rspec-users] Calling script/spec from directories other than RAILS_ROOT

[David Chelimsky]

On Wed, Aug 11, 2010 at 11:56 AM, samullen  wrote:
> I've written a simple shell function which, depending on where it is
> called, will ascend the directory tree until it finds ./script/spec
> or, failing that, the spec first found in $PATH. What I'm running into
> is that although my tests pass when I call script/spec from
> RAILS_ROOT, they do not pass when it's called from any other location.
> This happens regardless of whether I use my function or call spec
> directly.
>
> Examples:
> from RAILS_ROOT -
> script/spec spec/controllers/actors_controller_spec.rb # Passes
>
> from /home/fooman/rails_project/spec/controllers -
> /home/fooman/rails_project/script/spec actors_controller_spec.rb #
> FAILS because it can't find 'request'
>
> What do I need to do to run spec for a rails project in a directory
> other than RAILS_ROOT?

1. add :type => controller, :type => view, etc so RSpec knows what
kind of example group to load
1.a. if you're using rspec-2, you'll have to include the correct module instead
2. use absolute paths to require spec_helper

Personally, I'd just keep running the specs from the project root.

HTH,
David

>
> Thank you,
> Samuel Mullen
> ___
> rspec-users mailing list
> rspec-users@rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>
___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users

Re: [rspec-users] Module & Mixin testing strategy

[David Chelimsky]

On Aug 14, 2010, at 9:26 AM, Ashley Moran wrote:

> 
> On 14 Aug 2010, at 11:34, Mike Howson wrote:
> 
>> Just wondered what people thoughts are to testing module's to be
>> included in mixin's? Seems to me there are two main approaches:-
> 
> Hi Mike
> 
> I've been doing a lot of this sort of coding lately, as I've been extracting 
> duplicated code into a mini-framework based on modules.
> 
> 
>> 1. Test the behavior in a mixin object that includes the module because
>> its the behavior of the object thats important not the code structure.
>> 
>> 2. Test the module in isolation as it potentially code be included
>> anywhere.
> 
> I'm not sure I know how option 2 is even possible, unless your module is all 
> module methods, as you can't call instance methods on a module directly.
> 
> However, it's easy to do this in RSpec with some Ruby meta-magic:
> 
>  module MyModule
>def foo
>  "bar"
>end
>  end
> 
>  describe MyModule do
>let(:class_with_my_module) {
>  Class.new do
>include MyModule
>  end
>}
> 
>subject { class_with_my_module.new }
> 
>its(:foo) { should eq bar }
>  end

Or:

describe M do
  it "does something" do
host = Object.new.extend(M)
host.some_method_defined_in_m.should do_something
  end
end

I think either approach satisfies "test the module in isolation", even though 
it's not in isolation from the behaviour of Object.

> If the best approach is 2 - to test the module in isolation and the
>> module uses instance variables or methods from the object its being
>> mixed with then we would need to create a test object in the rspec test
>> that included the module and defined the required instance variables and
>> methods. Does this lead to 1 being the best approach as we are not then
>> forced to mock up a mixin just to test the module?
> 
> I'm not 100% sure but I *think* the snippet above is an implementation of 
> what you describe here.  Please correct me if I misunderstood.
> 
> 
>> The question came about because I recently had to get an untested rails
>> module under test that was included in a number of controllers and
>> depended on 'request' and 'response'. I was then faced with either
>> testing one of the controllers that included that module but also added
>> further complexity or defining a new thin controller used solely for
>> testing the module within the spec file.
> 
> In this case, you may be able to get some mileage with the above code, but 
> using `Class.new(ActionController::Base)`.
> 
> You can test individual objects that include your module with shared 
> examples, for example:
> 
>  module Fooable
>def foo
>  "bar"
>end
>  end
> 
>  class Baz
>include Fooable
> 
># Oops - this is overriding Fooable#foo
>def foo
>  "quux"
>end
>  end
> 
>  shared_examples_for "a Fooable object" do
># Optional
>before(:each) do
>  unless respond_to?(:fooable)
>raise "You must provide instance method fooable"
>  end
>end
> 
>it "should have a foo of 'bar'" do
>  fooable.foo.should eq "bar"
>end
>  end
> 
>  describe Baz do
>subject { Baz.new }
>it_should_behave_like "a Fooable object" do
>  let(:fooable) { subject }
>end
>  end
> 
> My recommendation at the moment is to make the shared examples work 
> fully-integrated (ie, no mocks).  I've run into issue where shared examples 
> rely on mocks, which I haven't solved yet (at least not in my code - it's my 
> next TODO).
> 
> Currently I'm doing both the above.  The isolated module spec proves the 
> module enchants objects with the correct behaviour, the shared examples 
> double-check that you haven't broken that behaviour in concrete classes.
> 
> See also the recent thread "Evaluating shared example customisation block 
> before shared block" from 30th July onwards (it goes on to talk about passing 
> parameters to shared example groups, which is possible in RSpec-2 master).
> 
> HTH
> 
> Ash
> 
> -- 
> http://www.patchspace.co.uk/
> http://www.linkedin.com/in/ashleymoran
> 
> ___
> rspec-users mailing list
> rspec-users@rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users

___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users

Re: [rspec-users] Module & Mixin testing strategy

[David Chelimsky]

On Aug 14, 2010, at 5:34 AM, Mike Howson wrote:

> Hi,
> 
> Just wondered what people thoughts are to testing module's to be
> included in mixin's? Seems to me there are two main approaches:-
> 
> 1. Test the behavior in a mixin object that includes the module because
> its the behavior of the object thats important not the code structure.
> 
> 2. Test the module in isolation as it potentially code be included
> anywhere.

3. All of the above, and then some ...

I need to blog this, which I'll do later, but here is the short version:


Consider this structure:

module M; end
class C
  include M
end

We specify responsibilities of objects from the perspective of their consumers. 
If module M is included in class C, consumers of class C have no reason to know 
that module M is involved. They just care about the behaviour. Same is true of 
classes A, B, and C, if they each include module M. Keeping in mind that each 
host class/object (classes and modules that include or extend M) can override 
any of the behaviour of M, each host should therefore be specified 
independently.

Additionally, if module M enforces some rule, like host objects (i.e. classes 
and modules that include or extend M) must implement method F, then that 
responsibility belongs to M, and should be specified in the context of M, not 
any of its host classes/objects.

So we're interested in specifying two things:
a. the behaviour of each class/object that mixes in M in response to events 
triggered by their consumers
b. the behaviour of M in response to being mixed in
 


For specifying the behaviour of M in response to being mixed in, I typically 
mix M into anonymous classes and objects and specify what happens. Brief 
example:

describe M do
  it "requires host object to provide a foo method" do
host = Object.new
expect do
  host.extend(M)
end.to raise_error(/Objects which extend M must provide a foo method/)
  end
end

For specifying the behaviour of host classes/objects, I've used a combination 
of shared example groups and custom macros in the past, but I don't think the 
macros will be necessary any longer. Thanks to some lively discussion [1-5], 
and code from Wincent Colaiuta, Ashley Moran and Myron Marsten, shared example 
groups just got _awesome_! They can now be parameterized and/or customized in 
three different ways. The biggest change came from having it_should_behave_like 
(and its new alias, it_behaves_like), generate a nested example group instead 
of mixing a module directly into the host group. This means that these two are 
equivalent:

###
shared_examples_for M
  it "does something" do
# 
  end
end

describe C do
  it_behaves_like M
end
###

###
describe C do
  context "behaves like M" do 
it "does something" do
  # 
end
  end
end
###

In rspec-1, shared groups are modules that get mixed into the host group, which 
means material defined in the shared group can impact the host group in 
surprising ways. With this new structure in rspec-2, the nested group is a 
completely separate group, and combination of sharing behaviour (through 
inheritance) and isolating behaviour (through encapsulation) provides power we 
never had before.

Here are the techniques for customizing shared groups:

# Parameterization
describe Host do
  it_should_behave_like M, Host.new
end

Here, the result of Host.new is passed to the shared group as a block 
parameter, making that value available at the group level (each example group 
is a class), and the instance level (each example runs in an _instance_ of that 
class). So ...

shared_examples_for M do |host|
  it "can access #{host} in the docstring" do
host.do_something # it can access the host _in_ the example
  end
end

# Methods defined in host group
describe Host do
  let(:foo) { Host.new }
  it_should_behave_like M
end

In this case, the foo method defined by let is inherited by the generated 
nested example group. Inherited methods like this are only available in the 
scope in which they are defined, so foo would be available at the instance 
level (i.e. in examples). If foo was defined as a class method, then it would 
be available at the class level in the nested group as well.

# Methods defined in an extension block
describe Host do
  it_should_behave_like M do
let(:foo) { Host.new }
  end
end

In this case, the block passed to it_should_behave_like is eval'd after the 
shared group is eval'd.

The combo of the extension block and inherited methods allows us to define 
groups that programmatically enforce rules for the host groups. For example:

shared_examples_for M do
  unless respond_to?(:foo)
raise "Groups that include shared examples for M must provide a foo method"
  end
end 

This means that library authors can now ship shared groups that will instruct 
end users how to use them. Awesome!!!


I'll amend and refine this in a blog post sometime soon, but hopefully this is 
a helpful overview.

Cheers,
David

[1] http://

Re: [rspec-users] Autotest does not start

[David Chelimsky]

On Aug 12, 2010, at 4:02 PM, Don French wrote:

> There are lots of spec files. I can run them using rspec spec and
> everything is great. just the autotest does not work.
> Don French

Did you create autotest/discover.rb?

http://blog.davidchelimsky.net/2010/03/15/rspec-2-and-autotest/

> 
> On Aug 12, 10:48 am, Don French  wrote:
>> put in
>> $:.unshift(File.dirname(__FILE__) + '/../lib')
>> require 'reader'
>> and get the same thing
>> 
>> dhf
>> 
>> On Aug 12, 10:13 am, David Chelimsky  wrote:
>> 
>> 
>> 
>>> On Aug 12, 2010, at 3:08 PM, Don French wrote:
>> 
>>>> The helper file does not have anything in it as of right now. It had
>>>> the the old
>>>>  #begin
>>>> #  require 'spec'
>>>> #rescue LoadError
>>>> #  require 'rubygems' unless Config['NO_RUBYGEMS']
>>>> #  gem 'rspec'
>>>> #  require 'spec'
>>>> #end
>>>> from rspec 1.3.0
>> 
>>>> Now it is empty.
>> 
>>> I can't find it, but I could swear there was a bug report about empty spec 
>>> files causing rspec to not output anything. Try putting some code in there 
>>> and see what happens.
>> 
>>>> This project was generated via newgem.
>> 
>>>> I want to upgrade to rspec2 and ruby 1.9.2.  Doing it in stages
>>>> currently 1.9.1.
>> 
>>>> Don French
>> 
>>>> On Aug 12, 8:21 am, Ashley Moran 
>>>> wrote:
>>>>> On 12 Aug 2010, at 08:27, Don French wrote:
>> 
>>>>>> under bundler bundle exec autotest  standalone autotest both within
>>>>>> the project directory and there is a spec subdirectory with the spec
>>>>>> in them.
>> 
>>>>> What happens when you run `rspec spec`?
>> 
>>>>> What is in your spec_helper.rb file?
>> 
>>>>> What is the output of `find spec`?
>> 
>>>>> That's all I can think of asking right now...
>> 
>>>>> --http://www.patchspace.co.uk/http://www.linkedin.com/in/ashleymoran
>> 
>>>>> ___
>>>>> rspec-users mailing list
>>>>> rspec-us...@rubyforge.orghttp://rubyforge.org/mailman/listinfo/rspec-users
>>>> ___
>>>> rspec-users mailing list
>>>> rspec-us...@rubyforge.org
>>>> http://rubyforge.org/mailman/listinfo/rspec-users
>> 
>>> ___
>>> rspec-users mailing list
>>> rspec-us...@rubyforge.orghttp://rubyforge.org/mailman/listinfo/rspec-users
>> 
>> ___
>> rspec-users mailing list
>> rspec-us...@rubyforge.orghttp://rubyforge.org/mailman/listinfo/rspec-users
> ___
> rspec-users mailing list
> rspec-users@rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users

___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users

Re: [rspec-users] Autotest does not start

[David Chelimsky]

On Aug 12, 2010, at 3:08 PM, Don French wrote:

> The helper file does not have anything in it as of right now. It had
> the the old
>  #begin
> #  require 'spec'
> #rescue LoadError
> #  require 'rubygems' unless Config['NO_RUBYGEMS']
> #  gem 'rspec'
> #  require 'spec'
> #end
> from rspec 1.3.0
> 
> Now it is empty.

I can't find it, but I could swear there was a bug report about empty spec 
files causing rspec to not output anything. Try putting some code in there and 
see what happens.



> This project was generated via newgem.
> 
> I want to upgrade to rspec2 and ruby 1.9.2.  Doing it in stages
> currently 1.9.1.
> 
> Don French
> 
> On Aug 12, 8:21 am, Ashley Moran 
> wrote:
>> On 12 Aug 2010, at 08:27, Don French wrote:
>> 
>>> under bundler bundle exec autotest  standalone autotest both within
>>> the project directory and there is a spec subdirectory with the spec
>>> in them.
>> 
>> What happens when you run `rspec spec`?
>> 
>> What is in your spec_helper.rb file?
>> 
>> What is the output of `find spec`?
>> 
>> That's all I can think of asking right now...
>> 
>> --http://www.patchspace.co.uk/http://www.linkedin.com/in/ashleymoran
>> 
>> ___
>> rspec-users mailing list
>> rspec-us...@rubyforge.orghttp://rubyforge.org/mailman/listinfo/rspec-users
> ___
> rspec-users mailing list
> rspec-users@rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users

___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users

Re: [rspec-users] Name collision - how would you handle this?

[David Chelimsky]

On Aug 11, 2010, at 3:05 PM, Myron Marston wrote:

> Sorry it's taken me so long to respond--I have considerably less time
> on weekdays than the weekend to take care of things like this.
> 
>> Yehuda Katz made a similar suggestion to me, referencing some code from 
>> merb:http://github.com/merb/merb/blob/master/merb-core/lib/merb-core/contr...
>> 
>> Merb also has an override! method that end users can use to override the 
>> registered reserved methods, which I agree would be a necessary part of 
>> this. The idea being that any user that does that does so explicitly and 
>> knowingly.
> 
> Merb's implementation is very similar to what I had in mind.  It's
> nice to see I'm not in left field with my idea :).
> 
> I agree that having something like override! is important, although I
> think I slightly prefer an API like this:
> 
> allow_reserved_overrides do
>  def reserved_method
>  end
> end
> 
> Or maybe I like blocks too much...
> 
>> The blacklist comment probably wouldn't work for upstream libs like Rails, 
>> Test::Unit or MiniUnit. It would be up to RSpec to define those lists. But 
>> maybe that's an acceptable tradeoff. WDYT?
> 
> RSpec is pretty high-profile in the Ruby community, so we could
> hopefully get most libraries to add their reserved methods using
> something like:
> 
> if defined?(RSpec::Core.add_reserved_methods)
>  RSpec::Core.add_reserved_methods :foo, :bar, :bazz
> end
> 
> As far as Rails goes, rspec-rails seems like a natural point to
> register these reserved methods.  For libraries that are distributed
> with ruby like Test::Unit, I think it's acceptable to register their
> reserved methods in rspec-core itself.

I think they should all be registered in the same place, in rspec-core. Or are 
you saying that rspec-rails would take the responsibility of registering the 
names for rspec-rails, rails, test/unit and minitest? That makes sense to me, 
as long as they're all using RSpec::Core::register_reserved_name (or whatever).

> What do others think of this idea?  I'm willing to take a stab at
> implementing this if there is support for it.

I'm still not sold on this idea yet. Seems like a lot of complexity for not 
much benefit. I've already taken care of the message issue by encapsulating the 
assertion libs in a separate scope.

Anybody else have opinions on this?

> 
> Myron
> 
> ___
> rspec-users mailing list
> rspec-users@rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users

___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users

Re: [rspec-users] Autotest does not start

[David Chelimsky]

On Aug 11, 2010, at 4:54 PM, Don French wrote:

> That is correct. No tests are run. Just get the OS command prompt
> back.

You said in an earlier post that this happens whether you run this under 
bundler or not. What, precisely, are the commands you're using?

> Don French
> 
> 
> On Aug 11, 8:49 am, Ashley Moran 
> wrote:
>> On 11 Aug 2010, at 19:44, Don French wrote:
>> 
>>> Any help on this. I think I have read all posts related to autotest
>>> but still do not have the answer. Is there something that works better
>>> with Rspec that autotest?
>> 
>> When you say "and a prompt (back)" ... do you mean autotest exits in both 
>> situations and doesn't run any tests?
>> 
>> (I'm running autotest with RSpec 2 fine, BTW.)
>> 
>> Ash
>> 
>> --http://www.patchspace.co.uk/http://www.linkedin.com/in/ashleymoran
>> 
>> ___
>> rspec-users mailing list
>> rspec-us...@rubyforge.orghttp://rubyforge.org/mailman/listinfo/rspec-users
> ___
> rspec-users mailing list
> rspec-users@rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users

___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users

Re: [rspec-users] Rspec2, Autotest showing failure on all passing specs

[David Chelimsky]

On Aug 11, 2010, at 2:48 PM, Pixel wrote:

> On Wed, Aug 11, 2010 at 12:21 AM, David Chelimsky  
> wrote:
>> I've never seen that before. Do you have red_green installed and maybe 
>> referenced from ~/.autotest?
>> 
>>> 
>>> Off to try and reproduce this on a fresh gemset
>>> 
>>> -Cole
> 
> Hey David,
> It appears at the moment that this is coming from a gem called
> autotest-notification that does a bit of magic with the ~/.autotest
> file to add itself.  There is an open issue already and it doesn't
> seem like there is anything hinky about my setup.  My current
> suspicion is that it's because this autotest-notification gem can't
> play nicely with a) latest autotest b) rspec2 c)ruby 1.9.*.  I'm
> poking around in it right now to try to figure out if it's something I
> can fix.
> 
> Thanks for your response, for whatever reason I thought that bit of
> output was coming from autotest when it's really coming from this
> other gem.

Glad you found it, and thanks for following up. Hopefully you'll save the next 
person to experience this a few cycles.

Cheers,
David

> Thanks.
> -Cole

___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users

Re: [rspec-users] rspec2 not working with shoulda

[David Chelimsky]

On Aug 11, 2010, at 9:36 AM, David Chelimsky wrote:

> 
> On Aug 11, 2010, at 2:31 AM, Nadal wrote:
> 
>> I am using rails edge. I am using gem "rspec-rails", "= 2.0.0.beta.
>> 19" .
>> 
>> I have following code at spec/models/user_spec.rb
>> 
>> require 'spec_helper'
>> 
>> describe User do
>> 
>> it { should validate_presence_of(:email) }
>> 
>> it { should validate_presence_of(:name) }
>> 
>> end
>> 
>> 
>> Here is my gemfile
>> 
>> group :development, :test do
>> gem 'factory_girl_rails', :git => 'git://github.com/thoughtbot/
>> factory_girl_rails'
>> gem 'shoulda'
>> gem "rspec-rails", "= 2.0.0.beta.19"
>> gem "cucumber-rails", "= 0.3.2"
>> gem "capybara"
>> gem "launchy"
>> end
>> 
>> I am getting following error message.
>> 
>> 
>> Failure/Error: it { should validate_presence_of(:email) }
>>   undefined method `validate_presence_of' for
>> #
>>   # ./spec/models/user_spec.rb:5
> 
> Sounds like shoulda is not registering itself properly with rspec-2. I'd 
> check with the should list: http://groups.google.com/group/shoulda.

Also - the subject line is backwards - it shoulda been "shoulda not working 
with rspec-2" ;)

> 
> HTH,
> David
> 
> 
> 

___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users

Re: [rspec-users] rspec2 not working with shoulda

[David Chelimsky]

On Aug 11, 2010, at 2:31 AM, Nadal wrote:

> I am using rails edge. I am using gem "rspec-rails", "= 2.0.0.beta.
> 19" .
> 
> I have following code at spec/models/user_spec.rb
> 
> require 'spec_helper'
> 
> describe User do
> 
>  it { should validate_presence_of(:email) }
> 
>  it { should validate_presence_of(:name) }
> 
> end
> 
> 
> Here is my gemfile
> 
> group :development, :test do
>  gem 'factory_girl_rails', :git => 'git://github.com/thoughtbot/
> factory_girl_rails'
>  gem 'shoulda'
>  gem "rspec-rails", "= 2.0.0.beta.19"
>  gem "cucumber-rails", "= 0.3.2"
>  gem "capybara"
>  gem "launchy"
> end
> 
> I am getting following error message.
> 
> 
> Failure/Error: it { should validate_presence_of(:email) }
>undefined method `validate_presence_of' for
> #
># ./spec/models/user_spec.rb:5

Sounds like shoulda is not registering itself properly with rspec-2. I'd check 
with the should list: http://groups.google.com/group/shoulda.

HTH,
David



___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users

Re: [rspec-users] Rspec2, Autotest showing failure on all passing specs

[David Chelimsky]

On Aug 10, 2010, at 10:45 PM, Pixel wrote:

> Hey guys,
> This is making me nuts, and I've run out of things to google.
> I'm writing myself a little gem library, primarily for my own
> education.  I got a healthy start on my specs and figured I could do
> myself a favor and get the specs running under autotest.  It's not
> working quite like I expected.  My specs all pass, but autotest is
> showing red instead of green.  I've uploaded a screenshot of what I'm
> seeing, since I don't have a specific error to report.
> 
> http://img580.imageshack.us/img580/3396/screenshotterminal08111.png
> 
> You can see rspec is working fine without autotest.
> 
> I'm looking for two things here:
> a) How do I get more information out of autotest and/or rspec about
> this apparent error?  I've tried various incantations involving
> --verbose and -b and nothing seems to be getting at the information I
> want.
> b) How do I fix this?  I'd be happy to do more googling but I don't
> know what to look for anymore, various combinations of 'autotest'
> 'failure' 'rspec' 'rspec2' arn't getting me the information I need and
> I don't know what other keywords I can use.  I've gisted some of my
> configuration type files in hopes that I've just missed some simple
> setup (I used jeweler to start the setup, but it's setup for rspec1
> not rspec2 so I wonder if that's where the problem originated?)  You
> can see those here: http://gist.github.com/518386  (I'd be happy to
> include more if it's useful.)

I've never seen that before. Do you have red_green installed and maybe 
referenced from ~/.autotest?

> 
> Off to try and reproduce this on a fresh gemset
> 
> -Cole
> ___
> rspec-users mailing list
> rspec-users@rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users

___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users

Re: [rspec-users] Order guarantees of let

[David Chelimsky]

On Aug 10, 2010, at 9:08 AM, Rick DeNatale wrote:
> On Mon, Aug 9, 2010 at 11:21 AM, David Chelimsky  wrote:
>>> First of all, what's let! as opposed to let, I can't seem to find it
>>> via google or the latest draft of the book.
>> 
>> http://rdoc.info/projects/rspec/rspec-core - search for let and let!
>> 
>>> 
>>> Second, unless let! is a new method which not only defines the
>>> memoized method but invokes it
>> 
>> That's what it is. Sort of. It gets invoked by an implicit before hook which 
>> is added - those get eval'd in the order in which they get defined.
> 
> Makes sense.  So is it not (going to be) mentioned in the book, it
> doesn't seem to be in Beta 15.0 supposedly the final beta version.

Correct. At this point in the production process (indexing) there is no room to 
add new technical content to the book.

> -- 
> Rick DeNatale
> 
> Blog: http://talklikeaduck.denhaven2.com/
> Github: http://github.com/rubyredrick
> Twitter: @RickDeNatale
> WWR: http://www.workingwithrails.com/person/9021-rick-denatale
> LinkedIn: http://www.linkedin.com/in/rickdenatale
> ___
> rspec-users mailing list
> rspec-users@rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users

___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users

Re: [rspec-users] Cant able to create a Rspec files

[David Chelimsky]

On Aug 10, 2010, at 6:27 AM, Aruna Chinnamuthu wrote:

> Hi,
> 
> I am new to ROR. I am working on Rspec..
> I have been provided with a full package of an application.
> I kept it in my rails dir.
> The dir itself contains  spec folder with some controllers/models and
> fixtures but without spec_helper file.
> So when i run $spec spec/ i got an error
> 
> 
> /usr/lib/ruby/gems/1.8/gems/rspec-1.3.0/lib/spec/runner/options.rb:283:in
> `files_to_load': File or directory not found: spec/ (RuntimeError)
> 
> So i simply deleted the whole spec folder.
> And again created  a new spec by
> 
> ar...@aruna-desktop:~/railsprojects/appname_c$ script/generate rspec
> Configuring rspec and rspec-rails gems in config/environments/test.rb
> ...
> 
>  exists  lib/tasks
>  create  lib/tasks/rspec.rake
>  create  script/autospec
>  create  script/spec
>  create  spec
>  create  spec/rcov.opts
>  create  spec/spec.opts
>  create  spec/spec_helper.rb
> 
> 
> ar...@aruna-desktop:~/railsprojects/appname_c$
> 
> 
> after all this .. I try to add the testing spec for my controller Users
> by
> 
> ar...@aruna-desktop:~/railsprojects/appname_c$ script/generate
> rspec_controller Users new
> The name 'UsersController' is either already used in your
> application or reserved by Ruby on Rails.
> Please choose an alternative and run this generator again.
> ar...@aruna-desktop:~/railsprojects/appname_c$
> 
> I am getting the error as above ..
> Pls give me suggestions of why i am getting this error.
> How to resolve this one..

Hi Aruna,

I see that this is all a bit new for you, so here are a couple of things you 
may not understand.

The people who participate in this mailing list are here to help you, but we 
all volunteer our time to do this. This means that you have a responsibility to 
research things on your own before you ask questions here. I'm not talking 
hours of research, but in this case a simple google search will point you to 
the answer to your question. [1]

If you do a search like that and find that you are confused by the information 
that _is_ available, then by all means, please feel free to write us here with 
links to the confusing information and we'll either try to help or try to point 
you to a better resource (for example, this question is really a Rails 
question, not an RSpec question, so we'd likely point you to the Rails mailing 
list [2] for assistance).

I realize this may seem a bit off-puttting, but if you peruse our archives I 
think you'll see that we're actually a pretty helpful bunch, and we do look 
forward to helping you with your questions about RSpec.

Cheers,
David

[1] 
http://lmgtfy.com/?q=The+name+%27UsersController%27+is+either+already+used+in+your+application+or+reserved+by+Ruby+on+Rails.
[2] http://groups.google.com/group/rubyonrails-talk

> -- 
> Posted via http://www.ruby-forum.com/.
> ___
> rspec-users mailing list
> rspec-users@rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users

___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users

Re: [rspec-users] issue with rescue_action_in_public! and testing 404 responses

[David Chelimsky]

On Aug 8, 2010, at 2:53 PM, christofferklang wrote:

> Hello,
> I'm new to rails and I'm trying to wrap my heads around how to spec 
> controllers using RSpec (using rails 3rc1 and rspec 2.0.0.beta.19).
> 
> The problem I've run into is when I want to test that my controllers respond 
> with a 404 for unfound records. Whenever I run the spec, the 
> ActiveRecord::RecordNotFound exception is not caught by rails, causing the 
> spec example to fail since the exception propagates out of the controller 
> into the spec.
> 
> >From googling around I get that rails only handles the exceptions and does a 
> >404 response when it's run in production mode, and that you need to call 
> >rescue_action_in_public! in your example if you want this behavior for test 
> >mode. However, this does not seem to do anything for me. The example still 
> >fails because the exception bubbles escapes unhandled from the controller.
> 
> Do I need to set something up for the rescue_action_in_public! to work? Or is 
> this not the correct way to test missing records?
> 
> My full example: (using factory_girl, rspec mocks and devise)
> 
> 
> it "respons with 404 when trying to edit non-existing reads" do
>rescue_action_in_public!
>sign_in(@user)
>Read.should_receive(:find_by_id_and_user_id!).with(2, 
> @user.id).and_raise(ActiveRecord::RecordNotFound)
> 
>get :edit, :id => 2
>response.status.should eql 404
>  end
> 
> 
> and the exception:
> 1) ReadsController resources respons with 404 for non existing reads for GET 
> /reads/2/edit
> Failure/Error: get :edit, :id => 2
> ActiveRecord::RecordNotFound
It's up to you to handle the error in the controller. Something like this in 
ApplicationController:

  rescue_from ActiveRecord::RecordNotFound do
render '/404.html', :layout => false, :status => :not_found
  end

HTH,
David

> Thanks, /Christoffer 

___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users

Re: [rspec-users] Recognising RSpec files in the Textmate bundle

[David Chelimsky]

On Aug 9, 2010, at 9:56 AM, Rick DeNatale wrote:

> On Sun, Aug 8, 2010 at 11:45 PM, Elliot Winkler
>  wrote:
>> On Sun, Aug 8, 2010 at 3:53 PM, Phillip Koebbe 
>> wrote:
>>> 
>>> Here's another idea that's not so great, but maybe it will spur some
>>> thinking in someone else. What about a custom generator (or a flag on the
>>> official one) that added something like a shebang line at the beginning of
>>> example files. A short comment that identifies the file, like "# RSpec".
>>> Then a TM bundle could pick up on that and be happy.
>> 
>> Putting aside the fact that this is solving a very specific problem what
>> about #!/usr/bin/env spec ? 99% of the time the shebang won't be used, I'd
>> wager, so it'd pretty much be harmless.
> 
> As I tried to point out, textmate looks for shebang lines to compare
> against in the language definitions.  Right now the rspec bundle
> doesn't have a language definition since rspec files are really ruby
> files and want to use that language definition.
> 
> I guess I just don't see what's wrong with using the convention of
> naming spec files with the suffix _spec.rb as Mr. Textmate suggests
> http://blog.macromates.com/2007/file-type-detection-rspec-rails/
> 
> It's worked well for me for quite some time.

Hey Rick,

Shared groups are typically stored in a file that has a different name, and ppl 
want access to all the code completion and syntax highlighting of spec files in 
those files.

HTH,
David

> -- 
> Rick DeNatale
> 
> Blog: http://talklikeaduck.denhaven2.com/
> Github: http://github.com/rubyredrick
> Twitter: @RickDeNatale
> WWR: http://www.workingwithrails.com/person/9021-rick-denatale
> LinkedIn: http://www.linkedin.com/in/rickdenatale
> ___
> rspec-users mailing list
> rspec-users@rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users

___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users

Re: [rspec-users] Order guarantees of let

[David Chelimsky]

On Aug 9, 2010, at 10:06 AM, Rick DeNatale wrote:

> On Mon, Aug 9, 2010 at 8:49 AM, David Chelimsky  wrote:
>> 
>> On Aug 9, 2010, at 7:38 AM, Ashley Moran wrote:
>> 
>>> Hi
>>> 
>>> I was just about to replace a `before` block along the lines of:
>>> 
>>>  before(:each) do
>>>@cti_b_id = service.create(name: "Item-B")
>>>@cti_z_id = service.create(name: "Z-Item")
>>>@cti_a_id = service.create(name: "Item-A")
>>># ...
>>>  end
>>> 
>>> with
>>> 
>>>   let!(:cti_b_id) { ... }
>>>   let!(:cti_z_id) { ... }
>>>   let!(:cti_a_id) { ... }
>>> 
>>> But then I wondered - since the spec depends on the order they are created 
>>> in (it proves ordering is independent of creation order) - is the run order 
>>> of `let!` guaranteed?  I imagine they run in the order I expect (ie top to 
>>> bottom), but I wondered if that was an explicitly stated property of RSpec?
>> 
>> Yes, eval'd in order. No, not explicitly stated, but I think it should be. 
>> Want to submit a patch with a spec for this?
> 
> But,
> 
> First of all, what's let! as opposed to let, I can't seem to find it
> via google or the latest draft of the book.

http://rdoc.info/projects/rspec/rspec-core - search for let and let!

> 
> Second, unless let! is a new method which not only defines the
> memoized method but invokes it

That's what it is. Sort of. It gets invoked by an implicit before hook which is 
added - those get eval'd in the order in which they get defined.

> , then the order of evaluation will
> depend on the order the generated let methods are invoked in the
> example won't it?
> 
> 
> -- 
> Rick DeNatale
> 
> Blog: http://talklikeaduck.denhaven2.com/
> Github: http://github.com/rubyredrick
> Twitter: @RickDeNatale
> WWR: http://www.workingwithrails.com/person/9021-rick-denatale
> LinkedIn: http://www.linkedin.com/in/rickdenatale
> ___
> rspec-users mailing list
> rspec-users@rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users

___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users

Re: [rspec-users] Name collision - how would you handle this?

[David Chelimsky]

On Aug 9, 2010, at 7:42 AM, Matt Wynne wrote:

> 
> On 9 Aug 2010, at 13:04, David Chelimsky wrote:
> 
>> 
>> On Aug 9, 2010, at 6:37 AM, Matt Wynne wrote:
>> 
>>> 
>>> On 9 Aug 2010, at 01:54, David Chelimsky wrote:
>>> 
>>>> 
>>>> On Aug 8, 2010, at 11:13 AM, Matt Wynne wrote:
>>>> 
>>>>> 
>>>>> On 8 Aug 2010, at 16:53, David Chelimsky wrote:
>>>>> 
>>>>>> On Aug 8, 2010, at 10:40 AM, Matt Wynne wrote:
>>>>>>> On 8 Aug 2010, at 16:38, David Chelimsky wrote:
>>>>>>>> On Aug 7, 2010, at 4:10 PM, David Chelimsky wrote:
>>>>>>>> 
>>>>>>>>> Hey all,
>>>>>>>>> 
>>>>>>>>> It turns out that if you have
>>>>>>>>> 
>>>>>>>>> * Rails (2 or 3)
>>>>>>>>> * Ruby-1.9
>>>>>>>>> * a model named Message
>>>>>>>>> * let(:message) or def message in an example group
>>>>>>>>> * a Rails assertion in an example in that group
>>>>>>>>> * note that rspec-rails' matchers delegate to Rails' assertions
>>>>>>>>> 
>>>>>>>>> You'll get an error saying "wrong number of arguments (1 for 0)"
>>>>>>>>> 
>>>>>>>>> This is because the rails assertion, which, when running with 
>>>>>>>>> Ruby-1.9, delegates to Minitest::Assertions#assert_block, which 
>>>>>>>>> delegates to a message() method that it defines. So the message() 
>>>>>>>>> method defined by let() overrides the message() method in the 
>>>>>>>>> Assertions module, and results in unexpected and undesirable outcomes.
>>>>>>>>> 
>>>>>>>>> So - what should we do? I don't think changing Minitest is really an 
>>>>>>>>> option, as too many assertion libraries already wrap Minitest 
>>>>>>>>> assertions. I don't think RSpec should be in the business of 
>>>>>>>>> monitoring methods end-users define to make sure they're not 
>>>>>>>>> overriding pre-existing methods (what if you override a method 
>>>>>>>>> intentionally?). The only thing I'm left with is document this 
>>>>>>>>> particular case and hope for the best, but that feels unsatisfactory 
>>>>>>>>> as well.
>>>>>>>>> 
>>>>>>>>> Recommendations? Words of wisdom?
>>>>>>>> 
>>>>>>>> FYI - here's the issue that spawned this thread: 
>>>>>>>> http://github.com/rspec/rspec-rails/issues/152
>>>>>>> 
>>>>>>> Can you use the Assertions module some other way than mixing it into 
>>>>>>> the example (thereby polluting it with the Assertions module's methods?)
>>>>>> 
>>>>>> I like the idea in the abstract, but most of the rails assertions rely 
>>>>>> on some state that is local to the example (@response, @controller, 
>>>>>> @request, etc, etc). RSpec _could_ gather up all those instance 
>>>>>> variables and pass them into an assertion-wrapper object, but then it 
>>>>>> would be highly coupled to that implementation and would lead us down a 
>>>>>> familiar and unfriendly path of forcing rspec-rails releases for every 
>>>>>> rails release. That's a world I hope to leave behind with Rails 3 :)
>>>>> 
>>>>> So leave the rails assertions mixed into the example, but forward all the 
>>>>> calls to the MiniTest::Assertions methods to some other object that has 
>>>>> them mixed in. Won't that work?
>>>> 
>>>> Here's a prototype implementation: 
>>>> http://github.com/rspec/rspec-rails/commit/0cd384536cf532435ec8f290a9c357b60872acd7
>>>> 
>>>> It's on a branch 
>>>> (http://github.com/rspec/rspec-rails/tree/assertion-delegate) because I'm 
>>>> not convinced this is the right way to go yet, but I'd like some feedback 
>>>> from anyone who wishes to peruse and comment.
>>> 
>>> Yeah, that's what I was talking about. Co

Re: [rspec-users] Order guarantees of let

[David Chelimsky]

On Aug 9, 2010, at 7:38 AM, Ashley Moran wrote:

> Hi
> 
> I was just about to replace a `before` block along the lines of:
> 
>  before(:each) do
>@cti_b_id = service.create(name: "Item-B")
>@cti_z_id = service.create(name: "Z-Item")
>@cti_a_id = service.create(name: "Item-A")
># ...
>  end
> 
> with
> 
>   let!(:cti_b_id) { ... }
>   let!(:cti_z_id) { ... }
>   let!(:cti_a_id) { ... }
> 
> But then I wondered - since the spec depends on the order they are created in 
> (it proves ordering is independent of creation order) - is the run order of 
> `let!` guaranteed?  I imagine they run in the order I expect (ie top to 
> bottom), but I wondered if that was an explicitly stated property of RSpec?

Yes, eval'd in order. No, not explicitly stated, but I think it should be. Want 
to submit a patch with a spec for this?

> 
> Cheers
> Ash
> 
> -- 
> http://www.patchspace.co.uk/
> http://www.linkedin.com/in/ashleymoran
> 
> ___
> rspec-users mailing list
> rspec-users@rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users

___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users

Re: [rspec-users] Name collision - how would you handle this?

[David Chelimsky]

On Aug 9, 2010, at 6:37 AM, Matt Wynne wrote:

> 
> On 9 Aug 2010, at 01:54, David Chelimsky wrote:
> 
>> 
>> On Aug 8, 2010, at 11:13 AM, Matt Wynne wrote:
>> 
>>> 
>>> On 8 Aug 2010, at 16:53, David Chelimsky wrote:
>>> 
>>>> On Aug 8, 2010, at 10:40 AM, Matt Wynne wrote:
>>>>> On 8 Aug 2010, at 16:38, David Chelimsky wrote:
>>>>>> On Aug 7, 2010, at 4:10 PM, David Chelimsky wrote:
>>>>>> 
>>>>>>> Hey all,
>>>>>>> 
>>>>>>> It turns out that if you have
>>>>>>> 
>>>>>>> * Rails (2 or 3)
>>>>>>> * Ruby-1.9
>>>>>>> * a model named Message
>>>>>>> * let(:message) or def message in an example group
>>>>>>> * a Rails assertion in an example in that group
>>>>>>> * note that rspec-rails' matchers delegate to Rails' assertions
>>>>>>> 
>>>>>>> You'll get an error saying "wrong number of arguments (1 for 0)"
>>>>>>> 
>>>>>>> This is because the rails assertion, which, when running with Ruby-1.9, 
>>>>>>> delegates to Minitest::Assertions#assert_block, which delegates to a 
>>>>>>> message() method that it defines. So the message() method defined by 
>>>>>>> let() overrides the message() method in the Assertions module, and 
>>>>>>> results in unexpected and undesirable outcomes.
>>>>>>> 
>>>>>>> So - what should we do? I don't think changing Minitest is really an 
>>>>>>> option, as too many assertion libraries already wrap Minitest 
>>>>>>> assertions. I don't think RSpec should be in the business of monitoring 
>>>>>>> methods end-users define to make sure they're not overriding 
>>>>>>> pre-existing methods (what if you override a method intentionally?). 
>>>>>>> The only thing I'm left with is document this particular case and hope 
>>>>>>> for the best, but that feels unsatisfactory as well.
>>>>>>> 
>>>>>>> Recommendations? Words of wisdom?
>>>>>> 
>>>>>> FYI - here's the issue that spawned this thread: 
>>>>>> http://github.com/rspec/rspec-rails/issues/152
>>>>> 
>>>>> Can you use the Assertions module some other way than mixing it into the 
>>>>> example (thereby polluting it with the Assertions module's methods?)
>>>> 
>>>> I like the idea in the abstract, but most of the rails assertions rely on 
>>>> some state that is local to the example (@response, @controller, @request, 
>>>> etc, etc). RSpec _could_ gather up all those instance variables and pass 
>>>> them into an assertion-wrapper object, but then it would be highly coupled 
>>>> to that implementation and would lead us down a familiar and unfriendly 
>>>> path of forcing rspec-rails releases for every rails release. That's a 
>>>> world I hope to leave behind with Rails 3 :)
>>> 
>>> So leave the rails assertions mixed into the example, but forward all the 
>>> calls to the MiniTest::Assertions methods to some other object that has 
>>> them mixed in. Won't that work?
>> 
>> Here's a prototype implementation: 
>> http://github.com/rspec/rspec-rails/commit/0cd384536cf532435ec8f290a9c357b60872acd7
>> 
>> It's on a branch 
>> (http://github.com/rspec/rspec-rails/tree/assertion-delegate) because I'm 
>> not convinced this is the right way to go yet, but I'd like some feedback 
>> from anyone who wishes to peruse and comment.
> 
> Yeah, that's what I was talking about. Couple of thoughts / questions:
> 
> I'm still not clear why you need to copy the instance variable over though - 
> do the rails assertions get monkey-patched into the Test::Unit::Assertions 
> module then?

No - holdover from exploratory session.

> Also, how come there's nothing in the specs about the #message method that 
> caused all this?

Good point.

New patch: 
http://github.com/rspec/rspec-rails/commit/86600313462638e7becc726e53f1bc67af108667

>> Thanks,
>> David
>> 
>>>> It would also eliminate the option to use the Rails assertions directly in 
>>>> examples.
>>>> 
>>>> Oh, well :)
>>>> 
>>>>> cheers,
>>>>> Matt
>>>>> 
>>>>> http://blog.mattwynne.net
>>>>> +44(0)7974 430184
>>>> 
>>>> ___
>>>> rspec-users mailing list
>>>> rspec-users@rubyforge.org
>>>> http://rubyforge.org/mailman/listinfo/rspec-users
>>> 
>>> cheers,
>>> Matt
>>> 
>>> http://blog.mattwynne.net
>>> +44(0)7974 430184
>>> 
>>> ___
>>> rspec-users mailing list
>>> rspec-users@rubyforge.org
>>> http://rubyforge.org/mailman/listinfo/rspec-users
>> 
>> ___
>> rspec-users mailing list
>> rspec-users@rubyforge.org
>> http://rubyforge.org/mailman/listinfo/rspec-users
> 
> cheers,
> Matt
> 
> http://blog.mattwynne.net
> +44(0)7974 430184
> 
> ___
> rspec-users mailing list
> rspec-users@rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users

___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users

Re: [rspec-users] Name collision - how would you handle this?

[David Chelimsky]

On Aug 8, 2010, at 11:58 AM, Myron Marston wrote:

> Good error messages are important to a library's usability.  Could we
> find away to give the user a good error message when they override a
> "reserved method"?
> 
> I'm thinking this could be accomplished with 2 simple pieces:
> 
> 1. A method_added hook in Rspec-core that gives a warning or error
> when a reserved method is overridden.
> 2. An API that allows libraries to add to the reserved methods list.
> 
> That way, rspec doesn't have to have knowledge of other libraries; it
> would be the responsibility of other libraries to add their reserved
> methods to the list.

Yehuda Katz made a similar suggestion to me, referencing some code from merb: 
http://github.com/merb/merb/blob/master/merb-core/lib/merb-core/controller/merb_controller.rb#L508

Merb also has an override! method that end users can use to override the 
registered reserved methods, which I agree would be a necessary part of this. 
The idea being that any user that does that does so explicitly and knowingly.

The blacklist comment probably wouldn't work for upstream libs like Rails, 
Test::Unit or MiniUnit. It would be up to RSpec to define those lists. But 
maybe that's an acceptable tradeoff. WDYT?


> Myron
> 
> On Aug 8, 9:13 am, Matt Wynne  wrote:
>> On 8 Aug 2010, at 16:53, David Chelimsky wrote:
>> 
>> 
>> 
>> 
>> 
>>> On Aug 8, 2010, at 10:40 AM, Matt Wynne wrote:
>>>> On 8 Aug 2010, at 16:38, David Chelimsky wrote:
>>>>> On Aug 7, 2010, at 4:10 PM, David Chelimsky wrote:
>> 
>>>>>> Hey all,
>> 
>>>>>> It turns out that if you have
>> 
>>>>>> * Rails (2 or 3)
>>>>>> * Ruby-1.9
>>>>>> * a model named Message
>>>>>> * let(:message) or def message in an example group
>>>>>> * a Rails assertion in an example in that group
>>>>>> * note that rspec-rails' matchers delegate to Rails' assertions
>> 
>>>>>> You'll get an error saying "wrong number of arguments (1 for 0)"
>> 
>>>>>> This is because the rails assertion, which, when running with Ruby-1.9, 
>>>>>> delegates to Minitest::Assertions#assert_block, which delegates to a 
>>>>>> message() method that it defines. So the message() method defined by 
>>>>>> let() overrides the message() method in the Assertions module, and 
>>>>>> results in unexpected and undesirable outcomes.
>> 
>>>>>> So - what should we do? I don't think changing Minitest is really an 
>>>>>> option, as too many assertion libraries already wrap Minitest 
>>>>>> assertions. I don't think RSpec should be in the business of monitoring 
>>>>>> methods end-users define to make sure they're not overriding 
>>>>>> pre-existing methods (what if you override a method intentionally?). The 
>>>>>> only thing I'm left with is document this particular case and hope for 
>>>>>> the best, but that feels unsatisfactory as well.
>> 
>>>>>> Recommendations? Words of wisdom?
>> 
>>>>> FYI - here's the issue that spawned this 
>>>>> thread:http://github.com/rspec/rspec-rails/issues/152
>> 
>>>> Can you use the Assertions module some other way than mixing it into the 
>>>> example (thereby polluting it with the Assertions module's methods?)
>> 
>>> I like the idea in the abstract, but most of the rails assertions rely on 
>>> some state that is local to the example (@response, @controller, @request, 
>>> etc, etc). RSpec _could_ gather up all those instance variables and pass 
>>> them into an assertion-wrapper object, but then it would be highly coupled 
>>> to that implementation and would lead us down a familiar and unfriendly 
>>> path of forcing rspec-rails releases for every rails release. That's a 
>>> world I hope to leave behind with Rails 3 :)
>> 
>> So leave the rails assertions mixed into the example, but forward all the 
>> calls to the MiniTest::Assertions methods to some other object that has them 
>> mixed in. Won't that work?
>> 
>> 
>> 
>>> It would also eliminate the option to use the Rails assertions directly in 
>>> examples.
>> 
>>> Oh, well :)
>> 
>>>> cheers,
>>>> Matt
>> 
>>>> http://blog.mattwynne.net
>>>> +44(0)7974 430184
>> 
>>> ___
>>> rspec-users mailing list
>>> rspec-us...@rubyforge.org
>>> http://rubyforge.org/mailman/listinfo/rspec-users
>> 
>> cheers,
>> Matt
>> 
>> http://blog.mattwynne.net+44(0)7974 430184
>> 
>> ___
>> rspec-users mailing list
>> rspec-us...@rubyforge.orghttp://rubyforge.org/mailman/listinfo/rspec-users
> ___
> rspec-users mailing list
> rspec-users@rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users

___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users

Re: [rspec-users] Name collision - how would you handle this?

[David Chelimsky]

On Aug 8, 2010, at 11:13 AM, Matt Wynne wrote:

> 
> On 8 Aug 2010, at 16:53, David Chelimsky wrote:
> 
>> On Aug 8, 2010, at 10:40 AM, Matt Wynne wrote:
>>> On 8 Aug 2010, at 16:38, David Chelimsky wrote:
>>>> On Aug 7, 2010, at 4:10 PM, David Chelimsky wrote:
>>>> 
>>>>> Hey all,
>>>>> 
>>>>> It turns out that if you have
>>>>> 
>>>>> * Rails (2 or 3)
>>>>> * Ruby-1.9
>>>>> * a model named Message
>>>>> * let(:message) or def message in an example group
>>>>> * a Rails assertion in an example in that group
>>>>> * note that rspec-rails' matchers delegate to Rails' assertions
>>>>> 
>>>>> You'll get an error saying "wrong number of arguments (1 for 0)"
>>>>> 
>>>>> This is because the rails assertion, which, when running with Ruby-1.9, 
>>>>> delegates to Minitest::Assertions#assert_block, which delegates to a 
>>>>> message() method that it defines. So the message() method defined by 
>>>>> let() overrides the message() method in the Assertions module, and 
>>>>> results in unexpected and undesirable outcomes.
>>>>> 
>>>>> So - what should we do? I don't think changing Minitest is really an 
>>>>> option, as too many assertion libraries already wrap Minitest assertions. 
>>>>> I don't think RSpec should be in the business of monitoring methods 
>>>>> end-users define to make sure they're not overriding pre-existing methods 
>>>>> (what if you override a method intentionally?). The only thing I'm left 
>>>>> with is document this particular case and hope for the best, but that 
>>>>> feels unsatisfactory as well.
>>>>> 
>>>>> Recommendations? Words of wisdom?
>>>> 
>>>> FYI - here's the issue that spawned this thread: 
>>>> http://github.com/rspec/rspec-rails/issues/152
>>> 
>>> Can you use the Assertions module some other way than mixing it into the 
>>> example (thereby polluting it with the Assertions module's methods?)
>> 
>> I like the idea in the abstract, but most of the rails assertions rely on 
>> some state that is local to the example (@response, @controller, @request, 
>> etc, etc). RSpec _could_ gather up all those instance variables and pass 
>> them into an assertion-wrapper object, but then it would be highly coupled 
>> to that implementation and would lead us down a familiar and unfriendly path 
>> of forcing rspec-rails releases for every rails release. That's a world I 
>> hope to leave behind with Rails 3 :)
> 
> So leave the rails assertions mixed into the example, but forward all the 
> calls to the MiniTest::Assertions methods to some other object that has them 
> mixed in. Won't that work?

Here's a prototype implementation: 
http://github.com/rspec/rspec-rails/commit/0cd384536cf532435ec8f290a9c357b60872acd7

It's on a branch (http://github.com/rspec/rspec-rails/tree/assertion-delegate) 
because I'm not convinced this is the right way to go yet, but I'd like some 
feedback from anyone who wishes to peruse and comment.

Thanks,
David

>> It would also eliminate the option to use the Rails assertions directly in 
>> examples.
>> 
>> Oh, well :)
>> 
>>> cheers,
>>> Matt
>>> 
>>> http://blog.mattwynne.net
>>> +44(0)7974 430184
>> 
>> ___
>> rspec-users mailing list
>> rspec-users@rubyforge.org
>> http://rubyforge.org/mailman/listinfo/rspec-users
> 
> cheers,
> Matt
> 
> http://blog.mattwynne.net
> +44(0)7974 430184
> 
> ___
> rspec-users mailing list
> rspec-users@rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users

___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users

Re: [rspec-users] Name collision - how would you handle this?

[David Chelimsky]

On Aug 8, 2010, at 10:40 AM, Matt Wynne wrote:
> On 8 Aug 2010, at 16:38, David Chelimsky wrote:
>> On Aug 7, 2010, at 4:10 PM, David Chelimsky wrote:
>> 
>>> Hey all,
>>> 
>>> It turns out that if you have
>>> 
>>> * Rails (2 or 3)
>>> * Ruby-1.9
>>> * a model named Message
>>> * let(:message) or def message in an example group
>>> * a Rails assertion in an example in that group
>>> * note that rspec-rails' matchers delegate to Rails' assertions
>>> 
>>> You'll get an error saying "wrong number of arguments (1 for 0)"
>>> 
>>> This is because the rails assertion, which, when running with Ruby-1.9, 
>>> delegates to Minitest::Assertions#assert_block, which delegates to a 
>>> message() method that it defines. So the message() method defined by let() 
>>> overrides the message() method in the Assertions module, and results in 
>>> unexpected and undesirable outcomes.
>>> 
>>> So - what should we do? I don't think changing Minitest is really an 
>>> option, as too many assertion libraries already wrap Minitest assertions. I 
>>> don't think RSpec should be in the business of monitoring methods end-users 
>>> define to make sure they're not overriding pre-existing methods (what if 
>>> you override a method intentionally?). The only thing I'm left with is 
>>> document this particular case and hope for the best, but that feels 
>>> unsatisfactory as well.
>>> 
>>> Recommendations? Words of wisdom?
>> 
>> FYI - here's the issue that spawned this thread: 
>> http://github.com/rspec/rspec-rails/issues/152
> 
> Can you use the Assertions module some other way than mixing it into the 
> example (thereby polluting it with the Assertions module's methods?)

I like the idea in the abstract, but most of the rails assertions rely on some 
state that is local to the example (@response, @controller, @request, etc, 
etc). RSpec _could_ gather up all those instance variables and pass them into 
an assertion-wrapper object, but then it would be highly coupled to that 
implementation and would lead us down a familiar and unfriendly path of forcing 
rspec-rails releases for every rails release. That's a world I hope to leave 
behind with Rails 3 :)

It would also eliminate the option to use the Rails assertions directly in 
examples.

Oh, well :)

> cheers,
> Matt
> 
> http://blog.mattwynne.net
> +44(0)7974 430184

___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users

Re: [rspec-users] Name collision - how would you handle this?

[David Chelimsky]

On Aug 8, 2010, at 8:05 AM, Ashley Moran wrote:

> On 8 Aug 2010, at 12:05, Matt Wynne wrote:
> 
>>> And you override it using let(:foo), which would be a perfectly reasonable 
>>> way to handle it. In fact, it would be the way I would handle in 
>>> instinctively, because now I don't have to wrote my own memoization 
>>> handling into the method.
>> 
>> I instinctively agree with ashley, but I see your point too David.
>> 
>> Would it be awful to make let even more magic, and do something with #caller 
>> to forward the message to MiniTest if it didn't come from the code in your 
>> example block? Maybe the method defined by let could even have a __hidden 
>> name, and then RSpec can forward the message to that __hidden method if the 
>> message was sent from within the example block.
>> 
>> Sounds pretty horrible, doesn't it?

Yes! It seems crazy to me to put this burden on RSpec, or any downstream 
library. The problem here stems from the fact that Minitest consumed a 
non-testing-domain-specific name here. Test::Unit uses build_message, which is 
still sort of generic, but at least it's a verb. I submitted a request to 
change message to build_message [1], but even if Ryan agrees to do it, we 
wouldn't likely see it in ruby-1.9.2, so we'd still have the conflict for some 
time.

Also, let's say he does agree - now people who like to prefix their 
test-data-building-helper-methods with build_xxx will be screwed too :)

I wonder if the right answer is for RSpec to implement its own base assertion 
library, matching the Test::Unit/Minitest assertion APIs. That would have an 
interesting side effect in that domain-specific assertion-libraries could be 
used in RSpec without having to depend on Test::Unit or Minitest. It would also 
allow folks who like RSpec's structure (example groups and examples) but prefer 
assert_xxx over RSpec's matcher to use RSpec the way they'd like without the 
additional dependency.

Thoughts on this? Really just an idea. I'm fairly convinced it's a bad one, but 
my head is sort of spinning over this issue right now (or maybe it's the 
cocktails at http://thedrchicago.com/), so I figured I'd throw it against the 
wall and see if it sticks (think spaghetti, or Jackson Pollock).

> Hmmm, sounds like it could create a pretty nasty coupling to MiniTest.  Maybe 
> there's a general solution like:
> 
>  define_example_method do # or maybe "define_helper" ?
># some stuff that only gets called from examples
>  end
> 
> I'm not sure I'd be keen on let embedding this magic, but maybe as a general 
> concept it makes more sense, as a way of isolating helper code in example 
> groups.

This suggests, to me, "don't use Ruby if you want things to work right."

> There's another side to the debate, which is that in shared example groups, I 
> prefer the precondition-check style to the templatemethod-fail style, ie 
> rather than:
> 
>  def foo
>raise "you need to define a foo method ..."
>  end
> 
> I'd prefer to write:
> 
>  unless respond_to?(:foo)
>raise "you need to define a foo method ..."
>  end
> 
> But that would involve evaluating the configuration block first >:)

Keep in mind that it_should_behave_like generates a nested group, so shared 
group authors _can_ do this:

shared_examples_for "bar" do
  unless respond_to?(:foo)
raise "gotta have foo"
  end
end

and host group authors can do this:

describe "thing" do
  let(:foo) { Foo.new }
  it_should_behave_like "bar"
end

That's part of the beauty of eval'ing the conditions block last - we get the 
best of both worlds.

Cheers,
David

[1] 
http://rubyforge.org/tracker/index.php?func=detail&aid=28457&group_id=1040&atid=4097

> 
> Ash
> 
> -- 
> http://www.patchspace.co.uk/
> http://www.linkedin.com/in/ashleymoran

___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users

Re: [rspec-users] Name collision - how would you handle this?

[David Chelimsky]

On Aug 7, 2010, at 4:10 PM, David Chelimsky wrote:

> Hey all,
> 
> It turns out that if you have
> 
> * Rails (2 or 3)
> * Ruby-1.9
> * a model named Message
> * let(:message) or def message in an example group
> * a Rails assertion in an example in that group
>  * note that rspec-rails' matchers delegate to Rails' assertions
> 
> You'll get an error saying "wrong number of arguments (1 for 0)"
> 
> This is because the rails assertion, which, when running with Ruby-1.9, 
> delegates to Minitest::Assertions#assert_block, which delegates to a 
> message() method that it defines. So the message() method defined by let() 
> overrides the message() method in the Assertions module, and results in 
> unexpected and undesirable outcomes.
> 
> So - what should we do? I don't think changing Minitest is really an option, 
> as too many assertion libraries already wrap Minitest assertions. I don't 
> think RSpec should be in the business of monitoring methods end-users define 
> to make sure they're not overriding pre-existing methods (what if you 
> override a method intentionally?). The only thing I'm left with is document 
> this particular case and hope for the best, but that feels unsatisfactory as 
> well.
> 
> Recommendations? Words of wisdom?

FYI - here's the issue that spawned this thread: 
http://github.com/rspec/rspec-rails/issues/152
___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users

Re: [rspec-users] RSpec 2 autotest file

[David Chelimsky]

On Aug 7, 2010, at 4:54 PM, Ashley Moran wrote:

> Hi
> 
> I've tried using the autotest file from RSpec 2 (lib/autotest/rspec2.rb) but 
> I've found a problem with it, that I think is a bug.
> 
> The file contains two sections
> 
> * an Autotest `Autotest.add_hook :initialize` block
> * an Autotest class "Autotest::Rspec2"
> 
> In one project I'm working on, the code in Autotest::Rspec2 is really useful 
> to me, but the :initialize hook contains setup that interferes with my 
> project structure (I don't want a "lib" folder.
> 
> Unfortunately, it appears that Autotest's `clear_mappings` can't stop the 
> :initialize mappings making it into the final setup.  This means that to use 
> Autotest::Rspec2, I've had to copy-paste the contents into my own autotest 
> file, rather than subclassing.
> 
> Is this a bug?

Yes.

>  (ie, is there no workaround for the coupling between the two blocks?)  If 
> so, can it be fixed?

Yes: 
http://github.com/rspec/rspec-core/commit/c2e8a3947321e501b84113c1b2b1049df4868f4b

> Alternatively (or as well), is it time to drop autotest and use watchr 
> instead?  I noticed RSpec 2 uses that, and it seems really fast and simple, 
> both of which go down very well with me...

I don't think we need to drop one to use the other :)

Cheers,
David

> Any thoughts?
> 
> Cheers
> Ash
> 
> -- 
> http://www.patchspace.co.uk/
> http://www.linkedin.com/in/ashleymoran
> 
> ___
> rspec-users mailing list
> rspec-users@rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users

___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users

Re: [rspec-users] Recognising RSpec files in the Textmate bundle

[David Chelimsky]

On Aug 7, 2010, at 5:28 PM, Ashley Moran wrote:

> Hi
> 
> Did the RSpec TMBundle ever have multiple ways of recognising RSpec files?  
> I'm convinced it user to look for "spec_helper" on the first line.

I'm pretty sure it never did that.

> The Ruby bundle does something similar, as it looks for "firstLineMatch = 
> '^#!/.*\bruby';"
> 
> The reason I ask is because I now have several files that end "_contract.rb". 
>  Conceivably I might have other shared example files with different suffices. 
>  But it's fairly safe to say they will all start with "require 'spec_helper'".

I can't think of a case in which I've required spec_helper from a file that 
defines shared groups. So in my case, that is not safe to say :)

> WDYT?

I think it's good to do things that help end users, but we'd need a more 
reliable convention to base this on. Anybody (including Ashley) got any other 
suggestions?

Cheers,
David

> Cheers
> Ash
> 
> -- 
> http://www.patchspace.co.uk/
> http://www.linkedin.com/in/ashleymoran
> 
> ___
> rspec-users mailing list
> rspec-users@rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users

___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users

Re: [rspec-users] Name collision - how would you handle this?

[David Chelimsky]

On Aug 7, 2010, at 4:37 PM, Ashley Moran wrote:

> On 7 Aug 2010, at 22:10, David Chelimsky wrote:
> 
>> So - what should we do? I don't think changing Minitest is really an option, 
>> as too many assertion libraries already wrap Minitest assertions. I don't 
>> think RSpec should be in the business of monitoring methods end-users define 
>> to make sure they're not overriding pre-existing methods (what if you 
>> override a method intentionally?). The only thing I'm left with is document 
>> this particular case and hope for the best, but that feels unsatisfactory as 
>> well.
> 
> While I fully agree if you `def` a method that already exists, you should be 
> expected to deal with it yourself (that's just the way things are in Ruby), 
> does the same apply to `let`?  I can actually see an argument that you should 
> only be able to `let` a method that doesn't already exist, and also only do 
> it once (which is just a consequence of not being able to override a method, 
> given the current implementation). 

> Can you think of any downsides of preventing RSpec users from overriding 
> existing methods with `let`?

Yes. Let's say I write a shared example group with this:

def foo
  raise "you need to define a foo method in the block passed to 
it_should_behave_like"
end

And you override it using let(:foo), which would be a perfectly reasonable way 
to handle it. In fact, it would be the way I would handle in instinctively, 
because now I don't have to wrote my own memoization handling into the method.

> Are there any popular names already taken?  Or other problems?
> 
> To me, `let` is magic.  I don't think of it, first and foremost, of defining 
> a method.

>From the RDoc: Generates a method whose return value is memoized after the 
>first call.

> I see the things it creates as more like local variables, and just remind 
> myself that they're methods if I wonder why it works.
> 
> I'm not sold either way on this, but I think it's one worth a debate.

The debate is on! Any other opinions out there?

> Ash

___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users

[rspec-users] Name collision - how would you handle this?

[David Chelimsky]

Hey all,

It turns out that if you have

* Rails (2 or 3)
* Ruby-1.9
* a model named Message
* let(:message) or def message in an example group
* a Rails assertion in an example in that group
  * note that rspec-rails' matchers delegate to Rails' assertions

You'll get an error saying "wrong number of arguments (1 for 0)"

This is because the rails assertion, which, when running with Ruby-1.9, 
delegates to Minitest::Assertions#assert_block, which delegates to a message() 
method that it defines. So the message() method defined by let() overrides the 
message() method in the Assertions module, and results in unexpected and 
undesirable outcomes.

So - what should we do? I don't think changing Minitest is really an option, as 
too many assertion libraries already wrap Minitest assertions. I don't think 
RSpec should be in the business of monitoring methods end-users define to make 
sure they're not overriding pre-existing methods (what if you override a method 
intentionally?). The only thing I'm left with is document this particular case 
and hope for the best, but that feels unsatisfactory as well.

Recommendations? Words of wisdom?

Cheers,
David




___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users

Re: [rspec-users] How do I extend ExampleGroup in Rspec 2?

[David Chelimsky]

On Aug 7, 2010, at 10:15 AM, David Chelimsky wrote:

> On Aug 7, 2010, at 10:04 AM, Kristian Mandrup wrote:
> 
>> Thanks, but it didn't work. The following somewhat ugly hack works
>> however.
>> 
>> module RSpec::Core
>> class ExampleGroup
>>   def with_generator &block
>> RSpec::Generator.with_generator &block
>>   end
>> 
>>   def setup_generator test_method_name=nil, &block
>> RSpec::Generator.setup_generator test_method_name, &block
>>   end
>> end
>> end
> 
> Please submit an issue for this - it should work as I suggested: 
> http://github.com/rspec/rspec-core/issues

FYI - this passes for me:

module Foo
  def bar
yield
  end
end

RSpec.configure do |c|
  c.include Foo
end

describe :a do
  it "foo" do
    yielded = false
bar do
  yielded = true
end
yielded.should be_true
  end
end



> 
>> 
>> 
>> On Aug 7, 4:09 pm, David Chelimsky  wrote:
>>> On Aug 7, 2010, at 8:23 AM, Kristian Mandrup wrote:
>>> 
>>> 
>>> 
>>>> I simply want all methods of a module to be always available within
>>>> the context of an Example group.
>>> 
>>>> module RSpec
>>>> module Generator
>>>> def with_generator &block
>>>>  ...
>>>> end
>>> 
>>>> def setup_generator test_method_name=nil, &block
>>>>   ...
>>>> end
>>>> end
>>>> end
>>> 
>>>> How do I achieve this?
>>> 
>>>> In RSpec 1 I think you would use ExampleGroupFactory
>>> 
>>>> I thought I could do it something like this with RSpec 2?
>>> 
>>>> RSpec.configure do |c|
>>>> c.extend RSpec::Generator
>>>> end
>>> 
>>>> I want to be able to do something like this
>>> 
>>>> before :each do
>>> 
>>> before hooks are eval'd in the scope of an example, which is an _instance_ 
>>> of the example group class. Try using include instead of extend:
>>> 
>>> c.include RSpec::Generator
>>> 
>>> HTH,
>>> David
>>> 
>>> 
>>> 
>>>>   setup_generator 'migration_generator' do
>>>> tests MigrationGenerator
>>>>   end
>>>> end
>>> 
>>>> it "should generate create_user migration" do
>>>>   with_generator do |g|
>>>> ...
>>>> end
>>> 
>>>> Whereas now I have to do it like this, which I find a bit ugly and
>>>> cumbersome
>>> 
>>>> it "should generate create_user migration" do
>>>>   RSpec::Generator.with_generator do |g|
>>>> name = 'create_users'
>>>>   end
>>>> end
>>> 
>>>> Thanks.
>>>> ___
>>>> rspec-users mailing list
>>>> rspec-us...@rubyforge.org
>>>> http://rubyforge.org/mailman/listinfo/rspec-users
>>> 
>>> ___
>>> rspec-users mailing list
>>> rspec-us...@rubyforge.orghttp://rubyforge.org/mailman/listinfo/rspec-users
>> ___
>> rspec-users mailing list
>> rspec-users@rubyforge.org
>> http://rubyforge.org/mailman/listinfo/rspec-users
> 

___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users

Re: [rspec-users] How do I extend ExampleGroup in Rspec 2?

[David Chelimsky]

On Aug 7, 2010, at 10:04 AM, Kristian Mandrup wrote:

> Thanks, but it didn't work. The following somewhat ugly hack works
> however.
> 
> module RSpec::Core
>  class ExampleGroup
>def with_generator &block
>  RSpec::Generator.with_generator &block
>end
> 
>def setup_generator test_method_name=nil, &block
>  RSpec::Generator.setup_generator test_method_name, &block
>end
>  end
> end

Please submit an issue for this - it should work as I suggested: 
http://github.com/rspec/rspec-core/issues

> 
> 
> On Aug 7, 4:09 pm, David Chelimsky  wrote:
>> On Aug 7, 2010, at 8:23 AM, Kristian Mandrup wrote:
>> 
>> 
>> 
>>> I simply want all methods of a module to be always available within
>>> the context of an Example group.
>> 
>>> module RSpec
>>>  module Generator
>>>  def with_generator &block
>>>   ...
>>>  end
>> 
>>>  def setup_generator test_method_name=nil, &block
>>>...
>>>  end
>>>  end
>>> end
>> 
>>> How do I achieve this?
>> 
>>> In RSpec 1 I think you would use ExampleGroupFactory
>> 
>>> I thought I could do it something like this with RSpec 2?
>> 
>>> RSpec.configure do |c|
>>> c.extend RSpec::Generator
>>> end
>> 
>>> I want to be able to do something like this
>> 
>>>  before :each do
>> 
>> before hooks are eval'd in the scope of an example, which is an _instance_ 
>> of the example group class. Try using include instead of extend:
>> 
>> c.include RSpec::Generator
>> 
>> HTH,
>> David
>> 
>> 
>> 
>>>setup_generator 'migration_generator' do
>>>  tests MigrationGenerator
>>>end
>>>  end
>> 
>>>  it "should generate create_user migration" do
>>>with_generator do |g|
>>>  ...
>>>  end
>> 
>>> Whereas now I have to do it like this, which I find a bit ugly and
>>> cumbersome
>> 
>>>  it "should generate create_user migration" do
>>>RSpec::Generator.with_generator do |g|
>>>  name = 'create_users'
>>>end
>>>  end
>> 
>>> Thanks.
>>> ___
>>> rspec-users mailing list
>>> rspec-us...@rubyforge.org
>>> http://rubyforge.org/mailman/listinfo/rspec-users
>> 
>> ___
>> rspec-users mailing list
>> rspec-us...@rubyforge.orghttp://rubyforge.org/mailman/listinfo/rspec-users
> ___
> rspec-users mailing list
> rspec-users@rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users

___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users

Re: [rspec-users] How do I extend ExampleGroup in Rspec 2?

[David Chelimsky]

On Aug 7, 2010, at 8:23 AM, Kristian Mandrup wrote:

> I simply want all methods of a module to be always available within
> the context of an Example group.
> 
> module RSpec
>  module Generator
>  def with_generator &block
>   ...
>  end
> 
>  def setup_generator test_method_name=nil, &block
>...
>  end
>  end
> end
> 
> How do I achieve this?
> 
> In RSpec 1 I think you would use ExampleGroupFactory
> 
> I thought I could do it something like this with RSpec 2?
> 
> RSpec.configure do |c|
> c.extend RSpec::Generator
> end
> 
> I want to be able to do something like this
> 
>  before :each do

before hooks are eval'd in the scope of an example, which is an _instance_ of 
the example group class. Try using include instead of extend:

c.include RSpec::Generator

HTH,
David


>setup_generator 'migration_generator' do
>  tests MigrationGenerator
>end
>  end
> 
>  it "should generate create_user migration" do
>with_generator do |g|
>  ...
>  end
> 
> Whereas now I have to do it like this, which I find a bit ugly and
> cumbersome
> 
>  it "should generate create_user migration" do
>RSpec::Generator.with_generator do |g|
>  name = 'create_users'
>end
>  end
> 
> Thanks.
> ___
> rspec-users mailing list
> rspec-users@rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users

___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users

Re: [rspec-users] Could not find generator rspec:install.

[David Chelimsky]

On Aug 6, 2010, at 12:39 PM, SWEngineer wrote:

> I'm trying to follow this tutorial here: 
> http://railstutorial.org/chapters/static-pages#top
> 
> When I run:
> 
> $ rails generate rspec:install
> 
> I get:
> 
> Could not find generator rspec:install.
> 
> What could be the problem?

The tutorial shows the rspec-rails gem configured in both the :development and 
:test groups. Do you have it set up that way?

> 
> Thanks.
> ___
> rspec-users mailing list
> rspec-users@rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users

___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users

Re: [rspec-users] Cucumber Development

[David Chelimsky]

On Aug 6, 2010, at 12:28 PM, Subhash Mishra wrote:

> David Chelimsky wrote:
>> On Aug 6, 2010, at 12:06 PM, Subhash Mishra wrote:
>> 
>>> Hi All,
>>> I'm using cucumber for some time. it's quite good and i want to do some
>>> further development, so that user can even parse the arguments. I'm
>>> looking for developers guide of cucumber or even if some one knows the
>>> close by file to change for this requirement would be very helpful.
>>> any response about cucumber coding structure would be helpful.
>> 
>> Cucumber has its own mailing list/user group: 
>> http://groups.google.com/group/cukes.
>> 
>> I'd recommend asking there, though you'll probably want to be a bit more 
>> specific about your question.
>> 
>> Cheers,
>> David
> 
> Thanx,
> Well as far as concern of my problem is only this much that i want to 
> parse argument of cucumber sentence before calling sentence definition
> e.g. suppose i have a cucumber sentence
>  When I press ""
> and there corresponding definition
>  When /^I press "([^\"]*)"$/ do |arg1|
> ruby code
>  end
> where ever above cucumber sentence will be encountered, the actual ruby 
> code is going to be called and  is going to be passed in 
> 'arg1'. i want to do some operation on this  before being 
> supplied to arg1.
> :-)

Please post this to the Cucumber user group: 
http://groups.google.com/group/cukes.
___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users

Re: [rspec-users] Cucumber Development

[David Chelimsky]

On Aug 6, 2010, at 12:06 PM, Subhash Mishra wrote:

> Hi All,
> I'm using cucumber for some time. it's quite good and i want to do some
> further development, so that user can even parse the arguments. I'm
> looking for developers guide of cucumber or even if some one knows the
> close by file to change for this requirement would be very helpful.
> any response about cucumber coding structure would be helpful.

Cucumber has its own mailing list/user group: 
http://groups.google.com/group/cukes.

I'd recommend asking there, though you'll probably want to be a bit more 
specific about your question.

Cheers,
David
___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users

Re: [rspec-users] Evaluating shared example customisation block before shared block

[David Chelimsky]

On Aug 6, 2010, at 3:18 AM, Ashley Moran wrote:

> 
> On Aug 05, 2010, at 4:28 am, David Chelimsky wrote:
> 
>> At this point, the customization block is still being eval'd after the 
>> shared block, and I'm fairly well convinced this is the right thing, in 
>> combination with params to the block.
> 
> I don't think it makes any different any more, at least not to me.  The only 
> thing you can't do is use class methods in shared example descriptions, but 
> you don't need to do that any more now anyway.
> 
>> Next release will FINALLY have parameterized shared groups. Sweet!
> 
> Brilliant :-)  What's the current release plan?

Barring the unforeseen, I'll knock out beta.20 this weekend.

David

> 
> Cheers
> Ash

___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users

Re: [rspec-users] Evaluating shared example customisation block before shared block

[David Chelimsky]

On Aug 4, 2010, at 1:35 PM, Myron Marston wrote:

>> I wouldn't even bother to undef those methods.
> 
> If we don't undef the methods, then the semantics of the
> #module_eval_with_args (or whatever we call it) will be different on
> 1.8.6 and other versions.  On 1.8.6, a method definition in the block
> would define both an instance method _and_ a class method.  Someone
> could write a spec against 1.8.6, and accidentally call the class
> method, not realizing they've done this, and the spec wouldn't work on
> 1.8.7 and above since the class method won't be there.  So I think the
> undefs are important, and I don't think it adds too much complexity.
> 
>> Something like:
>> 
>> def module_eval_with_args(*args, &block)
>>   if respond_to?(:module_exec)
>> module_exec(*args, &block)
>>   else
>> # custom solution
>>   end
>> end
>> 
>> At that point, as long as all the shared group specs are passing, we're 
>> good. Make sense?
> 
> Makes total sense.  I'll work on porting this to RSpec, and open an
> github issue with a link to the commits when I'm done.

FYI - to those paying attention - I merged Myron's changes with support for 
parameterized shared groups even in 1.8.6.

At this point, the customization block is still being eval'd after the shared 
block, and I'm fairly well convinced this is the right thing, in combination 
with params to the block.

Next release will FINALLY have parameterized shared groups. Sweet!

Cheers,
David
___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users

Re: [rspec-users] [newbie] tradeoffs of direct model access vs. simulated browser (webrat)

[David Chelimsky]

On Aug 4, 2010, at 2:48 PM, Lille wrote:

> I appreciate your comments...
> 
> @Matt - sounds like you're reminding me I can have a unified
> presentation to the customer if I express all my specs in cucumber,
> whether any individual scenario takes the simulated browser approach
> or not.
> 
> I'm basing my freshman efforts here on 'The RSpec Book', whose beta
> version suggests that one might BDD their views/models/controllers
> each in isolation if they hadn't already decided on taking a simulated
> browser approach with webrat (+ selenium.)

There is a brief discussion in the views chapter that says that the jury is out 
on the value of view specs in some contexts and tries to put some guidelines 
into place about how to approach a decision about doing them or not. But that 
is only for view specs and it is context specific. It does not apply to 
controller and model specs, and is not intended to suggest that cukes vs specs 
is an either/or proposition.

There is a picture on the 3rd page of the Rails section of the book that very 
clearly conveys the process: start with cukes and use them to drive down to 
view, controller and model specs.

> I guess I don't think this
> choice -- as I interpret it from "The RSpec Book' -- is arbitrary: in
> my case, upon consideration, simulating the browser in every scenario
> doesn't seem the best approach.

The DMA vs Simulated Browser decision is discussed in several places in the 
first few chapters of the Rails section as well. There is a section in the 
Cucumber with Rails chapter that states: "For features that produce many edge 
cases, it can be useful to drive a few through the Rails stack and the rest 
using just Direct Model Access for everything."

Seems like your conclusion is perfectly aligned with the book's recommendations.

Cheers,
David

> Thanks,
> 
> Lille
> 
> On Aug 4, 3:06 pm, Tim Walker  wrote:
>> We constantly explore and define this delicate balance. It's not easy
>> and there are no absolutes!
>> 
>> One thing that drives us is to approach the "automated testing stack"
>> as a pyramid (not sure where this originates but we used a slide of it
>> when we used to teach executable requirements with fitnesse). The
>> base, widest slice, of the pyramid is your unit tests which you should
>> have the most of. Moving up to controller tests and cucumber tests
>> (not through the user interface). What's left is the smallest piece,
>> the UI tests, which should focus on the UI, probably. Probably because
>> we're constantly breaking the rules. On complex pages with a lot of
>> javascript and xhr callbacks it's important to test the entire stack
>> from the UI through to the data persistence.
>> 
>> Tim
>> 
>> 
>> 
>> On Wed, Aug 4, 2010 at 11:44 AM, Lille  wrote:
>>> Hi,
>> 
>>> My app involves the elicitation of tabular data over a succession of
>>> controller/model/view groups. The net result is a numeric outcome
>>> based on the entered data (basically, it's a spreadsheet on Rails.)
>> 
>>> Here is the nub of my question about developing such a thing with
>>> RSpec:
>> 
>>> + if I test with a simulated browser approach, my scenarios will need
>>> span multiple controller/model/view triads to confirm the expected
>>> result in as many cases as I feel I need to cover. Basically, an
>>> entire app use-cycle is contained in every scenario -- this doesn't
>>> remind me of anything I've seen in "The RSpec Book", for example.
>> 
>>> + I think I prefer rspec'ing the models directly -- it's concise and I
>>> don't duplicate simulated browser actions for no particular reason.
>>> What's the point of confirming that different data in the same set of
>>> fields is submitted successfully, like 20 times? I'll only simulate
>>> the browser to build the view/controllers and test their behavior when
>>> inputs are inadequate or require differential responses.
>> 
>>> My preferred strategy is sort of like saying to the client: 1) here
>>> are all the numeric outcomes we need to confirm, and 2) here in a
>>> smaller, overlapping set are the behavioral outcomes we need to
>>> confirm
>> 
>>> In short, it seems to me the simulated browser approach (webrat) is
>>> overkill when one is dealing with exhaustive cases and there is no
>>> differential response in the controller or view parts based on them.
>> 
>>> Lille
>>> ___
>>> rspec-users mailing list
>>> rspec-us...@rubyforge.org
>>> http://rubyforge.org/mailman/listinfo/rspec-users
>> 
>> ___
>> rspec-users mailing list
>> rspec-us...@rubyforge.orghttp://rubyforge.org/mailman/listinfo/rspec-users
> ___
> rspec-users mailing list
> rspec-users@rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users

___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users

Re: [rspec-users] Evaluating shared example customisation block before shared block

[David Chelimsky]

On Aug 4, 2010, at 1:55 AM, Myron Marston wrote:

> Ashley: thanks for posting the example.  It's nice to see how this all
> fits together.
> 
> Re: RSpec 2 for ruby 1.8.6: I don't see RSpec 2 as being all that
> useful for Rails 2.x projects on ruby 1.8.6.  However, it's still very
> important for gems.  I just converted one of my projects (VCR[1]) to
> RSpec 2, and VCR supports ruby 1.8.6, 1.8.7 and 1.9.1.  If we remove
> ruby 1.8.6 support from RSpec 2, I'd have to migrate back to RSpec 1.x
> so that I can continue to run the spec suite on 1.8.6.  I imagine
> there will be plenty of other libraries that will want to upgrade to
> using RSpec 2 after the final release, while still supporting 1.8.6.
> 
> Good news: I messed around with module_exec some more, and I think I
> have a working implementation for 1.8.6[2].  This was complicated
> enough that I wanted to work on it in isolation from RSpec; hence the
> separate github project.  We'll probably want to re-organize it a bit
> before merging it in, if it's deemed "good enough" to work for our
> needs.  It has some specs that pass for module_exec on 1.8.7, and they
> pass on 1.8.6 with my implementation, too.  There may be cases where
> it still doesn't work quite right, though--feel free to fork, add
> specs, etc.

Hey Myron - I think what you have is perfectly fine. The only issue I ran into 
was that of defining instance methods, and your solution seems sound. I 
wouldn't even bother to undef those methods. We're not putting module_exec in 
as an API. In fact, in rspec, I think we should change the names of module_exec 
and instance_exec to something rspec-specific so that users don't rely on our 
implementation for other purposes. Something like:

def module_eval_with_args(*args, &block)
  if respond_to?(:module_exec)
module_exec(*args, &block)
  else
# custom solution
  end
end

At that point, as long as all the shared group specs are passing, we're good. 
Make sense?


> 
> Myron
> 
> [1] http://github.com/myronmarston/vcr
> [2] http://github.com/myronmarston/module_exec
> ___
> rspec-users mailing list
> rspec-users@rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users

___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users

Re: [rspec-users] Evaluating shared example customisation block before shared block

[David Chelimsky]

On Aug 4, 2010, at 3:43 AM, Ashley Moran wrote:

> 
> On 4 Aug 2010, at 1:05 AM, David Chelimsky wrote:
> 
>> 
> 
> 
> One other thought I've had is keyword syntax.  While currently I'm writing:
> 
>  it_satisfies_contract "[Entity] Collection:", :children, :child, Child.name
> 
> I prefer keyword arguments, so I'd like to write:
> 
>  it_satisfies_contract "[Entity] Collection:",
>:children,
>item_name: "child",
>class_name: Child.name
> 
> Currently that would mean rewriting the contract like this:
> 
>  contract "[Entity] Collection:" do  |collection_name, options|
> 
># ...
> 
>describe "#{collection_name}" do
>  describe "Helper methods:" do
>describe "#new_#{options[:item_name]}, #get_#{options[:item_name]}" do
> 
># ...
> 
> WDYT about RSpec automatically translating keyword options to methods?

What happens if the shared spec author really wants it to just be a hash? Do 
you think that's a valid use case?

> They'd need to be defined as singleton class methods and instance methods to 
> have the same availability as block parameters.
> 
> Ash
> 
> -- 
> http://www.patchspace.co.uk/
> http://www.linkedin.com/in/ashleymoran
> 
> 
> 
> ___
> rspec-users mailing list
> rspec-users@rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users

___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users

Re: [rspec-users] RSpec 2 add-on for testing and specifying generators - initial release

[David Chelimsky]

On Aug 3, 2010, at 3:06 PM, Kristian Mandrup wrote:

> http://github.com/kristianmandrup/rspec_for_generators
> 
> When creating Rails generators I noticed that the only option I could
> find for testing was to use a special Rails TestCase class created
> specifically for use with Test Unit.
> So I thought I could wrap it to be used with RSpec 2 instead. I now
> have a working first release with room for lots of improvements!  But
> at least it seems to work fine for now, as demonstrated by a small
> RSpec 2 test suite that comes with it.
> 
> Note: This library is NOT in any way an official RSpec 2 release of
> any sort. I only use the RSpec name to indicate that it is an add-on
> component for RSpec 2. That it can be used with RSpec 2.
> Not sure what other convention there would be to indicate this?
> 
> Maybe I should rename it to something like the following to make it
> more clear?
> 
> rspec2-addon-for-generators

Ben Mabey called his email-spec. So maybe generator-spec?

> 
> Hope you find it useful as a starting point. Free feel to patch it,
> refactor etc.
> Enjoy!
> 
> Kristian
> ___
> rspec-users mailing list
> rspec-users@rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users

___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users

Re: [rspec-users] [RSpec] Testing a helper with or without model layer?

[David Chelimsky]

On Aug 3, 2010, at 9:23 AM, Bruno Cardoso wrote:

> Hi David
> 
>> Even though the code is in a helper, it depends heavily on the model. 
>> This exhibits a code smell called Feature Envy, in which one object (the 
>> helper) does some computation but another object (the CfgInterface 
>> model) has all the data. Based on that, one might argue this method 
>> belongs on the model anyhow, in which case the argument of stubbing out 
>> the model layer makes little sense.
> 
> I see your point and in this case you are probably right but what if my 
> helper was more heavy on the processing and still very data dependent ? 
> Should I use fixtures on the helper or should I stub/mock whatever I 
> need to avoid the model layer within the helper ?

It really depends on how deep the helper is reaching into the model. Ideally, 
when you're stubbing a layer, you want to be able to stub one thing. In this 
example, there are many things that need to be stubbed. A common example is a 
display formatter for a person's name:

it "concats the first and last name" do
  person = double('person', :first_name => "Joe", :last_name => "Smith")
  helper.full_name_for(person).should == "Joe Smith"
end

Here we're just stubbing a couple of values on one object - simple. In this 
case it makes sense to just stub the model.

> 
>> There are also several expectations that overlap. It doesn't matter that 
>> the class is a Hash - what matters is that it behaves like a hash, which 
>> is demonstrated in other expectations. The fact that the keys exist is 
>> also demonstrated in the expectations that access those keys.
> 
> Good point, thanks.
> 
>> Based on those comments, I'd probably do something like 
>> http://gist.github.com/506366. Then I'd figure out how to swap in 
>> factories for the fixtures - right now there's no way to understand what 
>> 'CONS_ALL_ACCOUNT' means without looking elsewhere.
> 
> 'CONS_ALL_ACCOUNT' actually has no impact when using stub/mocks, 
> 'CONS_ALL_ACCOUNT' was the input parameter the model was using to fetch 
> data from the BD, in the second form of the test with stubs/mocks, this 
> input parameter has no meaning since I'm controlling all return 
> parameters.

___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users

Re: [rspec-users] Evaluating shared example customisation block before shared block

[David Chelimsky]

On Aug 3, 2010, at 4:35 PM, Ashley Moran wrote:

> 
> On 3 Aug 2010, at 12:50 PM, David Chelimsky wrote:
> 
>> Pushed:
>> 
>> http://github.com/rspec/rspec-core/commit/84303616be1ac2f8126675488947b47f6945cebe
>> http://github.com/rspec/rspec-core/commit/3cea7b8bea51766d632e20bcc9ef15c64b719ea1
> 
> Awesomeness!
> 
> 
>> Please do let me know if this works with what you've got.
> 
> In general, yes, this is a massive improvement!  I've realised some things 
> that never occurred to me before, though.  Maybe you have some thoughts...
> 
> I've put everything on a Gist[1] (which needs a few tweaks here and there, 
> but I think it's a reasonably example).  Notes:
> 
> * DomainLib is my holding module for everything I've extracted out of the 
> project source.  Anything inside that is generic, analogous to eg 
> ActiveRecord (eg Entity <-> AR::Base)
> 
> * I've only pasted the specs, and only the contract-based ones at that (the 
> implementation is not very interesting, nor is the interaction spec).
> 
> * I don't like the word contract any more, at least not here.  It needs a 
> better name, probably something that would fit if you wrote a similar spec 
> for ActiveRecord's has_many.

I actually like contract a lot. Maybe we'll need alias_shared_examples_for_to :)

> Some things I ran into:
> 
> First, I found that you can't use the block variables in local helper 
> methods.  Because Ruby methods aren't closures, I've had to replace methods 
> like:
> 
>  def entity_dot_new_collection_member(*args)
>entity.send(:"new_#{item_name}", *args)
>  end
> 
> with:
> 
>  define_method :entity_dot_new_collection_member do |*args|
>entity.send(:"new_#{item_name}", *args)
>  end
> 
> Not a big deal, but it's not as readable as it was before.  (Not that it was 
> exactly large-print Winnie the Pooh to start with, given the abstract nature 
> of the shared examples.)

This is just Ruby. It bugged me for a while too, but mostly because I kept 
forgetting. Now I'm completely accustomed to it and def and define_method seem 
quite the same to me.

> Second, you can't refer to `described_class` in the descriptions.  I don't 
> know why I though you'd be able to, but it would be nice if it worked :)  
> (You can see the place where my failed attempt was, where I left 
> .)

This was a mis-alignment between names in the group and its examples 
(example_group.describes == example.described_class), but is now fixed (you can 
refer to described_class in both cases): 
http://github.com/rspec/rspec-core/commit/b236a8d8927da108097fed7982d1450e4701939d

> Finally, I realised something when I added another example.  I should say 
> though, that all this time, I was only using the shared examples with one 
> collection on the entity, and I added another a few minutes ago just for fun, 
> and it just worked... I like :)  But it raised a point about things that are 
> common to all shared examples, and parameters to individual uses.  In my 
> example case, `entity_class` and `entity` are relevant to both of the 
> "collection" shared example groups, but `collection_name`, `item_name`, 
> `class_name` are parameters to the shared examples individually.  
> 
> With the current setup, there's no way to require that a host group provides 
> eg `entity_class`.

shared_examples_for "foo" do
  raise "gotta define entity_class" unless 
public_instance_methods.map{|m|m.to_s).include?("entity_class")
end

> And also, if it's defined as a `let` in the host, you can't use it in the 
> descriptions in the shared example group (which you couldn't before, of 
> course).

Right - the only thing available to descriptions is going to be the params you 
pass in.

> So I think this solves 90% of the problems I had before, and is certainly a 
> workable solution to the specs I'm trying to write.  I'd love to hear your 
> thoughts on the rest though.
> 
> 
>> The issue of the evaluation order is still up for grabs, but this now 
>> supports params to shared groups in Ruby >= 1.8.7.
> 
> Well, I deliberately didn't check what order you ended up using!  Whatever it 
> is works for me now, although I guess future experiments could change that...

Thanks for all the feedback!

Cheers,
David

> 
> 
> Cheers!
> Ash
> 
> 
> [1] http://gist.github.com/507140
> 
> 
> -- 
> http://www.patchspace.co.uk/
> http://www.linkedin.com/in/ashleymoran
> 
> 
> 
> ___
> rspec-users mailing list
> rspec-users@rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users

___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users

Re: [rspec-users] [RSpec] Testing a helper with or without model layer?

[David Chelimsky]

On Aug 3, 2010, at 6:34 AM, Bruno Cardoso wrote:

> Hi guys,
> 
> I wanted to get a more experienced opinion about a test I had to do.
> 
> I posted the code at pastie with comments for best visual readability:
> 
> http://pastie.org/private/qvvrxubslvia2nv6l3km4q

Even though the code is in a helper, it depends heavily on the model. This 
exhibits a code smell called Feature Envy, in which one object (the helper) 
does some computation but another object (the CfgInterface model) has all the 
data. Based on that, one might argue this method belongs on the model anyhow, 
in which case the argument of stubbing out the model layer makes little sense.

There are also several expectations that overlap. It doesn't matter that the 
class is a Hash - what matters is that it behaves like a hash, which is 
demonstrated in other expectations. The fact that the keys exist is also 
demonstrated in the expectations that access those keys.

Based on those comments, I'd probably do something like 
http://gist.github.com/506366. Then I'd figure out how to swap in factories for 
the fixtures - right now there's no way to understand what 'CONS_ALL_ACCOUNT' 
means without looking elsewhere.

HTH,
David


> Any feedback is appreciated
> 
> Thanks
> -- 
> Posted via http://www.ruby-forum.com/.
> ___
> rspec-users mailing list
> rspec-users@rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users

___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users

Re: [rspec-users] Evaluating shared example customisation block before shared block

[David Chelimsky]

On Aug 3, 2010, at 6:43 AM, Ashley Moran wrote:

> 
> On Aug 03, 2010, at 12:22 pm, David Chelimsky wrote:
> 
>> My inclination is to get this feature out with explicit non-support for 
>> 1.8.6, and then add support for 1.8.6 if we can get this to work. Working on 
>> that now - should be pushing some code (including Myron's contribution) 
>> later today.
> 
> Do you have everything in place to finish this off?  Happy to help out if you 
> want me to do any more coding on this, but it sounds like you've figured out 
> a solution.  In which case I'll sit back and see how the changes fit with the 
> shared examples I've got so far...

Pushed:

http://github.com/rspec/rspec-core/commit/84303616be1ac2f8126675488947b47f6945cebe
http://github.com/rspec/rspec-core/commit/3cea7b8bea51766d632e20bcc9ef15c64b719ea1

Please do let me know if this works with what you've got.

The issue of the evaluation order is still up for grabs, but this now supports 
params to shared groups in Ruby >= 1.8.7.

> 
> Cheers
> Ash 
> 
> -- 
> http://www.patchspace.co.uk/
> http://www.linkedin.com/in/ashleymoran
> 
> ___
> rspec-users mailing list
> rspec-users@rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users

___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users

Re: [rspec-users] Evaluating shared example customisation block before shared block

[David Chelimsky]

On Aug 2, 2010, at 7:52 AM, David Chelimsky wrote:

> On Aug 1, 2010, at 10:08 PM, Myron Marston wrote:
> 
>> OK, I tried to implement #module_exec on ruby 1.8.6, and here's what I
>> came up with:
>> 
>> http://github.com/myronmarston/rspec-core/commit/364f20ebd5b7d9612227cb6e86a6e8c8c2e9931e
>> 
>> It works (at least in the sense that it allows the specs and features
>> I added in the previous commits in that branch to pass on ruby 1.8.6),
>> but I don't think it's correct.  
> 
> If we're not exposing this as an API, and we're only using it in order to 
> support this feature in RSpec when running Ruby 1.8.6, and it solves our 
> problem, then I think it's correct as it needs to be.

These are all true except for the "and it solves our problem" part. It almost 
does, but the one missing piece is that methods defined in the shared group are 
not available to its examples:

shared_examples_for "thing" do
  def thing; Thing.new; do
  it "does something" do
thing.should do_something
  end
end

My inclination is to get this feature out with explicit non-support for 1.8.6, 
and then add support for 1.8.6 if we can get this to work. Working on that now 
- should be pushing some code (including Myron's contribution) later today.

Cheers,
David

> 
>> It just calls #instance_exec, but
>> instance_exec and module_exec are not the same (at least as I
>> understand them...).  However, I based that implementation on rubinius
>> 1.0.1's:
>> 
>> http://github.com/evanphx/rubinius/blob/release-1.0.1/kernel/common/module.rb#L438-441
>> 
>> Backports (a library that implements features of later versions of
>> ruby in 1.8.6) implements it in a similar fashion:
>> 
>> http://github.com/marcandre/backports/blob/v1.18.1/lib/backports/1.8.7/module.rb
>> 
>> Unfortunately, rubyspec doesn't provide much help in defining how
>> module_exec should work:
>> 
>> http://github.com/rubyspec/rubyspec/blob/master/core/module/module_exec_spec.rb
>> 
>> I'd need some concrete examples demonstrating how module_exec should
>> work (as compared to instance_exec) to implement it correctly.  My
>> understanding is that they are identical except in regards to method
>> definitions--def's within an instance_exec define methods directly on
>> the Module object instance, whereas def's within a module_exec define
>> instance methods in the module (i.e. methods that will be added to any
>> class that includes the module).
>> 
>> One side issue I discovered is that instance_exec is implemented in
>> rspec-expectations, but not rspec-core (which, incidentally, is why I
>> linked to the cucumber implementation; I grepped in rspec-core and
>> couldn't find it).  instance_exec is already used in rspec-core:
>> 
>> http://github.com/rspec/rspec-core/blob/v2.0.0.beta.19/lib/rspec/core/example_group.rb#L179
>> 
>> It needs to be implemented in rspec-core if you want rspec-core to be
>> able to be used on 1.8.6 without rspec-expectations.
> 
> Done: 
> http://github.com/rspec/rspec-core/commit/7d492bdc3657ca9472368b50f3f3f6635aca7fe0
> 
>> 
>> Myron
> 

___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users

Re: [rspec-users] migration question

[David Chelimsky]

On Aug 2, 2010, at 7:46 AM, rogerdpack wrote:

> Got this:
> 
> no such file to load -- spec/rake/spectask
> 
> anybody know off hand what the equivalent is for rspec2?

rspec/core/rake_task

I'll add that to Upgrade.markdown

> -r
> ___
> rspec-users mailing list
> rspec-users@rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users

___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users

Re: [rspec-users] migration question

[David Chelimsky]

On Aug 2, 2010, at 8:09 AM, David Chelimsky wrote:

> 
> On Aug 2, 2010, at 7:46 AM, rogerdpack wrote:
> 
>> Got this:
>> 
>> no such file to load -- spec/rake/spectask
>> 
>> anybody know off hand what the equivalent is for rspec2?
> 
> rspec/core/rake_task
> 
> I'll add that to Upgrade.markdown

http://github.com/rspec/rspec-core/blob/master/Upgrade.markdown

> 
>> -r
>> ___
>> rspec-users mailing list
>> rspec-users@rubyforge.org
>> http://rubyforge.org/mailman/listinfo/rspec-users
> 

___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users

Re: [rspec-users] Evaluating shared example customisation block before shared block

[David Chelimsky]

On Aug 1, 2010, at 10:08 PM, Myron Marston wrote:

> OK, I tried to implement #module_exec on ruby 1.8.6, and here's what I
> came up with:
> 
> http://github.com/myronmarston/rspec-core/commit/364f20ebd5b7d9612227cb6e86a6e8c8c2e9931e
> 
> It works (at least in the sense that it allows the specs and features
> I added in the previous commits in that branch to pass on ruby 1.8.6),
> but I don't think it's correct.  

If we're not exposing this as an API, and we're only using it in order to 
support this feature in RSpec when running Ruby 1.8.6, and it solves our 
problem, then I think it's correct as it needs to be.

> It just calls #instance_exec, but
> instance_exec and module_exec are not the same (at least as I
> understand them...).  However, I based that implementation on rubinius
> 1.0.1's:
> 
> http://github.com/evanphx/rubinius/blob/release-1.0.1/kernel/common/module.rb#L438-441
> 
> Backports (a library that implements features of later versions of
> ruby in 1.8.6) implements it in a similar fashion:
> 
> http://github.com/marcandre/backports/blob/v1.18.1/lib/backports/1.8.7/module.rb
> 
> Unfortunately, rubyspec doesn't provide much help in defining how
> module_exec should work:
> 
> http://github.com/rubyspec/rubyspec/blob/master/core/module/module_exec_spec.rb
> 
> I'd need some concrete examples demonstrating how module_exec should
> work (as compared to instance_exec) to implement it correctly.  My
> understanding is that they are identical except in regards to method
> definitions--def's within an instance_exec define methods directly on
> the Module object instance, whereas def's within a module_exec define
> instance methods in the module (i.e. methods that will be added to any
> class that includes the module).
> 
> One side issue I discovered is that instance_exec is implemented in
> rspec-expectations, but not rspec-core (which, incidentally, is why I
> linked to the cucumber implementation; I grepped in rspec-core and
> couldn't find it).  instance_exec is already used in rspec-core:
> 
> http://github.com/rspec/rspec-core/blob/v2.0.0.beta.19/lib/rspec/core/example_group.rb#L179
> 
> It needs to be implemented in rspec-core if you want rspec-core to be
> able to be used on 1.8.6 without rspec-expectations.

Done: 
http://github.com/rspec/rspec-core/commit/7d492bdc3657ca9472368b50f3f3f6635aca7fe0

> 
> Myron

___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users

Re: [rspec-users] RSpec 2 Ruby 1.8.6 support (was Evaluating shared example customisation block before shared block)

[David Chelimsky]

On Aug 2, 2010, at 4:49 AM, Ashley Moran wrote:

> 
> On Aug 01, 2010, at 11:52 pm, David Chelimsky wrote:
> 
>> re: 1.8.6, we've got a home-grown implementation of instance_exec that runs 
>> in 1.8.6 (although I just discovered that it's broken - fix coming shortly). 
>> I could
>> 
>> a) add such a thing for module_exec as well, though I haven't quite figured 
>> out how that works yet. 
>> b) only support parameterized shared groups in ruby 1.8.7 or better
>> c). the most drastic option, would be to drop support for 1.8.6 entirely, 
>> but I don't think that's really feasible yet.
> 
> Hmmm.  If you're working on a Rails project with RSpec 2 (which I'm not, but 
> I'm guessing that will be a very common case), you need 1.8.7 anyway, as 
> Rails 3 won't run on anything less.  If you're not using Rails, I can't 
> imagine anyone starting a new project on 1.8.6 now.  (All my new stuff is on 
> 1.9.2.)

But what about people who are, for what ever reasons, stuck with Ruby 1.8.6 and 
want to upgrade? Also, there are a few rspec-2 + rails-2 efforts in the works, 
and there will be a solution for this sometime this fall.

We need to support 1.8.6.

> 
> Is 1.8.6 support in RSpec 2 *really* necessary?  Any thoughts from anyone?
> 
> Cheers
> Ash
> 
> -- 
> http://www.patchspace.co.uk/
> http://www.linkedin.com/in/ashleymoran
> 
> ___
> rspec-users mailing list
> rspec-users@rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users

___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users

Re: [rspec-users] Evaluating shared example customisation block before shared block

[David Chelimsky]

On Aug 1, 2010, at 5:12 PM, Ashley Moran wrote:

> 
> On 1 Aug 2010, at 3:43 PM, David Chelimsky wrote:
> 
>> shared_examples_for "blah" do |a,b|
>> ...
>> end
>> 
>> it_should_behave_like "blah", 1, 2
>> 
>> That wouldn't have worked with the old implementation, but it would work 
>> perfectly well now. This would also "just work" with hash-as-keyword-args:
>> 
>> shared_examples_for "blah" do |options|
>> it "blah #{options[:a]}" do
>>   ..
>> end
>> end
>> 
>> it_should_behave_like "blah", :a => 1
>> 
>> Now you can do this:
>> 
>> [1,2,3].each do |n|
>> it_should_behave_like "blah", :a => n
>> end
>> 
>> And we can still use the customization block to define methods, hooks 
>> (before/after) and let(). Now it just feels like the rest of RSpec.
>> 
>> Thoughts?
> 
> One thought: me.facepalm :)
> 
> The only thing it lacks is a DSL to define the requirements.  Would it still 
> be desirable to be able to write:
> 
>  shared_examples_for "blah" do |options|
>require_argument options[:a]
>it "blah #{options[:a]}" do
>  ..
>end
>  end
> 
> Or some such?
> 
> Also, after staring at this for a while, I'm puzzled by something.  In this 
> code:
> 
>  it_should_behave_like "blah", :a => 1
> 
> how does :a => 1 get passed to the "options" block, as `shared_block` in the 
> code is never called with arguments?  Would this need another code change?  
> (Apologies if I'm being thick, it's late and I should probably go to bed, but 
> I wanted to review this first...)

Actually, I just discovered that ruby 1.8.7 actually added module_exec. What 
does this mean? It means this:

  def self.define_shared_group_method(new_name, report_label=nil)
module_eval(<<-END_RUBY, __FILE__, __LINE__)
  def self.#{new_name}(name, *args, &customization_block)
shared_block = world.shared_example_groups[name]
raise "Could not find shared example group named \#{name.inspect}" 
unless shared_block

describe("#{report_label || "it should behave like"} \#{name}") do
  module_exec *args, &shared_block
  module_exec *args, &customization_block if customization_block
end
  end
END_RUBY
  end

What does that mean? It means this:

shared_examples_for "foo" do |a,b,c|
  it "#{a} #{b} #{c}s" do
a.should do_something_with(b, c)
  end
end

describe "something" do
  it_behaves_like "foo", 1, 2, 3
end

Ta da!!

Two problems to solve at this point:

1. order of evaluation of blocks
2. what to do about ruby 1.8.6

re: order of evaluation of blocks, I think I'm inclined to go one way one 
minute, and another the next. Somebody convince me of one or the other.

re: 1.8.6, we've got a home-grown implementation of instance_exec that runs in 
1.8.6 (although I just discovered that it's broken - fix coming shortly). I 
could

a) add such a thing for module_exec as well, though I haven't quite figured out 
how that works yet. 
b) only support parameterized shared groups in ruby 1.8.7 or better
c). the most drastic option, would be to drop support for 1.8.6 entirely, but I 
don't think that's really feasible yet.

Thoughts?

David

> Cheers
> Ash

___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users

Re: [rspec-users] Evaluating shared example customisation block before shared block

[David Chelimsky]

On Aug 1, 2010, at 5:39 PM, Myron Marston wrote:

>> Seems like your mental model is that of a customization block being a 
>> subclass or re-opening of the shared block. What you say makes sense in that 
>> model, but that's not the same model I have.
> 
> My mental model is indeed that the customization block is like a
> subclass.  I'm not sure where I got it--it's just the intuitive way I
> understood shared_examples_for and it_should_behave_like.  But if no
> one else shares this mental model, then there's not much point in
> making rspec work this way.  I'm happy going with whatever the general
> consensus is.  Although, I do think that my mental model makes for
> some interesting possibilities :).
> 
>> Assuming that can work. I've taken a closer look and getting that to work 
>> would take some serious re-architecting that I'm not sure is a good idea.
> 
> Maybe I misunderstood you here, but I took this to refer to the
> passing of parameters to the shared example group, as you
> suggested...and it turns out this isn't very hard at all:
> 
> http://github.com/myronmarston/rspec-core/commit/c353badcb8154ab98a7dc46eb19c8a9fc702ec73

If we do this, we should use module_exec for both blocks so they both get the 
same arguments.

> 
> The one issue with this is that it uses #module_exec, which is not
> available in ruby 1.8.6--so we'd have to find a way to implement it,
> similar to how cucumber implements #instance_exec when it's not
> available:
> 
> http://github.com/aslakhellesoy/cucumber/blob/30d43767a7cffd1675e990115ac86c139e4ea3e0/lib/cucumber/core_ext/instance_exec.rb#L16-31

RSpec does that too :). Pretty sure it was Aslak that added that some years 
back.

Yeah - I'm playing around with an implementation of module_exec, but it doesn't 
seem to work quite the same way as instance exec does. Not yet, anyhow.

David

> 
> Myron
> ___
> rspec-users mailing list
> rspec-users@rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users

___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users

Re: [rspec-users] Evaluating shared example customisation block before shared block

[David Chelimsky]

On Aug 1, 2010, at 11:40 AM, Myron Marston wrote:

>> The particular issue of simple values being used in the docstrings and the 
>> examples themselves (i.e. exposed to everything in the block scope) could be 
>> handled like this:
>> 
>> shared_examples_for "blah" do |a,b|
>>   ...
>> end
>> 
>> it_should_behave_like "blah", 1, 2
> 
> Fantastic idea.  I'm sold.  I'm not sure why this simple idea didn't
> occur to me earlier :(.
> 
>> That's no different from methods that have default values for arguments:
>> 
>>   def foo(bar, baz = :default)
>> 
>> If you provide only 1 arg, all is well, but the first one is required. 
>> Here's the same idea expressed in a group:
>> 
>> shared_examples_for "foo" do
>>   unless defined?(:bar)
>> raise "you need to supply a bar() method"
>>   end
>> 
>>   unless defined?(:baz)
>> def baz; :default; end
>>   end
>> end
> 
> This does indeed work, to the extent that the methods the consumer
> needs to override are ones the author of the shared example ground had
> in mind, and coded as such.  This isn't an issue when the shared
> example group and the consuming code are in the same code base.  But
> the idea has been brought up that shared example groups could be
> provided by a library for users to use to enforce a contract of some
> class or object they write that the library interacts with.  I think
> it's likely that library authors won't declare their helper methods
> using the "unless defined?" idiom, because they can't anticipate all
> the needs of their users, and they probably aren't even aware that
> they have to declare their methods this way to allow them to be
> overridden.

I kind of jumped around from one part of this thread to the other - 
apologies if my responses seem to lack cohesion

That would be the tricky gotta RTFM part - I'd rather have that burden on the 
shared group/library author than its consumer.

>  Suddenly it's _impossible_ for consumers of the shared
> example group to override any of the helper methods.
> 
> I _love_ how flexible ruby is, and the fact that every method can be
> overridden, without the original author of the a method having to do
> anything special to allow it.  Your suggestion above seems (to me
> anyway) to be more in line with a language like C#, where methods are
> not overriddable by default, and developers have to use the virtual
> keyword to make them so.

Seems like your mental model is that of a customization block being a subclass 
or re-opening of the shared block. What you say makes sense in that model, but 
that's not the same model I have.

If we were going to go with the subclass model, I think we'd be best served by 
going all the way there. So this structure:

describe "foo" do
  it_behaves_like "bar", "with baz == 3" do
def baz; 3 end
  end
end

Would result in:

foo # top level group
  it behaves like bar # nested group generated by it_behaves_like using "bar" 
in the report
with baz == 3 # 3rd level nested group generated using the customization 
block

This would make the whole relationships between things much more transparent. I 
don't love this idea either, but we're searching for balance here. At least I 
am :)

> So, all of that is just to say that I'm still in favor of eval'ing the
> customization block last.  To me, the primary need for eval'ing the
> customization block first was to allow it define class helper methods
> that the shared example group could use to interpolate into doc
> strings, and this need is solved much more elegantly with David's
> suggestion.

Assuming that can work. I've taken a closer look and getting that to work would 
take some serious re-architecting that I'm not sure is a good idea. Consider 
the code as it is now:

http://github.com/rspec/rspec-core/blob/cc72146205fb93ca11e1f290d3385151b51181ad/lib/rspec/core/example_group.rb#L61

I've restructured it a bit after some of this conversation, but right now the 
customization block is still eval'd last. I think this code is very easy to 
grok for a reasonably advanced Rubyist (i.e. if you can get past 
module_eval(<<-END_RUBY), then the content of the String is no problem), but if 
we start adding gymnastics to support various combinations of nice-to-haves, 
then this code will quickly become harder to read.

In my experience with RSpec, readability/simplicity of the internals _does_ 
matter to end users, not just contributors and maintainers, because many want 
to understand what's going on under the hood. That is a strong motivator for me 
to keep things exactly as they are now (simple and readable).

In terms of end-users, the consumer of the shared group would not need to be 
any different in either of these two scenarios:

shared_examples_for "foo" do
  # with customization_block eval'd before
  unless defined?(:bar)
raise "you need to supply a bar() method"
  end
end

shared_examples_for "foo" do
  # with customization_block eval'd after
  def bar
raise "you need to supply a bar() method

Re: [rspec-users] Evaluating shared example customisation block before shared block

[David Chelimsky]

;t have worked with the old implementation, but it would work 
perfectly well now. This would also "just work" with hash-as-keyword-args:

shared_examples_for "blah" do |options|
  it "blah #{options[:a]}" do
..
  end
end

it_should_behave_like "blah", :a => 1

Now you can do this:

[1,2,3].each do |n|
  it_should_behave_like "blah", :a => n
end

And we can still use the customization block to define methods, hooks 
(before/after) and let(). Now it just feels like the rest of RSpec.

Thoughts?



> 
> Myron
> 
> 
> On Jul 31, 12:56 am, Ashley Moran 
> wrote:
>> On 31 Jul 2010, at 1:10 AM, David Chelimsky wrote:
>> 
>>> You can still get the same outcome, but you have to implement it in the 
>>> group like this:
>> 
>>> unless defined?(:foo)
>>>  def foo; "foo"; end
>>> end
>> 
>> Maybe a DSL method while I'm working on it?  Maybe:
>> 
>>   default_helper(:foo) do
>> "foo"
>>   end
>> 
>> WDYT?
>> 
>>> I think it's a good trade-off to put that burden on the group (and it's 
>>> author) rather that the consumers of the group.
>> 
>> Agreed, it'd cause a lot of duplication of effort the other way round.
>> 
>> --http://www.patchspace.co.uk/http://www.linkedin.com/in/ashleymoran
>> 
>> ___
>> rspec-users mailing list
>> rspec-us...@rubyforge.orghttp://rubyforge.org/mailman/listinfo/rspec-users
> ___
> rspec-users mailing list
> rspec-users@rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users

___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users

Re: [rspec-users] Evaluating shared example customisation block before shared block

[David Chelimsky]

On Aug 1, 2010, at 9:43 AM, David Chelimsky wrote:

> 
> On Jul 31, 2010, at 1:06 PM, Myron Marston wrote:
> 
>>> You can still get the same outcome, but you have to implement it in the 
>>> group like this:
>> 
>>> unless defined?(:foo)
>>> def foo; "foo"; end
>>> end
>> 
>> Good point--I hadn't thought of that.  The one issue I see with it is
>> that the author of the shared example group may not have knowledge of
>> which helper methods consumers will need to override.
> 
> That's no different from methods that have default values for arguments:
> 
>  def foo(bar, baz = :default)
> 
> If you provide only 1 arg, all is well, but the first one is required. Here's 
> the same idea expressed in a group:
> 
> shared_examples_for "foo" do
>  unless defined?(:bar)
>raise "you need to supply a bar() method"
>  end
> 
>  unless defined?(:baz)
>def baz; :default; end
>  end
> end
> 
>> So he/she
>> either defines all helper methods that way, or guesses about which
>> ones to define that way (and potentially guesses wrong).
>> 
>>> Maybe a DSL method while I'm working on it?  Maybe:
>>> 
>>>  default_helper(:foo) do
>>>"foo"
>>>  end
>>> 
>>> WDYT?
>> 
>> If we go the route of having the customization block evaluated first,
>> then I like the idea, but I'm generally wary of adding more DSL
>> methods to RSpec.  I think we should be careful to only add new DSL
>> methods that many people will find useful.  If you find it useful,
>> it's very easy to use it in your project without it being part of
>> RSpec: just define default_helper in a module, and use config.extend
>> YourModule in the RSpec.configuration block.  (Note that I'm _not_
>> against adding this to RSpec: I just want to be sure we don't add a
>> bunch of DSL methods that have limited usefulness.)
>> 
>> Looking back at the initial example that prompted the thread, it looks
>> to me like the primary use case for evaluating the customization block
>> first is so that you can parameterize the shared example group's
>> example descriptions.  (There may be other use cases for defining a
>> class-level helper methods, but none springs to mind).  I also do this
>> frequently.  Often times I have something like this:
>> 
>> [:foo, :bar, :baz].each do |method|
>> it "does something for #{method}" do
>>subject.send(method).should ...
>> end
>> end
>> 
>> In this case I'm using the method parameter at the class level (to
>> interpolate into the description string) and at the instance level
>> (within the example itself).
>> 
>> If we evaluated the customization block first, it would allow this,
>> but you'd have to define both an instance and class helper:
>> 
>> it_should_behave_like "something" do
>> def self.method_name; :foo; end
>> def method_name; :foo; end
>> end
>> 
>> I think this is a clunky way to essentially pass a parameter to the
>> shared example group.  Better would be something like this:
>> 
>> it_should_behave_like "something" do
>> providing :method_name, :foo
>> end
>> 
>> The instance of the shared example group provides :foo as the value of
>> the method_name parameter.  providing simply defines a class and an
>> instance helper method with the given value.
>> 
>> I've written up an untested gist with a start for the code that would
>> implement this:
>> 
>> http://gist.github.com/502409
>> 
>> I think there's value in evaluating the customization block first and
>> value in evaluating it last.  We can get the best of both worlds if we
>> limit what's evaluated first to a subset (say, a few DSL methods, and
>> maybe all class method definitions), extract it, and evaluate that
>> first, then evaluate the shared block first, then evaluate the
>> customization block.  The gist demonstrates this as well.  This may
>> confuse people, but it does give us the best of both worlds, I think.
> 
> Agreed on both points: best of both worlds and confusing :)
> 
> When I said "maybe a DSL" I was thinking only in the context of the shared 
> group, not in the consuming group.
> 
> What makes the example in your gist confusing to me is that we start to get 
> into a different mental model of what a shared group is. Based on recent 
> changes, for me, it's just a nested example

Re: [rspec-users] Evaluating shared example customisation block before shared block

[David Chelimsky]

On Jul 30, 2010, at 6:56 PM, Myron Marston wrote:

> On Jul 30, 2:58 pm, Ashley Moran 
> wrote:
>> On 30 Jul 2010, at 5:00 PM, David Chelimsky wrote:
>> 
>>> By all means.
>> 
>> I've started on that and filed a ticket[1].
>> 
>> One question I have, is I keep calling the Example Group that uses a shared 
>> block the "host group".  Is there already a name for it?  I never know what 
>> to use, and I'm not sure "host group" describes it accurately anyway.
>> 
>> Cheers
>> Ash
>> 
>> [1]http://github.com/rspec/rspec-core/issues/issue/99
>> 
>> --http://www.patchspace.co.uk/http://www.linkedin.com/in/ashleymoran

> I may be the only one who finds this useful, but I think there's value
> in evaluating the customization block after the shared example group
> block.  It allows the shared example group to provide a default
> implementation of a helper method, and then an instance of the shared
> behavior to override the helper method if appropriate.  If you
> evaluate the customization block before the shared example group
> block, the default implementation wins out, and you have no way to
> override helper methods in an instance of a shared example group.

You can still get the same outcome, but you have to implement it in the group 
like this:

unless defined?(:foo)
  def foo; "foo"; end
end

I think it's a good trade-off to put that burden on the group (and it's author) 
rather that the consumers of the group.
___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users

Re: [rspec-users] Evaluating shared example customisation block before shared block

[David Chelimsky]

On Jul 30, 2010, at 10:17 AM, Wincent Colaiuta wrote:

> El 30/07/2010, a las 16:10, David Chelimsky escribió:
> 
>> Actually - maybe I spoke to soon. Ordering things this way would mean that 
>> you couldn't do this:
>> 
>> shared_examples_for Enumerable do
>> def enumerable
>>   raise "you must provide an enumerable method that returns the object which 
>> you're specifying should behave like Enumerable"
>> end
>> it "..." { .. }
>> end
>> 
>> Although, if you were going to do that, I guess you could do this:
>> 
>> shared_examples_for Enumerable do
>> unless defined?(:enumerable)
>>   raise "you must provide an enumerable method that returns the object which 
>> you're specifying should behave like Enumerable"
>> end
>> it "..." { .. }
>> end
>> 
>> Maybe that, or a DSL that wraps that, is the better way, so we can get the 
>> best of both worlds?
>> 
>> shared_examples_for Enumerable do
>> require_instance_method :foo, "gotta have foo instance method"
>> require_class_method :foo, "gotta have foo class method"
>> require_instance_variable "@foo", "gotta have an instance variable named 
>> @foo"
>> it "..." { .. }
>> end
>> 
>> Thoughts?
> 
> I think the DSL would probably be over-engineering.
> 
> One of the purposes the DSL would fulfill is to alert the user if he/she 
> forgets to provide some required support methods or variables, but you 
> already get those alerts "for free" in the form of failing specs and 
> NoMethodErrors etc, so I don't think that really justifies it.
> 
> The other purpose of the DSL would be to explicitly list the "dependencies" 
> of the shared example group to someone who's scanning it. Again, I'm not sure 
> if it's really justified, given that a much simpler solution already exists:
> 
>  shared_examples_for Enumerable do
># requires:
>#   - instance method: foo
>#   - class method: foo
>#   - instance variable: @foo
> 
>it "..." { ... }
>  end
> 
> (I'm a big fan of doing the simplest thing that could possibly work.)

That would only work if people read the docs :)

The programatic approach would warn the user when they try to do something.

I'm not sold on the DSL at this point, but I do like the idea of having a 
library help the developer do the right thing. If I provide spec extensions for 
a library (other than RSpec in this case) that include a shared group that "you 
can use to spec your foos to make sure they comply with this API" (or 
whatever), then this sort of thing can be very helpful. Make sense?

> 
> Cheers,
> Wincent
> 
> 
> 
> ___
> rspec-users mailing list
> rspec-users@rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users

___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users

Re: [rspec-users] Evaluating shared example customisation block before shared block

[David Chelimsky]

On Jul 30, 2010, at 10:57 AM, Ashley Moran wrote:

> 
> On Jul 30, 2010, at 3:10 pm, David Chelimsky wrote:
> 
>> Maybe that, or a DSL that wraps that, is the better way, so we can get the 
>> best of both worlds?
>> 
>> shared_examples_for Enumerable do
>> require_instance_method :foo, "gotta have foo instance method"
>> require_class_method :foo, "gotta have foo class method"
>> require_instance_variable "@foo", "gotta have an instance variable named 
>> @foo"
>> it "..." { .. }
>> end
>> 
>> Thoughts?
> 
> Actually, I *much* prefer this, as it makes it explicit what the host spec 
> must provide in order to have the shared behaviour.  (Wincent's email has 
> just popped up so consider this a response to his message too.)  I lean 
> towards making things fail as early and explicitly as possible, as it reduces 
> the total worldwide developer head-scratching time.  
> InvalidSharedExampleUsageError("Must provide instance method :foo") or some 
> such wins for me over NoMethodError("undefined method foo on <#Class ...>").  
> There should be no _requirement_ to use this DSL though, so the key would be 
> to make sure it doesn't muddy the RSpec code.
> 
> This is probably something that could be solved in code quicker than debate.  
> It's a yak I'm happy to shave before getting back to my own project as it 
> impacts what I'm working on ... want me to have a look at it this evening, 
> David?  I can fork rspec-core and play around with the idea.

By all means.

> Regards
> Ash

___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users

Re: [rspec-users] Evaluating shared example customisation block before shared block

[David Chelimsky]

On Jul 30, 2010, at 9:03 AM, David Chelimsky wrote:

> 
> On Jul 30, 2010, at 5:13 AM, Ashley Moran wrote:
> 
>> Hi
>> 
>> I finally looked into why this is not currently possibly in RSpec 2 (beta 
>> 19):
>> 
>> shared_examples_for "Etymology" do
>>   describe "The etymology of foo" do
>> it "is followed by #{after_foo}" do
>>   # ...
>> end
>>   end
>> end
>> 
>> describe "foo", focus: true do
>>   it_should_behave_like "Etymology" do
>> def self.after_foo
>>   "bar"
>> end
>>   end
>> end
>> 
>> It's because of the current implementation of 
>> ExampleGroup.define_shared_group_method, which evaluates the shared example 
>> block before the customisation block:
>> 
>>  shared_group = describe("#{report_label} \#{name}", &shared_block)
>>  shared_group.class_eval(&customization_block) if customization_block
>> 
>> (This is behaviour I found surprising.)
>> 
>> However, with a little more metaprogramming jiggery-pokery, you can have 
>> them evaluated in the other order:
>> 
>> module RSpec
>>   module Core
>> class ExampleGroup
>>   # ...
>> 
>>   def self.define_shared_group_method(new_name, report_label=nil)
>> report_label = "it should behave like" unless report_label
>> module_eval(<<-END_RUBY, __FILE__, __LINE__)
>>   def self.#{new_name}(name, &customization_block)
>> shared_block = world.shared_example_groups[name]
>> raise "Could not find shared example group named 
>> \#{name.inspect}" unless shared_block
>> 
>> compound_block = lambda do |*args|
>>   module_eval &customization_block if customization_block
>>   module_eval &shared_block
>> end
>> 
>> shared_group = describe("#{report_label} \#{name}", 
>> &compound_block)
>> shared_group
>>   end
>> END_RUBY
>>   end
>> 
>>   # ...
>> end
>>   end
>> end
>> 
> 
> Or ...
> 
>  def self.define_shared_group_method(new_name, report_label=nil)
>report_label = "it should behave like" unless report_label
>module_eval(<<-END_RUBY, __FILE__, __LINE__)
>  def self.#{new_name}(name, &customization_block)
>shared_block = world.shared_example_groups[name]
>raise "Could not find shared example group named \#{name.inspect}" 
> unless shared_block
> 
>describe "#{report_label} \#{name}" do
>  module_eval &customization_block if customization_block
>  module_eval &shared_block
>end
>  end
>END_RUBY
>  end
> 
>> Would this be a useful improvement to RSpec 2?
> 
> Yes
> 
>> Any opinions on the order of the block evaluation for shared examples
> 
> Makes perfect sense to me. Wanna make a patch with an additional scenario in 
> the cuke?

Actually - maybe I spoke to soon. Ordering things this way would mean that you 
couldn't do this:

shared_examples_for Enumerable do
  def enumerable
raise "you must provide an enumerable method that returns the object which 
you're specifying should behave like Enumerable"
  end
  it "..." { .. }
end

Although, if you were going to do that, I guess you could do this:

shared_examples_for Enumerable do
  unless defined?(:enumerable)
raise "you must provide an enumerable method that returns the object which 
you're specifying should behave like Enumerable"
  end
  it "..." { .. }
end

Maybe that, or a DSL that wraps that, is the better way, so we can get the best 
of both worlds?

shared_examples_for Enumerable do
  require_instance_method :foo, "gotta have foo instance method"
  require_class_method :foo, "gotta have foo class method"
  require_instance_variable "@foo", "gotta have an instance variable named @foo"
  it "..." { .. }
end

Thoughts?

> 
>> 
>> Cheers
>> Ash
>> 
>> -- 
>> http://www.patchspace.co.uk/
>> http://www.linkedin.com/in/ashleymoran
>> 
>> ___
>> rspec-users mailing list
>> rspec-users@rubyforge.org
>> http://rubyforge.org/mailman/listinfo/rspec-users
> 

___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users

Re: [rspec-users] Evaluating shared example customisation block before shared block

[David Chelimsky]

On Jul 30, 2010, at 5:13 AM, Ashley Moran wrote:

> Hi
> 
> I finally looked into why this is not currently possibly in RSpec 2 (beta 19):
> 
>  shared_examples_for "Etymology" do
>describe "The etymology of foo" do
>  it "is followed by #{after_foo}" do
># ...
>  end
>end
>  end
> 
>  describe "foo", focus: true do
>it_should_behave_like "Etymology" do
>  def self.after_foo
>"bar"
>  end
>end
>  end
> 
> It's because of the current implementation of 
> ExampleGroup.define_shared_group_method, which evaluates the shared example 
> block before the customisation block:
> 
>   shared_group = describe("#{report_label} \#{name}", &shared_block)
>   shared_group.class_eval(&customization_block) if customization_block
> 
> (This is behaviour I found surprising.)
> 
> However, with a little more metaprogramming jiggery-pokery, you can have them 
> evaluated in the other order:
> 
>  module RSpec
>module Core
>  class ExampleGroup
># ...
> 
>def self.define_shared_group_method(new_name, report_label=nil)
>  report_label = "it should behave like" unless report_label
>  module_eval(<<-END_RUBY, __FILE__, __LINE__)
>def self.#{new_name}(name, &customization_block)
>  shared_block = world.shared_example_groups[name]
>  raise "Could not find shared example group named 
> \#{name.inspect}" unless shared_block
> 
>  compound_block = lambda do |*args|
>module_eval &customization_block if customization_block
>module_eval &shared_block
>  end
> 
>  shared_group = describe("#{report_label} \#{name}", 
> &compound_block)
>  shared_group
>end
>  END_RUBY
>end
> 
># ...
>  end
>end
>  end
> 

Or ...

  def self.define_shared_group_method(new_name, report_label=nil)
report_label = "it should behave like" unless report_label
module_eval(<<-END_RUBY, __FILE__, __LINE__)
  def self.#{new_name}(name, &customization_block)
shared_block = world.shared_example_groups[name]
raise "Could not find shared example group named \#{name.inspect}" 
unless shared_block

describe "#{report_label} \#{name}" do
  module_eval &customization_block if customization_block
  module_eval &shared_block
end
  end
END_RUBY
  end

> Would this be a useful improvement to RSpec 2?

Yes

> Any opinions on the order of the block evaluation for shared examples

Makes perfect sense to me. Wanna make a patch with an additional scenario in 
the cuke?

> 
> Cheers
> Ash
> 
> -- 
> http://www.patchspace.co.uk/
> http://www.linkedin.com/in/ashleymoran
> 
> ___
> rspec-users mailing list
> rspec-users@rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users

___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users

Re: [rspec-users] proposition: warn on rake spec - group :test

[David Chelimsky]

On Jul 30, 2010, at 3:09 AM, Rainer Kuhn wrote:
> On Jul 29, 3:29 pm, David Chelimsky  wrote:
>> On Jul 27, 2010, at 7:29 AM, Rainer Kuhn wrote:
>> 
>>> Consider putting out some information on rake spec, when rspec ist
>>> only defined in the :test group.
>>> This just cost me an hour until I read the blog post explaining it.
>> 
>>> Thing is, rake spec doesn't show on "rake -T" but it runs fine, just
>>> not doing anything.
>>> One line of output, like:
>> 
>>> "Either use RAILS_ENV=test or put 'gem rspec' in the :development
>>> group"
>> 
>>> would be nice
>> 
>> RSpec can't do anything if it's not loaded, which is the case when you run 
>> rake -T without rspec-rails in the :development group. I realize that this 
>> is new, but this is the way Rails-3 is supposed to work and we're all going 
>> to be learning how Gemfiles work for a while. Note that when you generate a 
>> new Rails-3 app (as of the release candidate), the generated Gemfile says 
>> this:
>> 
>> # Bundle gems for the local environment. Make sure to
>> # put test-only gems in this group so their generators
>> # and rake tasks are available in development mode:
>> # group :development, :test do
>> #   gem 'webrat'
>> # end


> That's not entirely true, there is a diffence between lot loaded and
> not defined, let me show you:
> 
> This is without rspec in the dev group, so it does not show in rake -T:
> 
> ~/work/myproject$ rake spec
> (in /Users/rainerkuhn/work/myproject)
> 
> ~/work/myproject$ rake IdontExist
> (in /Users/rainerkuhn/work/myproject)
> rake aborted!
> Don't know how to build task 'IdontExist'
> 
> (See full trace by running task with --trace)
> ~/work/myproject$

Interesting. I see the same behaviour, but it's not what you think it is. Try 
"rake spec:models" and you'll get the "Don't know how to build" error. I added 
a "raise" statement to the top of the rspec.rake file (i.e. the first line - 
raises if the file is even loaded) and it raises if I include rspec in the 
:development group, but not in the :test group.

I then pulled rspec completely out of the Gemfile and, lo and behold, still no 
error on "rake spec" - just does nothing.

Doesn't solve this issue, but does verify that RSpec won't be able to solve it. 
It'll have to come from either users getting used to the idea of putting 
rspec-rails in the :development group, or a change to Rails.

ps -  I moved your response from the top to the bottom. Please post inline or 
at the bottom so readers can follow the thread: 
http://idallen.com/topposting.html.
___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users

Re: [rspec-users] how to fix 'rake gems:refresh_specs' gems has no specificati

[David Chelimsky]

On Jul 30, 2010, at 7:47 AM, Amit Jain wrote:

> David Chelimsky wrote:
>> On Jul 30, 2010, at 6:52 AM, Amit Jain wrote:
>> 
>>>>> from /usr/lib/ruby/gems/1.8/gems/rcov-0.9.8/bin/rcov:511
>>> 
>>>   config.gem "rspec-rails", :version => ">= 1.3.2"
>> 
>> OK - so the problem now is that you've got rspec-rails 2.0.0.beta 
>> installed and that satisfies the ">= 1.3.2" gem requirement, but it only 
>> works with Rails 3. Try changing that to this:
>> 
>>  config.gem "rspec-rails", :version => "~> 1.3.2"
>> 
>> The "~>" matches any gem versions that begin with 1.3, so if you later 
>> upgrade to 1.3.3 it will still work, but it won't match 2.0.0.xxx.
>> 
>> Also, try running with the "rake spec" command before using rcov, which 
>> adds complexity to the mix.
> 
> Hi After adding
>  config.gem "rspec-rails", :version => "~> 1.3.2"
> line in config/environment.rb file. i am getting such type of error.
> 
> [a...@localhost MyApplication]$ ruby script/server
> 
> => Booting WEBrick
> => Rails 2.3.4 application starting on http://0.0.0.0:3000
> can't activate rspec-rails (= 2.0.0.beta.19, runtime) for [], already 
> activated rspec-rails-1.3.2 for []
> /usr/lib/ruby/site_ruby/1.8/rubygems.rb:230:in `activate'
> /usr/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:35:in `require'
> /home/Amit/Myworkspace/MyApplication/vendor/rails/activesupport/lib/active_support/dependencies.rb:156:in
>  
> `require'
> /home/Amit/Myworkspace/MyApplication/vendor/rails/activesupport/lib/active_support/dependencies.rb:521:in
>  
> `new_constants_in
> /home/Amit/Myworkspace/MyApplication/vendor/rails/activesupport/lib/active_support/dependencies.rb:156:in
>  
> `require'
> /home/Amit/Myworkspace/MyApplication/vendor/rails/railties/lib/commands/server.rb:84
> /usr/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:31:in 
> `gem_original_require'
> /usr/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:31:in `require'
> script/server:3
> Missing these required gems:
>  rspec-rails  ~> 1.3.2
> 
> You're running:
>  ruby 1.8.6.399 at /usr/bin/ruby
>  rubygems 1.3.6 at /home/Amit/.gem/ruby/1.8, /usr/lib/ruby/gems/1.8
> 
> Run `rake gems:install` to install the missing gems.
> -
> 
> I try $ rake gems:install but not install any thing and i also try
> 
> [r...@localhost MyApplication]# gem uninstall rspec-rails-1.3.2
> ERROR:  While executing gem ... (Gem::InstallError)
>cannot uninstall, check `gem list -d rspec-rails-1.3.2`
> [r...@localhost MyApplication]# `gem list -d rspec-rails-1.3.2`
> [r...@localhost MyApplication]#
> 
> I don't know about this error and why it is coming.

Try this:

gem install rspec-rails --version "1.3.2"

___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users

Re: [rspec-users] how to fix 'rake gems:refresh_specs' gems has no specificati

[David Chelimsky]

On Jul 30, 2010, at 6:52 AM, Amit Jain wrote:

> David Chelimsky wrote:
>> On Jul 30, 2010, at 2:03 AM, Amit Jain wrote:
>> 
>>>> rails. Please do this:
>>>> it using some means other than what is recommended by Rails, which is to 
>>>> David
>>> (NameError)
>>> /home/Amit/Myworkspace/MyApplication/vendor/rails/activesupport/lib/active_support/dependencies.rb:158:in
>>>  
>>>  ... 11 levels...
>>> from /usr/lib/ruby/gems/1.8/gems/rcov-0.9.8/bin/rcov:511:in `load'
>>> from /usr/lib/ruby/gems/1.8/gems/rcov-0.9.8/bin/rcov:511
>>> from /usr/bin/rcov:19:in `load'
>>> from /usr/bin/rcov:19
>>> Please help me.
>> 
>> Please show me what  you typed in your config/environment.rb to 
>> configure rspec-rails.
> 
> Hi ,
> 
> I configure the rspec-rails gem in config/environment.rb:
> 
>config.gem "rspec-rails", :version => ">= 1.3.2"

OK - so the problem now is that you've got rspec-rails 2.0.0.beta installed and 
that satisfies the ">= 1.3.2" gem requirement, but it only works with Rails 3. 
Try changing that to this:

  config.gem "rspec-rails", :version => "~> 1.3.2"

The "~>" matches any gem versions that begin with 1.3, so if you later upgrade 
to 1.3.3 it will still work, but it won't match 2.0.0.xxx.

Also, try running with the "rake spec" command before using rcov, which adds 
complexity to the mix.

> Thanks
> Amit
> -- 
> Posted via http://www.ruby-forum.com/.
> ___
> rspec-users mailing list
> rspec-users@rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users

___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users

Re: [rspec-users] how to fix 'rake gems:refresh_specs' gems has no specificati

[David Chelimsky]

On Jul 30, 2010, at 2:03 AM, Amit Jain wrote:

> David Chelimsky wrote:
>> On Jul 29, 2010, at 6:37 AM, Amit Jain wrote:
>> 
>>> 
>>> and
>>> 
>>> ~/mygreatapp/ $ ./script/plugin install 
>>> svn://rubyforge.org/var/svn/rspec/tags/REL_X_Y_Z/vendor/rspec_on_rails/vendor/plugins/rspec
>> 
>> rspec_on_rails is 2 years old and works with 2 year old versions of 
>> rails. Please do this:
>> 
>> 1. delete all rspec plugins from vendor/plugins
>> 2. configure the rspec-rails gem in config/environment.rb:
>> 
>> config.gem "rspec-rails", :version => ">= 1.3.2"
>> 
>> 3. rake gems:install
>> 4. rake gems:unpack
>> 
>> The problem you're having with CVS in vendor/gems is that you installed 
>> it using some means other than what is recommended by Rails, which is to 
>> use "rake gems:unpack". Please remove that and any other gems that you 
>> didn't install with "rake gems:unpack" from your vendor/gems directory, 
>> configure them config/environment.rb, and re-install them with "rake 
>> gems:unpack".
>> 
>> If you continue to have trouble with this, please consult the 
>> ruby-on-rails documentation and/or mailing lists, as your issues are 
>> gem/plugin installation issues, not RSpec issues.
>> 
>> HTH,
>> David
> 
> I am getting some different error message:
> 
> $rcov user_spec.rb
> 
> /home/Amit/Myworkspace/MyApplication/config/../vendor/rails/railties/lib/rails/gem_dependency.rb:119:Warning:
>  
> Gem::Dependency#version_requirements is deprecated and will be removed 
> on or after August 2010.  Use #requirement
> /home/Amit/Myworkspace/MyApplication/vendor/rails/activesupport/lib/active_support/dependencies.rb:440:in
>  
> `load_missing_constant': uninitialized constant Rails::Railtie 
> (NameError)
>  from 
> /home/Amit/Myworkspace/MyApplication/vendor/rails/activesupport/lib/active_support/dependencies.rb:80:in
>  
> `const_missing'
>  from 
> /home/Amit/Myworkspace/MyApplication/vendor/gems/rspec-rails-2.0.0.beta.19/lib/rspec-rails.rb:3
>  from /usr/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:31:in 
> `gem_original_require'
>  from /usr/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:31:in 
> `require'
>  from 
> /home/Amit/Myworkspace/MyApplication/vendor/rails/activesupport/lib/active_support/dependencies.rb:158:in
>  
> `require'
>  from 
> /home/Amit/Myworkspace/MyApplication/config/../vendor/rails/railties/lib/rails/gem_dependency.rb:208:in
>  
> `load'
>  from 
> /home/Amit/Myworkspace/MyApplication/config/../vendor/rails/railties/lib/initializer.rb:307:in
>  
> `load_gems'
>  from 
> /home/Amit/Myworkspace/MyApplication/config/../vendor/rails/railties/lib/initializer.rb:307:in
>  
> `each'
>   ... 11 levels...
>  from /usr/lib/ruby/gems/1.8/gems/rcov-0.9.8/bin/rcov:511:in `load'
>  from /usr/lib/ruby/gems/1.8/gems/rcov-0.9.8/bin/rcov:511
>  from /usr/bin/rcov:19:in `load'
>  from /usr/bin/rcov:19
> Please help me.

Please show me what  you typed in your config/environment.rb to configure 
rspec-rails.
___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users

Re: [rspec-users] how to fix 'rake gems:refresh_specs' gems has no specificati

[David Chelimsky]

On Jul 29, 2010, at 6:37 AM, Amit Jain wrote:

> David Chelimsky wrote:
>> On Jul 29, 2010, at 5:19 AM, Amit Jain wrote:
>>> Hello,
>>> I recently unpacked the latest rspec and rspec rails in my
>>> applicaiton.
>> 
>> How did you unpack them (what command did you use)?
> I just install rspec gem through the commands:
>  root# gem install rspec
>  root# gem install rcov
> 
> and
> 
> ~/mygreatapp/ $ ./script/plugin install 
> svn://rubyforge.org/var/svn/rspec/tags/REL_X_Y_Z/vendor/rspec_on_rails/vendor/plugins/rspec

rspec_on_rails is 2 years old and works with 2 year old versions of rails. 
Please do this:

1. delete all rspec plugins from vendor/plugins
2. configure the rspec-rails gem in config/environment.rb:

config.gem "rspec-rails", :version => ">= 1.3.2"

3. rake gems:install
4. rake gems:unpack

The problem you're having with CVS in vendor/gems is that you installed it 
using some means other than what is recommended by Rails, which is to use "rake 
gems:unpack". Please remove that and any other gems that you didn't install 
with "rake gems:unpack" from your vendor/gems directory, configure them 
config/environment.rb, and re-install them with "rake gems:unpack".

If you continue to have trouble with this, please consult the ruby-on-rails 
documentation and/or mailing lists, as your issues are gem/plugin installation 
issues, not RSpec issues.

HTH,
David

> 
> but it's not work
> 
> ~/mygreatapp/ $ ./script/generate rspec
> and then
> ./script/generate rspec_model User
> 
>> 
>>> When I run my specs I get:
>>> 
>>> $ rcov user_spec.rb
>> 
>> Where are you typing this command? What happens when you type "rake 
>> spec" from the project root?
>> I run that command in /spec/models directory
> 
> /spec/models $ rcov user_spec.rb
> 
>>> config.gem: Unpacked gem CVS in vendor/gems has no specification file.
>> 
>> This error suggests that you unpacked the gem using "gem unpack" instead 
>> of "rake gems:unpack".
>> 
>>> Run 'rake gems:refresh_specs' to fix this.
>>> config.gem: Unpacked gem CVS in vendor/gems not in a versioned
>>> directory. Giving up.
>> 
>> And this one suggests that you may have put a CVS plugin directly in the 
>> gems folder. Rails wants you to put plugins in vendor/plugins, and use 
>> "rake gems:unpack" to install gems in vendor/gems.
>> 
>>> from
>>> /home/Amit/Myworkspace/MyApplication/vendor/plugins/rspec_on_rails/lib/spec/rails.rb:3
>> 
>> What version of rails are you using? rspec_on_rails was replaced by 
>> rspec-rails nearly two years ago, when rails was at 2.1.x. If you're 
>> using any version of rails later than 2.1, you should be using the 
>> rspec-rails gem.
> 
> I am using Rails 2.3.4.
> -- 
> Posted via http://www.ruby-forum.com/.
> ___
> rspec-users mailing list
> rspec-users@rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users

___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users

Re: [rspec-users] Testing controller and action with parameters

[David Chelimsky]

On Jul 29, 2010, at 8:37 AM, Anderson Leite wrote:

> I have an action and I am testing it like this:
> 
> The action:
> ==
>  def create
>@event = Evento.new(params[:event])
>@event.aproved = false
>if @event.save
>  redirect_to :action => "index"
>else
>  render :action => "new"
>end
>  end
> 
> 
> The RSpec test:
> ==
> 
>  before do
>@event = mock_model(Event)
>Event.stub!(:new).and_return(@event)

Use stub instead of stub! (which will eventually be deprecated)

>@event.stub!(:aproved=).and_return(false)
>@event.stub!(:save).and_return(true)

You can add the method stubs to the mock_model declaration:

@event = mock_model(Event, :approved= => false, :save => true)

>  end
> 
>  it "should register some event and keep it not aproved" do

The word "and" in an example's name suggests too many things are being spec'd 
in one example. I'd split these out into "registers the event" and "leaves the 
event un-approved"

HTH,
David

>Event.should_receive(:new).once
>@event.should_receive(:aproved=).once
>@event.should_receive(:save).once
>get "create"
>response.should redirect_to :action => 'index'
>  end
> 
> 
> It seems to be working for me and the test is passing, by I think this
> test is still ugly or probabily can be improved.
> 
> How do you make tests like this?

___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users

Re: [rspec-users] should_receive break the method chain?

[David Chelimsky]

On Jul 29, 2010, at 7:46 AM, Zhenning Guan wrote:

> class A
> def process
>  @b.calculate
> end
> end
> 
> 
> it 'should change b calculate value' do
>  @b.should_receive(:calculate)
>  @a.process
> 
>  @b.calculae_value.should == 'after_calculae'
> end
> 
> it will fail, if I comment out #...@b.should_receive(:calculate), the test
> pass,
> or if comment out #...@b.calculae_value.should == 'after_calculae', also
> pass.
> 
> so my colleague said maybe should_receive break the mehod chain and
> return.
> thing is really going this way?

Your colleague is correct. Any time you use object.stub(:method) or 
object.should_receive(:method) on a real object, the method is replaced by the 
mock framework. This is true with all of the popular ruby mock/test double 
frameworks. The one way to get around that is to use RR's[1] proxy.

HTH,
David

[1] http://github.com/btakita/rr
___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users

Re: [rspec-users] proposition: warn on rake spec - group :test

[David Chelimsky]

On Jul 27, 2010, at 7:29 AM, Rainer Kuhn wrote:

> Consider putting out some information on rake spec, when rspec ist
> only defined in the :test group.
> This just cost me an hour until I read the blog post explaining it.
> 
> Thing is, rake spec doesn't show on "rake -T" but it runs fine, just
> not doing anything.
> One line of output, like:
> 
> "Either use RAILS_ENV=test or put 'gem rspec' in the :development
> group"
> 
> would be nice


RSpec can't do anything if it's not loaded, which is the case when you run rake 
-T without rspec-rails in the :development group. I realize that this is new, 
but this is the way Rails-3 is supposed to work and we're all going to be 
learning how Gemfiles work for a while. Note that when you generate a new 
Rails-3 app (as of the release candidate), the generated Gemfile says this:

# Bundle gems for the local environment. Make sure to
# put test-only gems in this group so their generators
# and rake tasks are available in development mode:
# group :development, :test do
#   gem 'webrat'
# end

HTH,
David

___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users

Re: [rspec-users] Gem post-install messages

[David Chelimsky]

On Jul 27, 2010, at 1:45 AM, Mislav Marohnić wrote:

> When you install the rspec-rails stack, the rspec gem post-install messages 
> take more than 60 lines in total. Most of those messages are something 
> uninformative like "thank you for installing the rspec-blah". Um, OK. You're 
> welcome, I guess?
> 
> http://pastie.org/1061716
> 
> The rspec-rails message is way too long, too. It should link to its web page 
> with upgrade instructions for Rails apps. But looking at the rspec-rails 
> GitHub project, I can't find the same instructions in the Readme, 
> Upgrade.markdown or the wiki. So the post-install message for the gem 
> contains the most useful upgrade documentation? That's no good.

All good advice. Please report this last bit to 
http://github.com/rspec/rspec-rails/issues so it stays on the radar. I'll 
remove the "thank you" from the other ones now.

Cheers,
David___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users

Re: [rspec-users] how to fix 'rake gems:refresh_specs' gems has no specificati

[David Chelimsky]

On Jul 29, 2010, at 5:19 AM, Amit Jain wrote:
> Hello,
> I recently unpacked the latest rspec and rspec rails in my
> applicaiton.

How did you unpack them (what command did you use)?

> When I run my specs I get:
> 
> $ rcov user_spec.rb

Where are you typing this command? What happens when you type "rake spec" from 
the project root?

> config.gem: Unpacked gem CVS in vendor/gems has no specification file.

This error suggests that you unpacked the gem using "gem unpack" instead of 
"rake gems:unpack".

> Run 'rake gems:refresh_specs' to fix this.
> config.gem: Unpacked gem CVS in vendor/gems not in a versioned
> directory. Giving up.

And this one suggests that you may have put a CVS plugin directly in the gems 
folder. Rails wants you to put plugins in vendor/plugins, and use "rake 
gems:unpack" to install gems in vendor/gems.

> config.gem: Unpacked gem rmagick-2.13.1 in vendor/gems has no
> specification file. Run 'rake gems:refresh_specs' to fix this.
> /usr/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:31:in
> `gem_original_require': no such file to load -- application
> (MissingSourceFile)
>  from /usr/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:31:in
> `require'
>  from
> /home/Amit/Myworkspace/MyApplication/vendor/rails/activesupport/lib/active_support/dependencies.rb:158:in
> `require'
>  from
> /home/Amit/Myworkspace/MyApplication/vendor/plugins/rspec_on_rails/lib/spec/rails.rb:3

What version of rails are you using? rspec_on_rails was replaced by rspec-rails 
nearly two years ago, when rails was at 2.1.x. If you're using any version of 
rails later than 2.1, you should be using the rspec-rails gem.

> from /usr/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:31:in
> `gem_original_require'
>  from /usr/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:31:in
> `require'
>  from
> /home/Amit/Myworkspace/MyApplication/vendor/rails/activesupport/lib/active_support/dependencies.rb:158:in
> `require'
>  from ./../spec_helper.rb:6
>  from /usr/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:31:in
> `gem_original_require'
>  from /usr/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:31:in
> `require'
>  from ./user_spec.rb:1
>  from /usr/lib/ruby/gems/1.8/gems/rcov-0.9.8/bin/rcov:511:in `load'
>  from /usr/lib/ruby/gems/1.8/gems/rcov-0.9.8/bin/rcov:511
>  from /usr/bin/rcov:19:in `load'
>  from /usr/bin/rcov:19


___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users

Re: [rspec-users] rspec 1 - nested examples (in an each block) use the final block variable 4 times instead of each of the 4 once

[David Chelimsky]

On Jul 28, 2010, at 5:42 PM, nruth wrote:

> Please correct me if this is fixed in Rspec 2, but in Rspec 1 I have
> hit upon the following problem (at least thrice, this time it costing
> me several hours), code is the best example:
> 
> I have a practice examination system where each record is one of
> several "subtests" (think tagging rather than subclassing) which is
> part of a constant string array. I want to test each's behaviour
> indepently in my specs (since an earlier implementation used STI
> rather than tagging, and I want to test each kind of test follows the
> spec)
> 
> My specs use this approach in parts:
> 
> describe "#add_question_set_of_type" do
>  MyModule::SUBTESTS.each do |subtest|
> 
>describe %Q("#{subtest}") do
>… specs using subtest
>  end
> end
> 
> where SUBTESTS is a constant array of strings.
> 
> the problem is doing this breaks any blocks that look like

Where are these blocks, in the outer or inner example group? Please provide a 
complete example, including everything I need to run and see the output you're 
seeing.

Thx


> 
>  let(:subtest) {MyModule.subtest_to_sym(subtest)}
> 
> or
> 
>  before(:each) do
>@subtest = MyModule.subtest_to_sym(subtest)
>  end
> 
> Instead I have to avoid the @ or let examples, and use the more
> explicit (verbose):
> 
>  MyModule.subtest_to_sym(subtest)
> 
> using the let or before @ approaches both fail.
> 
> Using puts within the code (for debugging purposes) I found that the
> specs were only being exposed to the final value of the array, while I
> expected (and have seen, or at least assumed from past passes) that
> all 4 (or so) of the strings were being used to create unique methods
> on the example group (one per iteration).
> 
> 
> Is this something that should be:
> 
> a. avoided, because it's crazy, and written differently
> b, documented
> c. investigated further
> 
> I can provide a more complete example if helpful?
> 
> Thanks,
> Nick
> ___
> rspec-users mailing list
> rspec-users@rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users

___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users

Re: [rspec-users] about spec.opts and command line options and global options

[David Chelimsky]

On Jul 28, 2010, at 1:52 PM, Jarmo Pertman wrote:

> Hello!
> 
> I have some questions/proposals which have been quite time on my mind
> already.
> 
> Let's suppose i have files under spec directory with the following
> structure and contents:
> # spec/helper.rb
> module Helper
> end
> 
> # spec/my_spec.rb
> describe Helper do # notice the usage of constant Helper
> end
> 
> #spec/spec.opts
> --require spec/helper
> 
> If i execute "spec spec\my_spec.rb" then everything works as expected.
> This solution gives me the possibility not to write all those require
> statements into each spec file and i'm happy to use it so i can write
> less duplicate code.
> 
> But there is a big problem if i want to enter some additional
> parameters for some specific run. Let's say i'd like to execute this
> command:
> spec spec\my_spec.rb -b
> 
> I would expect this "-b" to merged with all the options from
> spec.opts, but what actually happens is that all options from
> spec.opts are ignored, thus the test above will fail because Helper
> constant is missing. That just doesn't make sense!
> 
> I also found the place in code where this magic happens:
> # spec/runner/option_parser.rb
> 
> def parse_file_options(...)
> ...
>if options_file.nil? &&
>   File.exist?('spec/spec.opts') &&
>   !...@argv.any?{|a| a =~ /^\-/ }
> options_file = 'spec/spec.opts'
>end
> ...
> end
> 
> So, if there are any command line arguments specified then spec.opts
> is ignored...
> 
> Let me bring some more realistic example if you might think that this
> magic require in spec.opts is bad idea...
> 
> Let's have a "normal" spec.opts file:
> # spec.opts
> --format
> nested
> -c
> 
> This means that i'm using nested formatter with colored output. Not a
> bad idea, i guess.
> 
> But now if i want to execute only one example with -e, then my output
> will not be nested nor colored because of this ignore statement
> above... again, that doesn't make sense, does it?
> 
> Also, is there any possibility to have global options - let's say that
> i want every project on my PC to have nested and colored output - what
> shall i do? Any easy way to accomplish it programmatically if there's
> no built-in functionality yet?
> 
> Why is spec.opts hardcoded to be in spec directory? I would like it to
> work like rake is searching for rakefiles - searches up in the
> directory tree until finding rakefile.
> 
> I would like if spec.opts allowed to enter Ruby code so i wouldn't
> have to hardcode --require statement paths from working dir, but could
> use something like File.dirname(__FILE__) + "/helper"...
> 
> In summary, my proposals for spec.opts would be:
> 1) Search for spec.opts upwards starting from spec directory.
> 2) Merge command line options with spec.opts - e.g have higher
> priority for command line options, BUT preserve spec.opts if they're
> not overridden.
> 3) Make spec.opts to handle Ruby code.
> 4) Allow some way to specify global configuration options for RSpec.
> 
> I'm using RSpec 1.3.0 and don't know how these situations are handled
> in RSpec 2 branches.
> 
> Hopefully my ideas make sense.

I think http://github.com/rspec/rspec-core/blob/master/Upgrade.markdown might 
answer some of your questions.

HTH,
David
___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users

Re: [rspec-users] Problem running RSpec tests with Rails

[David Chelimsky]

On Jul 27, 2010, at 4:10 AM, Bruno Cardoso wrote:

> David Chelimsky wrote:
>> On Jul 26, 2010, at 12:36 PM, Bruno Cardoso wrote:
>> 
>>> Thanks for the answers.
>>> 
>>> What both solutions (from Ashley and David) do is not modify the BD in 
>>> anyway, so nothing gets dropped and nothing is created. This resolves 
>>> the problem but what if I want a clean installation in each test run?
>> 
>> So is your goal here to have the rake task(s) ignore the fact that you 
>> have pending migrations, but still have it reset the test database so 
>> it's schema looks like the development database schema?
> 
> Exactly.

OK. This is not Rails' intent (which is why 'db:abort_if_pending_migrations' is 
a prereq of 'db:test:prepare'), but you can use the same technique I described 
earlier on 'db:test:prepare' instead of 'spec':

  Rake::Task['db:test:prepare'].clear_prerequisites

Now you should get what you're looking for.

Cheers,
David

> 
> I'm ok with the previous solution, it's something we can do but I would 
> like to know what I could do if I wanted to go by my first plan.
> -- 
> Posted via http://www.ruby-forum.com/.
> ___
> rspec-users mailing list
> rspec-users@rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users

___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users

Re: [rspec-users] Problem running RSpec tests with Rails

[David Chelimsky]

On Jul 26, 2010, at 12:36 PM, Bruno Cardoso wrote:

> Thanks for the answers.
> 
> What both solutions (from Ashley and David) do is not modify the BD in 
> anyway, so nothing gets dropped and nothing is created. This resolves 
> the problem but what if I want a clean installation in each test run?

So is your goal here to have the rake task(s) ignore the fact that you have 
pending migrations, but still have it reset the test database so it's schema 
looks like the development database schema?

> Is 
> there a way to keep my "schema_migrations" table or remove the check for 
> migration scripts? I would still like to recreate the rest of the 
> tables.
> -- 
> Posted via http://www.ruby-forum.com/.
> ___
> rspec-users mailing list
> rspec-users@rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users

___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users

Re: [rspec-users] Problem running RSpec tests with Rails

[David Chelimsky]

On Jul 26, 2010, at 11:50 AM, Ashley Moran wrote:

> 
> On Jul 26, 2010, at 5:12 pm, Bruno Cardoso wrote:
> 
>> Not sure if this is a RSpec problem or Rails but I believe is more a
>> RSpec situation.
>> 
>> What happens is that when I run my RSpecs tests all the BD is recreated,
>> 
>> ...
>> 
>> Anyone know how to resolve this?
> 
> Hi Bruno
> 
> Are you running `rake spec` as opposed to the spec command?  The default 
> Rails spec task depends on the "db:test:prepare" task, which bombs your DB.

The test DB, not the development DB, right? If it's bombing your dev DB then 
please file a bug report and we can sort it out.

>  I fixed this in my project with a file "lib/tasks/rspec_fixes.rake":
> 
>  class Rake::Task
>def overwrite(&block)
>  @actions.clear
>  enhance(&block)
>end
>  end
> 
>  Rake::Task['db:test:prepare'].overwrite do

Another approach would be:

Rake::Task['spec'].prerequisites.clear

Cheers,
David

># We don't want to run migrations or load the schema!!!
>  end
> 
> HTH
> 
> Ash
> 
> -- 
> http://www.patchspace.co.uk/
> http://www.linkedin.com/in/ashleymoran
> 
> ___
> rspec-users mailing list
> rspec-users@rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users

___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users

Re: [rspec-users] Problem running RSpec tests with Rails

[David Chelimsky]

On Jul 26, 2010, at 11:12 AM, Bruno Cardoso wrote:

> Hi
> 
> Not sure if this is a RSpec problem or Rails but I believe is more a
> RSpec situation.
> 
> What happens is that when I run my RSpecs tests all the BD is recreated,
> including the "schema_migration" table, because of this I get a problem
> saying:
> 
> You have 29 pending migrations:
>  20100628100855 CreateCustomers
>  20100628103228 CreateAccounts
>  20100628172155 CreateCfgEntities
>  ...
>  etc
> 
> It seems rails notices that the schema_migration tables is empty and
> that are migration scripts to run. This shouldn't be needed because
> Rails uses schema.rb to recreate the table, right?

The test database, yes, but it won't get that far if you have any pending 
migrations in the development database.

If you run "rake spec --trace" you'll see that it runs db:test:prepare, which 
runs db:abort_if_pending_migrations.

HTH,
David

> 
> I'm using JRuby with JDBC connection by the way.
> 
> Anyone know how to resolve this?


___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users

Re: [rspec-users] [newbie] rspec, validations and factory_girl

[David Chelimsky]

On Jul 26, 2010, at 11:34 AM, Lille wrote:

> Hi,
> 
> class B < ActiveRecord::Base
>  belongs_to :a
>  validates_numericality_of :some_attribute, :greater_than =>
> 0, :allow_blank=>true
> 
>  def some_attribute
>  a.numeric_attr * read_attribute(:some_attribute)
>  end
>  ...
> 
> If I create an instance of my class B in rspec with factory_girl w.out
> a parent (but not required!)

It may not be a business requirement, but the some_attribute method above 
requires it's existence in order to run without error.

Try:

def some_attribute
  return nil unless a
  a.numeric_attr * read_attribute(:some_attribute)
end

HTH,
David

> instance of class A, I get the following
> error: "undefined method `numeric_attr' for nil:NilClass".
> 
> Why? Is this an apparent idiosyncrasy of using rspec and factory_girl
> together?
> Thanks,
> 
> Lille

___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users

[rspec-users] what is the value of the distinction between exceptions and failures?

[David Chelimsky]

There is a feature request to make a distinction between exceptions and logical 
failures in RSpec's output. If this topic interests you, please take a look at 
http://github.com/rspec/rspec-core/issues/#issue/93 and add your thoughts to 
the conversation there.

Thx,
David
___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users

Re: [rspec-users] Controller stub and helper spec with lastest beta

[David Chelimsky]

On Jul 24, 2010, at 9:33 AM, chatgris wrote:

> Hello,
> 
> I have two issues with beta 2.0.0.beta.18. First, here's the gems :
> 
> gem "rails", "3.0.0.beta4"
> gem "mongoid", "2.0.0.beta10"
> 
> group :test do
>  gem "rspec-rails", "2.0.0.beta.18"
>  gem "factory_girl_rails", "1.0"
> end
> 
> My spec_helper : 
> http://github.com/chatgris/blabbr/blob/spec/spec/spec_helper.rb

You've got some unnecessary stuff in spec_helper.rb. Try this:

1. Include rspec-rails in the :development group so you can see its rake tasks 
and generators [1]
2. Move all the configuration (except mock_with :rspec) from spec_helper to 
another file in spec/support/.
2. Regenerate spec_helper by running "script/rails generate rspec:install"

[1] 
http://blog.davidchelimsky.net/2010/07/11/rspec-rails-2-generators-and-rake-tasks-part-ii/

> First issue is related to stubbing the current_user method in
> controller.
> 
> describe 'current_user == added_by' do
> 
>before :all do
>  @current_user = Factory.create(:user)
>  @smiley = Factory.create(:smiley)
>end

This is probably not related to these issues, but it's generally better to 
create DB-backed objects (i.e. using Factory.create) in before(:each) blocks so 
they get the benefit of Rails' transaction management.

>before :each do
>  controller.stub!(:logged_in?).and_return(true)
>  controller.stub!(:current_user).and_return(@current_user)
>end
> 
>it 'should be able to see index' do
>  get :index
>  response.should be_success
>end
> end
> 
> current_user is defined in application_controller.rb
> 
> That code have this result :
> 
> SmiliesController current_user == added_by should be able to see index
>Failure/Error: controller.stub!(:logged_in?).and_return(true)
>undefined method `stub!' for #
># ./spec/controllers/smilies_controller_spec.rb:36

This suggests that something is getting in the way of loading rspec-mocks 
correctly. Please follow directions above and let me know if that solves it.

> The other issue is related to helpers specs. Considers this code :
> 
> require 'spec_helper'
> 
> describe LinkHelper do
>  before :all do
>@user = Factory.create(:creator)
>@topic = Factory.build(:topic)
>  end
> 
>  it "displays a 80px width gravatar link to the user page" do
>helper.link_to_avatar(@user).should == " \"> www.gravatar.com/avatar/4f64c9f81bb0d4ee969aaf7b4a5a6f40.jpg?size=80\"
> />"
>  end
> 
> end
> 
> That gives this error :
> 
> LinkHelper displays a 80px width gravatar link to the user page
>Failure/Error: Unable to find matching line from backtrace
>undefined local variable or method `example' for
> #
># /home/chatgris/.bundle/ruby/1.8/bundler/gems/rspec-
> rails-863ffee12bd6030ece577b07c39297c14aacad85-master/lib/rspec/rails/
> example/helper_example_group.rb:54:in `_controller_path'

I think this is the source of the problem. It looks like bundler is loading 
some version of rspec-rails other than the "2.0.0.beta.18" that is specified in 
the Gemfile.

What version of bundler are you using?


># /home/chatgris/.bundle/ruby/1.8/bundler/gems/rspec-
> rails-863ffee12bd6030ece577b07c39297c14aacad85-master/lib/rspec/rails/
> example/helper_example_group.rb:61
> 
> 
> Thanks for your help.
> ___
> rspec-users mailing list
> rspec-users@rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users

___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users

Re: [rspec-users] newbie: how to preserve NoMethodError under stubbing?

[David Chelimsky]

On Jul 24, 2010, at 4:35 AM, Wincent Colaiuta wrote:

> El 24/07/2010, a las 08:26, David Chelimsky escribió:
> 
>> On Fri, Jul 23, 2010 at 6:46 PM, Lille  wrote:
>>> Hi,
>>> 
>>> I've been browsing the RSpec book and the RDoc, but I can't see how to
>>> ensure the following:
>>> 
>>> Stub an instance with a method it doesn't have and raise NoMethodError
>>> (or something like it.)
>> 
>> RSpec doesn't support anything like that. I'm not sure if any of the
>> Ruby frameworks do, though I've been involved with conversations about
>> this sort of thing before.
> 
> I'm not sure if I understand the request, but with RR you can do this:
> 
>>> require 'rr'
> => true
>>> extend RR::Adapters::RRMethods
> => main
>>> foo = Object.new
> => #
>>> stub(foo).bar { raise NoMethodError }
> => #
>>> foo.bar
> NoMethodError: NoMethodError
> 
> Although like I said, not sure if I understood Lille's request.

I read the request as this:

class Foo
  def bar; end
end

f = Foo.new
f.stub(:barr)
#=> Error: "The Foo class does not have a 'barr' method. Perhaps you meant to 
stub 'bar'"

For me this would have very limited utility because 1/2 the time I'm 
deliberately stubbing methods that don't even exist yet on doubles doubling for 
objects that don't even exist yet, which is why I wouldn't want it to be 
something that happens implicitly by default.

Here's another thread on the same matter from a little over a year ago:

http://groups.google.com/group/rspec/browse_thread/thread/cf0b3eae192b9d8c/f5b77b008de628c7?lnk=gst&q=mock+audit#f5b77b008de628c7

Cheers,
David

> 
> Cheers,
> Wincent

___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users

Re: [rspec-users] [Rails] Stubbed static methods are bleeding over into other specs and making them fail

[David Chelimsky]

On Fri, Jul 23, 2010 at 7:29 PM, Patrick Gannon  wrote:
>> I just got a chance to try this, and ran into more problems.  Prior to
>> trying this, we were running RSpec2 beta 13.  When I changed our Gemfile to
>> depend on 'edge' RSpec et al (as you suggested above), I get a very strange
>> error when I run rake (after doing a 'bundle install').  The same error
>> occurs after I tell it specifically to use beta 16 (rather than 'edge').  It
>> seems to somehow not be able to find the bundler gem when it runs the main
>> bundler script from within rake:
>> C:/Ruby187/lib/ruby/site_ruby/1.8/rubygems.rb:779:in
>> `report_activate_error': Could not find RubyGem bundler (>= 0)
>> (Gem::LoadError)
>>         from C:/Ruby187/lib/ruby/site_ruby/1.8/rubygems.rb:214:in
>> `activate'
>>         from C:/Ruby187/lib/ruby/site_ruby/1.8/rubygems.rb:1082:in `gem'
>>         from C:/Ruby187/bin/bundle:18
>> rake aborted!
>> bundle exec  C:/Ruby187/bin/ruby.exe  -Ilib -Ispec
>> "./spec/controllers/discrepancies_controller_spec.rb" (...spec names
>> omitted..) failed
>> When I downgrade back to beta 13, everything works again.  I can't seem to
>> figure out why it wouldn't be able to find the bundler gem (since obviously
>> bundler is installed), so I cannot say whether or not your fix for the
>> stubbing issue solved my problem.  The stack trace (resulting from running
>> rake with "--trace") and my current list of installed gems (via "bundle
>> list") is here: http://gist.github.com/470278 (sorry for the line breaks)
>>
>> bundler-1.0.0.beta.4 should fix this. Please give it a shot.
>
> Ok, I upgraded to bundler 1.0 beta 9 and configured Gemfile to use edge
> RSpec et al (as recommended above).  After doing a 'bundle install', our
> tests failed (without trying to re-enable any of the mocking functionality
> originally mentioned).  It appears that now RSpec is trying to reference
> ActiveRecord, even though we're not using ActiveRecord.  (We specifically
> require each of the railties other than ActiveRecord in application.rb,
> rather than requiring rails/all.)  The error that rake produces is: Don't
> know how to build task 'db:test:prepare'.  I then went ahead and defined an
> empty rake task called db:test:prepare, and then got another error relating
> to ActiveRecord: uninitialized constant
> RSpec::Rails::FixtureSupport::ActiveRecord (NameError).  Stack trace is
> here: https://gist.github.com/acbaf0a384b301013140 (sorry for the formatting
> - copied/pasted from a DOS window).  I then tried to use RSpec 2.0 beta.16
> (rather than edge) and it skipped straight to the aforementioned error (even
> when db:test:prepare wasn't defined, it didn't complain about that).
> Thanks,
> Pat

OK - I believe I've fixed the ActiveRecord problem. Please try "bundle
install" again (make sure you get rspec-rails >=
83f2a44bfd31e7133248bba67bfe3ad89dc59b27.

HTH,
David
___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users

Re: [rspec-users] newbie: how to preserve NoMethodError under stubbing?

[David Chelimsky]

On Fri, Jul 23, 2010 at 6:46 PM, Lille  wrote:
> Hi,
>
> I've been browsing the RSpec book and the RDoc, but I can't see how to
> ensure the following:
>
> Stub an instance with a method it doesn't have and raise NoMethodError
> (or something like it.)

RSpec doesn't support anything like that. I'm not sure if any of the
Ruby frameworks do, though I've been involved with conversations about
this sort of thing before.

I wouldn't want behaviour like this myself unless it could be invoked
explicitly with a command line argument, but was otherwise off. In
other words, you could do something like:

  rspec spec --audit-stubbed-methods

And then that would generate some sort of report.

Feel free to submit a feature request to
http://github.com/rspec/rspec-mocks if you're interested in pursuing
such.

Cheers,
David


>
> I want to do this because I don't want to use incorrect names for my
> dependency methods...
>
> Thanks,
>
> Lille
> ___
> rspec-users mailing list
> rspec-users@rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>
___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users

Re: [rspec-users] Check out my shelves

[David Chelimsky]

On Fri, Jul 23, 2010 at 10:47 AM, Varchar  wrote:
> Hi rspec,
>
> Check out the books I added on Goodreads.

All, please do what you can to keep this sort of spam from coming to
this list. That means when you sign up for services and have them
email all your contacts, you need to make sure this list gets
excluded.

Cheers,
David
___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users

Re: [rspec-users] should_receive test unexpectedly failing

[David Chelimsky]

On Jul 22, 2010, at 10:48 AM, ericindc wrote:

> I'm unsure why this test is still failing.  I've tested it in console
> and the code works as expected.  Is there something wrong with how I
> have my test written?
> 
> ** error
> 
> 1) Job selecting the next job to be processed should lock the next job
>Failure/Error: job.should_receive(:update_attribute).with(:locked,
> true)
>(#).update_attribute(:locked, true)
>expected: 1 time
>received: 0 times
> 
> 
> ** job_spec.rb
> 
>it "should lock the next job" do
> job = Factory(:job, :locked => false)
> job.should_receive(:update_attribute).with(:locked, true)
> Job.next
>end
> 
> 
> ** job.rb
> 
>def self.next
>  job = incomplete.unlocked.prioritized.limit(1).first

This job object is not the same object as the on in the spec. To get this to 
work, you'd have to stub like so:

  Job.stub_chain(:incomplete, :unlocked, :prioritized, :limit).and_return(job)

Personally, I wouldn't bother, especially since you're using a real db backed 
object anyhow (Factory(:job ...)). I'd just write the spec like this:

job = Factory(:job, :locked => false)
job.next
job.should_not be_locked

Much cleaner and to the point, and less invasive (and therefore less brittle).

HTH,
David

>  job.lock! if job
>  job
>end
> 
>  def lock!
>update_attribute(:locked, true)
>  end
> 
>  def unlock!
>update_attribute(:locked, false)
>  end
> ___
> rspec-users mailing list
> rspec-users@rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users

___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users

Re: [rspec-users] spec w/o db:test:prepare

[David Chelimsky]

On Jul 21, 2010, at 3:32 PM, Peter Fitzgibbons wrote:
> On Tue, Jul 20, 2010 at 6:40 PM, David Chelimsky  wrote:
> On Jul 20, 2010, at 4:18 PM, Peter Fitzgibbons wrote:
> 
> > HI All,
> >
> > I would like to perform my spec runs without the db:test:prepare rake 
> > prereq.
> > It would be nice if I could alter spec to prereq db:test:purge only.
> >
> > Could you give me some advice/urls/pointers on how best to go about this?
> 
> Rake::Task[:spec].clear_prerequisites
> task :spec => ["db:test:purge"]

> How 'bout for rspec2?

Should work the same way.

> 
> BTW: Where should these magic lines be placed?  Inside a 
> ./config/initializers/my_init.rb ??

In any .rake file in lib/tasks (those should get loaded after the ones in the 
gems)___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users

Re: [rspec-users] spec w/o db:test:prepare

[David Chelimsky]

On Jul 21, 2010, at 4:17 PM, David Chelimsky wrote:

> On Jul 21, 2010, at 3:32 PM, Peter Fitzgibbons wrote:
>> On Tue, Jul 20, 2010 at 6:40 PM, David Chelimsky  
>> wrote:
>> On Jul 20, 2010, at 4:18 PM, Peter Fitzgibbons wrote:
>> 
>> > HI All,
>> >
>> > I would like to perform my spec runs without the db:test:prepare rake 
>> > prereq.
>> > It would be nice if I could alter spec to prereq db:test:purge only.
>> >
>> > Could you give me some advice/urls/pointers on how best to go about this?
>> 
>> Rake::Task[:spec].clear_prerequisites
>> task :spec => ["db:test:purge"]
> 
>> How 'bout for rspec2?
> 
> Should work the same way.
> 
>> 
>> BTW: Where should these magic lines be placed?  Inside a 
>> ./config/initializers/my_init.rb ??
> 
> In any .rake file in lib/tasks (those should get loaded after the ones in the 
> gems)

Also - there's no magic about these lines. Standard Ruby/rake - no 
metaprogramming, nothing mysterious. Just gotta know how Rake works.

___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users

Re: [rspec-users] 'its' not working

[David Chelimsky]

On Jul 21, 2010, at 10:09 AM, Andrew Premdas wrote:

> trying out new syntax from jon larkowski's rspec presentation. Following 
> doesn't work in that when I run the line from the command prompt or from 
> textmate no specs are run
> 
> 
>  context "cancel" do
> subject do
>   order = at_dropshipping
>   order.cancel_dropship!
>   order
> end
> 
> its(:status) { should == 'waiting_for_shipping' }  # doesn't work
>  end
> 
> spec --version rspec 1.3.0

Please post the entire spec in question, the command you are using to run it, 
and all of the output you are seeing when  you try to run it.

Thx

> 
> tia
> 
> Andrew

___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users

Re: [rspec-users] spec w/o db:test:prepare

[David Chelimsky]

On Jul 20, 2010, at 4:18 PM, Peter Fitzgibbons wrote:

> HI All,
> 
> I would like to perform my spec runs without the db:test:prepare rake prereq.
> It would be nice if I could alter spec to prereq db:test:purge only.
> 
> Could you give me some advice/urls/pointers on how best to go about this?

Rake::Task[:spec].clear_prerequisites
task :spec => ["db:test:purge"]

Cheers,
David

___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users

Re: [rspec-users] methods not available...

[David Chelimsky]

On Jul 20, 2010, at 1:07 PM, rogerdpack wrote:

> Hi all. Noticed that with rspec 1.x
> 
> methods at "higher levels" aren't available in lower, ex:
> 
> context "a" do
> def go
> end
> 
> it "should pass" do
>go
> end
> 
>  it "should pass again" do
>   context "a::b" do

You can't wrap contexts inside examples.

This should work:

describe "a" do
  def go; end
  context "b" do
it "should access go" do
  go
end
  end
end

HTH,
David

>  go
>   end
>  end
> 
> end
> 
> This surprised me a bit, making re-use of outer methods unavailable.
> Is it expected?
> 
> Thanks!
> -r
> ___
> rspec-users mailing list
> rspec-users@rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users

___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users

Re: [rspec-users] controller.should_receive(:render) problem

[David Chelimsky]

On Jul 12, 2010, at 4:18 AM, Ruprict wrote:

> Hi.
> 
> My issue is similar to the one in this post:
> http://groups.google.com/group/rspec/browse_thread/thread/973d770e45bdd6cd/8ba067476003f08f?lnk=gst&q=render+controller+should_receive#8ba067476003f08f
> 
> (which, btw, I could not reply to...only option was "Reply to Author")
> where I have a RESTful controller.  I want create to redirect/render
> the new action if the model fails to save with the supplied form
> values.  Pretty basic and typical stuff.
> 
> In Rails, if I use
> 
> redirect_to(new_my_model_path)
> 
> then the entered values along with the error_messages on the object
> are lost and I can't re-fill the form or list the errors.  If I use
> 
> render :action => "new"
> 
> then I keep all the request data and can use it to fill in form, etc.
> 
> In my spec, if I use
> 
> controller.should_receive(:render).with({:action=>"new"})
> 
> I get an expectation error that render is never called.  This is true
> if I remove the .with() as well.
> 
> If y'all could let me know either 1) Why my redirect_to vs render
> argument is flawed and/or 2) What I am doing wrong in the spec, I'd
> appreciate it.

Please post the code in the failing spec and the new action, along with the 
backtrace of the error you're getting.

Thx,
David

> 
> Thanks,
> Ruprict

___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users

Re: [rspec-users] "bundle exec rspec" vs "rake spec"

[David Chelimsky]

On Jul 19, 2010, at 7:51 AM, Jay wrote:

> I'm in the process of upgrading my rails app to rails 3 and I'm
> getting different results from running the 2 commands above.  The
> "bundle exec rspec" runs my tests correctly, but when I run "rake
> spec" it doesn't seem to do anything.  I get "0 examples, 0
> failures".  This is on version 2.0.0.beta.17 of rspec.  Any ideas on
> what I'm doing wrong?

Which beta version of rails are you on?

Make sure that you've removed lib/tasks/rspec.rake and that rspec-rails listed 
in the :development group in your Gemfile.

HTH,
David

> 
> Thanks,
> Jay

___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users

Re: [rspec-users] deprecate mock_model?

[David Chelimsky]

On Jul 19, 2010, at 7:47 PM, David Chelimsky wrote:

> Hey all,
> 
> I'm thinking of deprecating mock_model in rspec-rails-2. stub_model is more 
> stable, reliable (not dependent on Rails internals like mock_model is), much 
> less intrusive, and I find that I use it all the time in spite of the need to 
> create a real model to back it up.

I spoke to soon. Please disregard :)
___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users

[rspec-users] deprecate mock_model?

[David Chelimsky]

Hey all,

I'm thinking of deprecating mock_model in rspec-rails-2. stub_model is more 
stable, reliable (not dependent on Rails internals like mock_model is), much 
less intrusive, and I find that I use it all the time in spite of the need to 
create a real model to back it up.

Anybody attached to mock_model? If so, please make your case.

Cheers,
David
___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users

Re: [rspec-users] rspec2 help output has brackets?

[David Chelimsky]

On Jul 19, 2010, at 8:17 AM, rogerdpack wrote:

> Hi all.
> 
> Saw this:
> 
> Usage: rspec [options] [files or directories]
>-b, --backtrace  Enable full backtrace
>-c, --[no-]color, --[no-]colour  Enable color in the output
>-d, --debug  Enable debugging
>-e, --example PATTERNRun examples whose full
> descriptions match this pattern
> (PATTERN is compiled into a Ruby
> regular expression)
>-f, --format FORMATTER   Choose a formatter
>   [p]rogress (default - dots)
>   [d]ocumentation (group and
> example names)
>   [h]tml
>   [t]extmate
>   custom formatter class name
> 
> tried this:
> $ rspec -fp (for the [p] in [p]rogress)
> 
> got this:
> 
> Exception `ArgumentError' at c:/dev/ruby/downloads/jruby/lib/ruby/gems/
> 1.8/gems/rspec-core-2.0.0.beta.17/lib/rspec/core/configuration.rb:191
> - Formatter 'p' unknown - maybe you meant 'documentation' or
> 'progress'?.
> c:/dev/ruby/downloads/jruby/lib/ruby/gems/1.8/gems/rspec-
> core-2.0.0.beta.17/lib/rspec/core/configuration.rb:191:in
> `formatter=': Formatter 'p' unknown - maybe you meant 'documentation'
> or 'progress'?. (ArgumentError)
> 
> is this expected?

Nope. Bug. rspec-core bugs go here: http://github.com/rspec/rspec-core/issues

Thx,
David

> Thanks.
> -r

___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users

Re: [rspec-users] Data-wise context combination for controller speccing

[David Chelimsky]

On Jul 19, 2010, at 3:58 AM, Matt Wynne wrote:

> 
> On 18 Jul 2010, at 00:10, David Chelimsky wrote:
> 
>> On Jul 17, 2010, at 1:18 PM, Costa Shapiro wrote:
>> 
>>> Hello,
>>> 
>>> I've been thinking of how to express my idea in code, but since I've never 
>>> been involved in RSpec development, I'd better have some feedback here 
>>> first.
>>> The feature suggestion below applies to any controller-like code under 
>>> spec, i.e. a stateless module producing output or just altering its data 
>>> store (it doesn't necessarily have to be a C of the MVC, but I suppose 
>>> merb/rails developers will particularly appreciate it).
>>> 
>>> Here is a skimmed sample to illustrate the pain:
>>> 
>>> describe BookController do
>>> 
>>>   context "registering a book" do
>>> 
>>> specify "from a new author on a new subject" do
>>>   auth = mock(:name => 'John Doe')
>>>   Author.should_receive(:find_
>>> by_name).and_return(nil)
>>>   Author.should_receive(:new).and_return(auth)
>>>   auth.should_receive(:save).and_return(true)
>>> 
>>>   subj = mock(:short => 'Mockery')
>>>   Subject.should_receive(:find_by_short).and_return(nil)
>>>   Subject.should_receive(:new).and_return(subj)
>>>   subj.should_receive(:save).and_return(true)
>>> 
>>>   title = 'Specs on Steroids'
>>> 
>>>   book = mock
>>>   Book.should_receive(:new).and_return(book)
>>>   book.should_receive(:save).and_return(true)
>>> 
>>>   post :register :author => auth.name, :title => title, :subject => 
>>> subj.short
>>>   response.should be_success
>>> end
>>> 
>>> specify "from a known author on a new subject" do
>>>   auth = mock(:name => 'Joe Dohn')
>>>   Author.should_receive(:find_by_name).and_return(auth)
>>> 
>>>   subj = mock(:short => 'Mockery')
>>>   Subject.should_receive(:find_by_short).and_return(nil)
>>>   Subject.should_receive(:new).and_return(subj)
>>>   subj.should_receive(:save).and_return(true)
>>> 
>>>   title = 'Specs on Steroids II'
>>> 
>>>   book = mock
>>>   Book.should_receive(:new).and_return(book)
>>>   book.should_receive(:save).and_return(true)
>>> 
>>>   post :register :author => auth.name, :title => title, :subject => 
>>> subj.short
>>>   response.should be_success
>>> end
>>> 
>>> specify "from a known author on a known subject" do
>>>   auth = mock(:name => 'Joe Dohn')
>>>   Author.should_receive(:find_by_name).and_return(auth)
>>> 
>>>   subj = mock(:short => 'Forgery')
>>>   Subject.should_receive(:find_by_short).and_return(subj)
>>> 
>>>   #...
>>> end
>>> 
>>> specify "from a new author on a known subject" do
>>>   #...
>>> end
>>>   end
>>> end
>>> 
>>> 
>>> And this is what I have in mind for doing exactly the same job:
>>> 
>>> describe BookController do
>>> 
>>>   context "registering a book" do
>>> 
>>> before :any, "from a new author", :author do
>>>   @auth = mock(:name => 'John Doe')
>>>   Author.should_receive(:find_by_name).and_return(nil)
>>>   Author.should_receive(:new).and_return(@auth)
>>>   @auth.should_receive(:save).and_return(true)
>>> end
>>> 
>>> before :any, "from a known author", :author do
>>>   @auth = mock(:name => 'Joe Dohn')
>>>   Author.should_receive(:find_by_name).and_return(@auth)
>>> end
>>> 
>>> before :any, "on a new subject", :subject do
>>>   @subj = mock(:short => 'Mockery')
>>>   Subject.should_receive(:find_by_short).and