Check class collision for scaffold controller generator is broken

[kdiogenes]

Sorry, but I was unable to produce an executable test case for generators from the templates. I'm getting cannot load such file when require "generators/generators_test_helper".

Steps to reproduce

Add the following test case to scaffold_controller_generator_test.rb:

def test_check_class_collision
  Object.send :const_set, :UsersController, Class.new
  content = capture(:stderr) { run_generator ["User"] }
  assert_match(/The name 'UsersController' is either already used in your application or reserved/, content)
ensure
  Object.send :remove_const, :UsersController
end

Expected behavior

Test pass (a collision is detected)

Actual behavior

Test fail (no collision detected)

This generator creates a UsersControllers, but checks UserController for collision. From the check_class_collision implementation I guess that the assumption is wrong. If I understand right, respond_to?(:controller_class_name) will always return false, since controller_class_name is private. In 2017 it was protected and prior to ruby 1.9 I guess that it was returning true based on this ruby issue.

Maybe named_base_test.rb could have exposed this problem if its assert_name implementation doesn't use send. I think everything being tested here is expected to be public, right?

Let me know if my assumptions are right, I'm looking to work in a PR!

[y-yagi]

Can you please provide a sample application that reproduces the issue?

[kdiogenes]

I provided an example application in https://github.com/kdiogenes/generator-class-collision. In the README there I already put the output for the commands rails g scaffold_controller name:string email:string and rails g controller Users name:string email:string.

For the first, there is no complaint about UsersController already being used in the application.

[y-yagi]

Thanks for your example application. I understood the issue.
Your understanding is correct and we need to fix that.

We don't want to expose the APIs unless really need it. In this case, it is better to specify include_all option of respond_to?. Could you fix?