opal-rspec 0.8.0 → 1.0.0

data/rspec-core/upstream/features/configuration/read_options_from_file.feature

@@ -1,36 +1,42 @@
 Feature: read command line configuration options from files
 
-  RSpec reads command line configuration options from files in three different
-  locations:
+  RSpec reads command line configuration options from several different files,
+  all conforming to a specific level of specificity. Options from a higher
+  specificity will override conflicting options from lower specificity files.
 
-    * Local: `./.rspec-local` (i.e. in the project's root directory, can be
-      gitignored)
+  The locations are:
+
+    * **Global options:** First file from the following list (i.e. the user's
+      personal global options)
 
-    * Project:  `./.rspec` (i.e. in the project's root directory, usually
+      * `$XDG_CONFIG_HOME/rspec/options` ([XDG Base Directory
+        Specification](https://specifications.freedesktop.org/basedir-spec/latest/)
+        config)
+      * `~/.rspec`
+
+    * **Project options:**  `./.rspec` (i.e. in the project's root directory, usually
       checked into the project)
 
-    * Global: `~/.rspec` (i.e. in the user's home directory)
+    * **Local:** `./.rspec-local` (i.e. in the project's root directory, can be
+      gitignored)
 
-  Configuration options are loaded from `~/.rspec`, `.rspec`, `.rspec-local`,
-  command line switches, and the `SPEC_OPTS` environment variable (listed in
-  lowest to highest precedence; for example, an option in `~/.rspec` can be
-  overridden by an option in `.rspec-local`).
+  Options specified at the command-line has even higher specificity, as does
+  the `SPEC_OPTS` environment variable. That means that a command-line option
+  would overwrite a project-specific option, which overrides the global value
+  of that option.
+
+  The default options files can all be ignored using the `--options`
+  command-line argument, which selects a custom file to load options from.
 
   Scenario: Color set in `.rspec`
     Given a file named ".rspec" with:
       """
-      --color
+      --force-color
       """
     And a file named "spec/example_spec.rb" with:
       """ruby
       RSpec.describe "color_enabled?" do
         context "when set with RSpec.configure" do
-          before do
-            # color is disabled for non-tty output, so stub the output stream
-            # to say it is tty, even though we're running this with cucumber
-            allow(RSpec.configuration.output_stream).to receive(:tty?) { true }
-          end
-
           it "is true" do
             expect(RSpec.configuration).to be_color_enabled
           end
@@ -64,13 +70,13 @@ Feature: read command line configuration options from files
       """
     And a file named ".rspec" with:
       """
-      --color
+      --no-color
       """
     And a file named "spec/example_spec.rb" with:
       """ruby
       RSpec.describe "custom options file" do
         it "causes .rspec to be ignored" do
-          expect(RSpec.configuration.color).to be_falsey
+          expect(RSpec.configuration.color_mode).to eq(:automatic)
         end
       end
       """

data/rspec-core/upstream/features/configuration/run_all_when_everything_filtered.feature

@@ -1,5 +1,9 @@
 Feature: run all when everything filtered
 
+  Note: this feature has been superseded by
+  [filter_run_when_matching](../filtering/filter-run-when-matching) and will be
+  removed in a future version of RSpec.
+
   Use the `run_all_when_everything_filtered` option to tell RSpec to run all the
   specs in the case where you try to run a filtered list of specs but no specs
   match that filter. This works well when paired with an inclusion filter like

data/rspec-core/upstream/features/core_standalone.feature

@@ -5,6 +5,8 @@ Feature: Use rspec-core without rspec-mocks or rspec-expectations
   available, but rspec-core can be used just fine without either of those
   gems installed.
 
+  # Rubinius stacktrace includes kernel/loader.rb etc.
+  @unsupported-on-rbx
   Scenario: Use only rspec-core when only it is installed
     Given only rspec-core is installed
       And a file named "core_only_spec.rb" with:

data/rspec-core/upstream/features/example_groups/basic_structure.feature

@@ -38,6 +38,7 @@ Feature: basic structure (`describe`/`it`)
         it "does one thing" do
         end
       end
+
       context "in another context" do
         it "does another thing" do
         end

data/rspec-core/upstream/features/example_groups/shared_context.feature

@@ -1,13 +1,23 @@
 Feature: shared context
 
-  Use `shared_context` to define a block that will be evaluated in the context
-  of example groups either explicitly, using `include_context`, or implicitly by
-  matching metadata.
+  Use `shared_context` to define a block that will be evaluated in the context of example groups either locally, using `include_context` in an example group, or globally using `config.include_context`.
+
+  When implicitly including shared contexts via matching metadata, the normal way is to define matching metadata on an example group, in which case the context is included in the entire group. However, you also have the option to include it in an individual example instead. RSpec treats every example as having a singleton example group (analogous to Ruby's singleton classes) containing just the one example.
 
   Background:
     Given a file named "shared_stuff.rb" with:
       """ruby
-      RSpec.shared_context "shared stuff", :a => :b do
+      RSpec.configure do |rspec|
+        # This config option will be enabled by default on RSpec 4,
+        # but for reasons of backwards compatibility, you have to
+        # set it on RSpec 3.
+        #
+        # It causes the host group and examples to inherit metadata
+        # from the shared context.
+        rspec.shared_context_metadata_behavior = :apply_to_host_groups
+      end
+
+      RSpec.shared_context "shared stuff", :shared_context => :metadata do
         before { @some_var = :some_value }
         def shared_method
           "it works"
@@ -17,6 +27,10 @@ Feature: shared context
           'this is the subject'
         end
       end
+
+      RSpec.configure do |rspec|
+        rspec.include_context "shared stuff", :include_shared => true
+      end
       """
 
   Scenario: Declare a shared context and include it with `include_context`
@@ -42,6 +56,13 @@ Feature: shared context
         it "accesses the subject defined in the shared context" do
           expect(subject).to eq('this is the subject')
         end
+
+        group = self
+
+        it "inherits metadata from the included context" do |ex|
+          expect(group.metadata).to include(:shared_context => :metadata)
+          expect(ex.metadata).to include(:shared_context => :metadata)
+        end
       end
       """
     When I run `rspec shared_context_example.rb`
@@ -70,7 +91,7 @@ Feature: shared context
       """ruby
       require "./shared_stuff.rb"
 
-      RSpec.describe "group that includes a shared context using metadata", :a => :b do
+      RSpec.describe "group that includes a shared context using metadata", :include_shared => true do
         it "has access to methods defined in shared context" do
           expect(shared_method).to eq("it works")
         end
@@ -86,6 +107,35 @@ Feature: shared context
         it "accesses the subject defined in the shared context" do
           expect(subject).to eq('this is the subject')
         end
+
+        group = self
+
+        it "inherits metadata from the included context" do |ex|
+          expect(group.metadata).to include(:shared_context => :metadata)
+          expect(ex.metadata).to include(:shared_context => :metadata)
+        end
+      end
+      """
+    When I run `rspec shared_context_example.rb`
+    Then the examples should all pass
+
+  Scenario: Declare a shared context and include it with metadata of an individual example
+    Given a file named "shared_context_example.rb" with:
+      """ruby
+      require "./shared_stuff.rb"
+
+      RSpec.describe "group that does not include the shared context" do
+        it "does not have access to shared methods normally" do
+          expect(self).not_to respond_to(:shared_method)
+        end
+
+        it "has access to shared methods from examples with matching metadata", :include_shared => true do
+          expect(shared_method).to eq("it works")
+        end
+
+        it "inherits metadata from the included context due to the matching metadata", :include_shared => true do |ex|
+          expect(ex.metadata).to include(:shared_context => :metadata)
+        end
       end
       """
     When I run `rspec shared_context_example.rb`

data/rspec-core/upstream/features/example_groups/shared_examples.feature

@@ -1,6 +1,6 @@
 Feature: shared examples
 
-  Shared examples let you describe behaviour of types or modules. When declared,
+  Shared examples let you describe behaviour of classes or modules. When declared,
   a shared group's content is stored. It is only realized in the context of
   another example group, which provides any context the shared group needs to
   run.
@@ -19,6 +19,50 @@ Feature: shared examples
   anything special (like autoload). Doing so would require a strict naming
   convention for files that would break existing suites.
 
+  **WARNING:** When you include parameterized examples in the current context multiple
+  times, you may override previous method definitions and last declaration wins.
+  So if you have this kind of shared example (or shared context)
+
+  ```ruby
+  RSpec.shared_examples "some example" do |parameter|
+    \# Same behavior is triggered also with either `def something; 'some value'; end`
+    \# or `define_method(:something) { 'some value' }`
+    let(:something) { parameter }
+    it "uses the given parameter" do
+      expect(something).to eq(parameter)
+    end
+  end
+
+  RSpec.describe SomeClass do
+    include_examples "some example", "parameter1"
+    include_examples "some example", "parameter2"
+  end
+  ```
+
+  You're actually doing this (notice that first example will fail):
+
+  ```ruby
+  RSpec.describe SomeClass do
+    \# Reordered code for better understanding of what is happening
+    let(:something) { "parameter1" }
+    let(:something) { "parameter2" }
+
+    it "uses the given parameter" do
+      \# This example will fail because last let "wins"
+      expect(something).to eq("parameter1")
+    end
+
+    it "uses the given parameter" do
+      expect(something).to eq("parameter2")
+    end
+  end
+  ```
+
+  To prevent this kind of subtle error a warning is emitted if you declare multiple
+  methods with the same name in the same context. Should you get this warning
+  the simplest solution is to replace `include_examples` with `it_behaves_like`, in this
+  way method overriding is avoided because of the nested context created by `it_behaves_like`
+
   Conventions:
   ------------
 
@@ -32,7 +76,7 @@ Feature: shared examples
       and require files in that directory from `spec/spec_helper.rb`:
 
       ```ruby
-      Dir["./spec/support/**/*.rb"].sort.each { |f| require f}
+      Dir["./spec/support/**/*.rb"].sort.each { |f| require f }
       ```
 
       Historically, this was included in the generated `spec/spec_helper.rb` file in
@@ -60,15 +104,15 @@ Feature: shared examples
         end
 
         describe "#include?" do
-          context "with an an item that is in the collection" do
+          context "with an item that is in the collection" do
             it "returns true" do
-              expect(collection.include?(7)).to be_truthy
+              expect(collection.include?(7)).to be(true)
             end
           end
 
-          context "with an an item that is not in the collection" do
+          context "with an item that is not in the collection" do
             it "returns false" do
-              expect(collection.include?(9)).to be_falsey
+              expect(collection.include?(9)).to be(false)
             end
           end
         end
@@ -91,9 +135,9 @@ Feature: shared examples
           initialized with 3 items
             says it has three items
           #include?
-            with an an item that is in the collection
+            with an item that is in the collection
               returns true
-            with an an item that is not in the collection
+            with an item that is not in the collection
               returns false
 
       Set
@@ -101,9 +145,9 @@ Feature: shared examples
           initialized with 3 items
             says it has three items
           #include?
-            with an an item that is in the collection
+            with an item that is in the collection
               returns true
-            with an an item that is not in the collection
+            with an item that is not in the collection
               returns false
       """
 
@@ -224,11 +268,11 @@ Feature: shared examples
       RSpec.describe String, :a => :b do
       end
       """
-      When I run `rspec shared_example_metadata_spec.rb`
-      Then the output should contain:
-        """
-        1 example, 0 failures
-        """
+    When I run `rspec shared_example_metadata_spec.rb`
+    Then the output should contain:
+      """
+      1 example, 0 failures
+      """
 
   Scenario: Shared examples are nestable by context
     Given a file named "context_specific_examples_spec.rb" with: