> In the case a developer has not constructed a controller, the setup
> method of ActionController::TestCase will attempt to construct a
> controller object. If it cannot construct a controller object, it
> silently fails.
> I added a warning in this case, and I'd like to eventually deprecate the
> behavior. I can't think of why anyone would want to use
> ActionController::TestCase and *not* test a controller. Does anyone
> know a reason *why* we would do this?
Maybe I'm missing something, but doesn't the call to setup_controller_request_and_response happen *before* any user-defined setup methods get called? In that case, it's intended to let users do unusual things (that don't set, or set to nonsense, controller_class) and then set up their own controller object.
Yes, I think that is true. However, there is the `controller_class=`
and the `tests` class method that you can use when AC::TC cannot intuit the
controller class from your test class name:
If you needed a dynamic anonymous controllers, you could just implement
the `controller_class` method on your test case, e.g.:
class FooTest < ActionController::TestCase
# new anonymous subclass on every test
There are some related commits that seem relevant:
I'd say there's a good chance that all of these changes are intended to support doing things like this:
I could be mistaken, but I don't think RSpec uses AC::TC behavior
methods. Maybe Mr. Chelimsky can enlighten us.
by handling the case where the controller-under-test isn't a named constant.
As I demoed above, the controller doesn't need to be a named constant,
you just need to implement the correct factory method. So I'm still at
a loss why we would want to support "unconstructable" controllers.
The reason I want to get rid of this code is because there is currently
a code path that allows `@controller` to be nil during the test run.
This is annoying because there are *many* methods that depend on this
instance variable, yet we cannot guarantee that the instance variable is
If this is truly something that is for RSpec only, then perhaps this
behavior should be pushed to RSpec rather than maintained in Rails.