Problem At my workplace, we're trying to find the best way to create automated-tests for an almost wholly javascript-driven intranet application. Right now we're stuck trying to find a good tradeoff between: Application code in reusable and nest-able GUI components. Tests which are easily created by the testing team Tests which can be recorded once and then automated Tests which do not break after small cosmetic changes to the site XPath expressions (or other possible expressions, like jQuery selectors) naively generated from Selenium-IDE are often non-repeatable and very fragile. Conversely, having the JS code generate special unique ID values for every important DOM-element on the page... well, that is its own headache, complicated by re-usable GUI components and IDs needing to be consistent when the test is re-run. What successes have other people had with this kind of thing? How do you do automated application-level testing of a rich JS interface? Limitations We are using JavascriptMVC 2.0, hopefully 3.0 soon so that we can upgrade to jQuery 1.4.x. The test-making folks are mostly trained to use Selenium IDE to directly record things. The test leads would prefer a page-unique HTML ID on each clickable element on the page... Training the testers to write or alter special expressions (such as telling them which HTML class-names are important branching points) is a no-go. We try to make re-usable javascript components, but this means very few GUI components can treat themselves (or what they contain) as unique. Some of our components already use HTML ID values in their operation. I'd like to avoid doing this anyway , but it complicates the idea of ID-based testing. It may be possible to add custom facilities (like a locator-builder or new locator method) to the Selenium-IDE installation testers use. Almost everything that goes on occurs within a single "page load" from a conventional browser perspective, even when items are saved Current thoughts I'm considering a system where a custom locator-builder (javascript code) for Selenium-IDE will talk with our application code as the tester is recording. In this way, our application becomes partially responsible for generating a mostly-flexible expression (XPath or jQuery) for any given DOM element. While this can avoid requiring more training for testers, I worry it may be over-thinking things.

javascripttestingseleniumselenium-idejavascriptmvc

Reputation: 3592

Using Selenium-IDE with a rich Javascript application?

Problem

At my workplace, we're trying to find the best way to create automated-tests for an almost wholly javascript-driven intranet application. Right now we're stuck trying to find a good tradeoff between:

Application code in reusable and nest-able GUI components.
Tests which are easily created by the testing team
Tests which can be recorded once and then automated
Tests which do not break after small cosmetic changes to the site

XPath expressions (or other possible expressions, like jQuery selectors) naively generated from Selenium-IDE are often non-repeatable and very fragile. Conversely, having the JS code generate special unique ID values for every important DOM-element on the page... well, that is its own headache, complicated by re-usable GUI components and IDs needing to be consistent when the test is re-run.

What successes have other people had with this kind of thing? How do you do automated application-level testing of a rich JS interface?

Limitations

We are using JavascriptMVC 2.0, hopefully 3.0 soon so that we can upgrade to jQuery 1.4.x.
The test-making folks are mostly trained to use Selenium IDE to directly record things.
The test leads would prefer a page-unique HTML ID on each clickable element on the page...
Training the testers to write or alter special expressions (such as telling them which HTML class-names are important branching points) is a no-go.
We try to make re-usable javascript components, but this means very few GUI components can treat themselves (or what they contain) as unique.
Some of our components already use HTML ID values in their operation. I'd like to avoid doing this anyway, but it complicates the idea of ID-based testing.
It may be possible to add custom facilities (like a locator-builder or new locator method) to the Selenium-IDE installation testers use.
Almost everything that goes on occurs within a single "page load" from a conventional browser perspective, even when items are saved

Current thoughts

I'm considering a system where a custom locator-builder (javascript code) for Selenium-IDE will talk with our application code as the tester is recording. In this way, our application becomes partially responsible for generating a mostly-flexible expression (XPath or jQuery) for any given DOM element. While this can avoid requiring more training for testers, I worry it may be over-thinking things.

Upvotes: 5

Answers (2)

Rajasankar

Reputation: 928

Record and Playback will not work in large scale testing. It may work for smoke tests and small repetitive tasks.

Instead of trying to generate unique IDs, try to solve that with CSS based selectors. Generating unique ids is ideal goal but I don't think that is possible in all practical cases.

If you trying to look for custom locators, it is better to look into BDD.

Upvotes: 1

Samo

Reputation: 8240

Can't you use css selectors with Selenium? That seems a little more straightforward than using XPath.

http://saucelabs.com/blog/index.php/2010/01/selenium-totw-css-selectors-in-selenium-demystified/

Upvotes: 0

Using Selenium-IDE with a rich Javascript application?

Problem

Limitations

Current thoughts

Answers (2)

Related Questions