rspec / rspec-core Goto Github PK

Starting from rspec 2.0.0.beta.9 if instance variables are set in before(:all) then they are not available in after(:all). See example https://gist.github.com/52f61da8b461d6c8b8e7

In 2.0.0.beta.8 it is working fine. And it is issue just with after(:all), in after(:each) instance variables are visible.

This is quite critical as I was using instance variables to destroy test data in database that were created in before(:all).

The regexp given to Autotest for failed tests is wrong, and that causes Autotest to fire its "green" hook no matter the results of the test. I believe it also causes some more errors in Autotest's logic, but I'm not sure.

I believe the regexp is suppose to return a tuple of (class name, method name) for every test that fails. That's not possible with RSpec, as the individual tests have no name.

The offending file is, obviously, lib/autospec/rspec2.rb.

When subject.method return nil, its(:method) return the subject instead of nil to matcher.
Example: http://gist.github.com/422094

Thanks for your great work on RSpec 2!

None of these work in rspec-2, but they all do in rspec-1:

describe "something" do
  it "does something" do
    pending
    # ....
  end

  it "does something else" do
    pending "getting something fixed"
    # ...
  end

  it "does something else" do
    pending "getting something fixed" do
      # ...
    end
  end

While writing code I just got this failure:

1) Rspec::Core::Runner ::DRbProxy with server running integrates via #run
    Failure/Error: Rspec::Core::Runner.new.run(%W[ --drb --drb-port #{drb_port} --version ], @err, @out)
    private method `puts' called for nil:NilClass
    # /Users/ashleymoran/Dropbox/PatchSpace/Development/work-source/rspec/rspec-core/spec/rspec/core/runner_spec.rb:180:in `block (4 levels) in <top (required)>'

Which is not enough to isolate the problem directly. Using -b on the command line gives me what I need, but too much. What would be ideal is to have the spec line that caused the failure, and also the topmost library code line too. In this case it would be:

1) Rspec::Core::Runner ::DRbProxy with server running integrates via #run
    Failure/Error: Rspec::Core::Runner.new.run(%W[ --drb --drb-port #{drb_port} --version ], @err, @out)
    private method `puts' called for nil:NilClass
    # /Users/ashleymoran/Dropbox/PatchSpace/Development/work-source/rspec/rspec-core/lib/rspec/core/runner.rb:104:in `run'
    # /Users/ashleymoran/Dropbox/PatchSpace/Development/work-source/rspec/rspec-core/spec/rspec/core/runner_spec.rb:180:in `block (4 levels) in <top (required)>'

(Merb handles this really well in its error pages, and lets you configure where you see errors from - lib, gems, framework. I'm sure you could go to town with error reporting, but just the above change would be really useful, to me at least.)

AroundProxy is passed a instance of Example while it looks as though it should
receive an instance of ExampleGroup.

The example_block instance evaled in Example#run is instance evaled by an
ExampleGroup instance if no around eachs are given. When around eachs are
given it should probably do the same.

With the present behaviour the following works OK:

require "rubygems"
require 'rspec_sequel_matchers'

Rspec.configure do |c|
  c.include RspecSequel::Matchers
end

describe Foo do
  it { should validate_integer :id }
end

But this does not:

require "rubygems"
require 'rspec_sequel_matchers'

Rspec.configure do |c|
  c.include RspecSequel::Matchers
end

describe Foo do
  around(:each) do |example|
    DB.transaction { example.run ; raise Sequel::Error::Rollback }
  end
  it { should validate_integer :id }
end

It complains about validate_integer being an undefined method for
RSpec::Core::Example.

I have created a patch that fixes this, but due to my (lack) of understanding
of rspec's internals it may not be appropriate. It is available at http://github.com/benarmston/rspec-core/commit/f57284298f3199c670c72538c46c7aa5f69d6875

I located the bug with beta11 and then updated to beta12 to fix where upon I
saw the deprecation notice. So, I'm not sure how much you might want this.

Regarding the deprecation: I was using the around filter to run the specs in a
transaction like so:

around(:each) do |example|

DB.transaction { example.run ; raise Sequel::Error::Rollback }

end

The database library, Sequel, only provides access to a transaction via a
block form. Meaning that this couldn't be implemented with a before block and
a seperate after block. Am I misunderstanding the deprecation notice, or is
this form of hook no longer supported?

For what its worth, the method of doing this with rspec 1 was:

class Spec::Example::ExampleGroup

def execute(_args, &block)
DB.transaction{super(_args, &block); raise Sequel::Error::Rollback}
end

end

As ExampleGroup now has all of its methods as class methods, this method of
overriding and calling super is unlikely to work.

Regards,
Ben Armston

In configuration.rb's color_enabled= method, the use of Config::CONFIG['host_os'] in place of RUBY_PLATFORM breaks autotest:

$ autotest
~/.rvm/gems/ruby-1.9.2-head@rails3beta/gems/rspec-core-2.0.0.beta.12/lib/rspec/core/backward_compatibility.rb:26:in `const_missing': uninitialized constant RSpec::Core::Configuration::Config (NameError)
        from ~/.rvm/gems/ruby-1.9.2-head@rails3beta/gems/rspec-expectations-2.0.0.beta.12/lib/rspec/expectations/backward_compatibility.rb:6:in `const_missing'
        from ~/.rvm/gems/ruby-1.9.2-head@rails3beta/gems/rspec-core-2.0.0.beta.12/lib/rspec/core/configuration.rb:126:in `color_enabled='
        from ~/.rvm/gems/ruby-1.9.2-head@rails3beta/gems/rspec-core-2.0.0.beta.12/lib/rspec/core/configuration_options.rb:19:in `block in configure'
        from ~/.rvm/gems/ruby-1.9.2-head@rails3beta/gems/rspec-core-2.0.0.beta.12/lib/rspec/core/configuration_options.rb:18:in `each'
        from ~/.rvm/gems/ruby-1.9.2-head@rails3beta/gems/rspec-core-2.0.0.beta.12/lib/rspec/core/configuration_options.rb:18:in `configure'
        from ~/.rvm/gems/ruby-1.9.2-head@rails3beta/gems/rspec-core-2.0.0.beta.12/lib/rspec/core/command_line.rb:7:in `initialize'
        from ~/.rvm/gems/ruby-1.9.2-head@rails3beta/gems/rspec-core-2.0.0.beta.12/lib/rspec/core/runner.rb:35:in `new'
        from ~/.rvm/gems/ruby-1.9.2-head@rails3beta/gems/rspec-core-2.0.0.beta.12/lib/rspec/core/runner.rb:35:in `run_in_process'
        from ~/.rvm/gems/ruby-1.9.2-head@rails3beta/gems/rspec-core-2.0.0.beta.12/lib/rspec/core/runner.rb:26:in `run'
        from ~/.rvm/gems/ruby-1.9.2-head@rails3beta/gems/rspec-core-2.0.0.beta.12/lib/rspec/core/runner.rb:14:in `block in autorun'

Adding require 'rbconfig' to configuration.rb fixes the problem, but I don't know if that's the best solution.

describe "something" do
  it "does something" do
    running_example.metadata[:description].should eq("does something")
  end
  it "does something else", :description => "foo" do
    running_example.metadata[:description].should eq("does something else")
  end
end

The latter example fails with:

    expected "does something else"
    got "foo"

This is bad news. We should disallow passing keys that have internal meaning to describe() and it().

I wrote a bunch in here and clicked the "bug" label, which then wiped it. Really, this shit only happens to me.

So, as the title suggests, if the first file, alphabetically, is blank... Rspec silently kills itself, leaving friends, family and (most importantly) me heart broken and saddened [at the loss of a few hours].

I'm good at whining, but thank you for creating Rspec.

Rakefile :spec Task

desc "Run Unit Specs Only"
Rspec::Core::RakeTask.new(:spec) do |spec|
  spec.pattern = "spec/myproj/**/*_spec.rb"
end

Command-line Example

mbp:myproj aitrus$ ls -1 spec/myproj/
a_menace_spec.rb
bazzam_spec.rb
kablooey_spec.rb
mbp:myproj aitrus$ rake spec
(in /Users/aitrus/Development/myproj)
mbp:myproj aitrus$ mv spec/myproj/a_menace_spec.rb.rb spec/myproj/zomg_spec.rb
mbp:myproj aitrus$ ls -1 spec/myproj/
bazzam_spec.rb
kablooey_spec.rb
zomg_spec.rb
mbp:myproj aitrus$ rake spec
(in /Users/aitrus/Development/myproj)
........................


Finished in 3.4 seconds
24 examples, 0 failures
mbp:myproj aitrus$ mv spec/myproj/zomg_spec.rb spec/myproj/da_middle_spec.rb
mbp:myproj aitrus$ ls -1 spec/myproj/
bazzam_spec.rb
da_middle_spec.rb
kablooey_spec.rb
mbp:myproj aitrus$ rake spec
(in /Users/aitrus/Development/myproj)
........................


Finished in 3.4 seconds
24 examples, 0 failures
mbp:myproj aitrus$ mv spec/myproj/da_middle_spec.rb spec/myproj/arrrgh_spec.rb
mbp:myproj aitrus$ ls -1 spec/myproj/
arrrgh_spec.rb
bazzam_spec.rb
kablooey_spec.rb
mbp:myproj aitrus$ rake spec
(in /Users/aitrus/Development/myproj)
mbp:myproj aitrus$ 

This was introduced in beta 13. Given the following example:

describe "outer" do
  it "fails" do
    raise "fail"
  end

  describe "inner" do
    it "passes" do
    end
  end
end

The inner group's example will not be executed.

The good news is that if the example in the outer group passes, the one in the inner group runs, so there aren't really false positives at the suite level (i.e. if the outer one is failing, as soon as you get it passing the inner one is run, so any failures there would reveal themselves). Mostly this just becomes confusing when resolving an issue in an outer group exposes failing examples in the inner group.

Once #11 is implemented we should remove spec.opts.

rake spec currently shells out, which means double work loading up environments. It needs to shell out in certain situations (args to the ruby command, rcov, etc), but there are many in which it need not shell out. We should make it smarter, so it only shells out if necessary.

Calling subject inside the example_block should return a modified subject.

The first argument to its() should be a symbol representing a method name to be called on subject.

For example, the following should pass:

class Foo
  def bar; 'fizz'; end
end
describe Foo do
  its(:bar) { should == 'fizz' }
end

Accessing the subject in a before or after block should be on the implicit or explicit subject, NOT the modified subject. See https://rspec.lighthouseapp.com/projects/5645/tickets/975-update-to-subject-not-available-to-its

Hey, wondering if this was removed on purpose or if it was an oversight in the conversion to Rspec 2. Seems that some IDEs use the --require directive to load custom formatters to display progress in their own UI.

I can submit a patch if it should be implemented.

rspec-1 has autotest support in lib/autotest/rspec.rb. We need to add this to rspec-2

Helper specs get generated, but they are not really "helper specs" in that they offer no specific support yet for spec'ing helpers.

They need to:

• provide a helper object which, in rspec-rails-1, is an instance of ActionView::Base
• make sure the helper object has access to all of the rails helpers (link_to, url_for, etc)
• make sure the helper object includes the helper being spec'd, so its methods can be accessed

Given a ./spec directory, the rspec command could assume that it holds specs and run them without having to type "rspec spec".

As of 2.0.0.beta.2, you can access the running example's metadata hash from an example or before/after(:each). Let's support accessing it from before/after(:all) as well - at least at the example group level. e.g.

describe "something" do
  before(:all) do
    running_example_group.metadata[:foo] = 'bar'
  end
  it "does something" do
    running_example.metadata[:example_group][:foo].should eq('bar")
    # or
    running_example_group.metadata[:foo].should eq("bar")
  end
end

CustomFormatter with options: --require custom_formatter.rb --format CustomFormatter is broken.

here is a patch: http://github.com/thibaudgg/rspec-core/commit/9b9b7cc1077e6e679d9a79560e2d39685880870e

Seems good?

I'm using rspec-core from master and I have following spec:

describe "foo" do
  before(:all) { do_sth }
  context "some" do
    it "should do barrr" do
      some should expectation
    end
  end
end

do_sth is never called. It started happening somewhere around 7th May.

This was suggested for cucumber, and it would also be nice for RSpec as well.

Here's the cuke discussion
http://groups.google.com/group/cukes/browse_thread/thread/acf19d76cfdbfdb7

It would be nice if the option names were coordinated, which is why I'm not submiting this a s patch.

Given a file like this:

describe "something" do
  it "does something" do
    # ....
  end
end

... you specify lines 1 or 2 and the example will run, but not if you specify line 3. In rspec-1 you can specify any line in the example.

With this spec

describe "something" do
 raise 'an error'
end

I get this output:

1) can create cache file apropo should be able to create a cache file
    Failure/Error: Unable to find matching line from backtrace
    bad
    # spec.can_create_cache_file.rb:27:in `block (2 levels) in '

http://github.com/rspec/rspec-core/blob/master/lib/rspec/core/formatters/base_formatter.rb#L118

ref: http://groups.google.com/group/rspec/browse_thread/thread/2dda93cd2c0b484b

2.0.0.beta.12

Running 'rake spec' with '--debug' in my .rspec file will produce:

"debugger statement ignored, use -d or --debug option on rspec to enable debugging"

Same thing when running 'rspec -d ./spec'

Running 'rdebug rspec ./spec' works ok.

Thanks!

-f option doesn't work with fully qualified formatter classes names.

E.g. if my formatter named "Spec::Runner::Formatter::TeamcityFormatter" then on run-time I get exception like this:
/Users/romeo/work/git/rspec-dev/repos/rspec-core/lib/rspec/core/configuration.rb:172:in const_defined?': wrong constant name Spec::Runner::Formatter::TeamcityFormatter (NameError) from /Users/romeo/work/git/rspec-dev/repos/rspec-core/lib/rspec/core/configuration.rb:172:informatter='
from /Users/romeo/work/git/rspec-dev/repos/rspec-core/lib/rspec/core/configuration_options.rb:22:in send' from /Users/romeo/work/git/rspec-dev/repos/rspec-core/lib/rspec/core/configuration_options.rb:22:inconfigure'
from /Users/romeo/work/git/rspec-dev/repos/rspec-core/lib/rspec/core/configuration_options.rb:21:in each' from /Users/romeo/work/git/rspec-dev/repos/rspec-core/lib/rspec/core/configuration_options.rb:21:inconfigure'
from /Users/romeo/work/git/rspec-dev/repos/rspec-core/lib/rspec/core/command_line.rb:11:in initialize' from /Users/romeo/work/git/rspec-dev/repos/rspec-core/lib/rspec/core/runner.rb:46:innew'
from /Users/romeo/work/git/rspec-dev/repos/rspec-core/lib/rspec/core/runner.rb:46:in run_in_process' from /Users/romeo/work/git/rspec-dev/repos/rspec-core/lib/rspec/core/runner.rb:37:inrun'
from /Users/romeo/work/git/rspec-dev/repos/rspec-core/lib/rspec/core/runner.rb:22

Problem occurs because "Object.const_defined?(formatter_to_use)" understands only simple constants without namespace. I'll attach a patch soon.

Add an option to the rspec command to configure a project directory for autotest, and eliminate the autospec command. Something like:

rspec --configure autotest

This would generate autotest/discover.rb, which would tell autotest that this is an rspec project.

Noticed that your documentation failed to build on rdoc.info (noticed a similar problem with the expectations project too). The reason is that your .document file incorrectly lists a README.rdoc file for inclusion, and that file doesn't actually exist. I'd suggest changing the line in .document to README.markdown and give it another shot at generating. Should fix it. If not, let me know and I'll be happy to help.

When including module within ExampleGroup then constants from that module should be accessible directly without specifying module name:

module MyModule 
  MyConstant = 1 
  
  def my_method 
    2 
  end 
end 

describe "including modules" do 
  include MyModule 

  it "works" do 
    my_method.should == 2 
    MyModule::MyConstant.should == 1 
  end 

  it "doesn't work, but should" do 
    MyConstant.should == 1 
  end 
end 

Running this simple spec will produce one failure with this message:

1) 
NameError in 'including modules doesn't work' 
uninitialized constant MyConstant

But in regular Ruby everything works as expected:

class MyClass
  include MyModule

  def initialize
    p my_method
    p MyModule::MyConstant
    p MyConstant
  end
end

MyClass.new # produces 2 1 1

Check this out:

http://gist.github.com/432864

It fails, and it shouldn't. Or maybe behavior of before(:all) changed slightly recently?

/Library/Ruby/Gems/1.8/gems/rspec-core-2.0.0.beta.8/lib/rspec/core/shared_example_group.rb:33:in `ensure_shared_example_group_name_not_taken':
Shared example group 'Some group' already exists (ArgumentError)

This only occurs if running multiple specs where the file is required.

I'm trying to use Steak and Capybara to run some scenarios using a JavaScript-capable backend (Culerity) and others using the standard rack_test backend.

In Cucumber this was done using tags, but with Steak and RSpec 1.3 I'm told you can do something like this:

scenario 'foo', :js => true do
  # ... this one runs under culerity
end

scenario 'bar' do
  # ... this one runs under rack_test
end

This is enabled by this config:

Spec::Runner.configure do |config|    
  config.before :each do
    Capybara.current_driver = :culerity if options[:js]
  end

  config.after :each do
    Capybara.use_default_driver if options[:js]
  end
end

Under RSpec 2 this trick won't work; it seems that "options" isn't available in the scope of these before/after config blocks. I've been able to dig out the options via some very ugly "instance_variable_get" inspection:

RSpec.configure do |config|
  config.before :each do
    if self.running_example.instance_variable_get(:@options)[:js]
      Capybara.current_driver = :culerity
    end
  end

  config.after :each do
    if self.running_example.instance_variable_get(:@options)[:js]
      Capybara.use_default_driver
    end
  end
end

So this ticket is about getting access to the arbitrary metadata that can be passed in to "describe" and "it" blocks via the options hash.

Note that in the use case I'm talking about above, using the "filter_run" stuff won't give me what I want (that's for selecting a subset of the examples to run, but I want to run all of the examples, but switch Capybara drivers on the fly).

What do you think about providing access to the options via an accessor?

I've noticed that I can get at the options passed in to the RSpec::Core::Example subclass; ie:

it "should foo", :stuff => true do
  ...
end

But I can't seem to get at the stuff passed in to the RSpec::Core::ExampleGroup subclass; ie:

describe "foo", :thing => true do
  ...
end

In practice I don't really care too much about access to that metadata, because I want to switch drivers on a per-scenario basis (ie. at the "it/scenario" level). But if you agree to making the metadata available at that level, I guess it makes sense to make the metadata at the "describe/feature" level available too.

What do you think?

If I can get a "green light" on the idea I'm happy to put a patch together.

Cheers,
Wincent

Current master (post-beta.13, pre-beta.13) supports an around hook in an example group, which allows you to do stuff like this:

describe Something do
  around do |example|
    Sequel::Model.db.transaction { example.run }
  end
end

We need to make this available globally as well. Something like:

RSpec.configure do |c|
  c.around do |example|
    Sequel::Model.db.transaction { example.run }
  end
end

title says it all :)

I created a scaffold in Rails 3 beta 4 and I get an error on the generated view index test:

Failure/Error: rendered.should have_selector("tr>td", :content => "MyString".to_s, :count => 2)
expected following output to contain a td>MyStringtd> tag:

It should be looking for MyString and not td>MyStringtd>.

My Gemfile contains this:

gem 'rails', '3.0.0.beta4'
group :test do
gem 'capybara'
gem 'database_cleaner'
gem 'cucumber-rails'
gem 'cucumber'
gem "rspec-rails", ">= 2.0.0.beta.12"
gem "rspec", ">= 2.0.0.beta.12"
gem 'webrat'
gem 'spork'
gem 'launchy'
gem 'ZenTest'
gem 'autotest-rails'
gem 'autotest-growl'
end

 %  rspec transactional_database_support_spec.rb 
/Users/sulky/.rvm/gems/ruby-1.9.2-head/gems/rspec-core-2.0.0.beta.8/lib/rspec/core/configuration.rb:230:in `require': no such file to load -- transactional_database_support_spec.rb (LoadError)
        from /Users/sulky/.rvm/gems/ruby-1.9.2-head/gems/rspec-core-2.0.0.beta.8/lib/rspec/core/configuration.rb:230:in `block in require_files_to_run'
        from /Users/sulky/.rvm/gems/ruby-1.9.2-head/gems/rspec-core-2.0.0.beta.8/lib/rspec/core/configuration.rb:230:in `map'
        from /Users/sulky/.rvm/gems/ruby-1.9.2-head/gems/rspec-core-2.0.0.beta.8/lib/rspec/core/configuration.rb:230:in `require_files_to_run'
        from /Users/sulky/.rvm/gems/ruby-1.9.2-head/gems/rspec-core-2.0.0.beta.8/lib/rspec/core/runner.rb:42:in `configure'
        from /Users/sulky/.rvm/gems/ruby-1.9.2-head/gems/rspec-core-2.0.0.beta.8/lib/rspec/core/runner.rb:28:in `run'
        from /Users/sulky/.rvm/gems/ruby-1.9.2-head/gems/rspec-core-2.0.0.beta.8/lib/rspec/core/runner.rb:12:in `block in autorun'

% ruby -v                    
ruby 1.9.2dev (2010-05-18 revision 27873) [x86_64-darwin10.2.0]

Ruby1.9.2: current_path( . ) is deleted from $LOAD_PATH
I fixed.
http://github.com/hasimo/rspec-core/commit/c8ce7716ccbac1b94353ed43d0ae50cface06225

Just added use_transactional_examples? config option to support an rspec-rails story. This really doesn't belong in rspec-core, but right now rspec-core doesn't offer a better way for rspec-rails to add its own config options.

Add support for something like .rspecconfig or .rspecrc in the home and project directories, override-able on the command line.

I'm on leopard

If I comment out line 340 in rcov, then it works:

Zlib::GzipReader.open(file){|gz| old_data = Marshal.load(gz) }

stack trace below:

[coreyhaines: rspec-core (master)]$ rake cucumber
(in /Users/coreyhaines/Documents/projects/rspec2/rspec-dev/repos/rspec-core)
/Users/coreyhaines/.rvm/rubies/ruby-1.8.7-p249/bin/ruby -I "/Users/coreyhaines/.rvm/gems/ruby-1.8.7-p249/gems/cucumber-0.6.4/lib:lib" -S rcov -Ilib -Ispec --exclude "mocks,expectations,gems/,features,spec/ruby_forker,spec/rspec,spec/resources,spec/lib,spec/spec_helper.rb,db/,/Library/Ruby/,config/" --text-report --sort coverage --aggregate coverage.data "/Users/coreyhaines/.rvm/gems/ruby-1.8.7-p249/gems/cucumber-0.6.4/bin/cucumber" -- --format progress
/Users/coreyhaines/.rvm/gems/ruby-1.8.7-p249/gems/rcov-0.9.8/bin/rcov:340: [BUG] Segmentation fault
ruby 1.8.7 (2010-01-10 patchlevel 249) [i686-darwin9.8.0]

If I comment out line 340 in rcov, it works:

Zlib::GzipReader.open(file){|gz| old_data = Marshal.load(gz) }

Stack trace below:

/Users/coreyhaines/.rvm/rubies/ruby-1.8.7-p249/bin/ruby -I "/Users/coreyhaines/.rvm/gems/ruby-1.8.7-p249/gems/cucumber-0.6.4/lib:lib" -S rcov -Ilib -Ispec --exclude "mocks,expectations,gems/,features,spec/ruby_forker,spec/rspec,spec/resources,spec/lib,spec/spec_helper.rb,db/,/Library/Ruby/,config/" --text-report --sort coverage --aggregate coverage.data "/Users/coreyhaines/.rvm/gems/ruby-1.8.7-p249/gems/cucumber-0.6.4/bin/cucumber" -- --format progress
/Users/coreyhaines/.rvm/gems/ruby-1.8.7-p249/gems/rcov-0.9.8/bin/rcov:340: warning: getc is obsolete; use STDIN.getc instead

Add a --drb command line switch with an option for specifying port.

It is not currently possible to use a helper method in both the subject block and an it/specify block. e.g.

describe "Foo" do
  def my_helper
    MyClass
  end

  subject { my_helper.new }
  specify { my_helper.should do_something }
end

This code gives undefined method `my_helper' for #Rspec::Core::ExampleGroup... as the subject block is being evaluated in the context of the ExampleGroup class.

If an explicit subject is specified, it should be evaluated in the context of the ExampleGroup instance (this was the case for rspec-1).

rspec-2 seems to work w/ jruby, but there is some sort of load path problem running rspec-core-2's cukes against jruby (using rvm):

$ ruby -S cucumber features/command_line/example_name_option.feature:44
Using the default profile...

...

      expected: /1\ example,\ 0\ failures/,
           got: "\n----------------------------------------------------------------------\n/Users/dchelimsky/projects/rspec2/repos/rspec-core/lib/rspec/core.rb:46:in `require': no such file to load -- rspec/expectations (LoadError)\n\tfrom /Users/dchelimsky/projects/rspec2/repos/rspec-core/lib/rspec/core.rb:46\n\tfrom /Users/dchelimsky/projects/rspec2/repos/rspec-core/lib/rspec/core.rb:1:in `require'\n\tfrom /Users/dchelimsky/projects/rspec2/repos/rspec-core/lib/rspec/autorun.rb:1\n\tfrom /Users/dchelimsky/projects/rspec2/repos/rspec-core/lib/rspec/autorun.rb:2:in `require'\n\tfrom /Users/dchelimsky/projects/rspec2/repos/rspec-core/tmp/aruba/../../bin/rspec:2\n" (using =~) (Rspec::Expectations::ExpectationNotMetError)
      features/command_line/example_name_option.feature:46:in `Then I should see "1 example, 0 failures"'

Ruby 1.9.2 removed current directory (".") from $LOAD_PATH and rspec can't load the files given on the command line.

We can change our loading behavior to expand path to absolute path when requiring files (I've did that in my fork here: http://github.com/sickill/rspec-core/commit/ebcb95546fadb5b50b5e5e2e3128ff8aa01ed9a7).

If you feel this is "obscure workaround" then let's discuss other possible solutions.