Frontend automation and stability
8 likes2,334 views
This document discusses frontend automation and stability. It recommends: 1. Writing unit tests using Mocha and Chai for efficient testing of separated layers and dependencies. 2. Performing UI testing using CasperJS for browser/DOM interaction or DalekJS for real browser support. 3. Integrating testing, code quality tools, and standards into a continuous integration system to catch errors and ensure code quality across contributors.
![{
"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';
}](https://image.slidesharecdn.com/frontendautomationandstability-140531092515-phpapp02/85/Frontend-automation-and-stability-35-320.jpg)
Frontend automation and stability
- 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
- 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 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. 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!
- 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
- 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? http://jscomplexity.org/complexity 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 https://www.npmjs.org/package/complexity-report Plato is a great tool for manual examinations https://github.com/es-analysis/plato
- 43. CI Integration CI can run your tools automatically and periodically It can catch accidental commits Nearly every grunt plugin supports .xml reporters
- 44. this 3 simple things can lead to a more stable and scalable JS codebase Testing Automation Standards & rules !