Why We Love WebdriverIO
Originally posted on our partner blog at East Coast Product, November 17, 2016
I’ve been using the WebdriverIO testing framework for the last eight months and have had an incredibly positive experience, so I want to share the love. If you are looking for a new testing framework, here are a few reasons to consider WebdriverIO.
It’s developer friendly
WebdriverIO is written entirely in JavaScript. This is awesome because it lets me write checks in a familiar language and allows me to use the same libraries I have used previously for Unit Testing (Mocha & Chai).
Also, WebdriverIO makes it super simple to find elements. Outside of searching for elements by only the text they contain (e.g. ‘button=Save’), WebdriverIO allows the use of advanced CSS selectors (e.g. ‘#editSomething>span #someElementID’, or ‘#elementId>h3:nth-of-type(1)’). This means there’s no need to rely on the pesky xPath and accidentally selecting duplicate elements is no longer an issue!
Combined with Firefinder for Firebug (for Firefox), WebdriverIO makes writing checks incredibly easy. The framework comes with a nice configuration utility that helped me create a config file in a matter of seconds. I did it by typing:
wdio config
in the command line of the project’s folder and then a command line wizard launched. After answering some questions about my project, the config file was done:
Another good aspect of WebdriverIO is it comes with its own test runner. I wanted to learn more about automated workflows, so I used gulp-webdriver, a Gulp plugin that runs selenium tests with the WebdriverIO runner. Setup is as easy as:
npm install -g gulp
npm install --save-dev gulp
and the gulp task for running checks looks something like this:
WebdriverIO supports other testing frameworks like Jasmine, Cucumber, and Mocha. I used Mocha because the configuration helper kindly offered it to me, and I’ve used it before.
Additionally, you can add custom options into the wdio.conf.js config file, e.g. for Mocha:
Not only that, you can set global variables, arrange scripts into suites, and set the number of browser instances. I’ll dive deeper into these options in a later blog post.
If you’re still doubting the framework’s friendliness, check out this awesome Gitter channel where WebdriverIO devs and users hang out, share knowledge, and help one another.
You get Selenium under the hood
The best thing about WebdriverIO and Selenium working together is that checks run in a broad range of browsers (the sorts that have drivers, that is), like Firefox, Chrome, Safari, and even IE. This makes cross-browser checking SO much easier.
It’s intuitive
The commands used in WebdriverIO checks are short, succinct, and pretty intuitive.
For example, logging into an app is as easy as:
Commands are customizable
Out of hundreds of available commands, sometimes we need that special one that’s not available. Thus, we make our own. WebdriverIO supports custom commands, so we can just call the “addCommand” function and pass in our custom steps like this:
I haven’t needed custom commands yet, but it’s good to know that they’re available if necessary.
Easy Page Object & Helper Functions
WebdriverIO supports the Page Objects design pattern. Using Page Objects is a way of separating page information from the checks. This helps reduce repeating the same selectors connected to a common action over and over, like Login, that cause you to end up with scripts that are difficult to maintain. If anything changes on the page, you’ll have to refactor your code to account for the change in multiple places, and you might miss a file or two. To work around this, a Page Object can be used to reference that action. Then, it’s easy just to refactor the Page Object with the update propagating to wherever you use it in the checking suites. Here’s an example of how to use of a Page Object:
Personally, I use helper functions for this purpose. Here’s an example of a helper function, account.js:
This function is then referenced in the testAccount.js suite like this:
That way, if anything changes in the Account/Login page code, I can refactor my account.js helper function, and I’m done.
When I was starting out, I didn’t really understand the Page Object Model but have since decided to give it another chance. Since it seems like helper functions do pretty much the same thing — reference an action and keep it separated from the checks — I’m not sure if I should switch to Page Object Model. If anyone has some good arguments for why the Page Object Model is a better choice, I’d be very interested in hearing them.
Final thoughts
I hope you find WebdriverIO as valuable as I have. If you want to play with it some more, check out this GitHub repo to see the examples from this post and a few extras that will be the topic of my next post (repo in progress). Happy Testing!
We’re constantly trying new tech to improve our development skills and experience. If you are interested in innovating and growing your product, let’s do it together. Reach out to us today.
