selenium-webdriver and WebdriverIO

[Christian Bromann]

Hey everyone,

after the Slack discussion yesterday I thought I would kick of a broader discussion around this topic as I think it needs to be addressed.

Something that disappoints me in this Selenium dev community is that people always refer to the "official" bindings and kind of ignore all the work that happen outside of the Selenium cosmos. I've been working on WebdriverIO longer than "WebdriverJS" exist on NPM. WebdriverJS is not even the real name of the "official" bindings since WebdriverIO was called like that before (see https://www.npmjs.com/package/webdriverjs) and I had to rename it because selenium-webdriver was called WebdriverJS out of the sudden. I don't actually care that much about the naming. However if we (the Selenium community) want to be an inclusive community (as Simon stated in Austin) we should appreciate all the work that happens around browser automation.

To be frank, Selenium has lost a lot of its power since browser vendors took over the work for building the drivers, and since the WebDriver spec is around Selenium is pretty much only a set of well maintained bindings to use the protocol properly. This opens the discussion about what a binding actually should be: just a tool that abstracts away sending HTTP requests to a server or a more opinionated framework for test automation as people use it like this in 90% of the times. In my opinion it should be able to do both. This is how WebdriverIO is actually designed.

It can be used as a standalone tool for various scenarios that require to automate a browser in any way. Examples for this are Spectron or Chimpjs which are tools that use WebdriverIO as automation engine in their sophisticated test framework. The standalone tool provides just the API where each command returns a promise so it can be used with async/await in cases where people don't want to use the WebdriverIO testrunner.

On the other side WebdriverIO comes with its own opinionated testrunner called wdio that allows people to simply setup a test suite by plugin a test framework like Mocha, Jasmine or Cucumber and a test reporter. It helps unexperienced QA engineers to get up and running quickly. All commands are synchronous using fibers. The reason for that is that it makes things just simpler especially for people that are not experienced with JavaScript and Promises and there are a lot of people that are moving their test stack from Java to Node. The testrunner provides a variety of services that allow to add functionality to the test scenario with some simple configs. For example creating a firefox profile by just applying extensions paths and firefox settings in the WebdriverIO config. Since the requirements of people are so diverse I made the experience that this really helps to tailor the needs for each test scenario perfectly.

In order to give people an excellent WebDriver experience in Node.js I am happy to discuss here a way how we can merge projects (like Selenium and Webdriver as Simon stated in the Slack discussion). A package that brings together the goodness of WebdriverIO and selenium-webdriver.

Some things that I feel important this project should have are:

• Be independent from the Selenium monorepo and live in a separate repo with its own build pipeline and contribution guidelines. I don't see a reason why all the bindings still live in the same repo. It makes it impossible to build a contribution community around a single binding. WebdriverIO managed to get a lot of great contributor over the years. Tons of developer help out fixing my bad english in the docs and there are people even building their own online course or a jsfiddle for WebdriverIO
• Allow to be a raw binding to a protocol but also allow to use it as a opinionated framework to run e2e tests with features like plugins and reporters

Please let me know what you guys think.

Thanks for reading!

Cheers

[Titus Fortner]

Christian, based on our previous conversations I understand some of your frustrations, and I think you make some good points here, but I'd like to clarify a couple things.

Selenium is a trademark owned by the SFC on behalf of the project which has an official codebase. It will always be factually accurate that the code in that project's repository will be "official" as far as "Selenium" is concerned.

The monorepo has been fundamental to the success of the project. It allows us to (mostly) have consistency between the languages (every binding implemented x in version x.y, etc), and has encouraged us to work together to solve similar problems. It hasn't been perfect, but there is a lot of advantage to being able to do things like having a single issue on Github and tagging each language that needs to do something to address that problem. 

"Selenium" should be a collection of language specific low level libraries that implement the W3C specification, paired with a server that can act as an intermediary node between the binding and the driver. It's a good thing that it doesn't have significant opinions. I think this is one of the reason that many of us are sad that PageFactory & ExpectedConditions and the like are included in the code base because they represent opinions about how the low level code can be used, and, as it turns out, their design isn't what most people would consider a best practice at this point, but now we're stuck with it and having to deal with people using it.

I'm very partial to the model that Jari pioneered with Ruby. Jari used Watir, but he only implemented the low-level code in one place (Selenium), and then leveraged that code to create a separate WebDriver implementation of Watir. That separation of concerns has made many things much easier to deal with in both code bases. Additionally, it has allowed projects like Capybara and older versions of page-object.gem to build their own implementations with significantly different opinions than Watir. Selenium should be considered exclusively "browser automation," and unbiased toward the various ways it can be used.

One possibility for WebdriverIO is not to "merge" projects, but to follow this Ruby model. Now that there is good(?) synchronization code in base Node, and now that WebDriverJS is using it, is there a reason (there might be I don't know your code structure or JS enough to actually know this answer) that WebdriverIO can't use WebDriverJS for the low level driver calls, and maintain the higher level features and helpers and opinions in WebDriverIO code base? Is there something in the WebDriverJS code that is itself still opinionated in a way that makes it difficult to build additional tools on top of it?

Doesn't WebdriverIO still require you to use the java standalone-server? Wouldn't leveraging WebDriverJS code allow you to both remove that requirement for running tests locally and also make it so that you don't have to implement the updated W3C specification in WebDriverIO code directly?

My dog in this fight is that I would like to figure out how the Selenium organization (and community) can be more supportive in general of open source projects that use it (Watir, Capybara, WebdriverIO, Selenide, SeLion, etc). Maybe this is as simple as a page on the new website (whenever it gets released) detailing the options and perhaps advantages and disadvantages or target audiences, etc. Maybe someone has a better idea for what might help. I'm just looking for ways to support the work of people (like you) who have put a lot of time creating code that makes it easier for people to use Selenium (specifically for testing).

--
You received this message because you are subscribed to the Google Groups "Selenium Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to selenium-developers+unsub...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/selenium-developers/7507d73b-2a30-4a78-8b16-16f18a411a20%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Simon Stewart]

Hi Christian,

On Thu, Nov 23, 2017 at 10:44 AM, Christian Bromann <christia...@saucelabs.com> wrote:

Hey everyone,

after the Slack discussion yesterday I thought I would kick of a broader discussion around this topic as I think it needs to be addressed.

Something that disappoints me in this Selenium dev community is that people always refer to the "official" bindings and kind of ignore all the work that happen outside of the Selenium cosmos. I've been working on WebdriverIO longer than "WebdriverJS" exist on NPM. WebdriverJS is not even the real name of the "official" bindings since WebdriverIO was called like that before (see https://www.npmjs.com/package/webdriverjs) and I had to rename it because selenium-webdriver was called WebdriverJS out of the sudden.

My initial read of this email is that you are feeling angry and frustrated, but it is unclear what you're actually angry about. My understanding is that you're feeling that your own work isn't being recognised. In itself, this isn't something that the Selenium project is able to help you with.

Having said this, you did bring up a number of suggestions and comments, and I'd like to address those in the best way that I can. I'd also like to help provide a better understanding how I view the Selenium community, goals, culture, and our decision making process; we don't always express those implicit aspects of the project clearly, so thank you for providing the opportunity to do so.

Before doing so, however, I must comment on one thing. One of most important cultural values of the Selenium project is respect and transparency. From your email, our initial interactions on IRC, and your comments on Twitter, I understand you're feeling frustrated, but I'd kindly ask you to respect our community's cultural values and be mindful of your tone. I'd encourage you to be direct about your needs or questions but please remove any form of attack or inflammatory language. We'd like to nurture a more effective and efficient environment for collaboration, and it's hard to do that when feeling attacked.

Moving on....

 

Your initial point, and conversation on IRC, noted that one of your issues centred around the use of the description "official bindings" for the JS bindings that are developed by the selenium project, and hosted within the project's source repository. To my mind, that seems like a reasonable label to apply to them. Are you suggesting an alternative?

 

However if we (the Selenium community) want to be an inclusive community (as Simon stated in Austin) we should appreciate all the work that happens around browser automation.

The Selenium community has worked very hard to make our culture one that is welcoming, collaborative, and a supportive, respectful place for contributors and users of all skill levels and needs. We have always -- and will continue to -- welcome outside contributors to the project, diverse speakers to our conferences, and clear and open dialogue and debate with people in the automation community outside of the project. We strive to be speak clearly, with respect and transparency, to everyone.

Not only do we respect the work of others, we actively desire collaboration, and our track record proves this. 

Selenium is an amazing Open Source project that many have contributed thousands of hours to. We've had long technical discussions about the health of our code, and the frameworks people build on Selenium, and about the direction of the project. Everyone, from the people caring and tending to the language bindings, all the way to those answering endless question on the mailing lists, work tirelessly on a volunteer basis to constantly improve the quality and functionality of the Selenium project.

The "inclusivity" I spoke of was around welcoming different views, different opinions, and folks from all parts of the software industry into the project, regardless of the axes we choose to differentiate people on. But, here's the key thing, it's welcoming those people into the project. When I want to work on other projects (and I do, such as Buck!) I join that project's community.

Putting this another way, and being direct:

The Selenium Project: We are welcoming and inclusive, but our goal is to work on Selenium.

One thing I'd dearly love is to expand our community further. We once had an active team of people who felt best able to contribute to the project by working on documentation, and we treated them with the same level of respect and support as we did to folks contributing code. I'd like to see that happen again. It would be wonderful if our project had the broadest possible set of contributors possible, ideally more closely representing the world we live in, not only for all the practical reasons that diversity offers, but because it'll be fun.

So, we are already a very inclusive and collaborative community, but there's always an opportunity to better live our ideals. You can see that happening as we evolve the public face of the project, such as Selenium Conf, to engage the entire global community, not discriminating between race, gender, or business. I'm sure our community’s goals will continue to evolve and grow because we do have an amazing contributor team and we respect and nurture collaborative minds.

To be frank, Selenium has lost a lot of its power since browser vendors took over the work for building the drivers, and since the WebDriver spec is around Selenium is pretty much only a set of well maintained bindings to use the protocol properly.

I do not understand the reason for this position. Not only does it overlook projects like IDE, Grid, and the Docker containers, but it misunderstands that the goals of Selenium have nothing to do with "power". For a long time, we used to joke that Selenium made testing "suck less"; our goal is to contribute something positive to the world, and this is how we chose to do it.

I agree that the browser vendors are now doing more than ever, and that's a great thing. If vendors are finding that they benefit from contributing to the project or the spec, it hardly make us lose power. It simply shows that the work we have done is benefiting the community of people who use browser automation, stretching from testers, toolsmiths, to who-knows-what. We've managed to build a community that stretches beyond just APIs, and the project is lead by people who have become friends over the years of effort. It really has nothing to do with "power". It has everything to do with common purpose, friendship, and joy. 

You're new to our community, and so may not have been privy to the endless discussions on the IRC channel, but that's always been a source of happiness. We've helped people do everything from learning to program, to helping them debug their tests, to figuring out what's going on with their code. It's one of the friendliest channels I've been on.

It's not all about the IRC channel. After being invited, I came to the SauceLabs office to help people become more familiar with the project, how it works, and the W3C spec (and it was lovely to be there!) I've also spoken with BrowserStack and other companies to try and help maintain and build an ecosystem.

 

This opens the discussion about what a binding actually should be: just a tool that abstracts away sending HTTP requests to a server or a more opinionated framework for test automation as people use it like this in 90% of the times. In my opinion it should be able to do both. This is how WebdriverIO is actually designed.

...

 

In order to give people an excellent WebDriver experience in Node.js I am happy to discuss here a way how we can merge projects (like Selenium and Webdriver as Simon stated in the Slack discussion). A package that brings together the goodness of WebdriverIO and selenium-webdriver.

Helping make life easier for users is an excellent thing to do and one of the things we focus on. Jason has put a huge amount of effort into making the webdriverjs bindings work nicely with modern Node, and to embrace the w3c protocol. The original promise manager we wrote was created before many in the JS community had really grasped Futures as a mechanism for dealing with async. That's now been deleted, as the language handles this now. I believe that was one of the stumbling blocks for integrating webdriverjs into other tools beforehand. 

I'm not sure what the value of shipping an opinionated test runner with Selenium will be, as opposed to doing something like Nemo, which wraps webdriverjs to offer something that I believe is similar to webdriverio. Could you please expand on the idea? 

 

Some things that I feel important this project should have are:

• Be independent from the Selenium monorepo and live in a separate repo with its own build pipeline and contribution guidelines. I don't see a reason why all the bindings still live in the same repo. It makes it impossible to build a contribution community around a single binding.

This is by design. We don't want a fractured community hunkered around a single binding. We want a broad community of people and friends working to make browser automation in general a more pleasant place to be. The cross-pollination of ideas is one of the things that brings us strength. Some examples:

 

* Titus's work in the Ruby world is feeding into the Java world as we move towards addressing usability concerns.

* Jason's work on configuring driver instances in JS is something the rest of us are looking at.

* My experience with the spec work has been applied in the Ruby and Python bindings.

* Jim's work in .Net has directly influenced how we're evolving the Java APIs.

As the motivational poster says, "If you want to go fast, travel alone. If you want to go far, travel together". We want to go far.

• Allow to be a raw binding to a protocol but also allow to use it as a opinionated framework to run e2e tests with features like plugins and reporters

I'd be interested to understand why this is a better approach than that taken by Nemo (or similar projects). 

 

Please let me know what you guys think.

Thanks for reading!

Thanks for reaching out. I hope we can continue having a productive and respectful discussion.

 

Cheers,

 

Simon

[Christian Bromann]

Hey Titus, hey Simon,

First of all thank you for taking the time and answering my probably a little bit confusing post.

> but I'd kindly ask you to respect our community's cultural values and be mindful of your tone. I'd encourage you to be direct about your needs or questions but please remove any form of attack or inflammatory language.

It was not my intention to be disrespectful in any way. I sometimes get heated up when I have to repeat myself over and over again supporting the community around WebdriverIO due to confusions around Selenium and WebDriver. I need to work on myself to be more professional in such situation. If someone felt attacked by that stupid tweet, I am sorry!

> Selenium is a trademark owned by the SFC on behalf of the project which has an official codebase. It will always be factually accurate that the code in that project's repository will be "official" as far as "Selenium" is concerned.

You are right Titus. I think here is the confusing part. The terminology about what browser/test automation is got mixed up over the years so that people referring to different things but actual mean something else. The way I see it and please correct me if I am wrong. The overall automation protocol we are using is the WebDriver protocol which enables a unified specification to control all browser. On the other side there is Selenium which is an umbrella of well maintained non opinionated client libraries in all languages that allow you to programatically use that standard. The differentiation is not really clear to many people. They say something like: we use Selenium when they instead use a framework that is not maintained by the “official” Selenium maintainers.

> Your initial point, and conversation on IRC, noted that one of your issues centred around the use of the description "official bindings" for the JS bindings that are developed by the selenium project, and hosted within the project's source repository. To my mind, that seems like a reasonable label to apply to them. Are you suggesting an alternative?

Due to this confusion it seems for many people that the “official” bindings is the only right and proper way to do browser automation. Speaking of the JS bindings, I don’t see how people can properly build up a sophisticated test suite by just using the official JS bindings. You would need to put it into a JS unit test framework and build tooling around in order to e.g. manage to run tests in parallel. I am not saying selenium-webdriver is bad tool, it isn't, it is quite the contrary. You guys did an awesome job. However I see a huge lack of features that help people to build up flake free and easy to manage test suites.

> is there a reason (there might be I don't know your code structure or JS enough to actually know this answer) that WebdriverIO can't use WebDriverJS for the low level driver calls

I think it can use selenium-webdriver to do this. After I’ve read your answers and clarifications on the goals and decision making around Selenium I think there is not an “WebdriverJS or WebdriverIO” I think it is more “WebdriverJS and WebdriverIO”. Where the former is more a low level package to call WebDriver commands and the latter a framework that provides high level test features so that people don’t need to solve certain problems like parallelisation all over again. To give another example: WebdriverIO is repeating stale element exception calls out of the box. In certain cases such error just happens and for someone who is not familiar with the underlying workings of WebDriver it is a frustrating and annoying issue to fix. From what I understand, it won’t be the goal of the Selenium bindings to fix such a problem for the user however it is a great use case for a higher level test framework to prevent running into such an issue.

> Doesn't WebdriverIO still require you to use the java standalone-server? Wouldn't leveraging WebDriverJS code allow you to both remove that requirement for running tests locally and also make it so that you don't have to implement the updated W3C specification in WebDriverIO code directly

Not sure if it would remove the requirement of running tests locally but it could definitely remove the necessity to reimplement the W3C WebDriver bindings. WebdriverIO would still need to do so because it supports Appium and wants to provide same tooling around testing desktop and mobile applications.

> Everyone, from the people caring and tending to the language bindings, all the way to those answering endless question on the mailing lists, work tirelessly on a volunteer basis to constantly improve the quality and functionality of the Selenium project.

I really appreciate all you guys work and know from my own experience how exhausting it can be to constantly answer the same questions again and again.

> I do not understand the reason for this position. Not only does it overlook projects like IDE, Grid, and the Docker containers, but it misunderstands that the goals of Selenium have nothing to do with "power". For a long time, we used to joke that Selenium made testing "suck less"; our goal is to contribute something positive to the world, and this is how we chose to do it.

While I was writing that sentence there I was still caught up in the “being called official” issue. Back in the days when driver where maintained by the Selenium contributors it kinda made sense to me to be called “official” because all the underlying technology where maintained by the team around Selenium. Since the browser vendors took over the job of maintaining the drivers I didn’t not understand why it is still called “official”. Now since I understand the goals of the binding being pretty much just a low level tool to run WebDriver commands I totally see that my argument there makes no sense.

> It's one of the friendliest channels I've been on.

I totally agree and I never said something different.

> Could you please expand on the idea?

Absolutely. As I said above, the JS binding is a low level tool that speaks the WebDriver protocol. Since it is so well maintained it should be the first tool of choice for automating a browser using WebDriver. However I do not necessarily thing it should be the first choice for testing your web application because it doesn’t provide features that help in terms of testing. Features that are essential like: parallelisation, spawning up browser drivers, serving your web app via static server before the test starts, providing a better integration to a cloud provider and other things. Yes you can build all this as part of your test suite but it requires work and experience to do so. A test framework like WebdriverIO provides all these and more with a variety of plugins and helps user in that way to avoid running into automation pitfalls.

> This is by design. We don't want a fractured community hunkered around a single binding.

This makes absolutely sense for me now. Since the scope of a binding is just making proper http calls to a browser driver it makes no sense to build communities around single ones. If the goal of a piece of software is to be a framework for a specific use case like testing I think it indeed make sense to have a broader community around that single piece of software. As example: Angular or React. They even have their own conferences nowadays and have build up a huge community around building web/mobile applications using web technologies.

> I'd be interested to understand why this is a better approach than that taken by Nemo (or similar projects). 

I think Nemo and WebdriverIO are quite similar from the idea. I think WebdriverIO is a little bit more evolved and developed

> Thanks for reaching out. I hope we can continue having a productive and respectful discussion.

Thank you for clarifying a lot of confusion around what the goal and scope of Selenium is. My initial frustration was not justified and I am sorry if I got off the wrong foot. I hope I was able this time to clarify myself and explain from where my initial frustration came from which is promoting the Selenium bindings as the “official” tool for web testing although its actual goal is just to provide low level support for browser automation. If I am right here I think it would be great if this nuance would get more highlighted.

Thanks and Cheers

Christian

[⇜Krishnan Mahadevan⇝]

Christian,

I was hoping if you could please help elaborate this part 

> promoting the Selenium bindings as the “official” tool for web testing although its actual goal is just to provide low level support for browser automation

Selenium in my naive understanding would still be the official tool for web testing. I was under the impression that, that around this tool there are these test frameworks/libraries which provide a cleaner abstraction and simplification which can be leveraged and benefitted by someone without having to re-invent the wheel. But assuming that there's no such framework/library that one finds which suites their requirement, then one would always fall back to just the official tool viz., Selenium for their automation needs.

So is your ask that Selenium project also call out the set of libraries/frameworks that are out there, built around selenium for various client bindings, so that its users can make an informed choice of whether to use the tool or a framework/library that is powered by the tool (Selenium in this case) ?

Thanks & Regards
Krishnan Mahadevan

"All the desirable things in life are either illegal, expensive, fattening or in love with someone else!"
My Scribblings @ http://wakened-cognition.blogspot.com/

My Technical Scribbings @ http://rationaleemotions.wordpress.com/

--

You received this message because you are subscribed to the Google Groups "Selenium Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to selenium-developers+unsub...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/selenium-developers/34de3c2d-7a6a-4b54-91b2-8b374a848efc%40googlegroups.com.

[Christian Bromann]

Hey Krishnan,

I can not speak much about other language bindings other than the JS one. In NodeJS in order to use the binding for test purposes you would need to put it into a unit test framework which would give you some basic test utilities like a test runner and assertions but lacks in other important features that are required for writing sustainable and large e2e test suites. For example:

• Test parallelization: most of the unit test frameworks don’t support this and the ones that do don’t let you manage how many parallel tests you want to run which is important if you test in the cloud or have a grid with a limited amount of resources
• Reporters: a unit test framework runs on a single platform so all reports do not differentiate between capabilities which is important when you run a big e2e test suite where you want to know which browser running which test file has caused an error
• Interfere in the test process: as mentioned above sometimes you run into automation pitfalls like stale element exception that are legitimate usage errors which are unknown to people that don’t know the underlying workings of the protocol and the automation technology
• Plugins to create a Chrome or Firefox profile: especially for Firefox you need to do some async operation before starting the session with the proper capabilities, in WebdriverIO you just use another plugin that allows you to define extensions and preferences in your config
• Integration into cloud services: even though you can run in the cloud using selenium-webdriver, you still need to update tests names and test status as part of your test logic, this is also simplified in WebdriverIO

There are a lot of other scenarios that differentiate a unit test from an e2e test and where a special framework would be more desired than just a simple binding.

Cheers

Christian

[Titus Fortner]

Hey Christian,

Firstly, I'm sorry for not doing a better job clarifying some of these distinctions when we've talked in the past.

​> I don’t see how people can properly build up a sophisticated test suite by just using the official JS bindings.

It was never the intention for people to do this. I believe Simon's intention was always that people would take the toolkit provided by the WebDriver implementation and would learn to use it to create their own custom solutions.​ PageFactory & ExpectedConditions, etc were intended to be examples of such things, but have turned into people erroneously considering them the "official" way to do it.

> WebdriverIO would still need to do so because it supports Appium

Doesn't Appium have JavaScript bindings similar to Selenium that WebdriverIO could also take advantage of? If not, that would also be a useful separation of concerns for WebdriverIO to help with (or convince the Appium team to work on).

Krishnan

​,​

> Selenium in my naive understanding would still be the official tool for web testing

No

​, and I think this is the point that Christian is trying to make​

. Selenium is software that is an implementation of the WebDriver protocol for automating browsers. One use of browser automation is testing websites, but there is nothing "official" about

​

it doing

​ 

that in any form

​. As a result, I'd like to see Selenium do a better job of distinguishing itself as "browser automation" instead of "test automation." 

> So is your ask that Selenium project also call out the set of libraries/frameworks that are out there, built around selenium for various client bindings, so that its users can make an informed choice of whether to use the tool or a framework/library that is powered by the tool (Selenium in this case) ?

That was my ask.

​I

n my experience, ​

people either use open source tools to do the extra

​test-focused, opinionated 

things that Selenium

​does

 not, or they

​have a small group of in-house people ​

build their own solution

​ for the people who write the tests to use​

​​

. I have seen a lot of frameworks that have

​made

 

​poor

 

​design ​

choices for their own home-grown solution

​s​

​, instead of solid, open source community vetted ones. Then again, I disagree with some of the opinionated open source decisions as well, but as an open source proponent I hate the idea that the wheel is constantly being implemented poorly. :)

So, the disagreement I seem to have with other core contributors is the extent to which opinionated test

​-​

focused tools can solve a

​necessary

 problem

​ in a sufficiently general way​

​, and the extent to which understanding the underlying Selenium libraries is necessary to properly write and maintain useful test suites. 

Simon: I can't find the updated documentation site you showed during your demo at Sauce Labs. Maybe I can propose some updates to it and we can more specifically discuss my ideas and see if we can agree on something.

Titus

--

You received this message because you are subscribed to the Google Groups "Selenium Developers" group.

To unsubscribe from this group and stop receiving emails from it, send an email to selenium-developers+unsubscribe...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/selenium-developers/f2ba140c-4768-4c13-867e-6f8884135649%40googlegroups.com.