Frontend automation and stability

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.

https://www.slideshare.net/matenadasdi1/frontend-automation-and-stability

7695c800a46abf4a8ad2e975379d6cba?s=128

Mate Nadasdi

May 31, 2014
Tweet

Transcript

  1. 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 “
  2. 4.
  3. 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
  4. 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
  5. 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
  6. 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
  7. 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
  8. 16.

    Unit tests cannot cover everything! Browser / DOM / Interaction

    specific behaviour should be tested in a different way
  9. 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:
  10. 20.

    This is Node, you can do everything! Create your own

    modules you can call global casper from everywhere
  11. 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:
  12. 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...
  13. 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!
  14. 33.

    Code style! Be aggressive! a smarter JSLint separated configuration file

    everyone can run the same config most IDEs can read it globally
  15. 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'; }
  16. 39.

    Who wouldn’t wanna track these? http://jscomplexity.org/complexity Lines of code (LOC)

    Halstead complexity measures Maintainability index Cyclomatic complexity
  17. 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
  18. 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
  19. 42.
  20. 43.

    CI Integration CI can run your tools automatically and periodically

    It can catch accidental commits Nearly every grunt plugin supports .xml reporters
  21. 44.

    this 3 simple things can lead to a more stable

    and scalable JS codebase Testing Automation Standards & rules !