In this talk, I would like to speak about best practices for writing e2e tests with Protractor. The styleguide that I will introduce, is a joint initiative of mine and @andresdom from Google. Some of the subjects that will be covered include why e2e testing is important, what e2e tests should cover, naming conventions, selector strategies, page objects, helper objects and performance considerations. That and lots of smileys obviously, because we wanted to smiley all the things ...right? ¯\_(ツ)_/¯

1. E2E Testing & Best Practices
with Protractor
@CarmenPopoviciu

3. Agenda
● E2E Testing
● Protractor
● Best Practices

4. E2E Testing

5. WHAT?
E2E testing is a means of verifying that all units of
an application interact as expected with each other
and that the system as a whole works as intended

6. What?
● Testing from the user perspective

7. What?
● Testing from the user perspective
● Main user interaction flows

8. What?
● Testing from the user perspective
● Main user interaction flows
● Major subpages or routes in the site

9. What?
● Testing from the user perspective
● Main user interaction flows
● Major subpages or routes in the site
● Essential elements on a page

10. WHY?
E2E testing will give you the confidence that
everything works OK

11. Why?
● Prevents production incidents

12. Why?
● Prevents production incidents
● Manual testing takes too much time

13. Why?
● Prevents production incidents
● Manual testing takes too much time
● E2E tests are documentation

14. Why?
● Prevents production incidents
● Manual testing takes too much time
● E2E tests are documentation
● Makes us better devs

15. Protractor

16. Protractor is an end-to-end testing
framework for AngularJS applications

17. Protractor
● Wrapper around WebdriverJS
● Adds Angular-specific locator strategies
● Runs tests against real browsers
● node.js program

18. Everything clear?

19. Let’s dive in a little deeper

20. Selenium
WebDriver
¯_(ツ)_/¯

21. Test Browser
Selenium
WebDriver
¯_(ツ)_/¯

22. Test Browser
WebDriver
Client
Libraries

23. Test Browser
WebDriver
Client
Libraries
language specific bindings
for Selenium WebDriver API

24. Test Browser
language specific bindings
for Selenium WebDriver API
JAVA
Ruby
Python
JS

25. Test Browser
JAVA
Ruby
Python
JS
WebDriver
Browser
Drivers

26. Test Browser
WebDriver implementations
specific to various browsers
JAVA
Ruby
Python
JS
WebDriver
Browser
Drivers

27. Test Browser
Chrome
Driver
Firefox
Driver
IE
Driver
JAVA
Ruby
Python
JS
WebDriver implementations
specific to various browsers

28. Test Browser
Chrome
Driver
Firefox
Driver
IE
Driver
JAVA
Ruby
Python
JS

29. Test Browser
Chrome
Driver
Firefox
Driver
IE
Driver
JAVA
Ruby
Python
JS
Real browsers that can
connect to anything internet
can connect to, including the
application under test

30. Test Browser
Chrome
Driver
Firefox
Driver
IE
DriverJS
Python
Ruby
JAVA
Angular apps are written in
JS, so we’ll use the
JavaScript bindings for the
Selenium WebDriver API

31. Test Browser
Chrome
Driver
Firefox
Driver
IE
Driver
WebdriverJS
JavaScript bindings for
WebDriver

32. Test Browser
Chrome
Driver
Firefox
Driver
IE
Driver
WebdriverJS
- findElement()
- getText()
- click()
...
JavaScript bindings for
WebDriver

33. Test Browser
Chrome
Driver
Firefox
Driver
IE
Driver
driver.get(url);
var el = driver.findElement(
webdriver.By.name('greet')
);
el.sendKeys('Hi!');
el.click();
Test Code
WebdriverJS
- findElement()
- getText()
- click()
...

34. Test Browser
Chrome
Driver
Firefox
Driver
IE
Driver
Test Code
WebdriverJS
- findElement()
- getText()
- click()
...
Webdriver Wire Protocol
/session/:sessionId/element/:id/text
/session/:sessionId/element/:
id/click/session/:sessionId/keys
….

35. Test Browser
Chrome
Driver
Firefox
Driver
IE
Driver
Test Code
WebdriverJS
- findElement()
- getText()
- click()
...
Selenium Server

36. Test Browser
Chrome
Driver
Firefox
Driver
IE
Driver
Test Code
WebdriverJS
- findElement()
- getText()
- click()
...
Selenium Server
Protractor

37. Test Browser
Chrome
Driver
Firefox
Driver
IE
Driver
Test Code
WebdriverJS
- findElement()
- getText()
- click()
...
Selenium Server
Protractor
NodeJS

38. Still confused?

39. That’s OK. It will take another few
attempts to get it right

40. (flashy green) Demo!

41. Control Flow

42. Control Flow
● Non blocking API

43. Control Flow
● Non blocking API
● WebdriverJS/Protractor APIs are purely
asynchronous

44. Control Flow
● Non blocking API
● WebdriverJS/Protractor APIs are purely
asynchronous
● Every function returns a promise

45. Control Flow
it('should greet’, function() {
browser.get('#/hello-world’);
var name = element(by.model(‘name’));
var greetBtn = element(by.tagName(‘button’));
var greeting = element(by.binding(‘greeting’));
name.sendKeys('DevfestRo');
greetBtn.click();
expect(greeting.getText()).toEqual('Hi DevfestRo!');
// ¯_(ツ)_/¯
});

46. Control Flow
● WebDriverJS maintains a queue of scheduled tasks
(pending promises), called the control flow

47. Control Flow
● WebDriverJS maintains a queue of scheduled tasks
(pending promises), called the control flow
● Each task is executed once the one before it in the
queue is finished

48. Control Flow
● WebDriverJS maintains a queue of scheduled tasks
(pending promises), called the control flow
● Each task is executed once the one before it in the
queue is finished
● Protractor adapts Jasmine so that each spec
automatically waits until the control flow is empty
before exiting

49. That was a LOT of
text for one slide

50. Ready for another quick dive?

51. ControlFlow
Class
Instance
webdriver.promise.controlFlow()
Task1
Task4
Task3
Task2
Queue
Task4
Task3
Task2
Task1
.execute(..)

52. Control Flow
flow.execute(function() {
console.log('a');
});
flow.execute(function() {
console.log('b');
});
flow.execute(function() {
console.log('c');
});
// a
// b
// c

53. Control Flow
flow.execute(function() {
console.log('a');
}).then(function() {
flow.execute(function() {
console.log('c');
});
});
flow.execute(function() {
console.log('b');
});
// a
// c
// b

54. (two seemingly random) Demos!

55. Best Practices

56. Use Page Objects to interact with the page under test
WHY?
Encapsulate information about the elements on the page under test
They can be reused across multiple tests
Decouple the test logic from implementation details

57. // avoid
/* question.spec.js */
describe('Question page', function() {
it('should answer any question', function() {
var question = element(by.model('question.text'));
var answer = element(by.binding('answer'));
var button = element(by.css('.question-button'));
question.sendKeys('What is the purpose of life?');
button.click();
expect(answer.getText()).toEqual("Chocolate!");
});
});

58. // recommended
/* question.spec.js */
var QuestionPage = require('./question.page');
describe('Question page', function() {
var question = new QuestionPage();
it('should ask any question', function() {
question.ask('What is the purpose of meaning?');
expect(question.answer.getText()).toEqual('Chocolate');
});
});

59. // recommended
/* question.page.js */
var QuestionPage = function() {
this.question = element(by.model('question.text'));
this.answer = element(by.binding('answer'));
this.button = element(by.className('question-button'));
this.ask = function(question) {
this.question.sendKeys(question);
this.button.click();
};
};
module.exports = QuestionPage;

60. Declare functions for operations that require more than
one step
WHY?
Most elements are exposed by the Page Object and can be used directly in the test
Doing otherwise adds unnecessary complexity

61. Don't make any assertions in your Page Objects
WHY?
It is the responsibility of the test to do all the assertions
Reader of the test should be able to understand the behavior of the application by
looking at the test only

62. Prefer protractor locators when possible
WHY?
Access elements easier
Code is less likely to change than markup
More readable locators

63. <ul class="red">
<li>{{color.name}}</li>
<li>{{color.shade}}</li>
<li>{{color.code}}</li>
</ul>
/* avoid */
var nameElem = element.all(by.css('.red li')).get(0);
/* recommended */
var nameElem = element(by.binding('color.name'));

64. Prefer by.id and by.css when no protractor locators are
available
WHY?
Access elements easier
Select markup that is less likely to change
More readable locators

65. NEVER use xpath
WHY?
Markup is very easily subject to change
xpath has performance issues
Unreadable locator

66. more at
https://github.com/CarmenPopoviciu/protractor-styleguide
https://goo.gl/1SmXer

67. THANK YOU!
https://goo.gl/1SmXer