End-to-end tests with Protractor Walmyr Filho
Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
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
Related Documents
