Javascript and Ajax testing with Cucumber, RSpec and Webrat ?

[Daryl Manning]

Just post Railscamp we're trying to be a lot better about testing and we've got at least one new app which has a small greek army of ajax (ajaxes? ajaxi? ajuxes?).

Was very curious as to what other people down here in Oceania are using to do their js and ajax testing. So far, Blueridge is looking good, but curious as to pros and cons from everyone who tests this stuff regularly.

thanks !
Daryl.
PS> So, yes watir, selenium and others are in there as well and just trying to find something to standardize on in here. Caveats: We've got a small dev team so it can't have too much of an admin or learning curve footprint

[Gareth Townsend]

My take.

Use selenium, power it through cucumber.

Only use it when testing AJAX.

Avoid in-browser testing wherever possible, otherwise your build times
will sky rocket!

> --
>
> You received this message because you are subscribed to the Google
> Groups "Ruby or Rails Oceania" group.
> To post to this group, send email to rails-...@googlegroups.com.
> To unsubscribe from this group, send email to rails-oceani...@googlegroups.com
> .
> For more options, visit this group at http://groups.google.com/group/rails-oceania?hl=en
> .

[Josh Price]

I'm with Gareth on this.

Unit test your JS, and even if you use BlueRidge to remove the DOM
from the equation, you'll eventually have do it in each browser. I
really like ScrewUnit, but there are other frameworks out there. The
problem with JS tests is it's fairly funky to include these in your
build. I've been on projects where we used Selenium to do this, but
it was overly complex.

Ideally you want to test everything in isolation in your app then use
Selenium (or equivalent) for your functional tests to make sure
everything hangs together.

Josh

[Andrew Grimm]

I wouldn't mind a talk on how to minimise admin footprints, if that's
an issue other people have.

Andrew

[Lachie]

On Thu, Nov 26, 2009 at 5:14 PM, Josh Price <jos...@gmail.com> wrote:
> I'm with Gareth on this.
>
> Unit test your JS, and even if you use BlueRidge to remove the DOM
> from the equation, you'll eventually have do it in each browser.  I
> really like ScrewUnit, but there are other frameworks out there.  The
> problem with JS tests is it's fairly funky to include these in your
> build.  I've been on projects where we used Selenium to do this, but
> it was overly complex.
>
> Ideally you want to test everything in isolation in your app then use
> Selenium (or equivalent) for your functional tests to make sure
> everything hangs together.
>
> Josh
>
>
> On 26/11/2009, at 5:00 PM, Gareth Townsend wrote:
>
>> My take.
>>
>> Use selenium, power it through cucumber.

Cucumber is definitely the right tool to drive these tests; and from
the cucumber github wiki (
http://wiki.github.com/aslakhellesoy/cucumber/javascript-and-ajax )

"Cucumber relies on 3rd party libraries for anything Javascript
related, including AJAX. We recommend one of these to test Javascript
functionality:

Celerity / Culerity
Watir or any of its cousins for browsers other than IE.
WebDriver
Selenium (The oldest and buggiest of them all)
Blue Ridge

All of these have Ruby APIs (or Java APIs that you can use if you run
Cucumber on JRuby), and all you need to do is use these APIs in your
Step Definitions."

The enduring problem with most of these is CI (continuous
integration), more specifically getting known, robust and reliable
state set up and running before each CI go around.

[Robert Postill]

Actually on a recent jruby project I was introduced to the awesome of
celerity (see http://celerity.rubyforge.org/). Celerity is a wrapper
around HTMLUnit which can run JavaScript through Rhino (hence the
JRuby focus). The speed increase over Selenium was amazing and well
worth checking out. Selenium is just such hard work (ever entered a
sleep just because your JavaScript was getting caught in Selenium? I
have:( ) I feel bad recommending it to anyone these days.

I used ScrewUnit for JavaScript on a recent project and while it
feels so nasty it is better than nowt. JSCoverage was hard to
integrate, hard to use and when I worked out *what* it did to the
JavaScript I needed a moment to lie down. I'd struggle to recommend
JSCoverage due to the poor bang for buck ratio.

Rob

2009/11/26 Gareth Townsend <gareth....@me.com>:

--

Ogden Nash - "The trouble with a kitten is that when it grows up,
it's always a cat." -
http://www.brainyquote.com/quotes/authors/o/ogden_nash.html