Haven't dived into RSpec but is it not possible for expect to accept either args or blocks, and process them internally?

First off, expect does accept either an arg or a block already. But if it's a block (or a proc/lambda arg), expect does not call the block automatically -- it just passes the block to the matcher and allows the matcher to call it if it wants. This is necessary because some matchers (the block matchers like raise_error, change, etc) must wrap the block in some extra logic to work properly because they deal in side effects, not expression return values.

View Gemfile-3-1
1 2 3 4
source ""
gem 'rspec-core', "~> 3.1.7"
gem 'allocation_stats'

I highly suspect that the RSpec core team all use black backgrounds in their terminals because sometimes the colors aren’t so nice on my white terminal

I certainly use a black background. I'm not sure about the other RSpec core folks. Regardless, if there are some color changes we can make that would make output look good on a larger variety of backgrounds, we'll certainly consider that (do you have some suggested changes?). In the meantime, the colors are configurable, so you can change the colors to fit your preferences on your machine. First, create a file at

View output
1 2 3 4 5 6 7 8 9 10
Using `an_error_other_than` as an argument to `raise_error`
failing (FAILED - 1)
1) Using `an_error_other_than` as an argument to `raise_error` failing
Failure/Error: expect {
expected an error other than SyntaxError, got #<SyntaxError: SyntaxError> with backtrace:
# ./spec/raise_error_spec.rb:12:in `block (3 levels) in <top (required)>'
View Gemfile-2-14
1 2 3 4
# A sample Gemfile
source ""
gem 'rspec', '~> 2.14.0'
View slash_vs_plus_string.rb
1 2 3 4 5 6 7 8 9 10
require 'benchmark/ips'
require 'allocation_stats'
def access_slashed_string
"Lorem ipsum dolor sit amet, consectetur adipiscing elit. Duis molestie " \
"elementum urna, a accumsan nunc euismod et. Aliquam porttitor, leo in " \
"aliquet aliquam, magna quam venenatis nulla, vel sagittis nisi nisi et " \
"nulla. Nulla quis facilisis turpis, vel blandit risus. Maecenas ut ante " \
"quis velit pretium pharetra ac rhoncus massa. Nulla quam dui, placerat " \
"eget quam vel, ultricies eleifend sem."

The reason for this is that do...end blocks bind at a different precedence level than {...} blocks. Consider this expression:

expect { foo }.to change { x }

The { x } block binds to change, and is passed as a block to that method. However, if you use do...end:

expect { foo }.to change do
View arg_matching_with_a_block.rb
1 2 3 4 5 6 7 8 9
# you can pass an implementation block, and use expectations in the block:
expect(MyClass).to receive(:method) do |arg_1, arg_2|
expect(arg_1).to eq(2)
expect(arg_2).to eq(3)
# or you can wrap any block in the `satisfy` (also aliased to `an_object_satisfying`) to turn it into a matcher:
expect(MyClass).to receive(:method).with(an_object_satisfying { |arg| arg.even? })
View Rakefile
1 2 3 4 5 6 7 8 9 10
require 'pathname'
HOME_DIR = Pathname("~").expand_path
def symlink_files_for_dir(to_symlink)
to_symlink = to_symlink.expand_path
to_symlink_root = Pathname("./to_symlink").expand_path
to_symlink.children.each do |child|
relative = child.relative_path_from(to_symlink_root)
symlink = HOME_DIR + ".#{relative}"
View Gemfile
1 2 3 4 5 6
# A sample Gemfile
source ""
gem 'rspec', '~> 3.0'
gem 'vcr', '~> 2.9'
gem 'webmock', '~> 1.20'
Something went wrong with that request. Please try again.