rspec-expectations 3.0.0.beta2 → 3.0.0.rc1

data/features/built_in_matchers/include.feature

@@ -1,126 +0,0 @@
-Feature: include matcher
-
-  Use the include matcher to specify that a collection includes one or more
-  expected objects.  This works on any object that responds to #include?  (such
-  as a string or array):
-
-    ```ruby
-    expect("a string").to include("a")
-    expect("a string").to include("str")
-    expect("a string").to include("str", "g")
-    expect("a string").not_to include("foo")
-
-    expect([1, 2]).to include(1)
-    expect([1, 2]).to include(1, 2)
-    expect([1, 2]).not_to include(17)
-    ```
-
-  The matcher also provides flexible handling for hashes:
-
-    ```ruby
-    expect(:a => 1, :b => 2).to include(:a)
-    expect(:a => 1, :b => 2).to include(:a, :b)
-    expect(:a => 1, :b => 2).to include(:a => 1)
-    expect(:a => 1, :b => 2).to include(:b => 2, :a => 1)
-    expect(:a => 1, :b => 2).not_to include(:c)
-    expect(:a => 1, :b => 2).not_to include(:a => 2)
-    expect(:a => 1, :b => 2).not_to include(:c => 3)
-    ```
-
-  Scenario: array usage
-    Given a file named "array_include_matcher_spec.rb" with:
-      """ruby
-      describe [1, 3, 7] do
-        it { should include(1) }
-        it { should include(3) }
-        it { should include(7) }
-        it { should include(1, 7) }
-        it { should include(1, 3, 7) }
-        it { should_not include(17) }
-        it { should_not include(43, 100) }
-
-        # deliberate failures
-        it { should include(4) }
-        it { should_not include(1) }
-        it { should_not include(3) }
-        it { should_not include(7) }
-        it { should_not include(1, 3, 7) }
-
-        # both of these should fail since it includes 1 but not 9
-        it { should include(1, 9) }
-        it { should_not include(1, 9) }
-      end
-      """
-    When I run `rspec array_include_matcher_spec.rb`
-    Then the output should contain all of these:
-      | 14 examples, 7 failures                       |
-      | expected [1, 3, 7] to include 4               |
-      | expected [1, 3, 7] not to include 1           |
-      | expected [1, 3, 7] not to include 3           |
-      | expected [1, 3, 7] not to include 7           |
-      | expected [1, 3, 7] not to include 1, 3, and 7 |
-      | expected [1, 3, 7] to include 1 and 9         |
-      | expected [1, 3, 7] not to include 1 and 9     |
-
-  Scenario: string usage
-    Given a file named "string_include_matcher_spec.rb" with:
-      """ruby
-      describe "a string" do
-        it { should include("str") }
-        it { should include("a", "str", "ng") }
-        it { should_not include("foo") }
-        it { should_not include("foo", "bar") }
-
-        # deliberate failures
-        it { should include("foo") }
-        it { should_not include("str") }
-        it { should include("str", "foo") }
-        it { should_not include("str", "foo") }
-      end
-      """
-    When I run `rspec string_include_matcher_spec.rb`
-    Then the output should contain all of these:
-      | 8 examples, 4 failures                             |
-      | expected "a string" to include "foo"               |
-      | expected "a string" not to include "str"           |
-      | expected "a string" to include "str" and "foo"     |
-      | expected "a string" not to include "str" and "foo" |
-
-  Scenario: hash usage
-    Given a file named "hash_include_matcher_spec.rb" with:
-      """ruby
-      describe Hash do
-        subject { { :a => 7, :b => 5 } }
-
-        it { should include(:a) }
-        it { should include(:b, :a) }
-        it { should include(:a => 7) }
-        it { should include(:b => 5, :a => 7) }
-        it { should_not include(:c) }
-        it { should_not include(:c, :d) }
-        it { should_not include(:d => 2) }
-        it { should_not include(:a => 5) }
-        it { should_not include(:b => 7, :a => 5) }
-
-        # deliberate failures
-        it { should_not include(:a) }
-        it { should_not include(:b, :a) }
-        it { should_not include(:a => 7) }
-        it { should_not include(:a => 7, :b => 5) }
-        it { should include(:c) }
-        it { should include(:c, :d) }
-        it { should include(:d => 2) }
-        it { should include(:a => 5) }
-        it { should include(:a => 5, :b => 7) }
-
-        # Mixed cases--the hash includes one but not the other.
-        # All 4 of these cases should fail.
-        it { should include(:a, :d) }
-        it { should_not include(:a, :d) }
-        it { should include(:a => 7, :d => 3) }
-        it { should_not include(:a => 7, :d => 3) }
-      end
-      """
-    When I run `rspec hash_include_matcher_spec.rb`
-    Then the output should contain "13 failure"
-

data/features/built_in_matchers/match.feature

@@ -1,51 +0,0 @@
-Feature: match matcher
-
-  The match matcher calls #match on the object, passing if #match returns a
-  truthy (not false or nil) value.  Regexp and String both provide a #match
-  method.
-
-    ```ruby
-    expect("a string").to match(/str/) # passes
-    expect("a string").to match(/foo/) # fails
-    expect(/foo/).to match("food")     # passes
-    expect(/foo/).to match("drinks")   # fails
-    ```
-
-  This is equivalent to using the =~ matcher (see the operator matchers
-  feature for more details).
-
-  Scenario: string usage
-    Given a file named "string_match_spec.rb" with:
-      """ruby
-      describe "a string" do
-        it { should match(/str/) }
-        it { should_not match(/foo/) }
-
-        # deliberate failures
-        it { should_not match(/str/) }
-        it { should match(/foo/) }
-      end
-      """
-    When I run `rspec string_match_spec.rb`
-    Then the output should contain all of these:
-      | 4 examples, 2 failures                 |
-      | expected "a string" not to match /str/ |
-      | expected "a string" to match /foo/     |
-
-  Scenario: regular expression usage
-    Given a file named "regexp_match_spec.rb" with:
-      """ruby
-      describe /foo/ do
-        it { should match("food") }
-        it { should_not match("drinks") }
-
-        # deliberate failures
-        it { should_not match("food") }
-        it { should match("drinks") }
-      end
-      """
-    When I run `rspec regexp_match_spec.rb`
-    Then the output should contain all of these:
-      | 4 examples, 2 failures             |
-      | expected /foo/ not to match "food" |
-      | expected /foo/ to match "drinks"   |

data/features/built_in_matchers/output.feature

@@ -1,70 +0,0 @@
-Feature: output matcher
-
-  The `output` matcher provides a way to assert that the
-  has emitted content to either `$stdout` or `$stderr`.
-
-  With no arg, passes if the block outputs `to_stdout` or `to_stderr`.
-  With a string, passes if the blocks outputs that specific string
-  `to_stdout` or `to_stderr`. With a regexp or matcher, passes if the
-  blocks outputs a string `to_stdout` or `to_stderr` that matches.
-
-  Note: This matcher works by temporarily replacing `$stdout` or `$stderr`,
-  so it's not able to intercept stream output that explicitly uses `STDOUT`/`STDERR`
-  or that uses a reference to `$stdout`/`$stderr` that was stored before the
-  matcher is used.
-
-  Scenario: output_to_stdout matcher
-    Given a file named "output_to_stdout_spec.rb" with:
-      """ruby
-      describe "output.to_stdout matcher" do
-        specify { expect { print('foo') }.to output.to_stdout }
-        specify { expect { print('foo') }.to output('foo').to_stdout }
-        specify { expect { print('foo') }.to output(/foo/).to_stdout }
-        specify { expect { }.to_not output.to_stdout }
-        specify { expect { print('foo') }.to_not output('bar').to_stdout }
-        specify { expect { print('foo') }.to_not output(/bar/).to_stdout }
-
-        # deliberate failures
-        specify { expect { }.to output.to_stdout }
-        specify { expect { }.to output('foo').to_stdout }
-        specify { expect { print('foo') }.to_not output.to_stdout }
-        specify { expect { print('foo') }.to output('bar').to_stdout }
-        specify { expect { print('foo') }.to output(/bar/).to_stdout }
-      end
-      """
-    When I run `rspec output_to_stdout_spec.rb`
-    Then the output should contain all of these:
-      | 11 examples, 5 failures                                      |
-      | expected block to output to stdout, but did not              |
-      | expected block to not output to stdout, but did              |
-      | expected block to output "bar" to stdout, but output "foo"   |
-      | expected block to output "foo" to stdout, but output nothing |
-      | expected block to output /bar/ to stdout, but output "foo"   |
-
-  Scenario: output_to_stderr matcher
-    Given a file named "output_to_stderr.rb" with:
-      """ruby
-      describe "output_to_stderr matcher" do
-        specify { expect { warn('foo') }.to output.to_stderr }
-        specify { expect { warn('foo') }.to output("foo\n").to_stderr }
-        specify { expect { warn('foo') }.to output(/foo/).to_stderr }
-        specify { expect { }.to_not output.to_stderr }
-        specify { expect { warn('foo') }.to_not output('bar').to_stderr }
-        specify { expect { warn('foo') }.to_not output(/bar/).to_stderr }
-
-        # deliberate failures
-        specify { expect { }.to output.to_stderr }
-        specify { expect { }.to output('foo').to_stderr }
-        specify { expect { warn('foo') }.to_not output.to_stderr }
-        specify { expect { warn('foo') }.to output('bar').to_stderr }
-        specify { expect { warn('foo') }.to output(/bar/).to_stderr }
-      end
-      """
-    When I run `rspec output_to_stderr.rb`
-    Then the output should contain all of these:
-      | 11 examples, 5 failures                                      |
-      | expected block to output to stderr, but did not              |
-      | expected block to not output to stderr, but did              |
-      | expected block to output "bar" to stderr, but output "foo\n" |
-      | expected block to output "foo" to stderr, but output nothing |
-      | expected block to output /bar/ to stderr, but output "foo\n" |

data/features/built_in_matchers/predicates.feature

@@ -1,161 +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
-    expect(7.zero?).to eq 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
-    expect(7).not_to be_zero       # calls 7.zero?
-    expect([]).to be_empty         # calls [].empty?
-    expect(x).to 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
-    expect(hash).to have_key(:foo)       # calls hash.has_key?(:foo)
-    expect(array).not_to 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`
-
-  Calling private methods will also fail:
-
-    `expected private_method? to return true but it's a private method`
-
-  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"
-
-    Scenario: calling private method causes error
-      Given a file named "attempting_to_match_private_method_spec.rb" with:
-       """ruby
-       class WithPrivateMethods
-         def secret?
-           true
-         end
-         private :secret?
-       end
-
-       describe 'private methods' do
-         subject { WithPrivateMethods.new }
-
-         # deliberate failure
-         it { should be_secret }
-       end
-       """
-     When I run `rspec attempting_to_match_private_method_spec.rb`
-     Then the output should contain "1 example, 1 failure"
-     And the output should contain "expectation set on private method `secret?`"

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
-    expect(obj).to 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
-    expect(obj).to 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
-    expect(obj).to respond_to(:foo).with(1).argument
-    expect(obj).to 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 |