opal-rspec 0.7.0.rc.1 → 0.7.0.rc.2

data/rspec-mocks/upstream/cucumber.yml

@@ -0,0 +1,2 @@
+default: --require features --tags ~@wip features --format progress
+wip: --require features --tags @wip:3 --wip features

data/rspec-mocks/upstream/features/.nav

@@ -0,0 +1,43 @@
+- basics:
+  - test_doubles.feature
+  - allowing_messages.feature
+  - expecting_messages.feature
+  - partial_test_doubles.feature
+  - null_object_doubles.feature
+  - spies.feature
+  - scope.feature
+- verifying_doubles:
+  - instance_doubles.feature
+  - class_doubles.feature
+  - object_doubles.feature
+  - dynamic_classes.feature
+  - partial_doubles.feature
+- configuring_responses:
+  - returning_a_value.feature
+  - raising_an_error.feature
+  - throwing.feature
+  - yielding.feature
+  - calling_the_original_implementation.feature
+  - block_implementation.feature
+- setting_constraints:
+  - matching_arguments.feature
+  - receive_counts.feature
+  - message_order.feature
+- mutating_constants:
+  - stub_defined_constant.feature
+  - stub_undefined_constant.feature
+  - hide_defined_constant.feature
+  - hide_undefined_constant.feature
+- working_with_legacy_code:
+  - any_instance.feature
+  - message_chains.feature
+- old_syntax:
+  - stub.feature
+  - should_receive.feature
+  - any_instance.feature
+  - stub_chain.feature
+  - unstub.feature
+- outside_rspec:
+  - minitest.feature
+  - standalone.feature
+- Changelog

data/rspec-mocks/upstream/features/README.md

@@ -0,0 +1,76 @@
+rspec-mocks helps to control the context in a code example by letting you set known return
+values, fake implementations of methods, and even set expectations that specific messages
+are received by an object.
+
+You can do these three things on test doubles that rspec-mocks creates for you on the fly, or
+you can do them on objects that are part of your system.
+
+## Messages and Methods
+
+_Message_ and _method_ are metaphors that we use somewhat interchangeably, but they are
+subtly different.  In Object Oriented Programming, objects communicate by sending
+_messages_ to one another. When an object receives a message, it invokes a _method_ with the
+same name as the message.
+
+## Test Doubles
+
+A test double is an object that stands in for another object in your system during a code
+example. Use the `double` method, passing in an optional identifier, to create one:
+
+```ruby
+book = double("book")
+```
+
+Most of the time you will want some confidence that your doubles resemble an existing
+object in your system. Verifying doubles are provided for this purpose. If the existing object
+is available, they will prevent you from adding stubs and expectations for methods that do
+not exist or that have invalid arguments.
+
+```ruby
+book = instance_double("Book", :pages => 250)
+```
+
+[Verifying doubles](./docs/verifying-doubles) have some clever tricks to enable you to both test in isolation without your
+dependencies loaded while still being able to validate them against real objects.
+
+## Method Stubs
+
+A method stub is an instruction to an object (real or test double) to return a
+known value in response to a message:
+
+```ruby
+allow(die).to receive(:roll) { 3 }
+```
+
+This tells the `die` object to return the value `3` when it receives the `roll` message.
+
+## Message Expectations
+
+A message expectation is an expectation that an object should receive a specific message
+during the course of a code example:
+
+```ruby
+describe Account do
+  context "when closed" do
+    it "logs an 'account closed' message" do
+      logger = double()
+      account = Account.new
+      account.logger = logger
+
+      expect(logger).to receive(:account_closed).with(account)
+
+      account.close
+    end
+  end
+end
+```
+
+This example specifies that the `account` object sends the `logger` the `account_closed`
+message (with itself as an argument) when it receives the `close` message.
+
+## Issues
+
+The documentation for rspec-mocks is a work in progress. We'll be adding Cucumber
+features over time, and clarifying existing ones. If you have specific features you'd like to see
+added, find the existing documentation incomplete or confusing, or, better yet, wish to write
+a missing Cucumber feature yourself, please [submit an issue](http://github.com/rspec/rspec-mocks/issues) or a [pull request](http://github.com/rspec/rspec-mocks).

data/rspec-mocks/upstream/features/basics/allowing_messages.feature

@@ -0,0 +1,35 @@
+Feature: Allowing messages
+
+  [Test doubles](./test-doubles) are "strict" by default -- messages that have not been specifically
+  allowed or expected will trigger an error. Use `allow(...).to receive(...)` to configure
+  which messages are the double is allowed to receive. You can also use `allow(...).to
+  receive_messages(...)` to configure allowed messages (and return values) in bulk.
+
+  Scenario: Allowed messages return nil by default
+    Given a file named "allow_message_spec.rb" with:
+      """ruby
+      RSpec.describe "allow" do
+        it "returns nil from allowed messages" do
+          dbl = double("Some Collaborator")
+          allow(dbl).to receive(:foo)
+          expect(dbl.foo).to be_nil
+        end
+      end
+      """
+     When I run `rspec allow_message_spec.rb`
+     Then the examples should all pass
+
+  Scenario: Messages can be allowed in bulk using `receive_messages`
+    Given a file named "receive_messages_spec.rb" with:
+      """ruby
+      RSpec.describe "receive_messages" do
+        it "configures return values for the provided messages" do
+          dbl = double("Some Collaborator")
+          allow(dbl).to receive_messages(:foo => 2, :bar => 3)
+          expect(dbl.foo).to eq(2)
+          expect(dbl.bar).to eq(3)
+        end
+      end
+      """
+     When I run `rspec receive_messages_spec.rb`
+     Then the examples should all pass

data/rspec-mocks/upstream/features/basics/expecting_messages.feature

@@ -0,0 +1,73 @@
+Feature: Expecting messages
+
+  Use `expect(...).to receive(...)` to expect a message on a [test double](./test-doubles). Unfulfilled
+  message expectations trigger failures when the example completes. You can also use
+  `expect(...).not_to receive(...)` to set a negative message expectation.
+
+  Scenario: Failing positive message expectation
+    Given a file named "unfulfilled_message_expectation_spec.rb" with:
+      """ruby
+      RSpec.describe "An unfulfilled positive message expectation" do
+        it "triggers a failure" do
+          dbl = double("Some Collaborator")
+          expect(dbl).to receive(:foo)
+        end
+      end
+      """
+     When I run `rspec unfulfilled_message_expectation_spec.rb`
+     Then it should fail with:
+      """
+        1) An unfulfilled positive message expectation triggers a failure
+           Failure/Error: expect(dbl).to receive(:foo)
+             (Double "Some Collaborator").foo(any args)
+                 expected: 1 time with any arguments
+                 received: 0 times with any arguments
+      """
+
+  Scenario: Passing positive message expectation
+    Given a file named "fulfilled_message_expectation_spec.rb" with:
+      """ruby
+      RSpec.describe "A fulfilled positive message expectation" do
+        it "passes" do
+          dbl = double("Some Collaborator")
+          expect(dbl).to receive(:foo)
+          dbl.foo
+        end
+      end
+      """
+     When I run `rspec fulfilled_message_expectation_spec.rb`
+     Then the examples should all pass
+
+  Scenario: Failing negative message expectation
+    Given a file named "negative_message_expectation_spec.rb" with:
+      """ruby
+      RSpec.describe "A negative message expectation" do
+        it "fails when the message is received" do
+          dbl = double("Some Collaborator").as_null_object
+          expect(dbl).not_to receive(:foo)
+          dbl.foo
+        end
+      end
+      """
+     When I run `rspec negative_message_expectation_spec.rb`
+     Then it should fail with:
+      """
+        1) A negative message expectation fails when the message is received
+           Failure/Error: dbl.foo
+             (Double "Some Collaborator").foo(no args)
+                 expected: 0 times with any arguments
+                 received: 1 time
+      """
+
+  Scenario: Passing negative message expectation
+    Given a file named "negative_message_expectation_spec.rb" with:
+      """ruby
+      RSpec.describe "A negative message expectation" do
+        it "passes if the message is never received" do
+          dbl = double("Some Collaborator").as_null_object
+          expect(dbl).not_to receive(:foo)
+        end
+      end
+      """
+     When I run `rspec negative_message_expectation_spec.rb`
+     Then the examples should all pass

data/rspec-mocks/upstream/features/basics/null_object_doubles.feature

@@ -0,0 +1,35 @@
+Feature: Null object doubles
+
+  [Test doubles](./test-doubles) are strict by default, raising errors when they receive messages that have not
+  been allowed or expected. You can chain `as_null_object` off of `double` in order to make
+  the double "loose". For any message that has not explicitly allowed or expected, the double
+  will return itself. It acts as a block-hole null object, allowing arbitrarily deep method chains.
+
+  Scenario: `as_null_object` allows arbitrarily deep message chains and returns itself
+    Given a file named "as_null_object_spec.rb" with:
+      """ruby
+      RSpec.describe "as_null_object" do
+        it "returns itself" do
+          dbl = double("Some Collaborator").as_null_object
+          expect(dbl.foo.bar.bazz).to be(dbl)
+        end
+      end
+      """
+     When I run `rspec as_null_object_spec.rb`
+     Then the examples should all pass
+
+  Scenario: Individual methods can still be allowed or expected
+    Given a file named "as_null_object_spec.rb" with:
+      """ruby
+      RSpec.describe "as_null_object" do
+        it "can allow individual methods" do
+          dbl = double("Some Collaborator", :foo => 3).as_null_object
+          allow(dbl).to receive(:bar).and_return(4)
+
+          expect(dbl.foo).to eq(3)
+          expect(dbl.bar).to eq(4)
+        end
+      end
+      """
+     When I run `rspec as_null_object_spec.rb`
+     Then the examples should all pass

data/rspec-mocks/upstream/features/basics/partial_test_doubles.feature

@@ -0,0 +1,70 @@
+Feature: Partial test doubles
+
+  A _partial test double_ is an extension of a real object in a system that is instrumented with
+  test-double like behaviour in the context of a test. This technique is very common in Ruby
+  because we often see class objects acting as global namespaces for methods. For example,
+  in Rails:
+
+  ```ruby
+  person = double("person")
+  allow(Person).to receive(:find) { person }
+  ```
+
+  In this case we're instrumenting Person to return the person object we've defined whenever
+  it receives the `find` message. We can also set a message expectation so that the example
+  fails if `find` is not called:
+
+  ```ruby
+  person = double("person")
+  expect(Person).to receive(:find) { person }
+  ```
+
+  RSpec replaces the method we're stubbing or mocking with its own test-double-like method.
+  At the end of the example, RSpec verifies any message expectations, and then restores the
+  original methods.
+
+  Note: we recommend enabling the [`verify_partial_doubles`](../verifying-doubles/partial-doubles) config option.
+
+  Scenario: Only the specified methods are redefined
+    Given a file named "partial_double_spec.rb" with:
+      """ruby
+      RSpec.describe "A partial double" do
+        # Note: stubbing a string like this is a terrible idea.
+        #       This is just for demonstration purposes.
+        let(:string) { "a string" }
+        before { allow(string).to receive(:length).and_return(500) }
+
+        it "redefines the specified methods" do
+          expect(string.length).to eq(500)
+        end
+
+        it "does not effect other methods" do
+          expect(string.reverse).to eq("gnirts a")
+        end
+      end
+      """
+     When I run `rspec partial_double_spec.rb`
+     Then the examples should all pass
+
+  Scenario: The original method is restored when the example completes
+    Given a file named "partial_double_spec.rb" with:
+      """ruby
+      class User
+        def self.find(id)
+          :original_return_value
+        end
+      end
+
+      RSpec.describe "A partial double" do
+        it "redefines a method" do
+          allow(User).to receive(:find).and_return(:redefined)
+          expect(User.find(3)).to eq(:redefined)
+        end
+
+        it "restores the redefined method after the example completes" do
+          expect(User.find(3)).to eq(:original_return_value)
+        end
+      end
+      """
+     When I run `rspec partial_double_spec.rb --order defined`
+     Then the examples should all pass

data/rspec-mocks/upstream/features/basics/scope.feature

@@ -0,0 +1,99 @@
+Feature: Scope
+
+  All rspec-mocks constructs have a per-example lifecycle. Message expectations are verified
+  after each example. Doubles, method stubs, stubbed constants, etc. are all cleaned up after
+  each example. This ensures that each example can be run in isolation, and in any order.
+
+  It is perfectly fine to set up doubles, stubs, and message expectations in a
+  `before(:example)` hook, as that hook is executed in the scope of the example:
+
+  ```ruby
+  before(:example) do
+    allow(MyClass).to receive(:foo)
+  end
+  ```
+
+  Since `before(:context)` runs outside the scope of any individual example, usage of
+  rspec-mocks features is not supported there. You can, however, create a temporary scope in
+  _any_ arbitrary context, including in a `before(:context)` hook, using
+  `RSpec::Mocks.with_temporary_scope { }`.
+
+  Scenario: Cannot create doubles in a `before(:context)` hook
+    Given a file named "before_context_spec.rb" with:
+      """ruby
+      RSpec.describe "Creating a double in a before(:context) hook" do
+        before(:context) do
+          @dbl = double(:foo => 13)
+        end
+
+        it "fails before it gets to the examples" do
+          expect(@dbl.foo).to eq(13)
+        end
+      end
+      """
+    When I run `rspec before_context_spec.rb`
+    Then it should fail with:
+      """
+      The use of doubles or partial doubles from rspec-mocks outside of the per-test lifecycle is not supported.
+      """
+
+  Scenario: Use `with_temporary_scope` to create and use a double in a `before(:context)` hook
+    Given a file named "with_temporary_scope_spec.rb" with:
+      """ruby
+      RSpec.describe "Creating a double in a before(:context) hook" do
+        before(:context) do
+          RSpec::Mocks.with_temporary_scope do
+            dbl = double(:foo => 13)
+            @result = dbl.foo
+          end
+        end
+
+        it "allows a double to be created and used from within a with_temporary_scope block" do
+          expect(@result).to eq(13)
+        end
+      end
+      """
+    When I run `rspec with_temporary_scope_spec.rb`
+    Then the examples should all pass
+
+  Scenario: Doubles cannot be reused in another example
+    Given a file named "leak_test_double_spec.rb" with:
+      """ruby
+      class Account
+        class << self
+          attr_accessor :logger
+        end
+
+        def initialize
+          @balance = 0
+        end
+
+        attr_reader :balance
+
+        def credit(amount)
+          @balance += amount
+          self.class.logger.log("Credited $#{amount}")
+        end
+      end
+
+      RSpec.describe Account do
+        it "logs each credit" do
+          Account.logger = logger = double("Logger")
+          expect(logger).to receive(:log).with("Credited $15")
+          account = Account.new
+          account.credit(15)
+        end
+
+        it "keeps track of the balance" do
+          account = Account.new
+          expect { account.credit(10) }.to change { account.balance }.by(10)
+        end
+      end
+      """
+    When I run `rspec leak_test_double_spec.rb`
+    Then it should fail with the following output:
+      | 2 examples, 1 failure                                                                                                      |
+      |                                                                                                                            |
+      |  1) Account keeps track of the balance                                                                                     |
+      |     Failure/Error: self.class.logger.log("Credited $#{amount}")                                                            |
+      |       Double "Logger" was originally created in one example but has leaked into another example and can no longer be used. |

data/rspec-mocks/upstream/features/basics/spies.feature

@@ -0,0 +1,144 @@
+Feature: Spies
+
+  [Message expectations](./expecting-messages) put an example's expectation at the start, before you've invoked the
+  code-under-test. Many developers prefer using an act-arrange-assert (or given-when-then)
+  pattern for structuring tests. Spies are an alternate type of test double that support this
+  pattern by allowing you to expect that a message has been received after the fact, using
+  `have_received`.
+
+  You can use any test double (or partial double) as a spy, but the double must be setup to
+  spy on the messages you care about. Spies automatically spy on all messages,
+  or you can [allow a message](./allowing-messages) to spy on it.
+
+  `have_received` supports the same fluent interface for [setting constraints](../setting-constraints) that normal message expectations do.
+
+  Note: The `have_received` API shown here will only work if you are using rspec-expectations.
+
+  Scenario: Using a spy
+    Given a file named "spy_spec.rb" with:
+      """ruby
+      RSpec.describe "have_received" do
+        it "passes when the message has been received" do
+          invitation = spy('invitation')
+          invitation.deliver
+          expect(invitation).to have_received(:deliver)
+        end
+      end
+      """
+    When I run `rspec spy_spec.rb`
+    Then the examples should all pass
+
+  Scenario: Spy on a method on a partial double
+    Given a file named "partial_double_spy_spec.rb" with:
+      """ruby
+      class Invitation
+        def self.deliver; end
+      end
+
+      RSpec.describe "have_received" do
+        it "passes when the expectation is met" do
+          allow(Invitation).to receive(:deliver)
+          Invitation.deliver
+          expect(Invitation).to have_received(:deliver)
+        end
+      end
+      """
+    When I run `rspec partial_double_spy_spec.rb`
+    Then the examples should all pass
+
+  Scenario: Failure when the message has not been received
+    Given a file named "failure_spec.rb" with:
+      """ruby
+      class Invitation
+        def self.deliver; end
+      end
+
+      RSpec.describe "failure when the message has not been received" do
+        example "for a spy" do
+          invitation = spy('invitation')
+          expect(invitation).to have_received(:deliver)
+        end
+
+        example "for a partial double" do
+          allow(Invitation).to receive(:deliver)
+          expect(Invitation).to have_received(:deliver)
+        end
+      end
+      """
+     When I run `rspec failure_spec.rb --order defined`
+     Then it should fail with:
+      """
+        1) failure when the message has not been received for a spy
+           Failure/Error: expect(invitation).to have_received(:deliver)
+             (Double "invitation").deliver(any args)
+                 expected: 1 time with any arguments
+                 received: 0 times with any arguments
+      """
+      And it should fail with:
+      """
+        2) failure when the message has not been received for a partial double
+           Failure/Error: expect(Invitation).to have_received(:deliver)
+             (<Invitation (class)>).deliver(any args)
+                 expected: 1 time with any arguments
+                 received: 0 times with any arguments
+      """
+
+  Scenario: Set constraints using the fluent interface
+    Given a file named "setting_constraints_spec.rb" with:
+      """ruby
+      RSpec.describe "An invitiation" do
+        let(:invitation) { spy("invitation") }
+
+        before do
+          invitation.deliver("foo@example.com")
+          invitation.deliver("bar@example.com")
+        end
+
+        it "passes when a count constraint is satisfied" do
+          expect(invitation).to have_received(:deliver).twice
+        end
+
+        it "passes when an order constraint is satisifed" do
+          expect(invitation).to have_received(:deliver).with("foo@example.com").ordered
+          expect(invitation).to have_received(:deliver).with("bar@example.com").ordered
+        end
+
+        it "fails when a count constraint is not satisfied" do
+          expect(invitation).to have_received(:deliver).at_least(3).times
+        end
+
+        it "fails when an order constraint is not satisifed" do
+          expect(invitation).to have_received(:deliver).with("bar@example.com").ordered
+          expect(invitation).to have_received(:deliver).with("foo@example.com").ordered
+        end
+      end
+      """
+    When I run `rspec setting_constraints_spec.rb --order defined`
+    Then it should fail with the following output:
+      | 4 examples, 2 failures                                                                           |
+      |                                                                                                  |
+      |  1) An invitiation fails when a count constraint is not satisfied                                |
+      |     Failure/Error: expect(invitation).to have_received(:deliver).at_least(3).times               |
+      |       (Double "invitation").deliver(any args)                                                    |
+      |           expected: at least 3 times with any arguments                                          |
+      |           received: 2 times with any arguments                                                   |
+      |                                                                                                  |
+      |  2) An invitiation fails when an order constraint is not satisifed                               |
+      |     Failure/Error: expect(invitation).to have_received(:deliver).with("foo@example.com").ordered |
+      |       Double "invitation" received :deliver out of order                                         |
+
+  Scenario: `have_received` generates a good example description
+    Given a file named "generates_description_spec.rb" with:
+      """ruby
+      RSpec.describe "An invitation" do
+        subject(:invitation) { spy('invitation') }
+        before { invitation.deliver }
+        it { is_expected.to have_received(:deliver) }
+      end
+      """
+    When I run `rspec --format documentation generates_description_spec.rb`
+    Then it should pass with:
+      """
+      An invitation
+        should have received deliver(any args) 1 time
+      """