This post is not about how to install and use Protractor. I believe setting up Protractor is a lot easy, so heading over to the documentation is an ideal choice to make. For those who have not heard of Protractor yet, it is nothing but an end-to-end test framework for AngularJS applications. However, it works seamlessly for non-angular applications as well, obviously, with a small tweak which is what this post is all about.
In a nutshell, Protractor runs tests against your application running in a real browser, interacting with it as a user would. That means you have to give a set of instructions for each test you write. But before that, let us create a small demo in jQuery (no AngularJS). Below demo is fairly simple but useful to put my point across about robustness of writing tests in Protractor. In this demo, we are having a dummy Google Sign In button loaded via a fake REST call to Google Developers APIs.
<br>
<!DOCTYPE html><br>
<html><br>
<head><br>
<title>Protractor: The Secret Service</title><br>
<script src="http://code.jquery.com/jquery-1.11.3.min.js"></script><br>
<script><br>
$(window).load(function() {<br>
// Simulating a REST call with Google APIs<br>
window.setTimeout(function() {<br>
$('#signin-placeholder').replaceWith(<br>
'<button id="signin">Google Sign In</button>'<br>
);</p>
<p> $('#signin').click(function() {<br>
$(this).text('Sign Out');<br>
});<br>
}, 2000);<br>
});<br>
</script><br>
</head><br>
<body><br>
<div id="signin-placeholder"></div><br>
</body><br>
</html><br>
Sleep
Now that we understood how our application works, it’s time to write E2E tests for it. Following test block might look sound and easy to grasp to you, but there are couple of hidden tricks have been used in order to pass it.
<br>
describe('Non EC Tests', function() {<br>
beforeEach(function() {<br>
browser.ignoreSynchronization = true;<br>
browser.get('demo.html');<br>
});</p>
<p> it('Should', function() {<br>
browser.sleep(2 * 1000);<br>
element(by.id('signin')).click();<br>
expect(element(by.id('signin')).getText()).toBe('Sign Out');<br>
});<br>
});<br>
First line in the beforeEach block i.e. browser.ignoreSynchronization is to tell Protractor that, Hey, this is not an Angular application, so do not wait for Angular to load. Start running tests as soon as the page loads in a browser. This is the one and only trick to consider while using Protractor for non-angular applications which means if in case a webdriver control flow hangs while running tests, that’s the thing to look for in the Spec. Moving on to the it block which is our actual test. In the beginning, we make sure to wait for 2 seconds as per our business logic before we click the login button. Later we confirm the button text is changed to Sign Out.
The important thing to note here is that the browser.sleep method is a last resort most people use to make tests pass to prevent random failures, however, in our case, it is tightly coupled with the business logic. If we increase/decrease the timeout in the fake REST call, we’ll have to adjust the same to fix the broken test. In addition to it, the real REST call may or may not complete within the expected timeout making your test unstable. Let’s fix that…
Wait
Selenium webdriver exports a method called browser.driver.wait that schedules a command to wait for a condition to hold true. This means wait will repeatedly evaluate the condition until it returns a truthy value. You can pass a condition or a custom function that returns a promise to it. So we will simply replace the browser.sleep statement with,
<br>
browser.wait(element(by.id('signin')).isDisplayed, 2 * 1000);<br>
In here browser will wait until isDisplayed method returns a truthy value. If it did not, it will time out after 2 seconds. Note in protractor version 2.0.0, due to changes in WebDriverJS, wait without a timeout will now default to waiting for 0 ms – which off-course forbids our business logic. So we chose to provide ideal explicit timeout. To your surprise the above statement will throw, Failed: No element found using locator: By.id("signin") error because it’s not available in the DOM yet. We could have used browser.waitForAngular method for Angular to render the button if we were using it in the demo. Protractor deals with such scenarios nicely, especially in Angular applications wherein it forces the webdriver to wait until Angular has finished rendering and has no outstanding $http or $timeout calls before continuing.
ExpectedConditions
No worries..! Selenium offers a different mechanism to handle the same for Protractor called as ExpectedConditions a.k.a. EC. It’s similar to protractor isDisplayed API that we saw earlier but especially for non-angular applications. Again the webdriver waits until the expected condition returns a truthy value. Moreover, you can mix it with multiple and, or, and not operators. So to fix the error, we’ll use,
<br>
browser.wait(protractor.ExpectedConditions.visibilityOf(<br>
element(by.id('signin'))<br>
));<br>
This will schedule a command for the webdriver to wait and repeatedly evaluate the condition to check if the element is available/visible in the DOM. There are various functions EC supports that you should take a look at http://www.protractortest.org/#/api?view=ExpectedConditions.
Wrap up
So that’s it. In a real-world project, I happened to encountered similar issues on staging environment where pages load slighly slow than local webserver and some of my tests started failing randomly because browser.sleep hack for HTTP or AJAX calls did not pan out :-). EC statements have helped me a lot while writing robust Protractor tests for non-angular apps and made tests more stable too, mostly, on Firefox and Safari.
Thanks for reading and keep Rocking \m/.
Its always better to hack around than... 