Reinstantiate controller during functional testing

Rails
1

… ok, I may be going about this the wrong way, or perhaps, a less
efficient way than is optimal, but I would like to test a little bit
of AJAX on one of my web pages. When I test this by hand, I bring up
the page which shows a select box, I select an item from the drop down
list, see another select box show up, go back to the first select box,
select a different item, and see something different happen.

I have tried to script this up in my functional test with something like
this:

test “blah blah blah”
xhr :post,
:add_lot_to_assembly,
:id => lots(:lot_one).to_param,
:use_part => parts(:part_three).to_param
assert_response :success

xhr :post,
    :add_lot_to_assembly,
    :id => lots(:lot_one).to_param,
    :use_part => parts(:part_two).to_param
assert_response :success

end

The problem is, there is an instance variable in my controller that is
set during the handling of the first #add_lot_to_assembly action. It
remains set for the second invocation of #xhr. This makes me think
that the controller instance is not reinstantiated between calls to
#xhr.

Am I misunderstanding this?

Is there some way to reinstantiate the controller prior to the 2nd xhr
call?

Is there a better way to have structured my functional test?

Should I be using something other than a functional test to test this
sort of behavior?

–wpd

2

On Oct 14, 1:19 pm, Patrick D. [email protected] wrote:

The problem is, there is an instance variable in my controller that is
set during the handling of the first #add_lot_to_assembly action. It
remains set for the second invocation of #xhr. This makes me think
that the controller instance is not reinstantiated between calls to
#xhr.

Am I misunderstanding this?

It sounds like you’ve got a clear idea what’s going on.

Is there some way to reinstantiate the controller prior to the 2nd xhr call?

Is there a better way to have structured my functional test?

Should I be using something other than a functional test to test this
sort of behavior?

The standard way of doing multiple requests in a test is to use an
integration test. It already takes care of a lot of the stuff you’d
need to deal with trying to shoehorn this into a functional test.

–Matt J.

3

Patrick D. wrote:
[…]

Do folks generally use the default (implied to mean, “blessed by the
Rails developers”) integration tests to test AJAX behavior? Or do
folks use one of the other test platforms out there?

Since you asked…

I don’t use the default integration tests for anything. That’s what
Cucumber is for, to my mind. For Ajax, you may need to integrate
Selenium into Cucumber (which is possible, but I’ve never had to do it).

I come from a background of “I won’t really understand why test
platform ABC is better than the default until I have fully appreciated
the limitations of the default test platform.” So I will probably
stay with the standard template for unit, functional, and integration
tests until I run into something that just doesn’t work well without
one of the other platforms.

True to a point. Have you played around with anything else out there
(RSpec?)?

–wpd

Best,

Marnen Laibow-Koser
http://www.marnen.org
[email protected]

4

On Thu, Oct 15, 2009 at 12:48 PM, Marnen Laibow-Koser
[email protected] wrote:

Patrick D. wrote:
True to a point. Have you played around with anything else out there
(RSpec?)?
Not yet… My applications and their associated tests have been
trivial and mostly been used as a learning tool for myself. I have
seen references to RSpec, Cucumber, and several other test platforms.

I am quite certain that they all address needs that aren’t met by the
standard unit/functional/integration tests baked into RoR.

But I figure that that, if the standard unit/functional/integration
tests are good enough for the RoR developers, they should be good
enough for me.

I am assuming (of course) that the RoR developers use the standard
test templates. If they don’t, then why is that template (still)
included in RoR?

It’s probably included because it was standard at some point in time,
and works well enough for small, simple projects.

Which are all I’ve played with so far. As my projects get bigger or
more complicated, then I’ll probably run into the same limitations
that inspired the other test environments and learn from that process.

–wpd

5

On Thu, Oct 15, 2009 at 12:27 PM, Matt J. [email protected] wrote:

It sounds like you’ve got a clear idea what’s going on.
integration test. It already takes care of a lot of the stuff you’d
need to deal with trying to shoehorn this into a functional test.

Thanks Matt,
As I was writing my email, I started wondering if I should be using an
integration test instead of a functional test. (Hence my last
question). My understanding of integration tests is that they are
geared towards testing a flow of operations across multiple
controllers. I always thought of that as “multiple different
controllers”, but obviously there is no reason why that has to be the
case.

I can go fix that. In the mean time (and just in case anybody
stumbles over this thread in the future), I found that putting:

@controller = LotsController.new

in between my two calls to xhr solved my particular problem.

Do folks generally use the default (implied to mean, “blessed by the
Rails developers”) integration tests to test AJAX behavior? Or do
folks use one of the other test platforms out there?

I come from a background of “I won’t really understand why test
platform ABC is better than the default until I have fully appreciated
the limitations of the default test platform.” So I will probably
stay with the standard template for unit, functional, and integration
tests until I run into something that just doesn’t work well without
one of the other platforms.

–wpd

6

Patrick D. wrote:

On Thu, Oct 15, 2009 at 12:48 PM, Marnen Laibow-Koser
[email protected] wrote:

Patrick D. wrote:
True to a point. �Have you played around with anything else out there
(RSpec?)?
Not yet… My applications and their associated tests have been
trivial and mostly been used as a learning tool for myself. I have
seen references to RSpec, Cucumber, and several other test platforms.

I am quite certain that they all address needs that aren’t met by the
standard unit/functional/integration tests baked into RoR.

Not necessarily. Some of them address the same needs, just in different
ways.

But I figure that that, if the standard unit/functional/integration
tests are good enough for the RoR developers, they should be good
enough for me.

Bad assumption. You’re not the Rails core team. Your needs may be
different from those of the Rails core team.

I am assuming (of course) that the RoR developers use the standard
test templates. If they don’t, then why is that template (still)
included in RoR?

There’s a lot of crap in Rails because it hasn’t been removed yet
(coughfixturescough).

It’s probably included because it was standard at some point in time,
and works well enough for small, simple projects.

Which are all I’ve played with so far. As my projects get bigger or
more complicated, then I’ll probably run into the same limitations
that inspired the other test environments and learn from that process.

I wonder. RSpec and Cucumber are good even for small, simple stuff.
You’re falling into the trap of assuming that the Rails core team is
perfect.

–wpd

Best,

Marnen Laibow-Koser
http://www.marnen.org
[email protected]

7

On Thu, Oct 15, 2009 at 1:06 PM, Marnen Laibow-Koser
[email protected] wrote:

I wonder. RSpec and Cucumber are good even for small, simple stuff.
You’re falling into the trap of assuming that the Rails core team is
perfect.

:slight_smile:

That may be the case. I prefer to think of it as assuming that the
Rails core team has more experience with this sort of thing than I
will ever have.

I’ll take a closer look at RSpec and Cucumber, especially since you
(yet another developer with vastly more experience at this sort of
thing than I have) have suggested it (and I have learned to respect
your suggestions based on your activity on this list).

Thanks for the tips.

Please keep them up.

–wpd