Selenium WebDriver – JavaScript nodeJS webdriver IO & more!

Course introduction video. Here I explain the technologies we will be covering and what is included in this course.

In this lecture, I demonstrate the simplicity and speed of a JavaScript test using WebdriverIO and Selenium

Git Bash for Windows is a package that is comprised of two parts: git which is a version control system (VCS) which tracks the file changes, commonly used for programming in a team setting. bash is a Linux-based command line (which has been ported over to Windows).

In this lecture, I teach you how to download and setup GitBash for which we will use extensively during this course.

iTerm2 is a replacement for Terminal and the successor to iTerm. It works on Macs with macOS 10.10 or newer. iTerm2 brings the terminal into the modern age with features you never knew you always wanted. It’s features rich and provides several additional features above the standard terminal which will make it easier to run our tests.

In this lecture, I show how Mac users can download and install iTerm2 and how to set the tool up successfully.

The Webdriver IO API page contains reference materials for all implemented selenium bindings and commands. WebdriverIO has all JSONWire protocol commands implemented and also supports special bindings for Appium.

NodeJS is a JavaScript runtime environment which includes everything you need to execute a program written in JavaScript. It’s built on Chrome’s V8 JavaScript engine. Node.js’ package ecosystem, npm, is the largest ecosystem of open source libraries in the world.     

WebdriverIO released a version update (to v.5) on the 17th December 2018. I will add a new section to explain the changes made very soon, but in the meantime please ensure to read this lecture note otherwise you will come across an error.

npm is a package manager for Javascript and it the worlds largest software registry. The registry consists of code that can be reused in your project (rather than having to rewrite it yourself!). In this lecture, I show you how to handle package dependencies.

Selenium Standalone is a node based CLI library for launching Selenium with WebDrivers support. Basically, it’s a way for us to use Selenium which is needed to run our automation tests. As explained in the NodeJS/ NPM lecture, we can instruct our project to use dependencies and in this case we are calling the selenium-standalone library.

Selenium Standalone acts as a middle layer between our automation framework and our browsers. It passes on test messages to the relevant browser that will then run our test against the application that’s in scope.

Sublime Text is a proprietary cross-platform source code editor with a Python application programming interface (API). It natively supports many programming languages and markup languages, and functions can be added by users with plugins, typically community-built and maintained under free-software licenses.

In this lecture we use one of the available demonstration tests found on the webdriver.io homepage to create our first test.

In this lecture, we look at creating and executing a second test that uses the contact us form on webdriveruniversity.com. Contact forms on websites can be quite tricky because there is usually validation in place before it can be submitted (e.g. you need to fill in the mandatory fields before you can submit the request). We can formulate tests to ensure we test all scenarios but, in this case, we want to keep things simple to demonstrate how little code is needed to direct our tests to the contact us form.

The main purpose of WebdriverIO is end-to-end testing on a big scale. Webdriverio provides a test runner (wdio) that helps you to build a reliable test suite that is easy to read and maintain. The test runner takes care of many problems you are usually facing when working with plain automation libraries. For one, it organizes your test runs and splits up test specs, so your tests can be executed with maximum concurrency. It also handles session management and provides a lot of features that help you to debug problems and find errors in your tests.

In this lecture, we look at triggering tests using the wdio file.

In this lecture, I start showing you how we can use the wdio file to trigger our ‘contactUsTest’ and ‘loginPortalTest’ tests.

In this lecture, we continue to work towards getting out wdiofile to execute our ‘contactUsTest’ and ‘loginPortalTest’ tests and actually execute to test with an example.

In this lecture, we take a more detailed look at the WDIO file and review some of the key sections of code.

In this lecture, I introduce you to Mocha. Here I explain its purpose, why we should use it and the benefits.

In this lecture we’ll start using Mocha to form our test cases. We are going to combine our two existing tests into one .js file and then use Mocha to construct our tests.

In this lecture we continue with the changes being explained in Part 1.

In this lecture we review our changes from part 1 and 2 and execute our new and improved tests.

In this lecture, we take a look at Sync mode and the difference between Synchronous and asynchronous requests.

In this lecture, we look at changing our wdio.conf file to show you how we can run our tests asynchronously, if needed.

In this lecture we looked at the Selenium Standalone Service where I show you how we could use npm scripts to enhance our framework.

In this module, we look at setting a base URL and handling multiple environments/ websites at runtime.

In this lecture, we looked at handling multiple environments during runtime. This is a common scenario, as most companies will use multiple environments to perform different tests in the real world.

For example, a company may have a website to perform sprint related work. They may have another website to perform regression testing. In this lecture, we look at adding an IF statement in our WDIO file to handle this situation.

In this lecture we looked at logging additional information when running our tests. This will greatly help when debugging our code.  

The assert module provides a way of testing expressions. For example, if the expression evaluates to 0, or false, an assertion failure is being caused, and the program is terminated. Think of assertions as a condition (e.g. we expect result A to be returned and if result A does not return then the test should fail).

In this lecture we start adding advanced assertions into our tests using Chai. This module is broken down into sections and we keep improving our tests as we advance.

In this lecture we continue on from the previous lecture and execute the newly created test (chai.js).

In this lecture we start adding Chai Assertions to our webdriverUniversityTests.js file by adding Chai assertions using the knowledge we have picked up from the previous two lectures.

In this lecture we look at refactoring and centralizing our assertions using the wdio file.   

The Pause command pauses execution for a specific amount of time. It is recommended to not use this command to wait for an element to show up. In order to avoid flaky test results, it is better to use commands like waitforExist or other waitFor commands (we cover this in a later module).

This lecture continues from the previous lecture. Here we recap on what we have done in Part 1 and attempt to execute the test to see the results.

In this lecture, we take a look at debug mode. Debug mode allows you to debug any issues that you may have during runtime.

In this lecture, we take a look at creating selectors. Selectors are used to be able to select elements on a website. An example would be to select a particular button on a webpage. We need to instruct our tests to use the button and we do this by referring to the locator associated to the button.

There is a great Chrome addon that makes creating selectors so much easier. It’s called Ranorex Selocity and it can be used to automatically generate selectors.

In this lecture, we looked at how we could target specific tests. The Mocha documentation provides examples of how we can run only the specified suite or test-case of our choosing. This is useful because currently when we run a test, it tests all cases within the test file. This is different from when we select which test file to use (as shown previously) as we are now focusing on a more granular level where we now choose the specific test to run within a single file when multiple tests exist.

In this lecture, we looked at how to skip specific tests. This is similar to the previous lecture but sometimes skipping a specific test is the better option when we have a number of tests we do want to run and only want to skip one (or a few) tests.

In this module we took a look as CSS extraction. CSS extraction is when we return CSS information of an element from a HTML page. An example of this is to find out the styling associated to a H1 element for example.

In this lecture, you are introduced to Mocha Hooks. The Mocha documentation provides us with some useful information and demonstrates how we can use them to set preconditions and clean up our tests after they’ve run.

In this lecture we continue on from Part 1 and delve further into creating tests using Mocha hooks. We’ve now already created the initial test skeleton and have included locators into our first test so that we can locate the fields of interest from the contact us form.

In this lecture we look at how we can handle multiple browser tabs using the webdriverio API. The specific command we are interested in is the switchTab command.

In this lecture we continued on from Part 1 but this time we added a couple of assertions to ensure the correct tab was in focus during out tests. So, for example, in our first “it” test we want to check to see if the contact us page opens in a new browser window. We can add an assertion into the test to check the URL of the newly opened page and can go a step further by checking the webpage title.

In this lecture we take a look at the isExisting function in detail. This function checks to see if at least one element is existing using a selector we provide. For example, we may want to check to see if a h1 heading exists on the webpage and our test will return either true or false.

In this lecture we continue building the isExistingTest.js file. We currently have the skeleton test defined and have placed locators in each of the “it” test blocks. We now need to use the locators to test for expected values.

In this lecture we take a look at the isVisible function. This function will return true if the selected DOM-element is visible for the locator that we provide.

In this lecture we take a look at the hasFocus function. This function allows us to test whether an element has focus (e.g. we have instructed our test to select a checkbox option and we want to prove the checkbox element is now in focus of the browser).

In this lecture we continue from Part 1 and continue adding to our test

In this lecture we take a look at the isEnabled function. This function allows us to test whether an element is enabled and will return a true or false value. A typical example of when we would use this function is when we test web forms. Sometimes a form field will be disabled (e.g. a second email input field) until the first email input field has been entered.

In this lecture we continue developing our test (from Part 1) and will now add assertions into our “it” blocks.

In this lecture take a look at the isSelected function which can be used to determine if a radio button option has been selected or not. It will return a true or false value.

In this lecture we continue to build our isSelected test from Part 1.

In this lecture we take a look at the isVisibleWithinViewpoint function, which will return true if the selected DOM-element is found by given selector and is visible within the viewport.

In this lecture we continue to build our isVisibleWithinViewpoint test from Part 1.

In this lecture we go back to our contactUsTest.js test and look to enhance the current file by introducing getText, isVisible and isExisting functions.

In this lecture we continue improving our contactUsTest.js file and will now use the locators to build methods round them to validate the output. We are now going to test to see if a successful form submission has taken place.

In this lecture we now review our code from the changes made in the last two lectures and attempt to execute our test.

In this lecture we take a look at the waitForText function. We can use this function to wait for an element (when given a CSS selector) for a given amount of time in milliseconds to have text or content.  

In this lecture we continue building our waitForText test from Part1.

In this lecture we take a look at the waitforExist and waitForVisible functions from the webdriverio documentation.

waitForExist can be used to wait for an element (using a locator) for a provided amount of time in milliseconds for the element to be present within the DOM. The value returned will be true if the found. There is also a reverse flag that can be used that will instead return true if the element does not exist.

waitForVisible can be used to wait for an element (using a selector) for an amount of time in milliseconds for an element to be visible on the page. The value returned will be true. There is also a reverse flag that can be used return true if the element does not become visible in the given amount of time.

In this lecture we continue from the last lecture and further develop the waitForExist and waitForVisible test file.

In this lecture we look at the waitUntil command. The waitUntil command allows you to wait on something. It expects a condition and waits until that condition is fulfilled with a truthy value.

In this lecture we look at the waitForValue command. WaitForValue waits for an element (using a locator) to have a value within the amount of time set in milliseconds.

In this lecture we take a look at Sync-Request which is a npm package than can be used to GET data from a given URL to retrieve data that we can then pull into our tests, rather than having to define specific values (such as testEmail@email.com).

In this lecture we continue on from Part 1 and finish making changes to our test file to use data from a JSON file. So far, we have installed the sync-request package, have referenced the package in our test file and have created two variables that link to the JSON file URL and have set the format of the data retrieved.

If you want to extend the browser instance with your own set of commands, there is a method called addCommand available from the browser object.