Site MapAccessibilityContact Us

Call us at (855) 254-1164 to learn more about Enterprise

PushToTest - Open Source Test

Taking Selenium To The Next Level

10 Excellent Selenium Testing Resources For You

I recently hosted a Become A Test Expert Webinar with Adam Goucher of the Selenium project. It was a fun Workshop. For all the testers in the world dedicated to building brittle, unmaintainable, and unmanageable tests, Adam has one direct message: You Are Doing It Wrong! Adam presented testing from a goal to let people test higher quality software builds with greater efficiency. Testers who watch the screencast learn how to write modular, easily mataintained test code in a rapid fashion.

Here is a list of 10 excellent Selenium testing resources that we discussed in the Workshop for you:
  • Testing Versus Checking - Adam's opinion article on the difference between testing a Web application and checking that a Web application works
  • Abstracting Locators in Selenese (Se-IDE) - How to write really concise and easily changeable Selenium element locators
  • Selenium IDE (Se-IDE) plugin tutorial - How to write your extensions to the Selenium IDE record/playback tool
  • CSS Locators Reference - a one-page quick reference
  • Page Objects - an object oriented approach to writing Selenium tests. Read an introductory article and an article on understanding Elements and Actions
  • Using a Continuous Integration (CI) server as a Se-Grid replacement. Read the TestMaker CI Guide.
  • Read Adam's Blog
  • A 30-minute tutorial on Repurposing Selenium Tests as Load and Performance Tests
  • Adam's Big Continuous Delivery Summary commentary on DevOps
  • Selenium 2 RefCard from DZone
  • Selenium RefCard (covers Selenium 1 and TestMaker)
Please Tweet me with resources you found to take Selenium to the next level. Enjoy.

-Frank


Michael Sorens comments:

1.       Your link for "Abstracting Locators in Selenese" (http://www.pushtotest.com/How%20To%20Minimize%20The%20Pain%20Of%20Locator%20Breakage) is broken. The correct link is http://saucelabs.com/blog/index.php/2010/09/how-to-minimize-the-pain-of-locator-breakage/

2.       Your link for "CSS Locators Reference" (http://saucelabs.com/blog/index.php/2011/01/why-jquery-in-selenium-css-locators-is-the-way-to-go/) is not really a CSS Locators Reference. It is a partial list; just the Sizzle enhancements apparently.

3.       You asked for other useful resources—take a look at my article and wallchart “XPath, CSS, DOM and Selenium: The Rosetta Stone” on Simple-Talk.com.

Keep up the good work!

~~Michael Sorens

---

Also, Adam Goucher posted this to the Selenium Developer list

Hey! Something I actually know about...

So, in IDE/RC we use Sizzle (http://sizzlejs.com) for CSS Selector-ing with no delegation to the browser. Which means you get all the Sizzly goodness of :contains(), :nth(), etc.

In WebDriver (/not/ Se2 since Se2 also has RC) the logic is as follows:
1) Check whether querySelector (or whatever the DOM function is) is available in the browser (it isnt in IE6 and 7 for instance) -- if not then jump to 3
2) Check whether querySelector returns an element -- if not then jump to 3 otherwise return the element
3) Inject Sizzle into the page and do a lookup for the element returning the element if it finds one and throwing some sort of exception otherwise

This is the oft mentioned fall-back-to-Sizzle scenario.

But.

Since we fall-back-to-Sizzle, does this mean that you can use the Sizzle extensions CSS? No. What happens when you send :contains() for instance to step two is you get an exception, not a 'I didn't find a locator using this string' message that would cause you to just skip along to three -- and then get an element.

Does this suck from a have-user-accessible-css perspective? Oh, absolutely[1]. But it also means that the project isn't tied to Sizzle for CSS fallback support if a RickyTheDancingDolphin CSS library comes along that it magnitudes faster at this but doesn't support all the Sizzle extensions.

I've got a blog post in the hopper at Sauce Labs which I hope to get out this week that has code how to work around this, but the general recommendations appear to be:

For RC:
- css= locators should be w3c locators
- dom= can be used to find elements via sizzle extensions

For WebDriver
- By.CSS_SELECTOR should be w3c locators
- Sizzle can be injected and called using the JavascriptExecutor

(You have no idea how much I have hurt my brain in the last two weeks to really understand this...)

-adam

[1] And I think it is another WebDriver migration disaster to not support Sizzle selectors at least initially whilst trying to coax people to start using it. A better idea would be to catch the parse exception, print out a deprecation warning and wean people off of sizzle specific css locators in By.CSS_SELECTOR. But I'm going to limit my 'migration experience' ranting for this email to just this.