Add new RedundantContext cop

[tejasbubane]

To check context with single example.

Closes #2001

---

Before submitting the PR make sure the following are checked:

• Feature branch is up-to-date with master (if not - rebase it).
• Squashed related commits together.
• Added tests.
• Updated documentation.
• Added an entry to the CHANGELOG.md if the new code introduces user-observable changes.
• The build (bundle exec rake) passes (be sure to run this locally, since it may produce updated documentation that you will need to commit).

If you have created a new cop:

• Added the new cop to config/default.yml.
• The cop is configured as Enabled: pending in config/default.yml.
• The cop is configured as Enabled: true in .rubocop.yml.
• The cop documents examples of good and bad code.
• The tests assert both that bad code is reported and that good code is not reported.
• Set VersionAdded: "<<next>>" in default/config.yml.

[tejasbubane]

Seems like we have a bunch of occurrences in this repo where we use single example inside context.

[koic]

It’s doubtful whether this should be regarded as "redundant" or as an appropriate use of vocabulary, as it depend on individual judgment. The justification provided in #2001 doesn’t seem entirely sufficient, at the least, it seems this cop should be disabled by default.

[ydah]

IMO, I am reluctant to add this cop. Our project goal is to enforce the guidelines and best practices outlined in the community RSpec style guide. Currently, I am skeptical about whether this approach qualifies as a best practice. As a first step, it might be better to start by discussing in the RSpec Style Guide.

[bquorning]

I like this cop. I have often manually changed specs like

context "when foo" do
  it "does bar" do
  end
end

into

it "does bar when foo" do
end

but I agree that it should probably be disabled by default.

[pirj]

Just specifically context and it?
I’dd love to have at least balancing examples for describe/example aliases if it’s a deliberate design choice.

[pirj]

The _ suggests that it only has one anything argument, with an assumption that it’s a docstring. But what if there’s a secondary string argument, or symbolic/hash metadata, too?

[pirj]

Cosmetic: I think the receiver should be nil here, not _

[pirj]

Will a numblock match with the current node pattern?

[pirj]

It is more fair to say “when the example is the only statement inside the example group. Eg another it_behaves_like or a method def would cause the cop to ignore the group.

Are there any cases with more than one statement (but one example) that we still want to flag/correct?
If not - just ignore this note, just make the description more generic, and maybe add another example with an example and some other statement in an example group.

[pirj]

I’m usually strongly against disabling cops, but this one, even though certainly serving some projects that strive to enforce this style, isn’t a good fit for the majority.

I support what @koic and @bquorning said.

[ydah]

If we are going to disable on default this Cop, I don’t think it should be added in the first place. It might be useful as a custom Cop for users, but I’m skeptical about whether it should be one that we maintain. For example, in my case, I group such Cops into my own custom Cop collection:

• https://github.com/ydah/rubocop-rspec-extra

[pirj]

Fair enough, @ydah
Btw be_empty is a nice one, but it’s probably unsafe for cases when the target is not an array.

@bquorning wdyt?