Official Selenium Blog

February 8, 2017

Hacking with IntelliJ

Filed under: Technical — shs96c @ 11:02 am UTC

Jetbrains have a programme for Open Source projects which allows them to receive IntelliJ IDEA licenses. As part of that programme, which the Selenium project has participated in for many years, they’ve asked us to provide a fair and balanced review of IntelliJ. I’ll attempt to do that, and I’ll try and state my biases up-front so you’re aware of them.

I’ve been using Jetbrain’s IntelliJ to hack on the Selenium code since I started working on it slightly over ten years ago. It’s still my favourite IDE for my Java work, and it’s plenty of fun to use. For some time, I’ve been using the (free) Community Edition, which is ample for many coding needs.

Most of my work is in Java, and that’s where I know IDEA best. I dabble in Ruby and Python, and I’ve written a reasonably large amount of Javascript, all in IDEA.

The Pros:

In common with other good IDEs, IDEA has the ability to work seamlessly with many different languages. If you’re a polyglot programmer, being able to stay in the same tool for much of your work makes life a lot easier. On the Selenium project, we use Java, C#, Ruby, Python, and Javascript extensively. I don’t do any C#, and I mainly focus on Java, but the support for JS, Ruby, and Python is lovely and seems to work well. The built in type detection and code navigation features are impressive (particularly for untyped languages such as JS)

Of course, the feature that made IDEA so awesome in the first place is the range of refactoring options it offers. These are great, and always have been. One nice feature I’ve noticed as we move to a Java 8 future (finally!) is that it offers suggestions to help migrate to new features where they make sense (and, I’ll be honest, sometimes when they don’t). It’s made making use of lambdas a lot easier.

For a while, IDEA was becoming slower and more bloated, but I’m pleased to see that, partly thanks to the work of developers from Facebook, the latest releases feel snappier and handle larger projects more efficiently. One thing I appreciate is how open Jetbrains were to receiving patches to their core product: it displays a level of respect for external contributors that I feel is important (of course, I would think that: I work on OSS for fun!)

There’s a nice wide range of plugins available for IDEA. I’ve hooked up the Buck plugin and made use of it. Without an extensions API, this plugin wouldn’t have been possible, but having them there is incredibly useful and makes the IDE even more capable.

Finally for the plus points of the IDE, I love that the IDE tracks new versions of Java relatively closely — it’s fun to see what new language features we’ll be able to use in the future!

The Cons:

Although it’s a fine product, there are some niggles to be had.

Most annoyingly, the built in code analysis doesn’t always warn that some Java classes won’t compile. The most recent example was where IDEA didn’t flag that some lambdas couldn’t be used since the choice of method to use was ambiguous. This may be because the Java language continues its slothful way forward, and the compiler improves with each release — certainly these same files compiled just fine with older Java releases.

When an error does happen, I’ve yet to find the magic setting to allow IDEA to keep going as far as possible. One of the features I like about Eclipse is that it’ll compile as much as it can, even if there are invalid source files. When doing TDD, this allows you to move just a little bit faster as unit tests can run and pass so long as they don’t touch faulty code. I dearly wish this same capability was present in IDEA!

On the Selenium project, we use Buck for our builds. The Buck plugin doesn’t (yet!) allow me to build and run tests within the IDE, yet Buck performs some steps that can’t be repeated by the IDE that are required for a successful build. IDEA offers the ability to run an Ant step before a build is run, and it would be extremely useful if this was generalised to “any shell command”. Most of the time, it’s fine, but it’s irksome to forget to run things!

On the whole, I love IntelliJ an awful lot. It’s a fast and capable IDE, and the company behind it supports OSS. What’s not to love?

December 24, 2013

Android and iOS Support

Filed under: Technical — shs96c @ 4:18 pm UTC

TL;DR: We’re retiring Selenium’s own AndroidDriver and iPhoneDriver in favour of any of Selendroid, iosdriver and Appium. If you’re using one of Selenium’s own mobile drivers, please evaluate one of these alternatives.

The longer version:

In 2007, Steve Jobs announced the iPhone and changed the mobile Web from a curiosity to something the mainstream wanted and used. Current trends suggest that mobile Web usage will surpass desktop usage in the not too distant future. Which is a long way of saying the mobile Web is going to be a big part of the future of your sites and that it’d be an extremely wise idea to test them on mobile devices.

The Selenium project responded to the rise of the mobile web by working to produce WebDriver implementations for both iOS and Android. The first lines of the iPhoneDriver (which also worked on the iPad) were added to the project early in 2009. The AndroidDriver was added in June 2010, and was primarily developed by engineers at Google. To this day you can download the official Android SDK and find “Google WebDriver” as one of the optional extras you can download.

After the initial work on the mobile drivers, something interesting happened. Experimental extensions and modifications to the drivers were made outside of the selenium project. The first one of these that I was involved with was “nativedriver“. This took the novel approach of allowing users to interact with the native UI of the phone, be it Android or iOS, using the familiar WebDriver APIs. The first time I saw it, I thought it was madness, but the engineers working on it soon convinced me that it made sense. And guess what? They were right.

Sadly, after proving the idea was viable and workable, the NativeDriver project ran out of steam, but it set the scene for three projects that have taken the idea and run with it to create remarkably capable pieces of mobile testing software: Selendroid, iosdriver and Appium. All three of these allow a tester familiar with the WebDriver APIs to test mobile apps on iOS and Android. Not only native ones, but also hybrid or pure web-based ones too. They’ve recently been joined by the Windows Phone WebDriver, which allows testing of mobile web apps on WinPhone 8.

All of these projects have something in common: they’re far more active, more capable and have pushed further than the equivalent code in the main selenium project. In fact, some of the members of the selenium team that contributed to both AndroidDriver and iPhoneDriver are now also working on those other projects. There’s work being done to maintain interoperability between the different drivers, allowing users to chose which framework is most appropriate for their needs without fear of their tests needing major rework.

This means that keeping the existing Android and iPhone drivers within the Selenium project isn’t helping our users. The alternatives are better, and keeping “official” drivers within the project muddies the water. Worse, the selenium developers are slow at making fixes to those drivers, which is incredibly frustrating for everyone involved. Because of this, the Selenium project has deleted the code for those drivers from its repository and we recommend you evaluate and use one of the alternatives.

Of course, the code will still live in our repo’s history, so if you’d like to build them yourself, then it’s still possible. The last version with the iPhoneDriver is ef9d578, and the last one with the Android source is 00a3c7d. We’ve uploaded a version of the AndroidDriver built from that revision to the downloads page to save you having to do so yourself.

These changes do not mean that we don’t support mobile as a project. It just means that we support the best implementations of mobile WebDriver, and those aren’t written as part of the Selenium project.

August 28, 2013

Mobile WebDriver

Filed under: Technical — shs96c @ 1:50 pm UTC

Although the WebDriver APIs started life as just a mechanism for automating web browsers, over the past few years it has been extended to also work on mobile devices. Projects such as Appium, iosdriver, and Selendroid have all shown that this approach works, and works well. On the Web, if you start using Selenium WebDriver with one browser (Firefox, for example), it’s easy to switch out the browser for another one (such as Internet Explorer or Chrome). It’d be nice to have a similar option for mobile, switching from one automation framework for Android to another.

As part of the Selenium 3 work, we have started working on a test suite to help ensure this level of interop between appium and iosdriver, and appium and selendroid. To kick start the process, the primary authors of each of those tools, as well as others including David Burns representing the Marionette project (Mozilla’s implementation of WebDriver for Firefox and Firefox OS) and Simon Stewart, the lead of the Selenium project, have spent the past two days locked in a small room in Mozilla HQ, London. They’ve taken this time to work out the areas where each of their projects didn’t align and agreed on a way to ensure a level of interoperability. There was only a minimal quantity of blood and tears, but plenty of hard work.

The agenda for the past two days can be found here, and the minutes are also available.

As we speak, work has started on a shared test suite, hosted in a repo in the selenium project’s Google Code page. Please, feel free to come along and join in!

January 22, 2013

A Plan to Drop Firefox 3.x Support

Filed under: Technical — shs96c @ 4:52 pm UTC
The support policy of the selenium project for Firefox browsers is to support the current and previous stables releases, as well as the current and previous ESR releases. At the time of writing, that means the supported versions are “10” and “17” (ESR) and “17” and “18” (stable channel). In addition to this, we are currently supporting Firefox 3.x too.
This is an official announcement that we are planning to end support for Firefox 3.x in the near future in RC, WebDriver and Core/IDE, and this is your chance to be involved in that decision. Unless there is a strong reason to do otherwise, I shall shortly be announcing a timeline for the end of the support of 3.x
Once support for Firefox 3.x is removed, the earliest supported Firefox version will be the ESR-1 release (currently Firefox 10).
Rationale:
Firefox 3.x is no longer actively supported by Mozilla, and this has been the case since April 24, 2012. Since this time, 3.x has dropped to under 1% of global Web traffic (0.62% at the time of writing according to StatCounter) Continued focus on supporting an effectively dead browser prevents the selenium team from using features in the newer releases for little benefit to you.
Continued support of Firefox 3.x by the selenium project gives the impression that that particular version is still a valid option used by the population of the Web. This is simply not the case, and it may mean that testers efforts are being spent fixing problems that almost no users will ever see.
What you can do:
If you agree that this is the right choice, then you do not need to do anything. If you disagree strongly and have the numbers to back up your position, particularly if you can help work on Firefox 3.x support, then please reply to the selenium-user google group.
On a personal note, I know that a lot of you may well have firefox 3.x support in your test plans and will be distressed by this plan. Please take the time to look at actual usage logs from your sites and applications to verify that continued support is worth your time and energy before responding. I’d really appreciate that.

January 14, 2013

Source Control

Filed under: Technical — shs96c @ 2:22 pm UTC

This short technical note is to announce that the Selenium project is now using git on Google Code in place of subversion.

The move has been a long time in the making, and it’s largely thanks to the efforts of Kristian Rosenvold that we’ve been able to do the migration and retain the project history. The project owes him a huge thank you! We’re in the process of migrating the last bits and pieces (none of which are user facing), so there may be some last minute turbulence as we settle everything down.

Although the canonical source will be on Google Code, we’re working on setting up a github mirror. We’ll announce the location of that once it’s set up.

February 24, 2012

Support for Ancient Browsers

Filed under: Technical — shs96c @ 11:39 am UTC

The first code checked into the Selenium project’s public repository was in November, 2004. We’re now in 2012. In the intervening years there have been many browsers released. The last browser we officially stopped supporting was Firefox 2.0, and it’s time to review the list of browsers again.

We periodically review the list of supported browsers as the more changes there are between the oldest version of a browser that we support and the most recent, the harder it is for us to add new features and maintain those that already exist. Balanced against the cost of maintaining the selenium code base itself are your tests; we know that your users might not be updating their browsers to the latest and greatest, and we know that you’ve still got to prove your app works on all the browsers that are important to you. That’s why what’s below is just our plan, and we’re talking about it now to let you have your say.

Looking at the market share of the browsers out there helps us make an informed choice about what it makes sense to support. This will most likely mean:

Firefox: the Firefox market appears to be split between those on 3.6 and those on the new rapid release schedule. Given this, we are thinking of officially supporting Firefox 3.6, and the last, latest and next release of Firefox (currently Firefox 9-11) as well as any ESR releases. The market share for Firefox versions 3.0 and 3.5 is tiny, and the effort to keep them working with selenium is disproportionately high.

Internet Explorer: Despite Microsoft’s efforts, IE 6 is still a popular browser, particularly in the workplace. We will continue to support IE versions 6 and up.

Safari: Safari 3 is now ancient and has been superseded by newer releases. We plan on only supporting Safari 4 and 5.

iOS: We’ll continue to target the most recent iOS release.

Android: Due to some technical limitations in previous Android releases, we are targeting Ice Cream Sandwich and onwards. We will continue to make available the testing framework for Froyo, but will not be making any changes to it.

These are only our plans. If you really need those browsers, and (better!) can help us maintain support for them, then please let us know.

You’ll notice that Opera and Chrome are not listed above. Since Opera and Google now maintain the drivers for those browsers, they are best placed to decide which are the supported versions, but in summary, Google support the major Chrome release channels (stable, beta, dev and canary) and Opera suggest using Opera 11.6+.

February 8, 2012

A Note About the Cybervillains SSL Certificate

Filed under: Technical — shs96c @ 9:10 pm UTC

If you’re using Selenium RC to test websites hosted on a secure site (accessed using a URL starting with HTTPS), we strongly recommend that you upgrade to Selenium 2.19. This is because the Cybervillains certificate in previous versions will expire soon, and has been replaced in 2.19 with an updated one.

Our thanks to Patrick Lightbody, Ivan De Marino and Mark Watson and Neustar for taking providing the new certificate and the patch!

January 5, 2012

Selenium 2.16 Released: Welcome to 2012!

Filed under: Releases,Technical — shs96c @ 11:36 am UTC

It’s been a while since we last blogged about a Selenium release. Since the release of 2.0, we’ve been attempting to give you a fresh and shiny Selenium release every week (though, in reality, we’re managing to get you one every 10 days on average). This allows you to pick the version that’s most suitable for you and your teams, but provides a route for quick feedback on how we’re doing. I think we’ve now ironed out a lot of the initial problems and bumps we ran into, so we are extremely proud to announce the release of Selenium 2.16.

If you’re unsure about what’s been happening since the last time we announced a release here, the best place to look is our changelog. The most notable feature in 2.16 is better support for Firefox 9, but if it’s been a while since you’ve last updated, we’ve been beavering away on bug fixes and making existing features work as flawlessly as possible. Now’s a great time to update!

One of the key tools we use for assessing whether it’s okay to push a release is our continuous build. This watches for each and every change made to the project’s source code, and runs an increasingly vast suite of tests to verify that nothing has broken. Our friends at SauceLabs have been extremely generous in providing support for this, and have worked closely with us to make the build as stable and quick as possible. Special kudos and thanks to them!

February 15, 2011

Selenium 2.0b2 Released

Filed under: Releases,Technical — shs96c @ 2:06 am UTC

We’ve just released Selenium 2.0b2. If you’re the impatient sort who loves to have the latest and greatest, head over to the download site and get it while it’s hot. If you’re a Python user, then all you need to do is a simple “pip install -U selenium”. Ruby users can, as ever, simply run “gem install selenium-webdriver”. Maven users need to wait just a little bit longer: we’re going to be checking the release in ASAP.

Between beta 1 and beta 2, we held a week-long Bug Bash, during which we closed a significant number of bugs. From a user’s perspective, other highlights include:

  • A more stable, capable iPhone driver.
  • Updated Android driver.
  • Improved python bindings for Selenium WebDriver. The namespace is now “selenium.webdriver”
  • Added “Selenium.getCssCount” to mirror “Selenium.getXpathCount”
  • WebElement.getText()” performs more consistently across different browsers.
  • Mono users can use the .Net bindings
  • Continued to improve the WebDriverBackedSelenium. If you’re looking to migrate from Selenium 1 to Selenium 2, and want to take your time, this is a useful stepping stone.
  • Reworked the Advanced User Interactions APIs. The big change is that the WebDriver APIs no longer rely on classes from the AWT.
  • .Net users now have more support classes, to make writing tests less tiresome.
  • The remote webdriver makes better use of sockets, which improves stability and scalability on Windows.
  • Started to add support for driving multiple IE instances. This is considered experimental, but we’d love to hear it’s working for you!

If you’re interested in the guts of Selenium 2 and how it worked, then you might find these interesting:

  • Continued reworking the IE and iPhone drivers to use the Automation Atoms.
  • Reworked the structure of the source tree to be more language focused.
  • We have the skeleton of a webdriver-backed selenium for Python.

As you can see, this is a big release. Beta 3 should be out a lot more quickly, and will be focusing on improving support for IE 9 and Firefox 4. Over the course of the 2.0b3 development, we shall also be removing as many deprecated methods as possible, so be sure to remove deprecation warnings from your builds when using 2.0b2!

September 5, 2010

Going Atomic: How

Filed under: Technical — shs96c @ 10:47 pm UTC

This is the second of my technical posts. Again, if you’re interested in the internal workings of Selenium 2, then please skip straight to something else. If you’re interested in how and why we made some of the technical decisions on the project, keep reading….

We left our intrepid heroes in a tight spot: they’d decided to write a shared library of code, to be used by the various webdriver implementations and selenium core, but the requirements for doing this seemed to be at odds with it actually happening.

Fortunately, at about the same time we started down this path, Google Open Sourced the Closure compiler. This is a Javascript compiler that takes as input a set of Javascript files, and which outputs Javascript. It can be configured to either pass the code through untouched into a single file, or it can compile a script aggressively, removing unused code-paths and minifying the output as much as possible. The Closure compiler is used on a lot of Google products, so we know that it’s reliable and consistent.

In order to get the best out of the Closure compiler, we’re writing the atoms using the Closure library. This isn’t as well known as some of the other JS libraries out there, but it’s solid, well tested and is being actively developed. It also features an easy-to-use extension of JsUnit, which makes writing tests a far simpler task than might otherwise be the case, and it has an easy to use mechanism for modularizing code.

So, given that we could compile a single Javascript function (and it’s dependencies) into a minified fragment of JS, we were all set, right? Not quite.

The problem is that the atoms are being extracted from two frameworks that have a different way of viewing the world. As an example, Selenium 1’s “getAttribute” method only returns the value of a particular attribute, whereas WebDriver’s “getAttribute” method will return the value of either a property or an attribute (because sometimes it’s hard to remember whether something is an attribute or a property of an element)

As with all problems in computer science, an extra level of indirection is used to solve this issue.

We’re busy implementing the expected behaviour of both WebDriver’s and Selenium’s API on top of the atoms.

There is, of course, the obvious question about how we get this carefully compressed JS into a driver. One option would be to include the raw Javascript as files in each language binding, and pull them in as required. That’s possible, but it would make each language binding bloated, and would introduce a lot of duplication. The alternative is to push the atoms as far into the driver as possible, and this is what we do. As part of the build process for webdriver, we take the compressed JS and convert it into a form that can be consumed by a particular driver. For example, for the IE driver, we convert them into constants in a C header file. These constants can then be referred to by the driver and converted back into a script than be executed via the same mechanism that is used by “executeScript”.

What do we gain from this seemingly baroque approach? Other than the ability to share the same code between drivers? Many things. The cost of maintenance drops dramatically as we can fix a bug in one place and have that fix be picked up by every driver. Because we’re working in pure JS and just querying the DOM, we can run the unit tests in a browser whilst we’re developing the code. This leads to a very tight feedback cycle. It also makes it easier for developers not familiar with the code to take a look at how we do things, and send us patches (always appreciated!) Finally, we can ensure a consistency of result.

Right, any questions?

Next Page »

Blog at WordPress.com.

%d bloggers like this: