Frontend automation and stability

1,395 views
1,226 views

Published on

https://speakerdeck.com/matenadasdi/frontend-automation-and-stability

We all know that after a certain amount of code complexity it’s impossible to maintain everything with simple manual processes. Frontend development is in a new era and we all have to focus on stability and scalability in our huge JavaScript architecture. I will present you our plans at Ustream to keep up with continuous feature development, our testing layers and solutions for workflow automation.

Published in: Technology
0 Comments
8 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,395
On SlideShare
0
From Embeds
0
Number of Embeds
70
Actions
Shares
0
Downloads
14
Comments
0
Likes
8
Embeds 0
No embeds

No notes for slide

Frontend automation and stability

  1. 1. Frontend automation and stability @matenadasdi Ustream, Inc
  2. 2. Common sentences from the past Writing tests is a huge overhead Browsers are unpredictable and we are not able to test real behaviour Let’s write this frontend task in PHP, Ruby, Python, Bash … Selenium is unstable and complicated “
  3. 3. It’s a new ERA Let’s ride it!
  4. 4. Testing
  5. 5. ! Trendy question: TDD is dead? </flame>
  6. 6. TDD/BDD/HDD/DVD… It doesn’t matter, Testing is a must in large scale!
  7. 7. Good news! We have everything what we need Hundreds of tools and frameworks - Mocha, Jasmine, Jest, Karma, QUnit Headless browsers - PhantomJS, SlimerJS, TrifleJS Headless navigation scripting libs - CasperJS, DalekJS
  8. 8. Our setup at
  9. 9. 1. Unit testing
  10. 10. Criterions for efficient unit testing Separated layers with different responsibilities for easier mocking Business Logic and the representation have to be separated Dependency Injection
  11. 11. Mocha + Chai framework: Node and Browser support Separate assert libraries Tons of reporters mocking: SinonJS Spies, Stubs, Mocks Assertions for invocations Faking AJAX, server Works with lot of frameworks module dependency mocking: SquireJS Dependency injector for RequireJS mock / store
  12. 12. It’s not an overhead, easy to run and write!
  13. 13. Coverage? function coverage function epam (speaker, onStage) { var talking = false; ! if (speaker && onStage){ talking = true; } ! return talking; } if epam called once, its covered statement coverage function epam (speaker, onStage) { var talking = false; ! if (speaker && onStage){ talking = true; } ! return talking; } with testing epam(true, true), all statement will be executed, so its covered branch coverage function epam (speaker, onStage) { var talking = false; ! if (speaker && onStage){ talking = true; } ! return talking; } with testing epam(true, true), and epam (true, false) all execution paths will be covered
  14. 14. Ok it’s nice, but is it possible in JS? ;)
  15. 15. Istanbul https://github.com/gotwarlost/istanbul Esprima based statement, branch, function coverage multiple reporters command line support Karma test runner http://karma-runner.github.io/0.12/index.html + WebStorm integration Istanbul code coverage support Mocha, Jasmine, QUnit support Jenkins, Travis support
  16. 16. Unit tests cannot cover everything! Browser / DOM / Interaction specific behaviour should be tested in a different way
  17. 17. 2. UI testing The genie is out of the bottle
  18. 18. Navigation scripting in Node
  19. 19. We use CasperJS Node.js based navigation scripting PhantomJS & SlimerJS support screenshot capture not necessary to use its testing framework Pro: phantomjs based browsers only Cons:
  20. 20. This is Node, you can do everything! Create your own modules you can call global casper from everywhere
  21. 21. DalekJS is coming up! Real browser support Chrome, FF, IE, Mobile Safari It can run in headless browsers too Pro: strict testing framework interface small documentation and not enough methods still developer preview (0.0.8) Cons:
  22. 22. 3. Test automation team selenium, real browsers, complex features, mobile devices
  23. 23. 4. Manual QA team Smoke tests, regression tests, screenshot comparison tool, internal debug tools
  24. 24. Automation
  25. 25. We picked Grunt
  26. 26. NPM for dependency management we could port every frontend related task to Node we use 12 grunt plugins (2800+ available globally) be careful, lot of tasks can lead to a huge/complex grunt file we have an own structure for task configurations Thanks to Grunt...
  27. 27. Why not Gulp? a bad question
  28. 28. Node streams are awesome, but it can be hard for non-js devs Code over configuration 713 plugins and coming up really fast Try both, and maybe use both! Gulp is good tool too!
  29. 29. Standards & Rules !
  30. 30. Our previous setup was too simple JSLint manually (!) YuiCompressor after commits in Jenkins
  31. 31. Rules are not rules if you break them!
  32. 32. Everyone writes different code and it’s normal
  33. 33. Code style! Be aggressive! a smarter JSLint separated configuration file everyone can run the same config most IDEs can read it globally
  34. 34. Esprima!!!!!!!!!!!!!!!!!!!!!!!!!!44 https://github.com/ariya/esprima more possibilities with
  35. 35. { "type": "Program", "body": [{ "type": "IfStatement", "test": { "type": "Identifier", "name": "epam" }, “consequent": { "type": "BlockStatement", "body": [{ "type": "ExpressionStatement", "expression": { "type": "AssignmentExpression", "operator": "=", "left": { "type": "Identifier", "name": "conf" }, "right": { "type": "Literal", "value": "SEC", "raw": "'SEC'" } } }] }, "alternate": null }] var epam = true; ! if (epam) { conf = 'SEC'; }
  36. 36. Semantics & your own rules Esprima based pluginable thanks to the AST it can examine semantics
  37. 37. Esprima based rule definitions
  38. 38. Complexity report Does it matter?
  39. 39. Who wouldn’t wanna track these? http://jscomplexity.org/complexity Lines of code (LOC) Halstead complexity measures Maintainability index Cyclomatic complexity
  40. 40. Cyclomatic complexity = E - N + 2P linearly independent paths in the method E = number of edges in the flow graph N = number of nodes in the flow graph P = number of nodes that have exit points 6 -6 + 2 = 2
  41. 41. JSComplexity & Plato We run complexity report in Jenkins nightly build for our whole JS codebase https://www.npmjs.org/package/complexity-report Plato is a great tool for manual examinations https://github.com/es-analysis/plato
  42. 42. CI Integration CI can run your tools automatically and periodically It can catch accidental commits Nearly every grunt plugin supports .xml reporters
  43. 43. this 3 simple things can lead to a more stable and scalable JS codebase Testing Automation Standards & rules !
  44. 44. Thank you! Questions? ! ! @matenadasdi

×