How to

Getting Started with WebdriverIO

Passion for quality is inculcated within everyone at Calcey and especially the QA professionals take the lead in ensuring every product, release, and delivery is meets expected standards. As a project-based company, we work with diverse business domains and functionalities. We all believe that testing plays an essential part of a project. Automating testing in every project regardless of its size, domain or the environment has been a challenge. To overcome this, we have come up with a handful of brittle tests but it has always been a challenging task to make it into a resilient test suite.

A few months ago we saw the extendable, compatible and feature rich WebdriverIO and decided to give it a go. We implemented a robust automation framework by customizing the features in the WebdriverIO and made it useful for any test environment such as mobile, web and API. Since then, progress with our automation plans has been extremely positive. The secret is that test scripts are easy to write, understand and maintain when it comes to WebdriverIO. Now we are able to write test cases for both web and mobile applications and with a coverage of nearly 70%. We can generally trust that a green build correctly means that the release is ready to go.

In this blog post, I’ll provide a walk through of how we managed to introduce this development and the tools that we have put in place to make it easier for our QA team to write and execute the tests.
I believe the famous Page Object Model (POM) made our path easier. Basically, the WebdriverIO is designed with the influence of page object design pattern. As stated in the WebdriverIO developer guide,
“By introducing the “elements as first-class citizens” principle it is now possible to build up large test suites using POM pattern. There are no additional packages required to create page objects. It turns out that “Object.create” provides all necessary features we need, such as inheritance between page objects, lazy loading of elements and encapsulation of methods and actions.”

Likewise, WebdriverIO facilitates quite a lot of necessary features to make the code look simple, concise and easy to read. In fact, it supports async programming concepts, so you don’t need to worry about handling a promise anymore. Typescript has been the buzzword these days due to many advantages it has, thus we have written our scripts with TypeScript which is a strongly typed superset of plain old Javascript. Further, Chai Assertion Library has been used for test assertion and Jasmine as the test runner both which allow you to write your tests in behavior driven development (BDD).

So far this has been a killer combination which provides a cleaner and faster control for testing any app thus meeting business requirements in a more reliable and scalable way!

So it’s time for us to get hands-on with WebdriverIO. For demo purposes, let’s use as guinea pig. This is a simple website built using react and the user can add his daily to-do notes one below the other.
Before we start, make sure to

Detailed steps can be found here.

Now that we are all set with our environment, it’s better we to plan out how we are going to maintain our tests and have a proper structure for writing our tests. After some research, we decided to go with the page object pattern. Page Object pattern is well-known in the world of test automation for enhancing test maintenance and reducing code duplication. Fortunately, the version 4 of WebdriverIO  test automation framework was designed with Page Object pattern in mind.

Let’s try to build a page object example for the to-do note page. The first step is to write the all important selectors that are required in our object as getter functions.

import { Client, Element, RawResult } from 'webdriverio';
import { CompletedPage } from '../completed/';
export class ToDoPage {
  private newTodo = 'input[class=new-todo]';
  private todoList = 'ul.todo-list li';
  private lastTodo = 'ul.todo-list li:last-child';
  private navigationLink = 'a[href=\'#/completed\']';
  get todoInput() : Client<RawResult<Element>> {
    return browser.$(this.newTodo);
  get todoListLength() : number {
    return browser.$$(this.todoList).length;

In the code shown above, we are using two get methods one to get a new to-do element and another to get the number of to-do lists present on that page.

Similarly, we can further write other methods needed such as navigating, completing and clicking an element as shown below.

public addToDo(todo): void {
public navigate(): void {
public completeLastTodo(): void {
public navigateToCompleted(): CompletedPage {
  return new CompletedPage();

After defining all required elements and methods for the page it’s time for us to write the tests using them. In the test class we are using the methods in the to-do class we created earlier using the import command as follows.

import { ToDoPage } from './';

We are using mocha’s BDD syntax to write our tests, therefore, each test suite and the case is defined by a describe or it block, respectively. The test suite begins with a describe function which takes two parameters:

  1. String – This describes what the test suite will be doing.
    eg: “Todo Page”
  2. function – This is the block of code that will execute what we described
    eg: describe(‘Todo page’, function() { });


describe('todo page', () => {
  let n = 0;
  let todoPage: ToDoPage;
  afterEach((done) => {
    const filename = './e2e/screenshots/Todo_'.concat(String(n), '.png');
    n += 1;

Then, we will start to write the specs of the test which will begin with it function. The it function takes two parameters.

  1. String – This describes the test specification
    1. “Should add todo”
    2. “Should remove completed”
  2. function – This is the block of code that will execute what we described
    1. it(‘should add todo’, function() { });

WebdriverIO sets up the test hooks in it’s config file by default. Each hook is executed at different stages of the test’s flow, with the before hook running once per describe block, before any it blocks are run.

A spec contains one or more expectations that test the state of the code which is called assertions. In almost all cases, you will need to locate one or more elements using a selector, then perform some operation on the element(s)

  • Examples:
    • Find text on a page and verify the text
    • Verify CSS properties of an element

For the assertion purpose, we have installed an assertion library called Chai! Chai provides three different styles (Expect, Should, and Assert), that allow you to write syntactically attractive assertions. We’ll be going with Expect for the moment. We can either initialize Expect in the Before hook located in the wdio config file or just import it into our test class.

import { expect } from 'chai';

After declaring Chai and Expect, we can now add the first assertion to our test.

it('Should add todo', () => {
  let todoListLength = todoPage.todoListLength;
  todoPage.addToDo("New Todo");
  const newTodoListLength = todoPage.todoListLength;
  expect(newTodoListLength) + 1);
it("Should remove completed", () => {
  let todoListLength = todoPage.todoListLength;
  todoPage.addToDo("New Todo 2");
  const newTodoListLength = todoPage.todoListLength;
  expect(newTodoListLength) + 1);
  let completedPage = todoPage.navigateToCompleted();
  const currentCompletedTodos =  completedPage.todoListLength;
  todoPage = completedPage.navigateToToDoList();
  completedPage = todoPage.navigateToCompleted();
  const newCompletedTodos = completedPage.todoListLength;
  expect(newCompletedTodos) + 1);

In the above code, we are adding a new to-do form (‘Should add todo’). After adding the to-do form, using the expect command we verify whether the number of to-do forms available now is 1 more than the number of to-do forms before. If this expectation passes we can conclude that the particular test is passed

Finally it’s time for us to run our tests. Open the terminal and change the directory to the folder where the wdio file is located
Enter the command “npm test” and press enter and your tests will start to run.

The test results will be shown as above in the terminal and if needed you can add 3rd party test reporters such as allure which is supported by WebdriverIO.

There you have it, that’s how you get started test automation with WebdriverIO. Try it out and let us know what you think.


How Is IoT Driving Sustainable Change?

Photo by NASA on Unsplash

IoT expert Pilgrim Beart shares his insight on how IoT is supporting sustainability, from electric cars to food waste.

Think of IoT and for the many it’s bleeping fridges and irritating smart speakers that literally have a ‘mind’ of their own.

Speak to an expert and you get the real world of IoT: exciting technology concerned with sustainability, that’s helping solve some of humanity’s biggest woes.

I caught up with Pilgrim Beart, IoT engineer and Co-founder of DevicePilot, to find out why we should be optimistic about the second generation of IoT.

Hey Pilgrim, please kick us off: what is DevicePilot?

You know when that smart thing in your house stops working?

Well, the folks who made it need to know how they should fix it. DevicePilot enables companies to do that with a Software as a Service (SaaS) platform for millions of smart things in homes, businesses and city-streets.

We’re a bit like Google Analytics, but for IoT.

So without you guys, the world would be full of malfunctioning devices turning on each other, and us?!

Haha something like that. Machine to Machine (M2M) communications have come a long way from the early 2000s when production was in-house: when devices were expensive, slow to build and completely incompatible with anything external.

Now we’re seeing this avalanche of IoT because anyone can easily build functionality — hardware modules, network connectivity, cloud components — which are multi dextrous and can pollinate across multiple applications.

This dynamic has fast tracked IoT to become the next most important ecosystem in tech. And it’s essential that remote monitoring and servicing happens so the ecosystem does not breakdown.

So, yes, we’re kind of an integral cog in the machine.

How is IoT driving sustainability?

It really is. Many of our customers are aiming to change the world for the better: to them, IoT is just a means to an important end.

For example Pod Point are an electric vehicle (EV) charging company. The CEO, Erik Fairbairn, started the company before there was even a murmur of a mass EV market in the UK.

Now that it has become clear that the internal combustion engine is doomed, EV charging is a massive growth industry. As the market matures, it has quickly become insufficient to simply deploy charging points: Pod Point has to make sure they are working and available 24/7! And that’s where we come in with our ability to remote monitor and analyse.

Pod Point’s transition from selling hardware to selling a service is representative of how a lot of successful IoT plays out.

Great example, Pilgrim. Where else is IoT doing good?

Food waste instantly springs to mind.

Our client Winnow uses IoT to help commercial kitchens around the world halve their food waste. It’s amazing! Their “connected scale” goes underneath the waste bin in a commercial kitchen, and when the porter chucks something into it, a tablet lights up to ask what it is.

It’s a bit like how we buy food in supermarkets, but in reverse.

The data is then fed back into the menu-planning and the chefs can reduce future waste with the clearer insight on how many portions to make on a given day. The tech is remarkably effective and has been picked up by many of the big players in the food industry. The fact is, it also saves the kitchen money so it makes business sense too.

What I love about Winnow’s proposition is that no-one — no IoT analyst and certainly not me — would have imagined it three years ago.

Yet, like many great ideas, it’s obvious in retrospect.

I mean, what vertical is it in? Smart Waste? Is that a thing? Well, it is now.

Winnow are a perfect example of new breed of what we call the “born connected” companies that DevicePilot serves: businesses who intrinsically assume that everythingshould be connected by default.

Sounds like DevicePilot have a seriously cool customer group!

We do!

We’ve built a product that solves the “seeing and managing your devices” problem. And there’s so much incredible stuff happening with IoT it’s just a case a of scaling it now. And how hard can that be? [laughs].

We also have an incredibly cool team.


OK go on then, tell us about them…

We’ve intentionally built a small team of exceptional multi-talented people who don’t conform to stereotypes. Our engineers are great communicators. Our lead developer thomas michael wallace has an amazing blog. So does our Chairman Rob Dobson who’s just made an AI-driven anti-cat water-pistol! Our Lead UI developer George and our Head of Marketing Yasemin work together to keep the look-and-feel of our product aligned with our marketing. They call themselves the “Duke and Duchess of Brand”.

Just don’t call us “Device Pilot” WITH a space!


I’m glad you got that last bit in, because I was bound to spell it “Device Pilot”.

I know. That’s why I said it!