We, at Wingify, have been writing e2e test cases for our A/B testing app for the past 5 months using protractor. Writing e2e scripts is easy but making them work 90% of the times on all browsers makes you go nuts! Sometimes, I feel that the browser is moody, but of course, we have to deal with all its moods and make sure that test cases are robust.
Getting your e2e tests to run smoothly everytime comes with experience. And, learning from my experiences testing our app, here is a post describing them.
An Overview of Protractor
Protractor is a specially designed wrapper around WebDriverJs to automate e2e testing for angular apps. The following figure gives an overview of the architecture involved for automation and testing :
Setting up protractor and add-ons
For basic setup, go through the Protractor official documentation.
Once the setup is done, you are ready to write and run e2e scripts. Next you need a report of failed and passed test cases along with screenshots.
protractor-html-screenshot-reporter , an npm module, provides you with an Html report of the test cases along with screenshots. Set it up as mentioned in npm documentation
Test Scenario and Test Data follow a one-to-many relationship, so we can’t hardcode the test data within the code. For example: The same login test script can be used to test the login of different types of users. To make life easy, it is a better option to make use of .xls files (Microsoft Excel, OpenOffice etc) and import data dynamically into the script, while execution.
xlsjs npm module lets us fetch the data from an .xls file and use it in script. Follow the below mentioned steps to set it up :
- Install xlsjs
- Call function as:
Test both Angular.js and non-Angular.js based pages
Our use case involves using Protractor for an Angular.js based app, but it works pretty well for non-Angular.js pages as well. Simply set the following flag to true and access the webdriver instance using browser.driver instead of element as shown below :
For instance, the following code for an angular page:
would be written as shown below for non angular page:
Sounds cool? Now let’s dig deeper in the protractor world.
A piece of protractor code
Before we start with the advance functions, let’s have a look at a simple login test case, where we verify that the user should be redirected to a welcome page after login.
Let’s study the code:
expect are jasmine framework methods to write the tests easily. Read more about them here.
beforeEach function in the code above executes before all
it blocks, however, you might not want to execute the code in
beforeEach for all
Tip: To control its execution you can use a flag variable as shown in the code below.
Multiple ways to select elements:
Interacting with the DOM:
element: returns a single element
element.all: returns a collection of elements. Use
last()functions to get a single element out of the collection.
Other awesome functions
filter: Similar to
filtertakes a collection of elements and returns a single element. The only difference is that the element can be selected based on the specified condition. This is useful when there is a dynamic/long list of elements having same selector path and you need to get an element using its text or any unique property.
Let’s take this example of clicking on a date from a calendar.
All the dates elements have the same selector. Therefore, define a filter function as :
Now to click on date 17, simply call the function as :
each: Use it when the same action has to be taken for all elements having common selector. For example : clearing the list of input fields in a Signup form.
map: Mapping a collection of elements in an array without use of protractor
mapfunction involves a lot of code to deal with all the proimises one by one. On the contrary, using map function for the same purpose is a piece of cake. Map function iterates through each element found with the locator and then resolves all the promises to return a promise with an array of values. For example : To get the text of all elements (with ng-repeat = ‘option in Options’) in an array, write the code as :
Tips and tricks
- Manage Browser logs: There will always be certain scenarios which would not be covered in e2e scripts. Therefore, it is a smart move to always check browser console errors for any unexpected issue in the app. The following piece of code allows you to keep a check at browser logs and fails the test cases if there are any errors :
- Combine element statements to move around the dom : Xpath provides an excellent way to move up and down the dom.
Common UseCase: Error messages are often displayed as a sibling to input or submit types. Therefore, instead of using a different selector path for error message, xpath can be used to pick the sibling.
To verify the error message “invalid URL”, simply write the assertion as:
Never use protractor element statements inside loop: The simple reason is that the webdriverJS (protractor) API is asynchronous. Element statements returns a promise and that promise is in unresolved state while the code below the statements continues to execute. This leads to unpredictable results. Hence, it is advisable to use recursive functions instead of loops.
Debug the tests using elementexplorer.js: elementexplorer.js lets you test the page interactively. You will find this JS file in node_modules/protractor/bin directory. Start the selenium server and run command:
Browser will load the URL and you will see > prompt. Use browser, element and protractor variables to interact with page.
Note: Make sure that the developer tools are closed while running commands in elementexplorer.js prompt, otherwise you will face an unexpected error as “TypeError: Cannot read property ‘click’ of null”
Maintaining and reusing test cases
Let’s admit it, e2e test cases are not easy to be maintained and updated. You have to organize the tests in a way that they can be edited easily. Let’s have a glance at Page-Objects, common-files and tests approach that we follow at Wingify, using nodeJS
- page-objects: Page-objects is a commonly used practice across the industry while writing e2e tests. It enables you to write clean tests by listing all the information about the elements in a page-object file. This means that you only need to change the page object file, in case of any change in template of app.
Our Application has more than 50 screens. Therefore we list all the page-objects i.e. dom elements of each screen in a seprate JS file. Take a look at login screen page-object file :
- common-module: The idea is to divide the entire e2e scenario in small reusable functions in a way that these functions can be used in other e2e scenarios as well. These reusable functions can be grouped in different files for maintainblity. The login and logout module is used in many e2e scenarios. So, both can be clubbed in a file as shown below :
- e2e-scripts: Include all the common-module functions to write the complete e2e-script as shown below :
- Take an extra step to write test cases in a way that they can be edited and maintained with ease.
- Create a modular approach keeping scalability in mind.
- Dive deep in the protractor world, use protractor’s awesome functions and have fun!!
Hope this post was a good enough reference to help you write end-to-end tests in a better way. If things might be unclear, or you have any questions, let us know via comments.