Web Testing Automation: Comparing Protractor and WebdriverIO Frameworks
As an example, I am using the same framework models and identical tests for the same web resource, with same checks but written using different frameworks. Initially, the tests were written for WebdriverIO and then ported to Protractor. The porting took about an hour for this specific instance.
1. In WDIO, code synchronization is peformed by an internal engine. However, if you wish, it allows you to use async / await syntax. In Protractor code, you need to use async / await to synchronize the code.
2. In WDIO, you have fewer waiters, and they look clearer. In Protractor, there are more default waiter types, and they are more flexible in customization but more complex in reading. Both frameworks allow writing your own waiters, in WDIO – waitUntil(), and in protractor – with browser.wait().
You can see example of waiters at the bottom of the screenshot.
3. In WDIO, you have to use getters when declaring the element. Otherwise, if the search for the element takes place before the element appears on the page, it will cause an error. Protractor uses the so-called Lazy elements, and the search for elements occurs automatically when calling a function where they are used.
4. WebdriverIO is more aimed at testing React applications, while Protractor is designed for testing Angular projects, so it has a built-in mechanism of waiting for a page to load in Angular. Writing tests for something OTHER than Angular is possible, but requires to use .waitForAngularEnabled(false) at every page opening in order to disable the mechanism of waiting for the answer from Angular on the page. If it is not used, the framework will wait for the page to load until the end of timeout, and then the tests fail.
- There are built-in selectors for Angular and a mechanism of waiting for the page to load and render.
- Requires to use async/await to synchronize the code execution.
- A large number of waiters out-of-the-box.
- Flexible customization of waiters.
- Cumbersome waiters.
- Usage of Lazy Elements.
- Rather good code readability.
To conclude: a good framework for writing tests for Angular applications. It can be used for writing tests for non-Angular applications, but you have to disable waiting for Angular on the page. It is the most popular at the moment, but the updates are not regular. If you need automation for Angular, this framework is your choice.
- There are built-in selectors for React.
- Built-in synchronization of code execution.
- You don’t have to use async/await.
- A small number of waiters out-of-the-box.
- Cumbersome getters when declaring elements.
- Good code readability.
To conclude: a good framework for writing tests for React and any other type of applications, including mobile (via Appium). The readability is a little better thanks to no need of using async/await and laconic waiters. If you need automation for React and more, and you are interested in regular updates and support, this framework is your choice.