Testing

Testing

The enemy of testing is a reliance on dependencies (e.g. jQuery, DOM, Bootstrap) being in the global scope. It's then incumbent on the developer to make sure that files are loaded and loaded in the correct order in both the application and testing environments. ES6 modules force us to declare a module's dependencies so that the module loading layer can ensure that they are available before the module executes. They also encourage us to write "inert" modules: modules which only expose functionality, but don't actually execute anything until invocation by controlling code.

What should we test?

1. User interaction with UI (view) causes an actionCreator (exposed by duck) to be fired with appropriate data.
2. Action creator dispatches appropriate actions, including across time in an async flow. (Call action creators and assert against dispatched actions).
3. Reducers handle the resulting actions by appropriately mutating the store's state. (Call reducer with actions and assert against returned state.)
4. Views render appropriate Components/HTML based on the store state. We use Enzyme to help test rendering.

###Libraries and frameworks involved in testing:

Mocha is our testing framework. It provides the functions "define" and "it" which wrap our assertions. It provides before and after hooks to allow for setup and teardown.

Karma orchestrates the testing process. It tells webpack to build the test bundle (tests and the modules they import), then executes the tests in one of many different target environments (browsers, PhantomJS, node.js) and delivers the report.

Sinon provides mocks, stubs and spies that help isolate code for testing purposes.

Chai is an assertion library that provides different flavors of assertion (e.g. expect, assert, should). It can also mock the the browser's XMLHttpRequest. For the sake of consistency, let's use Chai's assert flavor.

Rewire is a library that allows us to easily mock/stub a modules local (un-exported) variables.