Rails - Oct 2009 - Reinstantiate controller during functional testing

... 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

On Oct 14, 1:19 pm, Patrick Doyle
<wpds...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
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 Jones

On Thu, Oct 15, 2009 at 12:27 PM, Matt Jones
<al2o3cr-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
> On Oct 14, 1:19 pm, Patrick Doyle
<wpds...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 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.
>
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

Patrick Doyle 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
marnen-sbuyVjPbboAdnm+yROfE0A@public.gmane.org
-- 
Posted via http://www.ruby-forum.com/.

On Thu, Oct 15, 2009 at 12:48 PM, Marnen Laibow-Koser
<rails-mailing-list-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org>
wrote:
> Patrick Doyle 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

Patrick Doyle wrote:
> On Thu, Oct 15, 2009 at 12:48 PM, Marnen Laibow-Koser
> <rails-mailing-list-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org> wrote:
>> Patrick Doyle 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
(*cough*fixtures*cough*).
> 
> 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
marnen-sbuyVjPbboAdnm+yROfE0A@public.gmane.org
-- 
Posted via http://www.ruby-forum.com/.

On Thu, Oct 15, 2009 at 1:06 PM, Marnen Laibow-Koser
<rails-mailing-list-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org>
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.
>
:-)

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