Selenium: can we use webdriver and scLocator?

[FernandoMarcelo]

Hi,

I got scLocator running fine in my browser ( Firefox + Selenium IDE ). But now it's time to write my tests in PHP which connects to Selenium server using Webdriver ( https://github.com/chibimagic/WebDriver-PHP ).

I start my server with your user-extensions:

java -jar selenium-server.jar -userExtensions user-extensions.js

And it works fine.

But when i try to to use scLocator it doesn't work:

Unsuccessful WebDriver command: 7 - NoSuchElement - An element could not be located on the page using the given search parameters.
Command: POST - http://localhost:4444/wd/hub/session/1333050737162/element - {"using":"id","value":"scLocator=\/\/IButton[ID=\"send_button\"]\/"}
Message: Unable to locate element: {"method":"id","selector":"scLocator=//IButton[ID=\"send_button\"]/"}
Command duration or timeout: 29 milliseconds

Other things like id=login_link run fine.

Am i doing something wrong or user-extensions won't work in this situation?

[Isomorphic]

Use Selenium RC, not WebDriver. This still allows tests to be written in a variety of languages.

[FernandoMarcelo]

Are there any plans of supporting Webdriver?

I'm new to this but as far as i know, Webdriver is being actively developed and improved while RC is a different but yet old version.

As i'm starting to write tests now it would be better to use webdriver and avoid rewriting everything in a near future.

[Depado]

Making scLocator working with WebDriver is possible. Though there is still the problem : What if you need something else than scLocator in your programm that is written in the user-extensions.js ? If you're still interested in making scLocators work with your programm, you could try this, that would be a good beginning :

public By byScId(final String locator) {

		  final String id = locator
		      .replaceAll("'", "")
		      .replaceAll("\"", "");

		  return new By() {
		    public List<WebElement> findElements(SearchContext ignored) {
		      throw new UnsupportedOperationException("findElements");
		    }
		  
		    public WebElement findElement(SearchContext context) {
		      if (!(context instanceof JavascriptExecutor)) {
		        throw new NoSuchElementException("context must implement JavascriptExecutor");
		      }
		      
		      JavascriptExecutor js = (JavascriptExecutor) context;
		      
		      return (WebElement) js.executeScript(
		          "var o = window[arguments[0]]; " +
		          "if (!o) { return null; } " +
		          "var scLocator = '//' + o.getClassName() + '[ID=\"' + arguments[1] + '\"]'; " +
		          "return window.isc.AutoTest.getElement(scLocator)",
		          id, locator);
		    }
		  };
		}

[Isomorphic]

This is roughly how our WebDriver support will work once it's complete. As you point out, WebDriver has no notion of user-extensions.js and hence no notion of "custom commands" so we are having to refactor logic in user-extensions.js so that it can be called via WebDriver.

We certainly would not recommend using WebDriver with the below approach for use of scLocators, because without the custom commands, you're going to be writing ~5x as much code for a worse result (more fragile test). The custom commands are very, very powerful.

In fact, as the 3.1d docs now say, we will not be recommending WebDriver even once WebDriver support is complete. There is an in-depth discussion of why this is the case - we've added it below.

WebDriver / "Selenium 2"

WebDriver, which is now part of Selenium 2, uses a different basic architecture in which extensions are added to each browser in order to drive tests, instead of doing so from JavaScript.

Support for WebDriver-based testing for SmartClient is currently under development, with the intent to provide the same custom locator strategies and custom commands as we provide for Selenium 1.0. However, even once such support exists we will continue to recommend Selenium 1.0 rather than WebDriver-based Selenium 2, because:

1. Selenese/HTML scripts not supported: WebDriver does not directly support execution of Selenese (HTML script files)
2. Java skills required to write/record tests: lack of support for Selenese means a Java developer and Java environment is required to develop WebDriver tests. We consider this very bad, as the ideal setup is that QA personnel with limited skills can drop Selenese test files onto a test server and have them automatically run - this requires no Java skills
3. Selenium IDE recording made useless: Selenium IDE's export to WebDriver code requires large manual effort to produce working scripts. As things stand, it actually takes less effort to hand-write Java code, using Selenium IDE to capture locators only
4. WebDriver is more complex to install: need to install WebDriver support for each browser, and in some cases multiple WebDriver plugins for multiple versions of the browser
5. WebDriver supports less browsers: Although major browser bugs can sometimes break it, Selenium RC generally works with any browser that has JavaScript
6. Mobile testing issues: Mobile testing requires that an application be installed on the devices, doesn't run a normal browser (rather a browser embedded in a device), and supports only limited devices. In contrast, while Selenium RC doesn't support mobile, with Selenium 1.0 you can use Selenium Core to test any mobile device that supports JavaScript without installation of an app. Both situations have drawbacks but we feel class Selenium 1.0 has an overall advantage over WebDriver here.

Overall, WebDriver does not yet provide a solution that can be used in place of classic Selenium - at most WebDriver *could* be used by Java developers who plan to write tests in pure Java anyway.

However, if Selenese and Selenium IDE recording are also used, this implies two parallel sets of tests executed by different engines, and this complexity may not be worthwhile. This is especially true since part of the value of WebDriver is a simplified Java API, but the extensive custom commands provided by SmartClient mean that Selenium RC tests written in Java are far shorter and simpler anyway.

Ultimately, our current recommendation is to use Selenium 1.0 and Selenium RC only unless there are critically important tests that you can only build via WebDriver - this is rare and the most common such case is testing file upload. For these cases, use WebDriver for those tests only or use manual testing.

[Depado]

Unless I'll be able to hide the Selenium Remote control window and not open/close firefox for each @test I make, I'll continue searching solutions to use WebDriver. For now I got two tests. I'm doing it on a continuous integration platform (Jenkins). With only two tests (fill a textbox and assert it is filled, and another one a bit more complex) this takes 1 minute and 15 seconds. The total build on the Jenkins is about 8 minutes now but before it was 5.
I'm not saying that Selenium RC is bad but it doesn't fit my needs. And the fact that there is no way to unit test a smartGWT application without emulating a browser and a user is really bad. (Though I do understand why it is not possible)
And for now I'll stay on RC because that would be too hard to recode all the functions of the user extensions.js.
(Edit : If someone knows how to not open the selenium remote control window, just tell me)

[Isomorphic]

Something's wrong with your setup. Opening Firefox and running a test should take a few seconds. We would recommend troubleshooting this since WebDriver is right now mostly a dead end, or at least a great deal of wasted effort for a worse result.

[Depado]

It doesn't take long, but the fact that firefox closes and reopens each time there is a new test is bad for my build time. That's a problem I did not solved yet (though my Selenium instance is declared as static and started in a @BeforeClass and stopped in a @AfterClass)
And I'm talking about the whole compilation time which includes the construction of the war, starting jetty server, deploy the war with jetty, start selenium rc server, test, close selenium rc, close jetty.

[Isomorphic]

You just claimed 1 minute 15 seconds for two tests, that's not normal and suggests some kind of misconfiguration, or suggests that your tests take a long time to execute for reasons unrelated to launching browsers, and so would take the same amount of time with WebDriver.

Nor does Selenium RC introduce a requirement that only one test is run per browser launch. You can combine or separate them as needed, just as with WebDriver.

Overall, to the extent that there are differences in the speed of running tests with WebDriver vs Selenium RC, they are usually dwarfed by GWT compile time hence not worth worrying about.

And, even more important, the custom commands we provide with Selenium RC mean you can much more easily wait for conditions that aren't easily detected in the DOM (such as completion of all outstanding comm). This avoids the need to insert arbitrary waits for difficult to detect conditions, so you can run tests at full speed.

[Depado]

You're right. Though I don't manage to make all my tests work in a single browser. Yeah I claimed 1 minute and 15 seconds of test when my application is already built. That includes the Jetty/Selenium server and the deploy of the application too. The tests themselves must be about 30 seconds long.
Maybe when I'll manage to make it work properly in a single browser I'll change my mind about RC...

[anubhav a.]

Still need to use RC or is there some webdriver support

Quite a long time since the original post was posted, and I didn't find any other relevant blog on the same matter i.e. using Selenium RC or Selenium WebDriver for a GWT application automation.

After working for on Selenium WebDriver from the very first time it began in July 2011, I now come across any GWT application and was introduced to 'sclocator' which is injected through js in RC. But, being too handy and a fan of WebDriver I find it hard to come back to RC and for its obvious disadvantage. So, my concern is that with the announcement of Selenium 3, and the requirement to automate any GWT application do one need to age old RC with sclocator, or it can be done through WebDriver with ease or is there any other tool one can look for.

[Isomorphic]

We're not sure why you would be looking for a relevant "blog". Reading the docs is generally much more effective, and if you simply look at the Automated Testing overview, you'll find a large section on using WebDriver.

[anubhav a.]

Definitely I am not looking for any "blog". What I am looking for is that #5 of this thread, you favored RC over WebDriver so after about year and half more development in Selenium WebDriver project, do you still recommend RC over WebDriver to automated GWT application.
And is it really needed to use sclocator to locate elements on a GWT UI, or can it be done through native locators of webdriver i.e. xPath, cSS, ID, Class, Name etc.

[Isomorphic]

Again we'd highly recommend reading the Automated Testing overview, which answers both of those questions.