Selenium Blog

I have drastically fallen behind on the link reporting, but not the collecting, so this week’s Smattering will be multi-part.

The ‘big’ news falls for this edition is two fold –

1. We’re having a conference! Selenium Conference 2011 is April 4 – 6, 2011 in San Francisco. See the site for more information. (And I think our friends at Watir are going to be in the same space the day before.)
2. The Betas are here! The Beta’s are here! As Simon’s post announced, Selenium 2.0b1 has been released to the [unsuspecting] masses. Everyone, including Se-RC users are encouraged to switch their server over to it — its backwards compatible with 1.x and has a tonne of important fixes (like the HEAD request on open, -htmlSuite works again, etc.)

And not to downplay things, but here are the usual assortment of things I think are of interest/value to those automating stuff [with Selenium].

• Checklists are a Good Thing™ when it comes to testing, so why not automation too? So here is a Unit Test Review Checklist
• ExtJS is one of those things that seems to come up more often than not on the se-users list which makes me think I’m lucky that none of my clients use it. Testing Extjs Application With Selenium : Few Pointers seems like it would be useful in such an event though.
• Those of us around the automation space for awhile have often heard about Google’s mythic ‘Small, Medium, Large’ scheme for categorizing scripts — and now they are documented. Combining this idea with tagging of scripts and you’re laughing.
• Looks like IBM is now starting to care about Selenium in developerWorks with Automated web testing with Selenium which has an assortment of quick things to help people out. And it is IBM so it got lots of love from folks [bots?] on Twitter.
• Personas is something from the UX community that I’ve started to think more about in terms of what gets automated and/or how the the scripts are organized. The Persona Cheat Sheet will help you start down that road too.
• Testing Experience magazine recently had an Open Source issue which had some interesting articles. Doesn’t appear to be anything groundbreaking, but my definition of that might be a bit warped.
• Oooo! All of this year’s GTAC videos in one place. Now you really can pretend you were in India for the week.
• Go faster! Linking data generation to hotkeys is one of those posts that could be quite useful if you use automation to move quickly around a site so you can manually test it.
• Selenium IDE 1.0.10 is a ‘stable’ version (unlike 1.0.8 and 1.0.9 it seems) but did introduce one change to how element attributes are handled which I documented in Atoms have come to Selenium IDE
• Using Python’s unittest module? Consider upgrading to unittest2

Only 46 more links to go through… 🙂

Share this:

We recently released the first of the betas for Selenium 2. It’s available for Java, C# and Ruby. If you’ve been holding off trying Selenium 2 because of the alpha label, then the biggest improvement you’ll see is with the new WebDriver APIs, but there’s a lot more!

• A promise of relatively stable APIs
• For Firefox only right now, an API for dealing with alerts, prompts and confirms.
• A brand new IE driver.
• Better selenium emulation when using webdriver
• And a better implementation of webdriver’s API backed by the traditional Selenium technology.
• Ubiquitous use of Sizzle for emulating CSS selectors where native CSS selectors aren’t supported
• The advanced user interactions API
• An update to the AndroidDriver’s Android app.

Of course, we’d love this release to be completely bug free, but this is, after all, a beta, so there are some known issues:

• The selenium 1.x emulation using IE is a little flaky.
• The ChromeDriver is not as capable as the others.
• Anything in our bug list.

You can download it from here:

http://code.google.com/p/selenium/downloads/list

You can read the javadocs and the ruby docs.

An obvious question is “When will the beta end?” The short answer is when we’ve implemented the alerts and prompts and advanced user interactions APIs in all supported browsers. We expect there to be some flex in some APIs (removing deprecated methods, and within the advanced user interactions API) but what you have here is basically what you’re going to get when we hit 2.0 final. I have no idea how long this will take, but if you’re interested in helping out, let us know!

Thanks are due to all the committers who have worked so hard to get this code into shape. Thanks are also due to all the people who have taken the time to file bugs, ask for features and participated on the mailing lists. Thank you to you too, for going out and trying this new beta of Selenium 2.

You rock. 🙂

Share this:

As mentioned in Simon’s Going Atomic: Why? and Going Atomic: How, part of the merging of Selenium and WebDriver is to share common code between the two. And as of the 1.0.10 release of Selenium IDE, this merged code, ‘atoms’ is now included.

Some early users of this release are noticing that this the atom that drives assertAttribute and verifyAttribute is causing their scripts to break. This post explains the ‘why’ and suggests how to fix them as well.

The HTML spec has the notion of a boolean attribute which is one that does something just by being there rather than by its value; checked and selected are two such examples of this. Optionally, you could give these boolean attributes a value that is the same as their name (checked=”checked”) and your page would still validate, but really, the browsers only care that the attribute exist.

Prior to 1.0.10, it was not uncommon for people to do something like

assertAttribute | checkbox@checked | checked

which fetches the value of the checked attribute on the checkbox with the id or name of checkbox and fails the script is the value is not checked.

In 1.0.10 though, that will fail even if it is checked. This is because checked is a boolean attribute and will now return either true or throw an exception saying the attribute doesn’t exist. Redoing the above step check that the boolean attribute is set results in:

assertAttribute | checkbox@checked | true

Thankfully, most of the real-world interaction with boolean attributes is focused on checked, disabled, hidden and selected and in these cases using assertAttribute is not really the right thing to do. Instead, the Selenium API provides wrappers for you to use.

Checking for the absence of a boolean attribute that doesn’t have a nice wrapper is a bit of a pain though. In this example I am checking that the boolean attribute multiple is not on the select element with the name elephants.

assertEval | this.browserbot.findElement("css=select[name=elephants]").getAttribute("multiple"); | null

If you find yourself doing this very often, I suggest you wrap it up in a user-extension inside a plugin as something like

assertBooleanAttribute | css=select[name=elephants]@multiple | false
assertBooleanAttribute | css=select[name=elephants]@multiple | true

Hopefully this addresses some of the eventual ‘why the heck did my script break!?!?!’ problems that will no double crop up once Selenium IDE 1.0.10 gets wider distribution.

Share this: