How to start writing automated tests using WebdriverIO
End-to-end tests are useful tool for checking if current state of an application meets business requirements. In Fandom we put a lot of emphasis on such tests and ensuring that those needs are met along with application changes to make sure that we deliver the best possible experience for our users.
In this article series I’d like to present how to create functional tests in WebdriverIO, integrate them with Jenkins, containerize, scale and setup a good-looking test reports dashboard with Allure and implement a Continuous Deployment solution. But let’s start from the beginning.
What is WebdriverIO?
WebdriverIO (or just wdio) is an Open Source test framework for Node.js. Currently it’s one of the most popular testing frameworks in the JS automation world next to Selenium, Cypress or PhantomJS. It has gathered so many fans, not only because it’s free and supports WebDriver protocol, but also because it’s being very frequently updated with new features and plugins. With wdio comes a great bunch of integrations like e.g. plugins for web services (Applitools, BrowserStack, Appium, Sauce) and support for some of the most popular test reporters (Junit, Spec, Allure).
If you want to try WebdriverIO there’s already bunch of great resources online on how to set it up, but your first step should be visiting Getting Started doc. At the beginning of this article you read about config generator. Once you run it go with: local-machine as backend, Mocha test framework in sync mode, Spec test reporter and Chromedriver for browser. This configuration can be edited and we will do so along with next steps in our series, so don’t worry about it.
Once you’ve finished configuration you should add an example test in the specified test directory (if you didn’t set directory explicitly, it should be ./test/specs/ by default). For your very first run you can copy a test from mentioned Getting Started. To start your tests use command: ./node_modules/.bin/wdio wdio.conf.js (or check npx) you should notice test being executed in your Chrome browser and some test report in terminal.
Let’s write our first test!
Once you’ve setup wdio we can create our very first test. It’s going to be very simple as for now we won’t focus on readability nor code standards, but on understanding the whole idea. Test will navigate to www.fandom.com, accept GDPR rules and navigate to Explore Wiki page via link in the global navigation menu. Let’s swap our previous example test for the content below:
it('Explore Wikis redirect from Fandom.com', () => { browser.url('https://fandom.com'); $('[data-tracking-opt-in-overlay=true]').waitForDisplayed();
$('[data-tracking-opt-in-accept=true]').click(); $('.wds-global-navigation__dropdown-toggle').moveTo();
$$('.wds-global-navigation__dropdown-content ul li')[0].click(); assert.equal($('.hero-block').isDisplayed(), true);
assert.equal(browser.getUrl(), 'https://www.fandom.com/explore');});
If you execute your tests now, you should see a passing test with two checks highlighted in green. Let’s go line by line and check what’s happening in this code.
At the very beginning there’s an it() which describes a tests in MochaJS. That value will be printed in a report to differentiate tests. Inside of it() there’s test code. It’s starts from browser.url() which is a method for navigating to some webpage with specified URL. browser is a global object and you can read more about it the The Browser Object article.
If you check www.fandom.com you’ll see that anonymous user visiting the page for the first time needs to accept GDPR rules. Since our test does not have any sign in operation yet, we’ll need to accept it too. The next two lines are waiting for modal to appear and then accepting rules by clicking a button. Let’s take a look at line starting with $(‘[data-tracking-opt-in-overlay=true’) . This is a way to find first web element which contains CSS attribute data-tracking-opt-in-overlay with value true . Take a note that there are multiple ways to find an element — by CSS class, id, attribute or other. You can read more about them in this Selectors article.
Once element was found, program will proceed to executing method waitForDisplayed() . If that element will not be displayed then test will fail. Next line performs standard click behavior with click() method on another found element and in result should click “Accept” button in the GDPR modal.
In the next line test is using method moveTo() over found element (by the way — this time we used CSS class to find an element) we can simulate mouse pointer hovering over that dropdown. This is necessary as in the next step we would like to click somewhere inside the content of that dropdown.
Once tests hovered over that element and dropdown is finally open, upcoming step will be to click “Explore Wikis” option. When we described $() we mentioned that it returns first found web element, but what if there are few of those which match the criteria? For such cases there’s $$() as it returns an array of elements. As you can see it has been used in that line:
$$('.wds-global-navigation__dropdown-content ul li')[0].click();$$() returns an array of elements li which are children of element ul which is a child of an element with CSS class wds-global-navigation__dropdown-content . Then we can select specified element of the array ( [0] in this case) and finally execute method click() on it.
Last two lines are using assertions for checking expected values. Firstly it checks if there’s an element with CSS class hero-module displayed. Method isDisplayed() should return value true if element is on the page (and false otherwise). Then there’s a check if current URL matches the expected one and for that we used browser global object again and it’s url() method.
Summary
In this article we went through setting up WebdriverIO project and writing our very first tests. You should be able now to configure wdio on your local machine and write a simple test with Mocha. We mentioned some important Browser object methods, different ways of finding elements on a page and executing actions on them. And all that executed in Chrome browser.
There’s still room for improvement in this test as for example except waiting for GDPR modal and accepting rules we could instantly inject a Cookie. We could also improve the test structure by applying Page Object pattern or even add some more meaningful logging messages.
But this (and even more) will be covered in the next WebdriverIO related articles.
Originally published at https://dev.fandom.com.
