NW.js testing

by Nadav Sinai, 

nadav@misterbit.com

github.com/nadavsinai

March 2015

 

nadav@misterbit.com

github.com/nadavsinai

Nadav Sinai

  • Fullstack JS developer
  • PHP Background
  • Angular.js since 2013
  • done some big projects
  • A lot of testing...

Testing

  • The difference between "it should work" and "It works for sure!"
  • Safety from 3rd party-changes
  • Allows to maintain a project over time
  • Allows for big projects where nobody knows the internals of the whole system
  • Provides a good focused problem solving orientated method of developing - eg TDD

Unit vs. E2E

Unit tests

  • Check your own code in ISOLATION, use mocks for dependencies.
  • Check modules as black boxes (API - not implementation)
  • The basis of stable code base - makes location regression bugs easy.

 End-to-end (E2E,Integration) 

  • checks the whole system in runtime - with all parts wired up - both internal and 3rd party based
  • can be used to check different environments (eg browsers etc)

Testing jargon

Suite,Spec,Test,

Capacity,Runner,Framework

  • Different environments have different names for the same things!
  • Can be easily simplified

NW.JS testing

Pros:

Cons:

  •  community is not very testing  orientated

NW.JS  Unit tests

  • Keep tests in REAL environment - nw.js
  • Use Karma runner for easiest integration
  • Can use any framework - jasmine,mocha+chai etc.
  • Load tests only - use nw.js require() to get inspected target.
  • Works well in node context when writing modular code
  • Probelmatic approach when testing code in webkit-context & nw.gui based helpers such as menu, tray etc.

 

Demo using NodeWebkit-testing

Simple Karma Setup

  • add Karma, karma-jasmine
  • add 
    iamdenny/karma-nodewebkit-launcher
  • karma init config

  • files - tests only (require from tests what you need)

 browsers: ['NodeWebkitWithCustomPath'],
      customLaunchers: {
          'NodeWebkitWithCustomPath': {
              base: 'NodeWebkit',
              // Remember to include 'node_modules' if you have some modules there
              paths: ['js', 'node_modules']
          }
      },

Complex Karma Setup

  • Use of preprocessors in karma eg. browserify,webpack
  • load the whole application - caveat of angular 
  • probably needs  some automation eg gulp,grunt
  • when asserting and mocking becomes tedious use helpers such as angular-debaser, sinon, chai plugins etc.

E2E Tests

  • Normally based on WebDriverJS, Selenium Server (Java) and customized NW.js ChromeDriver
  • Protractor directConnect (AKA chromeOnly) saves us from using real Selenium Server.

Selenium Server

Node running

Tests using WebDriverJS Code

Browser running w/

special extension such as chromeDriver

E2E Tests

  • Protractor directConnect (AKA chromeOnly) spares us from using real Selenium Server.

Node running

Protractor tests w/  WebDriverJS code

ChromeDriver Accepting Selenium API and automating Browser

NW.js

Protractor Setup

  • Protractor directConnect (AKA chromeOnly) spares us from using real Selenium Server.
  • npm i -D protractor
  • get nw chromeDriver
  • protractor config
    • tests and browsers
    • ChromeDriver and NW.js executable path

E2E Tests

Actions are mainly done using WebdriverJS API mainly the following globals:

  • element ($,$$)
  • By
  • browser
  • protractor

Using testing general constructs :

  • preparation (beforeEach etc)
  • actions
  • expections
  • cleanup

Writing E2E Tests

  • Tests are async by nature, almost everything returns a promise, even Expect() has been monkey-patched
  • You should not make tests that are dependent on one another
  • Its best to abstract the selectors and actions of each section, so it can be easily reused and maintained (page objects - PO)
  • E2E testing is not 100% stable in most targets (user interaction, Sync problems etc) 

Thanks for listening!

Made with Slides.com