How to Select a Scripting Language for Selenium WebDriver Project
- September 24, 2021
- maira
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 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 | 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. 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 has been, or what factors you took into consideration that haven’t been mentioned here.