See https://medium.com/javascript-scene/what-every-unit-test-needs-f6cd34d9836d#.jg05xuy3o
Source:
http://jonnyreeves.co.uk/2012/stubbing-javascript-promises-with-sinonjs/
Suite = A set of specs or tests
Spec = A single test
Assertion = A statement that performs a check on the software's output
Coverage = the amount of code within an app that has associated tests
Set up = code to run before a test
Tear down = code to run after a test
Unit = A function which tests another function's output
Spy = A function that records how many times it has been called and with what arguments
Stub = A spy with pre-programmed behaviour
Mock = A spy with expectations
Spies, stubs and mocks are all ways of handling non trivial code
Testing pure functions is easy
Testing events, timeouts, server calls and asynchronous code is not
When using a spy, the original function still runs,
When using a stub, it doesn’t
Stubs have all the functionality of spies, but instead of just spying on what a function does, a stub completely replaces it
Test spies are useful to test both callbacks and how certain functions are used throughout the system under test. The following simplified example shows how to use spies to test how a function handles a callback:
"test should call subscribers on publish": function () { var callback = sinon.spy(); PubSub.subscribe("message", callback); PubSub.publishSync("message"); assertTrue(callback.called); }
When testing methods of your class you get extra information back about it under test, such as
calledOnce
calledWith(message)
spy.getCall(0).args[0]
Use them like this
var spy = sinon.spy(object, "method");
Use a stub when you want to:
Control a method’s behaviour from a test to force the code down a specific path. Examples include forcing a method to throw an error in order to test error handling.
When you want to prevent a specific method from being called directly (possibly because it triggers undesired behaviour, such as a XMLHttpRequest or similar)
‘evergreen’ tests
Evergreen tests never fail, even when your code is broken. That is really bad.
Expect/should = Behaviour Driven Development
Assert = Test Driven Development
Expect/should - written closer to plain English
Assert - more concise
//TDD
assert.equal(2 - 1, 1);
//BDD
expect(2 - 1).to.equal(1);
Frameworks listed in order of popularity on GitHub
Libraries listed in order of popularity on GitHub
Coverage can be reported using a coverage framework such as:
For easy config and speed
e.g. "Test": "npm run mocha './path.to.my.specs'"
Powerful, simple API, stable and popular
Write in plain English
The most popular
and plays nice with the other tools
The most popular
but not without its issues
Karma can run tests in real browsers
HTML and JSON can be loaded into your suite.
HTML that is updated dynamically can be tested by running the JS in the beforeStart
In most cases, you don't need to explicitly specify plugins option. By default, Karma loads all sibling NPM modules which have a name starting with karma-*
In the object for the preprocessor add the transform property and relevant transform library
Install a plugin for your browser
https://karma-runner.github.io/latest/config/browsers.html
Switch to this branch
feature/webpack-coverage
yarn test
yarn coverage
Write a suite of specs for the module
train-finder.js
Integration tests
Functional tests