5

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.

Darien
  • 3,482
  • 19
  • 35
  • Update: The project is in stasis for now, but I ended up writing a custom locator for Selenium-IDE. When a given element is selected, it creates a "breadcrumb path" to it by looking for a custom HTML5 data-attribute on all parent nodes, ex: `[FooControl,Toolbar,BarControl,Toolbar,ButtonSave]` This way developers deliberately annotate the View with nested labels (which only need to be unique in their own context), isolating the problem from issues like CSS styling or changing spans to divs etc. I plan to open-source it up on GitHub if I can get legal approval. – Darien May 31 '11 at 19:15

2 Answers2

1

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.

Rajasankar
  • 928
  • 1
  • 19
  • 41
0

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/

Samo
  • 8,202
  • 13
  • 58
  • 95
  • I personally wouldn't even mind even using jQuery expressions. I'm not trying to pick on XPath in particular, I just mean that there's been push-back against anything that would require testers to understand or alter what Selenium-IDE's recording feature generates for them. – Darien Jan 03 '11 at 21:05
  • Hire new testers :) Really though, I can definitely see how generating unique (and predictable) IDs would be a major pain in your situation. Best of luck! – Samo Jan 03 '11 at 21:11