User blog:Nikodamn/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, integreate 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('Redirect to Explore Wikis 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 a 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 <span style="background-color:rgb(242,242,242);">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 <span style="background-color:rgb(242,242,242);">$  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 <span style="background-color:rgb(242,242,242);">$$  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;

<span style="background-color:rgb(242,242,242);">$$ returns an array of elements <span style="background-color:rgb(242,242,242);">li  which are children of element <span style="background-color:rgb(242,242,242);">ul  which is a child of an element with CSS class <span style="background-color:rgb(242,242,242);">wds-global-navigation__dropdown-content  . Then we can select specified element of the array ( <span style="background-color:rgb(242,242,242);">[0]  in this case) and finally execute method <span style="background-color:rgb(242,242,242);">click  on it.

Last two lines are using assertions for checking expected values. Firstly it checks if there’s an element with CSS class <span style="background-color:rgb(242,242,242);">hero-module  displayed. Method <span style="background-color:rgb(242,242,242);">isDisplayed  should return value <span style="background-color:rgb(242,242,242);">true  if element is on the page (and <span style="background-color:rgb(242,242,242);">false  otherwise). Then there’s a check if current URL matches the expected one and for that we used <span style="background-color:rgb(242,242,242);">browser  global object again and it’s <span style="background-color:rgb(242,242,242);">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.