Selenium IDE Is Dead, Long Live Selenium IDE!

In August of 2017 Simon shared the bleak, hard news that as of Firefox 55 Selenium IDE would no longer work. Selenium IDE (or as we’ll refer to it from here on out – the Legacy IDE) was, and is, dead.

Since then quite a lot has happened with the IDE. We have a new version of it which we are referring to as… Selenium IDE!

It is currently in “alpha” and available for use in both Chrome and Firefox.

In his post Simon also mentioned “the fine people at Applitools“. This includes Tomer Steinfeld, Dave Haeffner, and Doron Zavalevsky. Together, along with contributions from the rest of the Selenium community and the SideeX project, we have been able to get the new Selenium IDE out into the wild. We are also working to close the gap on feature parity with its predecessor along with adding some much needed enhancements to the tool (more on that in future posts).

We’d love for you to give the new IDE a try and let us know what you think. Visit either the Chrome Web Store or Firefox Add-ons to install it. For info on how to use the tool, you can check out the getting started documentation on Selenium HQ.

If you have any questions you can find us on the Selenium Slack/IRC chat channel. Think you found a bug? File an issue. Want to contribute? Take a look at the project on GitHub.

Happy Testing!

 

 

Firefox 55 and Selenium IDE

The bad news: from Firefox 55 onwards, Selenium IDE will no longer work.

The reasons for this are complex, but boil down to two main causes:

1. Browsers are complicated pieces of software that are constantly evolving. Mozilla has been working hard to make Firefox faster and more stable, while still retaining the flexibility and ease of extension that we’ve come to know and love. As part of that process, Firefox is switching extensions from the original “XPI” format, to a newer, more widely adopted “Web Extension” mechanism.  
2. The Selenium project lacks someone with the time and energy to move the IDE forwards to take advantage of the new technologies.

Selenium is one of the most widely used pieces of testing software there is. Despite this, the team of people regularly contributing is small: since the start of the year, there are only 11 people who have made more than 10 commits, with two people accounting for more than half of those. Since 2016, only one person has been maintaining the IDE.

Selenium is an Open Source project. None of the core contributors — not the IDE maintainer, not the language binding owners — are paid to work on work on it. They do it because they love working on the code, and they typically do it in their “copious free time”. The IDE maintainer has had almost none of that to spare. We should all be thanking that committer for his time and effort. Thank you, Samit!

So what can we do to move forward? The first thing is that there are now a wealth of tools that are stepping up to fill the gap. You should go and have a look at them. The second thing is that there is an effort to rebuild IDE using modern APIs, to be usable across more than just Firefox. The fine people at Applitools are helping with this effort.

The third thing? That’s you. You could help us.

If you believe that a friendly UI for quickly recording and playing back tests is a useful Open Source tool, then please come and join us! The main technical discussions are happening on the #selenium IRC channel. If you’d prefer Slack, you can join us on that too. Or there’s the ever useful selenium-developers mailing list. Come onboard. We’d love your help, and IDE is a wonderful thing to contribute to!

Selenium IDE 1.0.12 – now with Firefox 5 support

Last week we quietly released Selenium IDE 1.0.12 on the website. It has Firefox 5 support along with other improvements. See the release notes and unofficial announcement. Download it here or ask Firefox to check for plugins updates.

And for those who did not download 1.0.11 (it was not pushed through the update system) you will want to read about the formatter change that landed.

Selenium IDE 1.0.11 – Now with Firefox 4 Support!

We know that you have been waiting eagerly for this release and you have to wait no more. Selenium IDE 1.0.11 is now here and you can get it from the seleniumhq download site. The update will also be pushed to you automatically over the next couple days.

Other things of note around this release
•Release Notes
•Where to log bugs
•Welcome Selenium IDE 1.0.11 (with Firefox 4 support)

Atoms have come to Selenium IDE

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.

checked	assertChecked(locator), assertNotChecked(locator), verifyChecked(locator), verifyNotChecked(locator)
disabled	assertEditable(locator), assertNotEditable(locator), verifyEditable(locator), verifyNotEditable(locator)
hidden	assertVisible(locator), assertNotVisible(locator), verifyVisible(locator), verifyNotVisible(locator)
selected	assertSelected*(locator, pattern), assertNotSelected*(locator, pattern), verifySelected*(locator, pattern), verifyNotSelected*(locator, pattern)

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.

Selenium IDE 1.0.7 – Now with Drag-and-Drop!

So its a month later than planned, but Selenium IDE 1.0.7 is now available. The delay was due to some internal build changes and not code, but one of the code changes that is there more than makes up for the delay.

That’s right, drag-and-drop has finally arrived to Se-IDE — though credit lies with Jérémy Hérault for implementing it.

Oh, and if you are Swedish, there is now a localization for you. Yes, a real one. Not just one that makes everything say Bork as was suggested to me. Although a Pirate locale might be arrr-some.

For those with version 1.0.5 or newer, the update will be pushed to you automatically over the next couple days. Those new to Selenium IDE or with 1.0.4 or older will want to install it now.

Other things of note around this release

• Release Notes
• Where to log bugs

Selenium 2.0 backend for running IDE test suite via the Se2 Firefox

The GSoC 2010, it’s a great adventure.

I’m Raynatou, I come from Burkina and do my internship at SERLI. Like all interns in this company the topic of my internship focuses on advanced topics like the integration of WebDriver as backend for Selenium IDE. Selenium IDE is currently built upon Selenium Core for interacting with web pages. Selenium Core has several major limitations, including the inability to fire native events. To avoid these limitations and produce more robust tests, I am investigating Selenium IDE to using WebDriver in place of Selenium Core.

I’m mentored by Eric Allen from SauceLabs, my lead mentor, and by Jérémy Hérault from SERLI, his second but not least ;).

Eric has already done most of this integration earlier this year. The goal of his work is mostly to show what’s possible with Selenium IDE and the Selenium 2.0 Firefox driver. It is based on an asynchronous communication between the Firefox WebDriver extension and Selenium IDE, Se-IDE waiting for that WebDriver says to him that the current command has been passed with success (or not) to call the next command of the current test case (use of callback function). The goal of my mission is to finalize this integration. However, Eric being a crazy man, and he has done it quickly and together we though to another way to do this merge.

Our new thinking is based on a synchronous communication between both of them. To do it, I get the FirefoxDriver instance and play with it like a normal object, by calling its methods. But the behaviour of FirefoxDriver isn’t as simple as I was thinking. JavaScript being a powerfull language (yes, it can make you shiver), I’ve had just to replace some objects (like Response object) and to use a Proxy (and a bit of IoC-like code) to simplify my life and the code to do. You can see my work on GitHub and follow it.

Currently, I think that more than 95% of the Selenium API commands are usable with WebDriver as backend in Selenium IDE. The process was basically to go through the seleniumemulation package and port all of the Java classes into JavaScript methods on the WebDriver class.

Now, I’m working on Unit tests to cover any of the 2.0 work I’ve done. I managed to get all of the Selenium Core tests to run through IDE. I’ve some refactorings to do to optimize the code and add more comments for a bigger comprehension of my work. I have almost finished.

I hope you enjoy what I’m doing and we hope (me and my mentors) that this work can be included in the wave of Selenium 2.

Selenium-IDE – Looking back and looking forward

Its been around six months and three releases since I took the reins of Selenium-IDE. The fundamental change in that time has been the adoption of a plugin model like the fine folks over that Firebug. (We’re also self-hosting it which is big from a project internals perspective.)

Right now, you can add custom user-extensions and formatters, but in the very near future you will be able to add location strategies as well.

So what does the future look like for Se-IDE?

• 1.0.8 – A whack of bug fixes, and maybe the location strategies via plugins
• 1.0.9 – If location strategies doesn’t get into 1.0.8, it will be here. And likely bug fixes.
• 1.0.10 – Remove UI-Element from Se-IDE and make it a plugin

There is also work on reworking the internals of Se-IDE from a synchronous model to an asynchronous through Google Summer of Code. If that is successful and we decide to use it, that will trigger a bump to 1.1.0.

Timelines you ask? Well, when I took over Se-IDE the plan was to do it monthly. That was either naive or overly optimistic so they are starting to stretch a bit. 1.0.8 is going to stretch it some more too. Look for a beta of 1.0.8 towards the end of the month with a final version by mid-August.

I know you are likely wondering what cool, superdidooper features will you be seeing in Se-IDE over the next while? Ummm, well, actually none. At least not from the core Se-IDE. There will be significant pushback on any new ‘feature’ or change that adds something to Se-IDE. If you cannot accomplish your goal through a plugin, then I would consider than an omission in terms of the API.

Thats where we are from the maintainer perspective, but end-users also have sway over this as well to some degree. We’re now using the Google Code Issue Tracker for managing the project. If you bug is not there, there is a significantly smaller chance of it being addressed. And if an issue has a number of stars on it, that is also an indicator we should be looking at it.

Now to hack on locators…

Selenium 3.0: Out Now!

We are very pleased to announce the release of Selenium 3.0. If you’ve been waiting for a stable release since 2.53.1, now’s your chance to update. And if you do, here is what you’ll find:

As we’ve said before, for users of the WebDriver APIs this is a drop-in replacement. You’ll find that modern browsers, such as Chrome and Edge will continue to work just as before, and we’ve taken the opportunity to fix some bugs and improve stability. Selenium Grid users may require updates to their configuration as the json config file format has been updated, as have some of command line parameter options, but the upgrade should also be smooth. 

The major change in Selenium 3.0 is we’re removing the original Selenium Core implementation and replacing it with one backed by WebDriver. This will affect all users of the Selenium RC APIs. For more information, please see the previous post.

A lot has changed in the 5 years between versions 2 and 3. When we shipped Selenium 2, the Selenium project was responsible for providing the driver for each browser. Now, we are happy to say that all the major browser vendors ship their own implementations (Apple, Google, Microsoft, and Mozilla). Because the browser vendors know their browsers better than anyone, their WebDriver implementations can be tightly coupled to the browser, leading to a better testing experience for you.

The other notable change has been that there is now a W3C specification for browser automation, based on the Open Source WebDriver. This has yet to reach “recommendation” status, but the people working on it (including members of the Selenium project!) are now focusing on finishing the text and writing the implementations.

Mozilla has been a front-runner in implementing the W3C WebDriver protocol. On the plus side, this has exposed problems with the spec as it has evolved, but it also means that Firefox support is hard to track as their engineering efforts have been forward looking, rather than on supporting the current wire protocol used by Selenium WebDriver. For now, the best advice we can offer is for you to try the latest release of geckodriver and Selenium together.

These are exciting times for browser automation! Selenium 3.0 is a major release and we’re looking forward to improving things further, as well as tracking the ongoing work of the W3C spec. Our goal is to keep the changes your tests need to deal with to an absolute minimum, to continue preserving the hard work that’s gone into writing your existing tests. 

As a personal note, I’d like to say thank you to each of the many people that have worked so hard to make Selenium 3 possible. That’s not just the developers and contributors to the Open Source project (past and present), but also the engineers from Google, Microsoft, Mozilla, and Apple, and everyone involved with the W3C spec. I’d also like to say thank you to everyone who’s taken the time to report bugs, our users and our community. The project is great fun to work on and you’re the reason for that. A final thank you is due to the Software Freedom Conservancy, who have provided invaluable help with the logistics of running a large OSS project.

 
Happy hacking, everyone! May your tests run fast and true!

Selenium 3 is Coming

Selenium 3 is coming! As I write this, we think that “beta 4” will be the last beta before the official 3.0 release. I’m here to tell you about what’s changed, and what impact this will have on your testing.

TL;DR:

• WebDriver users will just find bug fixes and a drop-in replacement for 2.x.
• Selenium Grid users will also find bug fixes and a simple update.
• The WebDriver APIs are now the only APIs actively supported by the Selenium project.
• The Selenium RC APIs have been moved to a “legacy” package.
• The original code powering Selenium RC has been replaced with something backed by WebDriver, which is also contained in the “legacy” package.
• By a quirk of timing, Mozilla have made changes to Firefox that mean that from Firefox 48 you must use their geckodriver to use that browser, regardless of whether you’re using Selenium 2 or 3.

In more depth:

When we released Selenium 2.0 in 2011, we introduced the new WebDriver APIs, and encouraged everyone to start moving to them. If you’re using the WebDriver APIs, then Selenium 3.0 is a simple drop-in upgrade. We’ve not changed any of the public WebDriver APIs, and the code is essentially the same as the last 2.x release. If you’re using Selenium Grid, the same applies: in most cases, you can just drop in the new JAR (or update your maven dependency to 3.0.0), and you’re done.

If the update to Selenium 3 is such a non-event, why did we call this Selenium 3.0? To answer this question, I first need to provide some history, and tell you a little about how Selenium works under the hood. The very first version of Selenium was “just” a very complicated Javascript framework, running in the browser and interpreting the table-based tests you may be familiar with if you use Selenium IDE. We call this “Selenium Core”. This Javascript framework formed the basis of the original implementation of Selenium RC (the oldest set of Selenium APIs, where all the method and functions were on the “Selenium” interface, and which have been deprecated for some time now). Over time, the needs of modern web testing have grown ever more complicated and sophisticated, and Selenium Core is now less capable of meeting these needs than it was before.

With Selenium 3.0, we are deleting the original Selenium Core implementation. If you use the old RC interfaces, we provide an alternative implementation that’s backed by WebDriver. This is the same “webdriver-backed selenium” that has been available as part of Selenium 2 since its release. Because the underlying technology has changed from Selenium Core to WebDriver, you may find some places where your existing tests using RC run into issues. Our experience with migrating suites is that it’s normally a systemic issue that can be fixed with a minimal engineering effort (that is, the problem is normally isolated to a few places, and these can be rewritten to avoid problems)

We’re also removing the original Selenium RC APIs from the main downloads. If you’re a Java user, and need to use them to support existing tests, then you’ll need a dependency to “org.seleniumhq.selenium:selenium-leg-rc:3.0.0” (or later!). It’s strongly recommended that you do not do this unless you absolutely need to.
If you’re someone who runs tests exported from IDE in the table format, there is now a new test runner that the project has made available for you to use that can be downloaded from the project’s website. It takes the same arguments as the old runner, and we’ve done our best to ensure the output of tests remains the same too.

At the same time as the Selenium project is shipping Selenium 3.0, Mozilla are changing the internals of Firefox in a way that makes it more stable and secure, but which also makes the community provided Firefox Driver no longer work. As such, if you use Firefox for your testing, you’ll need to use the geckodriver, which is an executable similar to the chromedriver and the Microsoft WebDriver for Edge. You’ll need to start using geckodriver even if you’re using Selenium 2 — the change is in the browser, not Selenium. Please be aware that geckodriver is alpha software, based on the evolving W3C WebDriver standard: everyone’s working flat out to give you the best testing experience they can, but there are undoubtedly some bumps in the road when it comes to testing with Firefox.

This release marks the culmination of a lot of hard work by the Selenium committers and community. I’d like to thank everyone who has been part of this process, and the Selenium users around the world who have done so much to make the project as successful as it is.