False positive for RSpec/RedundantPredicateMatcher at be_respond_to(:method, true)

[Tietew]

Expected behavior

Following usage is allowed:

it 'responds to bar' do
  expect(subject).to be_respond_to(:a_private_method, true)
end

This tests the subject responds to a private method a_private_method.

Actual behavior

RSpec/RedundantPredicateMatcher detected and autocorrected to respond_to(:symbol, true)

it 'responds to bar' do
  expect(subject).to respond_to(:a_private_method, true)
end

raises following error:

    Failure/Error: expect(subject).to respond_to(:a_private_method, true)
    TypeError:
       true is not a symbol nor a string

Because respond_to matcher accepts list of method symbols.
https://www.rubydoc.info/gems/rspec-expectations/RSpec%2FMatchers:respond_to

Steps to reproduce the problem

Run rubocop on:

it 'responds to bar' do
  expect(subject).to be_respond_to(:a_private_method, true)
end

RuboCop RSpec version

$ be rubocop -V
1.69.2 (using Parser 3.3.6.0, rubocop-ast 1.37.0, analyzing as Ruby 3.1, running on ruby 3.3.6) [x86_64-linux]
  - rubocop-capybara 2.21.0
  - rubocop-factory_bot 2.26.1
  - rubocop-i18n 1.14.6
  - rubocop-performance 1.23.0
  - rubocop-rails 2.27.0
  - rubocop-rake 0.6.0
  - rubocop-rspec 3.3.0
  - rubocop-rspec_rails 2.30.0

[pirj]

Can you please provided more details, what are you testing exactly?

I understand what the problem is, but at a glance it’s unlikely that the respond_to matcher is designed to check private methods. And, presumably, for a reason.

[Tietew]

@pirj Thank you for comment

I have a class that defines private methods dynamically.
I want to test whether the method is defined correctly.

it’s unlikely that the respond_to matcher is designed to check private methods.
Agreed. This is the reason why I use be_respond_to dynamic matcher.

[pirj]

Given so few information, I can suggest testing the class’s public interface instead. There is some influence from creation of those private methods on the public interface, isn’t there?