Frontend automation and stability
@matenadasdi
Ustream, Inc
Common sentences from the past
Writing tests is a huge overhead
Browsers are unpredictable and we are not able to test rea...
It’s a new ERA
Let’s ride it!
Testing
!
Trendy question:
TDD is dead?
</flame>
TDD/BDD/HDD/DVD…
It doesn’t matter,
Testing is a must in large scale!
Good news! We have everything what we need
Hundreds of tools and frameworks - Mocha, Jasmine, Jest, Karma, QUnit
Headless ...
Our setup at
1. Unit testing
Criterions for efficient unit testing
Separated layers with different responsibilities for easier mocking
Business Logic an...
Mocha + Chai
framework:
Node and Browser support
Separate assert libraries
Tons of reporters
mocking:
SinonJS
Spies, Stubs...
It’s not an overhead, easy to run and write!
Coverage?
function coverage
function epam (speaker, onStage)
{
var talking = false;
!
if (speaker && onStage){
talking = t...
Ok it’s nice, but is it possible in JS?
;)
Istanbul
https://github.com/gotwarlost/istanbul
Esprima based
statement, branch, function coverage
multiple reporters
comm...
Unit tests cannot cover everything!
Browser / DOM / Interaction specific behaviour
should be tested in a different way
2. UI testing
The genie is out of the bottle
Navigation scripting in Node
We use CasperJS
Node.js based navigation scripting
PhantomJS & SlimerJS support
screenshot capture
not necessary to use it...
This is Node, you can do everything!
Create your own modules
you can call global casper from everywhere
DalekJS is coming up!
Real browser support
Chrome, FF, IE, Mobile Safari
It can run in headless browsers too
Pro:
strict t...
3. Test automation team
selenium, real browsers, complex features, mobile devices
4. Manual QA team
Smoke tests, regression tests, screenshot comparison tool, internal debug tools
Automation
We picked Grunt
NPM for dependency management
we could port every frontend related task to Node
we use 12 grunt plugins (2800+ available g...
Why not Gulp?
a bad question
Node streams are awesome, but it can be hard for non-js devs
Code over configuration
713 plugins and coming up really fast
...
Standards & Rules
!
Our previous setup was too simple
JSLint manually (!)
YuiCompressor after commits in Jenkins
Rules are not rules if you break them!
Everyone writes different code
and it’s normal
Code style! Be aggressive!
a smarter JSLint
separated configuration file
everyone can run the same config
most IDEs can read ...
Esprima!!!!!!!!!!!!!!!!!!!!!!!!!!44
https://github.com/ariya/esprima
more possibilities with
{
"type": "Program",
"body": [{
"type": "IfStatement",
"test": {
"type": "Identifier",
"name": "epam"
},
“consequent": {
"...
Semantics & your own rules
Esprima based
pluginable
thanks to the AST it can examine semantics
Esprima based rule definitions
Complexity report
Does it matter?
Who wouldn’t wanna track these?
http://jscomplexity.org/complexity
Lines of code (LOC)
Halstead complexity measures
Mainta...
Cyclomatic complexity = E - N + 2P
linearly independent paths in the method
E = number of edges in the flow graph
N = numbe...
JSComplexity & Plato
We run complexity report in Jenkins nightly build for our whole JS codebase
https://www.npmjs.org/pac...
CI Integration
CI can run your tools automatically and periodically
It can catch accidental commits
Nearly every grunt plu...
this 3 simple things
can lead to a more stable and scalable JS codebase
Testing Automation Standards & rules
!
Thank you!
Questions?
!
!
@matenadasdi
Frontend automation and stability
Upcoming SlideShare
Loading in...5
×

Frontend automation and stability

977

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

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
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×