How to Select a Scripting Language for Selenium WebDriver Project

Scripting Language for Selenium WebDriver Project

Selenium WebDriver, an automation API that tests a browser as a user would, is often cited as being superior to other web automation tools by virtue of the wide range of language and framework options it provides to its users for writing test scripts.

Selenium WebDriver supported languages include Java, Python, Ruby, C#, JavaScript, Perl and PHP. When it comes to the frameworks that can be used with WebDriver, there’s quite a long list. Some of the popular supported frameworks are JUnit, TestNG, RSpec, unitTest, PHPUnit, and FitNesse, etc.

Java and Python typically compete neck-and-neck for their popularity ranking, and the most recent Tiobe Programming Community Index presently ranks Python above Java at second position. We’ll be conducting a quick comparison between WebDriver Java and Python APIs.

Selenium WebDriver is designed to provide a simpler, more concise programming interface to complement the limitations in the Selenium-RC API.

It’s always good to have options and choices, but sometimes making a choice from a long list of available options becomes a difficult thing to do. There are number of decisive factors that help us in making an appropriate scripting language choice while starting a new WebDriver automation project.

Some of the important factors that normally affect our choice are:

  • Different frameworks and tools that can be used with different APIs
  • Available documentation and support for different WebDriver APIs
  • Maturity of APIs and frequency of updates to them
  • List of supported browsers and project requirements for browsers
  • Ease of setting up scripting or running environment
  • Complexity level of web applications
  • Use of technologies like Flash, Silverlight etc. in web applications
  • Maintainability and Scalability requirements of the project
  • Skill level and experience of QA resources in different programming languages
  • In house support available for different languages from developers
  • Test cases complexity and required test coverage

At Kualitatem, we recently received a request for automating a web application that was developed in Python Django framework, and had some modules developed in Flash.

Before starting the project, we did a short study on WebDriver Java and Python APIs and also analyzed other factors mentioned above to make a choice that was best suited for this project.

The findings of the study are summarized in the following table:


Comparing Factors

WebDriver Java

WebDriver Python

Documentation & online support available More documentation and online support available Official documentation available, but lesser online support
Ability to handle complex scenarios Java & Python API features are identical and both can handle complex scenarios Java & Python API features are identical and both can handle complex scenarios
Flash, Silverlight etc. handling WebDriver can handle Flash and Silverlight when used with Sikuli (supported in java) Cannot handle Flash and Silverlight (no documentation available)
Supported frameworks (as per our requirements) TestNG, JUnit, Sikuli unitTest
Supported browsers Firefox, Chrome, Microsoft Edge, Opera, HTML unit, Android, iPhone Firefox, Chrome, Microsoft Edge, Opera, HTML unit, Android, iPhone
Setting up environment for running script A bit complex to setup Easier to setup
API matureness and updates frequency Primary WebDriver API. All new features are first implemented here Equally mature but lesser support and delayed updates
In house support available from developers Developers could support equally for Java & Python Developers could support equally for Java & Python
QA resource expertise More experience of WebDriver Java projects Few projects in WebDriver Python
Learning curve for language and API Higher Lesser

After considering all of the above factors, we concluded that there is not much difference between Java and Python API, aside from available online support and Flash handling capabilities.

We decided to go with WebDriver Java API, as the application had some modules developed in Flash, and in order to handle them we wanted to use Sikuli (which works in integration with WebDriver Java API). Apart from that, factors like better online support and experience with QA resources also made the case favorable for WebDriver Java API.

That being said, we’d love to hear how your experience with Selenium WebDriver has been, or what factors you took into consideration that haven’t been mentioned here.