When you are the maintainer of an npm package, you need to do some administrative work around its versioning. When you release a new version, you need to make sure the package.json is updated, the package is correctly uploaded to npm registry, the git repository is tagged accordingly and so on. You shouldn’t be doing these things manually if you can automate them.

In the previous series of posts, we had a look at functional testing with WebDriverIO and mocha. We explored the page object pattern and saw the challenges of asynchronous programming with promises. We even saw some ways of mitigating those challenges. However, there is another approach to the same problems. Instead of running our tests with mocha, we can run them using the integrated test runner of WebDriverIO. From version 4 onwards, I’ll quote from their site, “the integrated test runner allows you to write asynchronous commands in a synchronous way so that you don’t need to care about how to propagate a Promise to avoid racing conditions”. If you’re starting a new project, or if you don’t have many tests to migrate, this is definitely an interesting approach. This combines a synchronous-like approach without using anything extra.

In the previous post, we explored the Page Object pattern and rewrote our tests to use this technique. Sometimes, it can be that the tests appear to be a bit verbose due to the usage of promises. Additionally, promises and asynchronous programming in general can be somewhat confusing to developers. Let’s see some ways of making the tests shorter and easier to read.

So far, we’ve seen how to write functional tests using the WebDriverIO API directly. Let’s see what problems we may encounter with that and how the page object pattern comes to rescue. Our example functional tests work against Google’s homepage. One test verifies that the search text box exists and it’s visible. Another test types something into that search text box and performs the search. In order to identify the text box, we use the same selector, input[name=q]. The problem starts here and it’s not unique to functional tests: it’s copy pasting around magic strings.

In the previous post, we wrote some functional tests and we encountered our first failing test. Let’s see how we can go about investigating these failures, both on a developer machine and during continuous integration.

So far, we have essentially only one test, a test that verifies the title of the browser. Let’s try to make a more interesting test. We’ll need to interact with elements on the page and simulate the user’s journey.

Before we go any further, let’s take a break and add a bit of a structure to our functional tests. This will allow us to reduce the code we have to write for each test. We’ll also start thinking about how to organize the tests into folders and files.

Let’s continue our functional testing examples by adding a few more tests. This will demonstrate why we need to start thinking about the structure of our tests and why we should be developing a framework that will allow us to write less code. Let’s add one more test. We already have a test that verifies Google’s homepage title. We’ll do the same for Yahoo’s homepage. By the way, maybe it goes without saying, but normally you would be verifying your own site, during development and CI.

Let’s have a look at a first example of writing and running a functional test. This is going to be a very basic hello world example, but still it gives an opportunity of looking at the bare minimum usage of WebDriverIO and a first taste of asynchronous programming with promises.

In the previous series of posts, we’ve explored the basics of unit testing and the principles around it. When developing websites, there is another important type of testing: functional testing (also known as browser testing).