This presentation has been prepared by Oleksii Prohonnyi for internal Angular.js training to improve skills of newbies in JS/Angular. Part 1 (Introduction): http://www.slideshare.net/oprohonnyi/dive-into-angular-part-1-introduction Part 2 (Architecture): http://www.slideshare.net/oprohonnyi/dive-into-angular-part-2-architecture Part 3 (Performance): http://www.slideshare.net/oprohonnyi/dive-into-angular-part-3-performance Part 4 (Angular 2.0): http://www.slideshare.net/oprohonnyi/dive-into-angular-part-4-angular-20

1. DIVE INTO ANGULAR,
PART 5: EXPERIENCE
_by Oleksii Prohonnyi

2. AGENDA
 Unit testing
 E2E testing
 Angular 2 testing
 SEO
 Which version to use
 Performance measurement
 Isolated scopes
 Watchers counter
 References

3. UNIT TESTING

4. UNIT TESTING
 Angular comes with dependency injection built-in, which makes
testing components much easier, because you can pass in a
component's dependencies and stub or mock them as you wish.
 Components that have their dependencies injected allow them to
be easily mocked on a test by test basis, without having to mess
with any global variables that could inadvertently affect another
test.
 See more: docs.angularjs.org

5. UNIT TESTING: Tools
 Karma is a JavaScript command line tool that can be used to
spawn a web server which loads your application's source code
and executes your tests.
 Jasmine is a behavior driven development framework for
JavaScript that has become the most popular choice for testing
Angular applications.

6. UNIT TESTING: Controller

7. UNIT TESTING: Filter

8. UNIT TESTING: Directive

9. angular-mocks
 Angular also provides the ngMock module, which provides
mocking for your tests.
 This is used to inject and mock Angular services within unit tests.
In addition, it is able to extend other modules so they are
synchronous.
 Having tests synchronous keeps them much cleaner and easier
to work with.
 One of the most useful parts of ngMock is $httpBackend,
which lets us mock XHR requests in tests, and return sample
data instead.
 See more: docs.angularjs.org

10. E2E TESTING

11. E2E TESTING
 As applications grow in size and complexity, it becomes
unrealistic to rely on manual testing to verify the correctness of
new features, catch bugs and notice regressions.
 Unit tests are the first line of defense for catching bugs, but
sometimes issues come up with integration between components
which can't be captured in a unit test.
 End-to-end tests are made to find these problems.
 See more: docs.angularjs.org

12. E2E TESTING: Tools
 Protractor is a Node.js program, and runs end-to-end tests that
are also written in JavaScript and run with node. Protractor uses
WebDriver to control browsers and simulate user actions.
 For more information on Protractor, view getting started or the api
docs.
 Protractor uses Jasmine for its test syntax.
 Note: In the past, end-to-end testing could be done with a
deprecated tool called Angular Scenario Runner. That tool is now
in maintenance mode.

13. E2E TESTING: Testing scenario

14. E2E TESTING: Example

15. angular-seed
 This project is an application skeleton for a typical AngularJS
web app. You can use it to quickly bootstrap your angular
webapp projects and dev environment for these projects.
 The seed contains a sample AngularJS application and is
preconfigured to install the Angular framework and a bunch of
development and testing tools for instant web development
gratification.
 See more: docs.angularjs.org

16. ANGULAR 2 TESTING

17. ANGULAR 2 TESTING
 The Angular Testing Platform (ATP)
 The Application Under Test
 First app test
 Test an Asynchronous Service
 The Angular Test Environment
 Test a Component
 Test a Component in the DOM
 Run the tests with karma
 See more: angular.io

18. SEO

19. SEO
 The Basics of JavaScript Framework SEO in AngularJS
 Ajax Crawl Directive
 Prerenderer.io
 Angular 2 optimization:
– Making an App Render Server Side
– Universal Header Template
– Universal Service
– Universal Model
See more: builtvisible.com

20. WHICH VERSION TO USE

21. WHICH VERSION TO USE:
Angular 1.x
 Application should be developed in short terms.
 Team doesn’t know Angular.js at all.
 CRUD application.
 Visualizations and advanced user actions handling.
 Coding guidelines/code review process exists.
 Not Big Data rendering.
 Not low performance devices support.

22. WHICH VERSION TO USE:
Angular 1.5.x
 Application should be developed in short terms.
 Team doesn’t know Angular.js at all.
 CRUD application.
 Visualizations and advanced user actions handling.
 Coding guidelines/code review process exists.
 Not Big Data rendering.
 Angular 2 upgrade will be done.
 Component architecture.
 Distributed team.
 Not Low performance devices support.

23. WHICH VERSION TO USE:
Angular 2
 Application should be developed in long terms.
 Team has experience with TypeScript, ES6.
 Mobile devices advanced support.
 Development investigation effort is presented.
 Experience with React.js

24. PERFORMANCE
MEASUREMENT

25. PERFORMANCE MEASUREMENT:
AUTOMATION
 http://jsperf.com/
 https://code.google.com/archive/p/jslitmus/
 https://duzun.me/playground/js_speed
 Selenium autotests
 https://github.com/pkaminski/digest-hud
 http://github.hubspot.com/BuckyClient/

26. PERFORMANCE MEASUREMENT:
GENERAL
 Who should use the process:
– Developers - during dev. testing process to see performance
measurements changes;
– QA - at the beginning of the project, after performance optimization
features dev. done, at the end of the project.
 What should be measured:
– Scripting, rendering and painting time for scenario.
– $digest/$apply function calls number and execution time.
 What should be fixed during testing:
– Computer system requirements and resources.
– Application configuration, third-party modules configuration.
– Testing scenarios

27. PERFORMANCE MEASUREMENT:
Scripting, rendering and painting time
1. Open dev tools in Chrome
2. Go to Timeline tab
3. Uncheck all the options at the top panel (JS Profile, Memory, Paint,
Screenshots)
4. Click to start recording (or ctrl + E)
5. Click to finish (or ctrl + E)
6. Save timeline data (Open mouse context menu by right mouse button and
select "save timeline data" option)
7. Select all the timeline frame (you can do it with mouse scroll)
8. Chose Summary tab
9. Take a screenshot of Summary diagram
 See more: developer.chrome.com

28. PERFORMANCE MEASUREMENT:
$digest/$apply function calls
1. Open dev tools in Chrome
2. Go to Profiles tab
3. Chose "Collect JavaScript CPU Profile“ in "Select Profiling type" menu
4. Click start to start recording (or ctrl + E)
5. Click stop to stop recording (or ctrl + E)
6. Save Profile data (at the "CPU Profiles" menu click "Save" button near the
snapshot to save it, or use mouse context menu)
7. Sort functions by "Total" time of execution (click on 'Total' tab to sort desc)
8. Set "Heavy (Bottom up)" mode.
9. Take a screenshot of first several functions that includes $.digest and
$.apply (most probably in first 4 functions)
 See more: developer.chrome.com

29. PERFORMANCE MEASUREMENT:
3 snapshots technique
 There should be done at least 3 snapshots of the system load
during the testing to be sure all cases are covered.
 Each of them should be captured on fixed data and configuration
with fixed time limits.
 1st – Idle application state (minimum of user actions).
 2nd – Typical application flow (typical user actions).
 3rd – High-load application state (all the functionality should be
used, untypical user actions performed).

30. PERFORMANCE MEASUREMENT:
Testing plan – 1st snapshot
1. The application is loaded
2. Start capturing
3. No actions required from tester (fixed time)
4. Stop capturing

31. PERFORMANCE MEASUREMENT:
Testing plan – 2nd snapshot
1. The application is loaded
2. Start capturing
3. Buy 3 tickets manually, 3 through buy dialog
4. Open lobby, switch to another stream
5. Switch back
6. Wait for presentation
7. See whole presentation
8. Stop capturing

32. PERFORMANCE MEASUREMENT:
Testing plan – 3rd snapshot
1. The application is loaded
2. Start capturing
3. Buy tickets manually, buy tickets through buy dialog
4. Set autobuy
5. Open lobby, switch stream
6. Play in stream with all possible prizes
7. Switch tickets pages
8. Open minigame
9. Resize client
10. Stop capturing

33. PERFORMANCE MEASUREMENT:
Test report
 At the end of performance testing the test report should be
created to track results of measurements.
 It is propose to use some simple email structure for collecting the
results.
 It should include:
– Full testing scenarios (steps, time, used streams name and
configuration), if they have been changed.
– Results of measurements for each scenario.
– Saved snapshots and timelines for each scenario (as email
attachments). The place to store timeline and performance logs should
be provided separately.

34. ISOLATED SCOPES

35. ISOLATED SCOPES

36. ISOLATED SCOPES

37. WATCHERS COUNTER

38. WATCHERS COUNTER

39. REFERENCES

40. REFERENCES
 http://andyshora.com/unit-testing-best-practices-angularjs.html
 https://www.smashingmagazine.com/2014/10/introduction-to-
unit-testing-in-angularjs/
 http://stackoverflow.com/questions/13499040/how-do-search-
engines-deal-with-angularjs-applications
 http://stackoverflow.com/questions/33225335/angular-js-
beginner-what-version-should-i-use
 http://stackoverflow.com/questions/23066422/how-do-i-measure-
the-performance-of-my-angularjs-apps-digest-cycle
 https://egghead.io/lessons/angularjs-understanding-isolate-scope

42. Oleksii Prohonnyi
facebook.com/oprohonnyi
linkedin.com/in/oprohonnyi