rspec-expectations 2.14.0 → 3.13.0

data/features/built_in_matchers/operators.feature

@@ -1,227 +0,0 @@
-Feature: operator matchers
-
-  RSpec provides a number of matchers that are based on Ruby's built-in
-  operators. These pretty much work like you expect. For example, each of these
-  pass:
-
-    ```ruby
-    7.should == 7
-    [1, 2, 3].should == [1, 2, 3]
-    "this is a string".should =~ /^this/
-    "this is a string".should_not =~ /^that/
-    String.should === "this is a string"
-    ```
-
-  You can also use comparison operators combined with the "be" matcher like
-  this:
-
-    ```ruby
-    37.should be < 100
-    37.should be <= 38
-    37.should be >= 2
-    37.should be > 7
-    ```
-
-  RSpec also provides a `=~` matcher for arrays that disregards differences in
-  the ording between the actual and expected array.  For example:
-
-    ```ruby
-    [1, 2, 3].should =~ [2, 3, 1] # pass
-    [:a, :c, :b].should =~ [:a, :c] # fail
-    ```
-
-  Scenario: numeric operator matchers
-    Given a file named "numeric_operator_matchers_spec.rb" with:
-      """ruby
-      describe 18 do
-        it { should == 18 }
-        it { should be < 20 }
-        it { should be > 15 }
-        it { should be <= 19 }
-        it { should be >= 17 }
-
-        it { should_not == 28 }
-
-        # deliberate failures
-        it { should == 28 }
-        it { should be < 15 }
-        it { should be > 20 }
-        it { should be <= 17 }
-        it { should be >= 19 }
-
-        it { should_not == 18 }
-      end
-      """
-     When I run `rspec numeric_operator_matchers_spec.rb`
-     Then the output should contain "12 examples, 6 failures"
-      And the output should contain:
-      """
-           Failure/Error: it { should == 28 }
-             expected: 28
-                  got: 18 (using ==)
-      """
-      And the output should contain:
-      """
-           Failure/Error: it { should be < 15 }
-             expected: < 15
-                  got:   18
-      """
-      And the output should contain:
-      """
-           Failure/Error: it { should be > 20 }
-             expected: > 20
-                  got:   18
-      """
-      And the output should contain:
-      """
-           Failure/Error: it { should be <= 17 }
-             expected: <= 17
-                  got:    18
-      """
-      And the output should contain:
-      """
-           Failure/Error: it { should be >= 19 }
-             expected: >= 19
-                  got:    18
-      """
-      And the output should contain:
-      """
-           Failure/Error: it { should_not == 18 }
-             expected not: == 18
-                      got:    18
-      """
-
-  Scenario: string operator matchers
-    Given a file named "string_operator_matchers_spec.rb" with:
-      """ruby
-      describe "Strawberry" do
-        it { should == "Strawberry" }
-        it { should be < "Tomato" }
-        it { should be > "Apple" }
-        it { should be <= "Turnip" }
-        it { should be >= "Banana" }
-        it { should =~ /berry/ }
-
-        it { should_not == "Peach" }
-        it { should_not =~ /apple/ }
-
-        it "reports that it is a string using ===" do
-          String.should === subject
-        end
-
-        # deliberate failures
-        it { should == "Peach" }
-        it { should be < "Cranberry" }
-        it { should be > "Zuchini" }
-        it { should be <= "Potato" }
-        it { should be >= "Tomato" }
-        it { should =~ /apple/ }
-
-        it { should_not == "Strawberry" }
-        it { should_not =~ /berry/ }
-
-        it "fails a spec asserting that it is a symbol" do
-          Symbol.should === subject
-        end
-      end
-      """
-     When I run `rspec string_operator_matchers_spec.rb`
-     Then the output should contain "18 examples, 9 failures"
-      And the output should contain:
-      """
-           Failure/Error: it { should == "Peach" }
-             expected: "Peach"
-                  got: "Strawberry" (using ==)
-      """
-      And the output should contain:
-      """
-           Failure/Error: it { should be < "Cranberry" }
-             expected: < "Cranberry"
-                  got:   "Strawberry"
-      """
-      And the output should contain:
-      """
-           Failure/Error: it { should be > "Zuchini" }
-             expected: > "Zuchini"
-                  got:   "Strawberry"
-      """
-      And the output should contain:
-      """
-           Failure/Error: it { should be <= "Potato" }
-             expected: <= "Potato"
-                  got:    "Strawberry"
-      """
-      And the output should contain:
-      """
-           Failure/Error: it { should be >= "Tomato" }
-             expected: >= "Tomato"
-                  got:    "Strawberry"
-      """
-      And the output should contain:
-      """
-           Failure/Error: it { should =~ /apple/ }
-             expected: /apple/
-                  got: "Strawberry" (using =~)
-      """
-      And the output should contain:
-      """
-           Failure/Error: it { should_not == "Strawberry" }
-             expected not: == "Strawberry"
-                      got:    "Strawberry"
-      """
-      And the output should contain:
-      """
-           Failure/Error: it { should_not =~ /berry/ }
-             expected not: =~ /berry/
-                      got:    "Strawberry"
-      """
-      And the output should contain:
-      """
-           Failure/Error: Symbol.should === subject
-             expected: "Strawberry"
-                  got: Symbol (using ===)
-      """
-
-  Scenario: array operator matchers
-    Given a file named "array_operator_matchers_spec.rb" with:
-      """ruby
-      describe [1, 2, 3] do
-        it { should == [1, 2, 3] }
-        it { should_not == [1, 3, 2] }
-
-        it { should =~ [1, 2, 3] }
-        it { should =~ [1, 3, 2] }
-        it { should =~ [2, 1, 3] }
-        it { should =~ [2, 3, 1] }
-        it { should =~ [3, 1, 2] }
-        it { should =~ [3, 2, 1] }
-
-        # deliberate failures
-        it { should_not == [1, 2, 3] }
-        it { should == [1, 3, 2] }
-        it { should =~ [1, 2, 1] }
-      end
-      """
-     When I run `rspec array_operator_matchers_spec.rb`
-     Then the output should contain "11 examples, 3 failures"
-      And the output should contain:
-      """
-           Failure/Error: it { should_not == [1, 2, 3] }
-             expected not: == [1, 2, 3]
-                      got:    [1, 2, 3]
-      """
-      And the output should contain:
-      """
-           Failure/Error: it { should == [1, 3, 2] }
-             expected: [1, 3, 2]
-                  got: [1, 2, 3] (using ==)
-      """
-      And the output should contain:
-      """
-           Failure/Error: it { should =~ [1, 2, 1] }
-             expected collection contained:  [1, 1, 2]
-             actual collection contained:    [1, 2, 3]
-             the missing elements were:      [1]
-             the extra elements were:        [3]
-      """
-

data/features/built_in_matchers/predicates.feature

@@ -1,137 +0,0 @@
-Feature: predicate matchers
-
-  Ruby objects commonly provide predicate methods:
-
-    ```ruby
-    7.zero?                  # => false
-    0.zero?                  # => true
-    [1].empty?               # => false
-    [].empty?                # => true
-    { :a => 5 }.has_key?(:b) # => false
-    { :b => 5 }.has_key?(:b) # => true
-    ```
-
-  You could use a basic equality matcher to set expectations on these:
-
-    ```ruby
-    7.zero?.should == true # fails with "expected true, got false (using ==)"
-    ```
-
-  ...but RSpec provides dynamic predicate matchers that are more readable and
-  provide better failure output.
-
-  For any predicate method, RSpec gives you a corresponding matcher.  Simply
-  prefix the method with `be_` and remove the question mark.  Examples:
-
-    ```ruby
-    7.should_not be_zero       # calls 7.zero?
-    [].should be_empty         # calls [].empty?
-    x.should be_multiple_of(3) # calls x.multiple_of?(3)
-    ```
-
-  Alternately, for a predicate method that begins with `has_` like
-  `Hash#has_key?`, RSpec allows you to use an alternate form since `be_has_key`
-  makes no sense.
-
-    ```ruby
-    hash.should have_key(:foo)       # calls hash.has_key?(:foo)
-    array.should_not have_odd_values # calls array.has_odd_values?
-    ```
-
-  In either case, RSpec provides nice, clear error messages, such as:
-
-    `expected zero? to return true, got false`
-
-  Any arguments passed to the matcher will be passed on to the predicate method.
-
-  Scenario: should be_zero (based on Fixnum#zero?)
-    Given a file named "should_be_zero_spec.rb" with:
-      """ruby
-      describe 0 do
-        it { should be_zero }
-      end
-
-      describe 7 do
-        it { should be_zero } # deliberate failure
-      end
-      """
-    When I run `rspec should_be_zero_spec.rb`
-    Then the output should contain "2 examples, 1 failure"
-     And the output should contain "expected zero? to return true, got false"
-
-  Scenario: should_not be_empty (based on Array#empty?)
-    Given a file named "should_not_be_empty_spec.rb" with:
-      """ruby
-      describe [1, 2, 3] do
-        it { should_not be_empty }
-      end
-
-      describe [] do
-        it { should_not be_empty } # deliberate failure
-      end
-      """
-    When I run `rspec should_not_be_empty_spec.rb`
-    Then the output should contain "2 examples, 1 failure"
-     And the output should contain "expected empty? to return false, got true"
-
-   Scenario: should have_key (based on Hash#has_key?)
-    Given a file named "should_have_key_spec.rb" with:
-      """ruby
-      describe Hash do
-        subject { { :foo => 7 } }
-        it { should have_key(:foo) }
-        it { should have_key(:bar) } # deliberate failure
-      end
-      """
-    When I run `rspec should_have_key_spec.rb`
-    Then the output should contain "2 examples, 1 failure"
-     And the output should contain "expected #has_key?(:bar) to return true, got false"
-
-   Scenario: should_not have_all_string_keys (based on custom #has_all_string_keys? method)
-     Given a file named "should_not_have_all_string_keys_spec.rb" with:
-       """ruby
-       class Hash
-         def has_all_string_keys?
-           keys.all? { |k| String === k }
-         end
-       end
-
-       describe Hash do
-         context 'with symbol keys' do
-           subject { { :foo => 7, :bar => 5 } }
-           it { should_not have_all_string_keys }
-         end
-
-         context 'with string keys' do
-           subject { { 'foo' => 7, 'bar' => 5 } }
-           it { should_not have_all_string_keys } # deliberate failure
-         end
-       end
-       """
-     When I run `rspec should_not_have_all_string_keys_spec.rb`
-     Then the output should contain "2 examples, 1 failure"
-      And the output should contain "expected #has_all_string_keys? to return false, got true"
-
-   Scenario: matcher arguments are passed on to the predicate method
-     Given a file named "predicate_matcher_argument_spec.rb" with:
-       """ruby
-       class Fixnum
-         def multiple_of?(x)
-           (self % x).zero?
-         end
-       end
-
-       describe 12 do
-         it { should be_multiple_of(3) }
-         it { should_not be_multiple_of(7) }
-
-         # deliberate failures
-         it { should_not be_multiple_of(4) }
-         it { should be_multiple_of(5) }
-       end
-       """
-     When I run `rspec predicate_matcher_argument_spec.rb`
-     Then the output should contain "4 examples, 2 failures"
-      And the output should contain "expected multiple_of?(4) to return false, got true"
-      And the output should contain "expected multiple_of?(5) to return true, got false"
-

data/features/built_in_matchers/respond_to.feature

@@ -1,84 +0,0 @@
-Feature: respond_to matcher
-
-  Use the respond_to matcher to specify details of an object's interface.  In
-  its most basic form:
-
-    ```ruby
-    obj.should respond_to(:foo) # pass if obj.respond_to?(:foo)
-    ```
-
-  You can specify that an object responds to multiple messages in a single
-  statement with multiple arguments passed to the matcher:
-
-    ```ruby
-    obj.should respond_to(:foo, :bar) # passes if obj.respond_to?(:foo) && obj.respond_to?(:bar)
-    ```
-
-  If the number of arguments accepted by the method is important to you,
-  you can specify that as well:
-
-    ```ruby
-    obj.should respond_to(:foo).with(1).argument
-    obj.should respond_to(:bar).with(2).arguments
-    ```
-
-  Note that this matcher relies entirely upon #respond_to?.  If an object
-  dynamically responds to a message via #method_missing, but does not indicate
-  this via #respond_to?, then this matcher will give you false results.
-
-  Scenario: basic usage
-    Given a file named "respond_to_matcher_spec.rb" with:
-      """ruby
-      describe "a string" do
-        it { should respond_to(:length) }
-        it { should respond_to(:hash, :class, :to_s) }
-        it { should_not respond_to(:to_model) }
-        it { should_not respond_to(:compact, :flatten) }
-
-        # deliberate failures
-        it { should respond_to(:to_model) }
-        it { should respond_to(:compact, :flatten) }
-        it { should_not respond_to(:length) }
-        it { should_not respond_to(:hash, :class, :to_s) }
-
-        # mixed examples--String responds to :length but not :flatten
-        # both specs should fail
-        it { should respond_to(:length, :flatten) }
-        it { should_not respond_to(:length, :flatten) }
-      end
-      """
-    When I run `rspec respond_to_matcher_spec.rb`
-    Then the output should contain all of these:
-      | 10 examples, 6 failures                                    |
-      | expected "a string" to respond to :to_model                |
-      | expected "a string" to respond to :compact, :flatten       |
-      | expected "a string" not to respond to :length              |
-      | expected "a string" not to respond to :hash, :class, :to_s |
-      | expected "a string" to respond to :flatten                 |
-      | expected "a string" not to respond to :length              |
-
-  Scenario: specify arguments
-    Given a file named "respond_to_matcher_argument_checking_spec.rb" with:
-      """ruby
-      describe 7 do
-        it { should respond_to(:zero?).with(0).arguments }
-        it { should_not respond_to(:zero?).with(1).argument }
-
-        it { should respond_to(:between?).with(2).arguments }
-        it { should_not respond_to(:between?).with(7).arguments }
-
-        # deliberate failures
-        it { should respond_to(:zero?).with(1).argument }
-        it { should_not respond_to(:zero?).with(0).arguments }
-
-        it { should respond_to(:between?).with(7).arguments }
-        it { should_not respond_to(:between?).with(2).arguments }
-      end
-      """
-    When I run `rspec respond_to_matcher_argument_checking_spec.rb`
-    Then the output should contain all of these:
-      | 8 examples, 4 failures                                  |
-      | expected 7 to respond to :zero? with 1 argument         |
-      | expected 7 not to respond to :zero? with 0 arguments    |
-      | expected 7 to respond to :between? with 7 arguments     |
-      | expected 7 not to respond to :between? with 2 arguments |

data/features/built_in_matchers/satisfy.feature

@@ -1,33 +0,0 @@
-Feature: satisfy matcher
-
-  The satisfy matcher is extremely flexible and can handle almost anything
-  you want to specify.  It passes if the block you provide returns true:
-
-    ```ruby
-    10.should satisfy { |v| v % 5 == 0 }
-    7.should_not satisfy { |v| v % 5 == 0 }
-    ```
-
-  This flexibility comes at a cost, however: the failure message
-  ("expected [actual] to satisfy block") is not very descriptive
-  or helpful.  You will usually be better served by using one of
-  the other built-in matchers, or writing a custom matcher.
-
-  Scenario: basic usage
-    Given a file named "satisfy_matcher_spec.rb" with:
-      """ruby
-      describe 10 do
-        it { should satisfy { |v| v > 5 } }
-        it { should_not satisfy { |v| v > 15 } }
-
-        # deliberate failures
-        it { should_not satisfy { |v| v > 5 } }
-        it { should satisfy { |v| v > 15 } }
-      end
-      """
-    When I run `rspec satisfy_matcher_spec.rb`
-    Then the output should contain all of these:
-      | 4 examples, 2 failures           |
-      | expected 10 not to satisfy block |
-      | expected 10 to satisfy block     |
-

data/features/built_in_matchers/start_with.feature

@@ -1,48 +0,0 @@
-Feature: start_with matcher
-
-  Use the `start_with` matcher to specify that a string or array starts with
-  the expected characters or elements.
-
-    ```ruby
-    "this string".should start_with("this")
-    "this string".should_not start_with("that")
-    [0,1,2].should start_with(0, 1)
-    ```
-
-  Scenario: with a string
-    Given a file named "example_spec.rb" with:
-      """ruby
-      describe "this string" do
-        it { should start_with "this" }
-        it { should_not start_with "that" }
-
-        # deliberate failures
-        it { should_not start_with "this" }
-        it { should start_with "that" }
-      end
-      """
-    When I run `rspec example_spec.rb`
-    Then the output should contain all of these:
-      | 4 examples, 2 failures                          |
-      | expected "this string" not to start with "this" |
-      | expected "this string" to start with "that"     |
-
-  Scenario: with an array
-    Given a file named "example_spec.rb" with:
-      """ruby
-      describe [0, 1, 2, 3, 4] do
-        it { should start_with 0 }
-        it { should start_with(0, 1)}
-        it { should_not start_with(2) }
-        it { should_not start_with(0, 1, 2, 3, 4, 5) }
-
-        # deliberate failures
-        it { should_not start_with 0 }
-        it { should start_with 3 }
-      end
-      """
-    When I run `rspec example_spec.rb`
-    Then the output should contain all of these:
-      | 6 examples, 2 failures                       |
-      | expected [0, 1, 2, 3, 4] not to start with 0 |
-      | expected [0, 1, 2, 3, 4] to start with 3     |

data/features/built_in_matchers/throw_symbol.feature

@@ -1,91 +0,0 @@
-Feature: throw_symbol matcher
-
-  The throw_symbol matcher is used to specify that a block of code
-  throws a symbol.  The most basic form passes if any symbol is thrown:
-
-    ```ruby
-    expect { throw :foo }.to throw_symbol
-    ```
-
-  You'll often want to specify that a particular symbol is thrown:
-
-    ```ruby
-    expect { throw :foo }.to throw_symbol(:foo)
-    ```
-
-  If you care about the additional argument given to throw, you can
-  specify that as well:
-
-    ```ruby
-    expect { throw :foo, 7 }.to throw_symbol(:foo, 7)
-    ```
-
-  Scenario: basic usage
-    Given a file named "throw_symbol_matcher_spec.rb" with:
-      """ruby
-      describe "throw" do
-        specify { expect { throw :foo    }.to     throw_symbol }
-        specify { expect { throw :bar, 7 }.to     throw_symbol }
-        specify { expect { 5 + 5         }.not_to throw_symbol }
-
-        # deliberate failures
-        specify { expect { throw :foo    }.not_to throw_symbol }
-        specify { expect { throw :bar, 7 }.not_to throw_symbol }
-        specify { expect { 5 + 5         }.to     throw_symbol }
-      end
-      """
-    When I run `rspec throw_symbol_matcher_spec.rb`
-    Then the output should contain all of these:
-      | 6 examples, 3 failures                      |
-      | expected no Symbol to be thrown, got :foo   |
-      | expected no Symbol to be thrown, got :bar   |
-      | expected a Symbol to be thrown, got nothing |
-
-  Scenario: specify thrown symbol
-    Given a file named "throw_symbol_matcher_spec.rb" with:
-      """ruby
-      describe "throw symbol" do
-        specify { expect { throw :foo    }.to     throw_symbol(:foo) }
-        specify { expect { throw :foo, 7 }.to     throw_symbol(:foo) }
-        specify { expect { 5 + 5         }.not_to throw_symbol(:foo) }
-        specify { expect { throw :bar    }.not_to throw_symbol(:foo) }
-
-        # deliberate failures
-        specify { expect { throw :foo    }.not_to throw_symbol(:foo) }
-        specify { expect { throw :foo, 7 }.not_to throw_symbol(:foo) }
-        specify { expect { 5 + 5         }.to     throw_symbol(:foo) }
-        specify { expect { throw :bar    }.to     throw_symbol(:foo) }
-      end
-      """
-    When I run `rspec throw_symbol_matcher_spec.rb`
-    Then the output should contain all of these:
-      | 8 examples, 4 failures                          |
-      | expected :foo not to be thrown, got :foo        |
-      | expected :foo not to be thrown, got :foo with 7 |
-      | expected :foo to be thrown, got nothing         |
-      | expected :foo to be thrown, got :bar            |
-
-  Scenario: specify thrown symbol and argument
-    Given a file named "throw_symbol_argument_matcher_spec.rb" with:
-      """ruby
-      describe "throw symbol with argument" do
-        specify { expect { throw :foo, 7 }.to     throw_symbol(:foo, 7) }
-        specify { expect { throw :foo, 8 }.not_to throw_symbol(:foo, 7) }
-        specify { expect { throw :bar, 7 }.not_to throw_symbol(:foo, 7) }
-        specify { expect { throw :foo    }.not_to throw_symbol(:foo, 7) }
-
-        # deliberate failures
-        specify { expect { throw :foo, 7 }.not_to throw_symbol(:foo, 7) }
-        specify { expect { throw :foo, 8 }.to     throw_symbol(:foo, 7) }
-        specify { expect { throw :bar, 7 }.to     throw_symbol(:foo, 7) }
-        specify { expect { throw :foo    }.to     throw_symbol(:foo, 7) }
-      end
-      """
-    When I run `rspec throw_symbol_argument_matcher_spec.rb`
-    Then the output should contain all of these:
-      | 8 examples, 4 failures                                       |
-      | expected :foo with 7 not to be thrown, got :foo with 7       |
-      | expected :foo with 7 to be thrown, got :foo with 8           |
-      | expected :foo with 7 to be thrown, got :bar                  |
-      | expected :foo with 7 to be thrown, got :foo with no argument |
-