Your SlideShare is downloading. ×
Frontend automation and stability
Upcoming SlideShare
Loading in...5

Thanks for flagging this SlideShare!

Oops! An error has occurred.

Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Frontend automation and stability


Published on …

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
  • Be the first to comment

No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

No notes for slide


  • 1. Frontend automation and stability @matenadasdi Ustream, Inc
  • 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. It’s a new ERA Let’s ride it!
  • 4. Testing
  • 5. ! Trendy question: TDD is dead? </flame>
  • 6. TDD/BDD/HDD/DVD… It doesn’t matter, Testing is a must in large scale!
  • 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. Our setup at
  • 9. 1. Unit testing
  • 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. 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. It’s not an overhead, easy to run and write!
  • 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. Ok it’s nice, but is it possible in JS? ;)
  • 15. Istanbul Esprima based statement, branch, function coverage multiple reporters command line support Karma test runner + WebStorm integration Istanbul code coverage support Mocha, Jasmine, QUnit support Jenkins, Travis support
  • 16. Unit tests cannot cover everything! Browser / DOM / Interaction specific behaviour should be tested in a different way
  • 17. 2. UI testing The genie is out of the bottle
  • 18. Navigation scripting in Node
  • 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. This is Node, you can do everything! Create your own modules you can call global casper from everywhere
  • 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. 3. Test automation team selenium, real browsers, complex features, mobile devices
  • 23. 4. Manual QA team Smoke tests, regression tests, screenshot comparison tool, internal debug tools
  • 24. Automation
  • 25. We picked Grunt
  • 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. Why not Gulp? a bad question
  • 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. Standards & Rules !
  • 30. Our previous setup was too simple JSLint manually (!) YuiCompressor after commits in Jenkins
  • 31. Rules are not rules if you break them!
  • 32. Everyone writes different code and it’s normal
  • 33. Code style! Be aggressive! a smarter JSLint separated configuration file everyone can run the same config most IDEs can read it globally
  • 34. Esprima!!!!!!!!!!!!!!!!!!!!!!!!!!44 more possibilities with
  • 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. Semantics & your own rules Esprima based pluginable thanks to the AST it can examine semantics
  • 37. Esprima based rule definitions
  • 38. Complexity report Does it matter?
  • 39. Who wouldn’t wanna track these? Lines of code (LOC) Halstead complexity measures Maintainability index Cyclomatic complexity
  • 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. JSComplexity & Plato We run complexity report in Jenkins nightly build for our whole JS codebase Plato is a great tool for manual examinations
  • 42. CI Integration CI can run your tools automatically and periodically It can catch accidental commits Nearly every grunt plugin supports .xml reporters
  • 43. this 3 simple things can lead to a more stable and scalable JS codebase Testing Automation Standards & rules !
  • 44. Thank you! Questions? ! ! @matenadasdi