Download as PDF, PPTX
Uploaded byWalmyr Lima e Silva Filho
Workshop - E2e tests with protractor
The document discusses end-to-end testing of AngularJS applications using Protractor. It provides an overview of how Protractor works, basic configurations, creating tests, the WebDriver control flow, and a style guide for writing Protractor tests. Some best practices covered include using Page Objects to encapsulate page elements, making tests independent, and navigating to pages before each test. The presentation also addresses testing non-AngularJS apps and takes questions.
More Related Content
![[Webinar] Continuous Testing Done Right: Test Automation at the World's Leadi...](https://cdn.slidesharecdn.com/ss_thumbnails/brianjordanapplitoolswebinar-160421122323-thumbnail.jpg?width=640&height=640&fit=bounds)
Similar to Workshop - E2e tests with protractor
Workshop - E2e tests with protractor
- 1.
- 2. Agenda ● How itworks ● Basic configurations ● Creating tests ● The WebDriver control flow ● Style guide ● E2e tests for non-AngularJS apps ● Questions + examples ● References
- 3. End to endtesting framework for AngularJS applications
- 4. Test pyramid -Mike Cohn
- 5. Differently of unittests, 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.
- 10.
- 12.
- 18.
- 19.
- 20. … and theControl Flow
- 21. So, you canwrite something like this:
- 22.
- 24.
- 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? ○ Unittests are much faster and e2e tests ○ Avoiding duplicity Do not create e2e tests for functionalities already covered by unit tests
- 28. ● Why? ○ Youmay 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? ○ Easyto 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? ○ Markupis easily subject to change ○ xpath has performance issues ○ xpath is not easily readable NEVER use xpath
- 36. ● Why? ○ Accesselements 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? ○ Accesselements 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 locatorsthat 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? ○ Encapsulationof 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? ○ Maintainthe code clean and ease finding what you are looking for Declare one Page Object per file
- 46. Use just onemodule.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 instantiateall 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? ○ Theuser 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 foroperations that require more than one step ● Why? ○ Clean code / Readability ○ Code reuse ○ Maintainability
- 54. ● Why? ○ Testsare 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? ○ Youmay 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? ○ E2etests 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? ○ Itis well documented ○ It is also supported by the Protractor team ○ beforeAll e afterAll Use Jasmine2
- 61. ● Why? ○ Runtests 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? ○ Youmay execute test cases isolated ○ Easy to debug (e.g.: fit, xit) Make tests totally independent of each other
- 64. Except when theoperations 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? ○ Ensurethat 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? ○ Ensurethat the tests is in a clean state ○ Avoid code duplicity Navigate till the page under test before each test
- 69.
- 71. Questions? + Examples (if youwant to see some)
- 72.
- 73.