Built on top of NodeJS and Selenium Webdriver (W3C WebDriver) API, WebdriverIO supports both web and mobile application testing. Since you are taking your time to read this article, it means you might fall into any of the below categories:
TABLE OF CONTENT
- Best Practices to Adopt While Developing WebdriverIO Framework
- Further Enhancements to Your Test Framework
Best Practices to Adopt While Developing WebdriverIO Framework
First and foremost, go for the latest version of WDIO, i.e., currently v6, released in early 2020. According to official documentation, LTS will be provided for v5 till April 2021, and v4 is currently deprecated. Now let’s see some of the desirable features that v6 has to offer.
a) Natively supports Puppeteer
To run a local test case, you are free to switch between Puppeteer and WebdriverIO API as you wish. Also, you won’t need to download the browser driver anymore. With WebdriverIO, you can check if a browser driver is running and accessible at localhost:4444/. In case it doesn’t, check if it uses Puppeteer as a fallback. Being able to access Puppeteer in your tests allows you to:
- Leverage the Chrome DevTools protocol capabilities, with a much richer set of automation features.
- Run commands on Puppeteer much faster. Hence it can help speed up local execution.
b) Performance Improvements
This has been one of the primary design goals of WDIO v6. It has also come with many internal improvements that will speed up test execution and lower CPU and memory usage.
And there’s a lot more. You can always refer to the WebdriverIO official documentation to know more about WebdriverIO v6.
2. Page Object Model (POM)
POM is a framework design pattern widely adopted by Agile practitioners for easy test script maintenance and enhanced code reusability. Implementing an approach like POM will help you efficiently manage your locators, reduce duplication, and make your framework more programmer-friendly.
3. Create Helper Methods
Now, this is also linked with code reusability and ease of maintenance. Fundamentally, the idea is to wrap the code for commonly performed actions – like logging in, clicking on something, waiting for a result, logging out, etc. into a method so that they can be shared and reused by all scripts.
Also, you can add parameters to customize these helper methods to suit various function call needs.
4. Don’t test the same functionality twice
To speed up the testing, we should be strategic in terms of test coverage. Reducing the duplicate and avoidable scenarios directly helps to bring the test case count down.
Needless to explain more, the lower the test case count, the faster the execution result.
5. Avoid Hardcoding URLs
In WebdriverIO, we have a configuration file wdio.conf.js, which aids us in specifying the location of the tests, frameworks you want to use, reporters, browsers, and all other general configs of the project.
Another useful option is to configure the
baseUrl of the application here so that we don’t need to specify it every time in our test scripts.
But generally, in most cases, we might need to run the application in multiple environments like – development, QA, staging, production, etc., each having different URLs. In that case, we can easily configure the URLs by declaring an environment variable and passing the detail of the environment/URL in which the test should run along with the test run command.
The configuration steps are briefly explained below:
Step 1: Create a separate file to maintain the URLs and export them. Here we have created a file named ‘wdio.config.url.js’ (Give any name of choice)
Step 2: The remaining settings are to be done in the wdio.conf.js file. First of all, require the URL file.
Step 3: Create an environment variable to pass the URL values.
Step 4: Create a condition to check if the value passed for ENV is valid.
Step 5: Now, inside exports.config change the baseUrl to match the environment variable.
Step 6: That’s pretty much it. Now along with the test run command, pass the value for ENV.
Here, the URL for DEV will be mapped, and the test starts running. If any invalid value is passed or the value of ENV is skipped, corresponding logs will be generated as per the check condition we created.
6. Writing a good test script
- Writing only one test case in a test file. This helps in keeping the test cases independent of each other, analyzing failure, and also aids in parallel testing.
- Keeping it short or atomic. Reduce the number of steps to below 20 (there is no golden rule). Make use of helper methods.
Let’s look into some possible factors that can slow down the testing and methods that can be adopted.
1. Parallel Testing
As the application features grow, so does the test count. It becomes more and more vital to enhance the execution speed and reduce overall execution time. One way of achieving this is through parallel testing, i.e., running your test scripts concurrently.
To enable parallel testing, adjust the maxInstances property in your config file. See the below sample code.
Here the maxInstances is set to 3, and 2 capabilities are mentioned (Chrome, Firefox). The math is simple. The WDIO test runner will spawn 6 processes, i.e., 3 test files will run simultaneously in the 2 browsers. You can adjust the values according to your requirements.
2. Disabling screenshots
Screenshots are often our saviors when it comes to debugging. But it also comes with the cost of execution time and slowing down your tests. Hence, the suggestion is to enable screenshots only when test failure occurs instead of taking screenshots for each and every step.
This WebdriverIO official documentation on the screenshot will guide you on how to implement this using Hooks.
3. Error Logging
Configuring error logging doesn’t have any direct impact on execution speed up. However, the idea is to enable logs only when some error occurs, hence keeping the log data more relevant, assisting us in quick debugging.
The level of logging verbosity can be set in the wdio.conf.js file.
4. Use the right wait methods
WebdriverIO provides us with various methods to assert wait in the program. It’s good to have an idea about which is to be used when and most importantly, which to avoid.
This method pauses execution for a specific amount of time. To avoid flaky test results, it is recommended not to use this command to wait for an element to show up, a page to load, or an action to happen. It is better to use commands like waitUntil, waitForExist, or other waitFor* commands.
This wait command is your universal weapon if you want to wait on something. It expects a condition and waits until that condition is fulfilled with a truthy value.
WebdriverIO offers many waitFor APIs, which helps to wait until an element is displayed, exists, clickable, etc.
Using the waitUntil() or waitFor* methods will make the script performance better. As the elements can be accessed as soon as they are available, and no extra waiting time is required.
Do check out the official WebdriverIO API documentation for more information.
5. Use headless browsers and drivers
A headless browser is a browser that does not have a user interface. Headless testing is a way of running your test cases without browser UI, making your script run faster. This is an option you can consider if you don’t need a real browser for testing or using CI/CD.
And no need to worry! You will still be able to capture screenshots and see how your application looks in headless mode. Debugging can be done as effectively. In WDIO, by adding a few arguments in your config file, you can adopt the headless version of your favorite browser.
a) For Firefox
b) For Chrome
Further Enhancements to Your Test Framework
1) Automation Testing using CI/CD Pipeline
To achieve speedy delivery with feedback on quality, it is crucial to integrate the automated testing into the CI/CD (Continuous Integration/Continuous Delivery) pipeline. This helps in enabling Continuous Testing.
WebdriverIO provides tight integration with CI systems like Jenkins. Being open-source, Jenkins is widely preferred in the automation testing world. With some quick and easy steps, Jenkins integration can be achieved in your WebdriverIO framework. Do check out the Jenkins official guide for Jenkins set-up!
Another favored strategy is to integrate Jenkins with container technologies like Docker. With the advent of Docker, practically all necessary application dependencies can be containerized. With this WDIO-Docker service, you may run your application container in your CI and in complete isolation.
2) Cross Browser Testing with Selenium Grid
To stay ahead in a highly competitive market, it is our duty as testers to ensure the application’s quality in all scenarios, i.e., the app should behave as expected across all platforms, browsers, and devices without crashing. This is where test coverage and cross browser testing comes into the picture.
LambdaTest is a popular cloud-based platform that provides you access to 2000+ browsers for both mobile and desktop to help you gain the maximum test coverage during the automated browser testing. Moreover, you can choose from a wide range of Windows and Mac operating systems, along with all legacy and latest browsers.
WedriverIO provides you service to seamlessly integrate LambdaTest into your framework through a few quick and easy steps. Let’s take a look!
Step 1: In your project terminal, give the following command to save LambdaTest service as a devDependency.
Step 2: Create a free account or log in to your LambdaTest account and fetch your unique username and access key. You can fetch the details from the Profile section.
Step 3: Now let’s make some edits to the config file. In your wdio.conf.js file
These are the additional configurations to be done:
- Pass your access token and user details by creating two variables, user and key.
- Set the tunnel as true to enable routing connections from LambdaTest cloud through your computer.
- Set the hostname corresponding to LambdaTest
- Optionally, you can also enable report formats like video recording, console, network logs, etc., to be true.
Step 4: Run your tests. Use the command appropriate to you.
The test starts running, and logs can be observed in the terminal.
To observe live running status, go to your Automation dashboard in LambdaTest.
We can analyze individual test run reports from Automation Logs.
We have successfully run our test cases using an automated cross browser testing solution provided by LambdaTest through a hassle-free experience!
Automation was introduced to accelerate the testing process and identify development bugs at the early stage. More and more companies are coming out from the shell of the traditional way of manual testing and adopting a more “shift left” approach focusing on how to leverage the benefits of automated testing in their development process.
Additionally, we have also covered a few of the best strategies to stay ahead, like CI/CD implementation and cross browser testing. Empowered by LambdaTest, we utilized a cloud-based solution for remote Selenium Grid to achieve parallel cross browser testing across multiple platforms.
Hopefully, this blog will enable you to optimize your framework and speed up testing. If you wish to optimize your web application quality by unlocking coverage in a wider variety of platforms or browsers or versions, please feel free to explore the LambdaTest platform.
Opinions expressed by Web Code Geeks contributors are their own.