Myron Marston myronmarston


    
    View why_expect_arg_vs_block.md 
  
  
    File suppressed. Click to show.
  
  
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 
  
  
    File suppressed. Click to show.
  
  
            1
            2
            3
            4
          
          
            source "https://rubygems.org"
 
gem 'rspec-core', "~> 3.1.7"
gem 'allocation_stats'

          
    View response.md 
  
  
    File suppressed. Click to show.
  
  
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 
  
  
    File suppressed. Click to show.
  
  
            1
            2
            3
            4
            5
            6
            7
            8
            9
            10
          
          
            Using `an_error_other_than` as an argument to `raise_error`
  failing (FAILED - 1)
  passing
 
Failures:
 
  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 
  
  
    File suppressed. Click to show.
  
  
            1
            2
            3
            4
          
          
            # A sample Gemfile
source "https://rubygems.org"
 
gem 'rspec', '~> 2.14.0'

          
    View slash_vs_plus_string.rb 
  
  
    File suppressed. Click to show.
  
  
            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."

          
    View explanation.md 
  
  
    File suppressed. Click to show.
  
  
        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 
  
  
    File suppressed. Click to show.
  
  
            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)
end
 
# 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 
  
  
    File suppressed. Click to show.
  
  
            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 
  
  
    File suppressed. Click to show.
  
  
            1
            2
            3
            4
            5
            6
          
          
            # A sample Gemfile
source "https://rubygems.org"
 
gem 'rspec',   '~> 3.0'
gem 'vcr',     '~> 2.9'
gem 'webmock', '~> 1.20'