On Mon, Sep 10, 2012 at 5:51 PM, Fearless Fool <li...@ruby-forum.com> wrote:
> I'm trying to understand what belongs -- and what doesn't belong -- in
> controller tests and in integration tests.
>
> As a common example, assume I have a list of named widgets. Somewhere
> in my code, I want to verify that
>
> widget = FactoryGirl.create(:widget)
> get :index
>
> generates a page that has the string #{widget.name} somewhere therein.
> But is that a controller test or an integration test?
>
What's the controller's responsibility here? I see two things:
* choose the right view
* assign the right values to the right variables
Actually rendering the right page with the right text on it sounds like a
view responsibility.
Therefore, how to check that the controller chooses the right view and
assigns the variables correctly?
As another example, assume a user must be logged on in order to access
> the widgets. I can test authentication and authorization separately,
> but is it considered necessary to write an integration test for this?
> Or is this something you'd verify at the controller level?
>
I find this slightly trickier. Again, what's the controller's
responsibility?
* ask to authenticate the user for certain routes
* ask to authorize the user for certain routes
It seems clear which tests to write for the controller, but I don't want to
have to check authentication and authorization for every example I run on a
specific route.
Therefore, check authentication for each route in its own test. Also, check
authorization for each route in its own test. Bad news: this will result in
a lot of duplication in tests; good news: I find it easy to remove this
duplication into a single set of authentication and authorization checks.
Imagine something like this:
describe "authenticate the user" do
ROUTES_REQUIRING_AUTHENTICATION = […]
ROUTES_REQUIRING_AUTHENTICATION.each do | route |
example "when requesting the resource at route #{route}" do
authentication_service.should_receive(…)
get route
end
end
end
The authorization policy checks will be a bit more complicated, but at
least you can gather them all in the same place for easy reference.
Etc. I'm not looking for specific answers to the above as much as
> guiding principles, or at least pointers to same. Thanks!
>
My guiding principles haven't changed in almost 15 years:
http://link.jbrains.ca/simple-design
--
J. B. (Joe) Rainsberger :: http://www.jbrains.ca ::
http://blog.thecodewhisperer.com
Author, JUnit Recipes
Free Your Mind to Do Great Work :: http://www.freeyourmind-dogreatwork.com
_______________________________________________
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
