Chris T wrote:
Eric
Thanks for the suggestions. Actually it is working in the browser.
After a bit of digging, I thought the problem might be with the
current_user method which wasn’t being updated with the change in
session[:user], so posted the query on Railsweenie hoping Rick might be
able to help (as the author of acts_as_authenticated). This is what he
said (which makes sense):
You can't call a controller method multiple times in a functional
test. Instance variables like @controller, @request, and @response
don't get recycled. So, since the same controller instance is
sticking around, that means the same @current_user is too.
Interesting, so it was “almost” a caching type issue…
Not sure if there’s a good way to achieve what I’m trying to do – it’s
not particular the Hello user I want to test, but I want to test the
number of items each user sees of a particular kind). Do separate tests
for each case? Or loop through a test rather than the controller method?
Or could (should?) I use integration tests (which i haven’t yet
investigated)?
I tend to subscribe to the ~1 assertion per test approach. Controller
tests already start to push that to 2-4 assertions so I definitely
wouldn’t combined tests for different aspects of the same functionality
into one test. So yes, I’d break up the test to separate cases.
Are you trying to test that the Model retreived the correct number of
things (in which case that would probably belong in a unit test of the
model, not the controller), or is there some controller side logic that
affects the list before rendering that you need to test?
Or are you testing that a list renders properly, perhaps with some
alternate text for cases where there are no elements? From a list
viewpoint, when I’m being pendantic in my tests, I’ll commonly take an
induction-based approach and write a test for each of the following:
base cases (empty list, one item list)
inductive case (assume it works for n, prove that it works for n+1)
Note, some testers talk about testing 0,1,2 and calling it “inductive”,
but unless the test case for 2 is written properly its not inductive.
An inductive test case looks like:
def test_inductive_step_for_foo
current_result = foo.method_to_test
foo.add next_foo
assert_equal current_result+correct_delta, foo.method_to_test
end
(of course method names, variables, and mechanism for combining
current_result and correct_delta will vary, but the key point is that
transformation from one state to the next is correct, not merely that
each state is correct.)
Eric