Starting WebApp Testing in Protractor Framework with Ease

So now that we have our system set up for Web App testing, we can now start with writing our first test using Protractor and AngularJS.

For a Protractor test to run, we need two files written in AngularJS.

First is the configuration file, which describes what the configuration of the environment will be, in which the test(s) will be run. It has the description of the URL of the web app under test, the environment variables that are shared by all the tests and test suites, the description of the test suites that are to be run, how to link to the Selenium server and the Specification file, which is the second file required, that has the source code definition of the tests.

The specification file has the definition of all the source code that is the automated test to be run on the web app. The specification has tests written in ‘it’ blocks, which constitute a test case of the test suite. One specification file represents a single test suite.

We first start by writing down the configuration. The selenium server, when up, is accessible at http://localhost:4444/wd/hub and the specification file will be addressed relative to the current directory in which the configuration file itself is. So this is how the configuration file, myconfig.js, should look like:

The specification file, mytests.js, has tests that you would run in your test suite:

This test attempts to navigate to the AngularJS homepage and uses its first example code enters my name in the text field and then verifies that the effect of it is successfully reflected in the message field below it.

The describe() method assigns a descriptor to the test suite, here it is ‘My First Test‘. The it() block here describes a single test case, and there can be many more in a suite. Every it() block has its own descriptor too. These descriptors help in preparing more readable reports.

We use the browser object’s get() method to open the URL in the browser configured in the configuration file. Since we didn’t configure any, the default browser’s, Google Chrome’s, instance is opened. The element object is used to identify and locate Angular specific elements of the web page. We use the ng-model attribute of the desired element using by.model() location strategy and type in the text value, using the sendKeys() method.

Similarly, we locate another element of the page, where the message is to be displayed, using the ng-binding Angular attribute, through the by.binding() strategy.

The expect() method is used to create assertions, necessary conditions to be checked, in Protractor based tests. We compare the message retrieved from the message field with the expected message using the toEqual() assertion method.

Now, to run this test, we first need to start up the selenium server. Open a terminal window and type

webdriver-manager start

---

If the webdriver reports any missing jars, it is because of the frequent updates to protractor, just type 

webdriver-manager --standalone update

and wait for the webdriver wrapper to update.

---

The active Selenium Server instances can be viewed by following the URL http://localhost:4444/wd/hub/static/resource/hub.html on any of the browsers.

Open another terminal window and navigate to the directory that has the configuration file(myconfig.js). Then type

protractor myconfig.js

This would fire up the tests in the specification file. A report would be verbosely printed to the same terminal window.  At the end of the execution of the tests, the status of the test is displayed.

We can also see the details of the session on the Webdriver hub page.

Though, in the above case, you’d have to be very fast as the test is really trivial and gets executed very quickly.

In case the test fails, the assertions that failed are also reported. But if the test fails somewhere else, it becomes a nightmare to actually trace to failure, scrolling through the ever-winding stack-trace printed.

In our next post, we would learn how to integrate the Jasmine report generation with our tests, which would allow us to produce better and more presentable reports of our test runs.

Till then, adios!