<commit_before>Feature: shared examples

  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.

  A shared group is included in another group using any of:

  ```ruby
  include_examples "name"      # include the examples in the current context
  it_behaves_like "name"       # include the examples in a nested context
  it_should_behave_like "name" # include the examples in a nested context
  matching metadata            # include the examples in the current context
  ```

  **WARNING:** Files containing shared groups must be loaded before the files that
  use them.  While there are conventions to handle this, RSpec does _not_ do
  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_example "some example", "parameter1"
    include_example "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_example` with `it_behaves_like`, in this
  way method overriding is avoided because of the nested context created by `it_behaves_like`

  Conventions:
  ------------

  1.  The simplest approach is to require files with shared examples explicitly
      from the files that use them. Keep in mind that RSpec adds the `spec`
      directory to the `LOAD_PATH`, so you can say `require
      'shared_examples_for_widgets'` to require a file at
      `#{PROJECT_ROOT}/spec/shared_examples_for_widgets.rb`.

  2.  One convention is to put files containing shared examples in `spec/support/`
      and require files in that directory from `spec/spec_helper.rb`:

      ```ruby
      Dir["./spec/support/**/*.rb"].sort.each { |f| require f}
      ```

      Historically, this was included in the generated `spec/spec_helper.rb` file in
      `rspec-rails`. However, in order to keep your test suite boot time down,
      it's a good idea to not autorequire all files in a directory like this.
      When running only one spec file, loading unneeded dependencies or performing<commit_msg>Shared examples feature has wrong description.<commit_after>Feature: shared examples

  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.

  A shared group is included in another group using any of:

  ```ruby
  include_examples "name"      # include the examples in the current context
  it_behaves_like "name"       # include the examples in a nested context
  it_should_behave_like "name" # include the examples in a nested context
  matching metadata            # include the examples in the current context
  ```

  **WARNING:** Files containing shared groups must be loaded before the files that
  use them.  While there are conventions to handle this, RSpec does _not_ do
  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:
  ------------

  1.  The simplest approach is to require files with shared examples explicitly
      from the files that use them. Keep in mind that RSpec adds the `spec`
      directory to the `LOAD_PATH`, so you can say `require
      'shared_examples_for_widgets'` to require a file at
      `#{PROJECT_ROOT}/spec/shared_examples_for_widgets.rb`.

  2.  One convention is to put files containing shared examples in `spec/support/`
      and require files in that directory from `spec/spec_helper.rb`:

      ```ruby
      Dir["./spec/support/**/*.rb"].sort.each { |f| require f}
      ```

      Historically, this was included in the generated `spec/spec_helper.rb` file in
      `rspec-rails`. However, in order to keep your test suite boot time down,
      it's a good idea to not autorequire all files in a directory like this.
      When running only one spec file, loading unneeded dependencies or performing
{'fraction_non_alphanumeric': 0.06894070236039147, 'fraction_numerical': 0.002302820955670697, 'mean_word_length': 3.440255591054313, 'pattern_counts': {'":': 0, '<': 3, '<?xml version=': 0, '>': 3, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '2227875', 'n_tokens_mistral': 1841, 'n_tokens_neox': 1739, 'n_words': 876}