The Selenium WebDriver is still one of the most popular tools to deal with UI automation testing. Especially with Selenium 4, the WebDriver continues to remain popular in the testing world by answering many new problems.
On the other hand, if you are a WebDriver user, you have undoubtedly encountered some problems, or will soon. In this article, I will share 5 problems that you might come across while using it, and their solutions ✅ We will examine them on ChromeDriver using Java. So let’s get started!
1️⃣ The SSL Certificate Problem
An SSL certificate error occurs when a web browser can’t verify the SSL certificate installed on a website. Then, the browser displays this error message when WebDriver tries to open a website:
This problem is one of the frequently encountered ones in testing on local environments. Although this seems like an obstacle, you can easily overcome it with WebDriver. First we need to create a ChromeOptions class object:
ChromeOptions handlingSSL = new ChromeOptions();
Then, we use the ACCEPT_INSECURE_CERTS method to accept the untrusted certificate:
handlingSSL.setCapability(CapabilityType.ACCEPT_INSECURE_CERTS, true);
Now we need to set the path of the chrome driver as follows:
String pathForChromeDriverSSL= "write here your chromeDriver path";
System.setProperty("webdriver.chrome.driver", System.getProperty("user.dir")+pathForChromeDriverSSL);
After path setting, we create an instance of Chrome driver with ChromeOptions object:
WebDriver driver = new ChromeDriver(handlingSSL);
And we are ready to open the website with the “get()” method:
driver.get("URL");
You can apply the above steps to your Driver class and use them whenever you need.
2️⃣ The Driver is Not Executable Problem
The Bonigarcia WebDriver Manager is a great solution in many ways if you don’t want to constantly download the latest Chrome driver version. However, it has some limitations. For example, when you need to work on a server like Apache Tomcat or on a container like Docker, you will have to download a third-party WebDriver.
If you use the Chrome driver for Linux, the problem you will most likely encounter in the version control (Git, SVN, etc) is that the driver is not executable:
java.lang.IllegalStateException: The driver is not executable
I guarantee you will get lost when you Google this exception. Of course, there are many complex ways to solve this problem, but you can easily overcome it with a simple implementation in your Driver class. The solution-
You need to import the class java.io.File:
String pathTheChromeDriverForLinux= "the path of your 3 party chrome driver for Linux";
File file= new File(System.getProperty("user.dir")+pathTheChromeDriverForLinux);
file.setExecutable(true);
3️⃣ The WebDriver Bug on Docker Container Problem
Docker is the most popular container of recent times, and offers useful solutions for software development and the CI/CD process. However, if you want to run ChromeDriver through a Jenkins running on Docker, you may be disappointed because it won’t work. You will see the following error messages:
Selenium::WebDriver::Error::UnknownError: unknown error: DevToolsActivePort file doesn't exist
or:
unknown error: DevToolsActivePort file doesn't exist (Driver info: chromedriver=2.40.565383 (76257d1ab79276b2d53ee976b2c3e3b9f335cde7),platform=Linux 4.4.0-121-generic x86_64) (WARNING: The server did not provide any stacktrace information) Command duration or timeout: 60.04 seconds Build info: version: '3.8.1', revision: '6e95a6684b', time: '2017-12-01T18:33:54.468Z' System info: host: 'ubuntu-test', ip: 'X.X.X.X', os.name: 'Linux', os.arch: 'amd64', os.version: '4.4.0-121-generic', java.version: '1.8.0_171' Driver info: driver.version: ChromeDriver...
The reason is a ChromeDriver bug on Docker. Whenever ChromeDriver tries to run within Docker, the driver will fail to start because of the error “DevToolsActivePort file doesn’t exist”. If you want to travel the history of the error, here are some StackOverflow links for you:
📌 Capybara headless chrome in docker returns DevToolsActivePort file doesn’t exist
But if you are directly interested in the solution, here it is-
Again we need to create an object of ChromeOptions class with the method setHeadless() as “true”:
ChromeOptions chromeOptions = new ChromeOptions().setHeadless(true);
And we need to add the arguments “–no-sandbox” and “–disable-dev-shm-usage” to chromeOptions as follows:
chromeOptions.addArguments("--no-sandbox","--disable-dev-shm-usage");
After adding arguments, we create an instance of Chrome driver with chromeOptions object:
WebDriver driver = new ChromeDriver(chromeOptions);
and now you’re out of trouble!
4️⃣ The Different Screen Resolution Problem
One of the biggest nightmares of a software test automation engineer is the tests that pass locally but fail on the remote. It’s not enough for automated tests to be successful only on your local computer, you must write universal ones. I mean your tests need to be executed in a different environment (browser, mobile, or an operating system).
One of the differences you will encounter when running your tests on another computer (and one that will definitely affect your tests) is the screen resolution. The most common problem with it is that Selenium cannot find a web element that was found before, at a smaller screen resolution.
Of course, you can develop various solutions to find web elements by using JavascriptExecutor. However, these solutions will not work if you face a problem apart from NoSuchElementException.
In this case, the best way is to use the DesiredCapabilities Class. The Desired Capabilities provide us instructions for the Selenium WebDriver, regarding the environment used while performing our tests.
For example, before you run your tests, you can set the browser screen resolution according to the computer. For this, it is sufficient to add a few new lines of code to your Driver class as follows-
Let’s say you want to change the screen resolution to 1280×800. You need to set the DesiredCapabilities like that:
DesiredCapabilities desiredCaps = new DesiredCapabilities();
desiredCaps.setCapability("os", "Windows");
desiredCaps.setCapability("os_version", "10");
desiredCaps.setCapability("browser", "chrome");
desiredCaps.setCapability("resolution", "1280x800");
If you create a WebDriver instance and set the DesiredCapabilities as follows:
WebDriver driver = new ChromeDriver(desiredCaps);
You will see this notification: “The constructor ChromeDriver(capabilities) is deprecated”. You can handle this problem by using ChromeOptions and merge() method as follows:
ChromeOptions options= new ChromeOptions();
// I added an argument as example
options.addArguments("--start-maximized");
options.merge(desiredCap);
WebDriver driver = new ChromeDriver(options);
5️⃣ The Different Default Browser Language Problem
Again, one of the problems that WebDriver tests will encounter in a different environment is different default browser languages. For example, you set your tests according to a browser whose default language is English. However, someone else wants to run these tests in a browser whose default language is German.
If the AUT is an application that is used in more than one country and differs according to language, there will definitely be problems in your tests. To avoid this problem, you can change your browser’s default language using the Selenium WebDriver independently from the environment. Here is the solution:
ChromeOptions options = new ChromeOptions();
options.addArguments("-lang= en");
WebDriver driver = new ChromeDriver(options);
You can find the ISO language codes here. After the above setting, you can check your browser’s current default language as follows:
JavascriptExecutor executor = (JavascriptExecutor) driver;
String actualLanguage = executor.executeScript("return window.navigator.userlanguage || window.navigator.language").toString();
Conclusion
In this article, we examined 5 important problems that can be encountered during UI testing and their solutions. The software applications that are being developed and changed every day will undoubtedly present us with brand new test problems. I’m sure this situation excites all test automation engineers because every new problem means a new journey. Don’t be afraid to go on these journeys even if there is no solution at the end 💡
Thanks Cagrı for this valuable informations