Workshop presented for the Appear.in team

1. End-to-end tests with
Protractor
Walmyr Filho

2. Agenda
● How it works
● Basic configurations
● Creating tests
● The WebDriver control flow
● Style guide
● E2e tests for non-AngularJS apps
● Questions + examples
● References

3. End to end testing framework
for AngularJS applications

4. Test pyramid - Mike Cohn

5. Differently of unit tests,
the main intention of UI
tests (e2e tests) is to save
time when running regression
tests, that are very slow and
boring to execute manually

6. How Protractor works?

10. protractor.conf.js

12. *.spec.js

18. WebDriver Control Flow

19. Promises ...

20. … and the Control Flow

21. So, you can write something like this:

22. Instead of this:

24. Style Guide

25. ● General rules
● Project structure
● Locators strategy
● Page Objects
● Test suites
Style guide

26. ● General rules
● Project structure
● Locators strategy
● Page Objects
● Test suites
Style guide

27. ● Why?
○ Unit tests are much faster and e2e tests
○ Avoiding duplicity
Do not create e2e tests for functionalities already
covered by unit tests

28. ● Why?
○ You may use tools such as grunt or gulp
to override configurations
○ Avoiding configurations duplicity
Use only one configuration file

29. /* Avoid */
protractor.conf.dev.js
protractor.conf.stg.js
protractor.conf.local.js
/* Recommended */
protractor.conf.js -> gulp test-local; gulp
test-dev; ...

30. ● General rules
● Project structure
● Locators strategy
● Page Objects
● Test suites
Style guide

31. ● Why?
○ Easy to locate tests
○ Separate e2e tests from unit tests
○ Cleaner test structure
Group e2e tests in a structure that make sense for the
whole project (ex.: my-project/tests/e2e/)

33. ● General rules
● Project structure
● Locators strategy
● Page Objects
● Test suites
Style guide

34. ● Why?
○ Markup is easily subject to change
○ xpath has performance issues
○ xpath is not easily readable
NEVER use xpath

36. ● Why?
○ Access elements easily
○ The code is harder to change than the
markup
○ More readable locators (e.g.: by.model,
by.binding, by.repeater)
Prefer Protractor specific locators when possible

38. ● Why?
○ Access elements easily
○ This way you use markup that is less
subject to change
○ Readability
Prefer by.id and by.css when there is not Protractor
specific locator available

40. Avoid text locators that change frequently
● Why?
○ Texts of buttons, links and labels tend
to change during the time
○ Tests will break after simple changes in
the texts
○ Localization

41. ● General rules
● Project structure
● Locators strategy
● Page Objects
● Test suites
Style guide

42. ● Why?
○ Encapsulation of elements from the page
under test
○ Code reuse
○ Decoupling test logic from
implementation details
Use Page Objects to interact with the page under test

44. ● Why?
○ Maintain the code clean and ease finding
what you are looking for
Declare one Page Object per file

46. Use just one module.exports at the end of the Page
Object
● Why?
○ One PageObject per file means that there
is only one class to export

48. Require and instantiate all node modules in the top of
● Why?
○ The dependencies and node modules must be
clear and easy to find
○ Separations of dependencies and test code
○ Dependencies are then available for all the
test suite

50. ● Why?
○ The user of the Page Object must have
quick access the the elements available
in the page
Declare all elements from the constructor as public

52. Declare functions for operations that require more than
one step
● Why?
○ Clean code / Readability
○ Code reuse
○ Maintainability

54. ● Why?
○ Tests are responsible for the assertions
○ People that will read the tests must be able
to understand the application expected
behaviour by just reading the tests
Don't do assertions in the Page Objects

55. ● Why?
○ You may reuse them in many tests
○ Avoid code duplicity
○ When a directive change, you just the to
change the wrapper, and only once
Add wrappers for directives, dialogs and common
elements

57. ● General rules
● Project structure
● Locators strategy
● Page Objects
● Test suites
Style guide

58. ● Why?
○ E2e tests exist to simulate real users
using the application with all its
integrations
○ Using the real application with its own
dependencies provides high confidence
Do not use mock unless this is totally necessary

59. ● Why?
○ It is well documented
○ It is also supported by the Protractor team
○ beforeAll e afterAll
Use Jasmine2

61. ● Why?
○ Run tests in parallel with sharding
○ The execution order is not guaranteed
○ You can run a test suite isolated
Make tests independent at least at the file level

63. ● Why?
○ You may execute test cases isolated
○ Easy to debug (e.g.: fit, xit)
Make tests totally independent of each other

64. Except when the operations to start the test are
too much expensive
● Why?
○ The tests would be running for ever
Make tests totally independent of each other

65. ● Why?
○ Ensure that the main application parts
are well connected to each other
○ Real users don't navigate by URLs
Have a test suite to navigate through the main
application routes

66. ● Why?
○ Ensure that the tests is in a clean state
○ Avoid code duplicity
Navigate till the page under test before each test

69. Testing non-AngularJS apps

71. Questions?
+
Examples (if you want to see some)

72. http://www.protractortest.org/#/infrastructure
http://www.protractortest.org/#/
https://spin.atomicobject.com/2014/12/17/asynchronous-testing-protractor-angular/
http://insights.tothenew.com/testing-automation-whitepaper-protractor-angularjs-apps
http://www.protractortest.org/#/style-guide
http://github.com/wlsf82/faker-experiments
https://github.com/wlsf82/primeiros-passos-com-protractor-guts-sc
http://leanpub.com/end-to-end-testing-with-protractor

73. Takk!
Walmyr Filho