Cop idea: add a rule for `it` block without any expectations

[yuriidanyliak]

Rubocop complains when there is too many expectations but says nothing when we have it with some code not including any expects. Maybe there is some sense to implement such rule?

[yuriidanyliak]

By the way, I can create corresponding PR, if there is some sense to add this rule.

[bquorning]

I think such a cop makes perfect sense. Just remember to allow these:

1. it without any block.
2. it with a call to skip.
3. it with a call to pending.

See http://www.relishapp.com/rspec/rspec-core/v/3-5/docs/pending-and-skipped-examples/pending-examples and http://www.relishapp.com/rspec/rspec-core/v/3-5/docs/pending-and-skipped-examples/skip-examples

[backus]

If this cop did exist I think it would have to be disabled by default. For example, maybe 80% of the specs for rubocop-rspec use this expect_violation helper method I added which dramatically simplifies things. Seems like this cop would flag these

[bquorning]

What if the cop is configurable with a list of methods? E.g. expext, skip, pending, expect_violation…

[backus]

That would make it much more manageable I think. Checkout the CustomInclude method that EmptyExampleGroup uses: https://github.com/backus/rubocop-rspec/blob/master/lib/rubocop/cop/rspec/empty_example_group.rb#L76

[bquorning]

@yuriidanyliak Do you still want to take a stab at implementing this cop?

[yuriidanyliak]

@bquorning yeah I'll try to implement such cop.

[yuriidanyliak]

Just wrote simplest version of cop. Going to make it more flexible and create a PR.

[pirj]

There are cases when this will result in false positives:

def expect_processed_value
  expect(process(value))
end

def surprise_the_crowd
  eq(100)
end

it 'is hard to detect an expectation here' do
  expect_processed_value.to surprise_the_crowd
end

[dgollahon]

As @backus pointed out, we would probably need to disable by default--there is a lot of room for false positives. A configurable whitelist probably covers most cases though.