End-to-end tests with Protractor

Walmyr Filho

Agenda

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

End to end testing framework for AngularJS applications

Test pyramid - Mike Cohn

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

How Protractor works?

protractor.conf.js

*.spec.js

WebDriver Control Flow

Promises ...

… and the Control Flow

So, you can write something like this:

Instead of this:

Style Guide

● General rules

● Project structure

● Locators strategy

● Page Objects

● Test suites

Style guide

● General rules

● Project structure

● Locators strategy

● Page Objects

● Test suites

Style guide

● Why?

○ Unit tests are much faster and e2e tests

○ Avoiding duplicity

Do not create e2e tests for functionalities already covered by unit tests

● Why?

○ You may use tools such as grunt or gulp

to override configurations

○ Avoiding configurations duplicity

Use only one configuration file

/* Avoid */

protractor.conf.dev.js

protractor.conf.stg.js

protractor.conf.local.js

/* Recommended */

protractor.conf.js -> gulp test-local; gulp test-dev; ...

● General rules

● Project structure

● Locators strategy

● Page Objects

● Test suites

Style guide

● 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/)

● General rules

● Project structure

● Locators strategy

● Page Objects

● Test suites

Style guide

● Why?

○ Markup is easily subject to change

○ xpath has performance issues

○ xpath is not easily readable

NEVER use xpath

● 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

● 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

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

● General rules

● Project structure

● Locators strategy

● Page Objects

● Test suites

Style guide

● 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

● Why?

○ Maintain the code clean and ease finding

what you are looking for

Declare one Page Object per file

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

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

● 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

Declare functions for operations that require more than one step● Why?

○ Clean code / Readability

○ Code reuse

○ Maintainability

● 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

● 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

● General rules

● Project structure

● Locators strategy

● Page Objects

● Test suites

Style guide

● 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

● Why?

○ It is well documented

○ It is also supported by the Protractor team

○ beforeAll e afterAll

Use Jasmine2

● 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

● Why?

○ You may execute test cases isolated

○ Easy to debug (e.g.: fit, xit)

Make tests totally independent of each other

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

● 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

● Why?

○ Ensure that the tests is in a clean state

○ Avoid code duplicity

Navigate till the page under test before each test

Testing non-AngularJS apps

Questions?+

Examples (if you want to see some)

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

Takk!

Walmyr Filho