User:Sshaikh2/sandbox
 | This article has multiple issues. Please help improve it or discuss these issues on the talk page. (Learn how and when to remove these messages)
|
 | |
| Initial release | 22 November 2011 |
|---|---|
| Stable release | 2.3.4
|
| Written in | JavaScript |
| Type | Test automation framework |
| License | MIT |
| Website | mochajs |
Mocha is a JavaScript test framework running on Node.js, featuring browser support, asynchronous testing, test coverage reports, and use of any assertion library. Testing with Mocha is flexible and allows accurate reporting of errors while mapping uncaught exceptions to the correct test cases. Mocha is free and open source, licensed under the MIT license.
Installation
[edit]Mocha is a powerful testing framework for Node.js so it can be easily installed mocha by npm command. The npm (node package manager) is the default package manager for the JavaScript runtime environment Node.js.
There are 3 steps to install Mocha:
- Setup file package.json with npm init
- Install: $ npm install -g mocha
- Check the local install version to make sure install successfully: $ mocha --version
Getting Started
[edit]Mocha is easy to get started with and use to test. Just use “mocha” command to test your JavaScript code. For example, first, create a file named indexSpec.js:
describe('Sanitize', function() {
it('returns lowercase of a string');
it('removes any hyphen');
})
And then just run mocha indexSpec.js in the command line:
$ mocha indexSpec.js
Sanitize
- returns lowercase of a string
- removes any hyphen
0 passing (7ms)
2 pending
Assertion Libraries
[edit]Assert module provides some assertion test that can be used to test invariants. There are a lot of assertion libraries for a node. You can use any assertion library in Mocha if you want, it will work when it throws an error. Mocha provides its users with five assertion libraries:
Should.js is a BDD style assertions library for Node.js -- test framework. As for this assertion library, should is a readable framework-agnostic assertion library. It is used to keep your test code clean and make sure your error messages can help your coding.
Expect.js is a minimalistic BDD-style assertion library for Node.js and the browser. This library can be used in many of the common internet browsers, such as, IE, Firefox, Safari, Chrome, Opera. expect.js is also compatible with all test frameworks. In addition, this is a standalone, single global with no prototype extensions or shims. Compared to should.js, expect.js API changes with respect to the browser compatibility.
Chai is a BDD/TDD assertion library for node and the browser that can be delightfully paired with any JavaScript testing framework. There are several interfaces provided by Chai in order to allow the developer to use the most comfortable one. BDD styles provide an expressive language and readable style. As for TDD assert style, it provides a more classical style. There are many plugins to extend Chai assertions for developers to use.
Better-assert is a c-style assert for Node.js, and it will report the expression string as the error message. It use callite for self document failure messages.
Unexpected assertion is an extensible BDD assertion toolkit. This assertion library provides users helpful error message and also helps them correct when they misspell assertions. The same as the other assertion libraries, this one is also compatible with all test frameworks. Furthermore, unexpected assertion supports asynchronous assertions using promises, single global with no prototype extensions or shims and cross-browser compatibility, works on Chrome, Firefox, Safari, Opera, IE6+, (IE6-IE8 with es5-shim).
Synchronous means it waits for each operation to complete after which it executes the next operation. Testing synchronous code is much simpler than testing asynchronous code. When testing synchronous code, omit the callback and then Mocha will automatically continue with the next step of the test.
describe('Array', function() {
describe('#indexOf()', function() {
it('should return -1 when the value is not present', function() {
[5,6,7].indexOf(7).should.equal(-1);
[5,6,7].indexOf(1).should.equal(-1);
});
});
});
Asynchronous will never wait for each operation to complete, rather it executes all operations in the first GO. The result of each operation will be handled once the result is available. So, testing asynchronous code is difficult because users always want to test things after they complete a module. But to know when each operation is completed is not directly possible in JavaScript. To test asynchronous code, first attempts are led it to rely heavily on timeouts. When testing it with Mocha, simply invoke the callback when your test is complete. So, users need to add a callback to it(), in order to let Mocha know that it should wait for the completion. The done method is used for the same purpose. Besides, using the function done() to a callback, developers can also return a Promise. This is useful if the code you are testing return promises instead of taking callbacks.
describe('Profile', function() {
describe('#make()', function() {
it('should make without error', function(done) {
var profile = new Profile('Lemmy');
profile.make(function(err) {
if (err) throw err;
done();
});
});
});
});
Compared to function expression, arrow function has a shorter syntax and lexically binds the value. Arrow functions are always anonymous. When testing arrow functions in Mocha, it’s discouraged when passing to Mocha. Their lexical binding of the this value makes them unable to access the Mocha context, and statements like this.timeout(1000) will not work inside an arrow function.
Hook is some logic, typically a function or a few statements, which is executed when the associated event happens. Hook is a RESTful and extendable Backend as a Service that provides an instant back-end to develop sites and apps faster, with dead-simple integration for JavaScript, iOS, Android. It has lots of features:
- Multi-tenancy (same instance may be used for many apps)
- User authentication (register, login, reset password)
- Data persistence through collections
- Data storage through many providers
- Real-time communication through WAMP sub-protocol (Web-sockets).
- Package management through composer
describe('hooks', function() {
before(function() {
// runs before all tests in this block
});
after(function() {
// runs after all tests in this block
});
beforeEach(function() {
// runs before each test in this block
});
afterEach(function() {
// runs after each test in this block
});
// test cases
});
Mocha also has hooks that are executed in different parts of suites, before the whole suite and before each test. Mocha has hooks like before(), after(), beforeEach(), afterEach() to set up preconditions and clean up the tests. All hooks can be invoked with an optional description, making it easier to pinpoint errors in the tests. If hooks are given named functions, those names will be used if no description is supplied. All hooks support asynchronous modes just like a regular test-case.
It is also possible to pick any file and add "root" for root- level hooks. For example, add beforeEach() outside of all describe() blocks. This will cause the callback to beforeEach() to run before any test case, regardless of the file it lives in (this is because Mocha has a hidden describe() block, called the "root suite"). Furthermore, If you need to perform asynchronous operations before any of your suites are run, you may delay the root suite. Simply run Mocha with the --delay flag. This will provide a special function, run(), in the global context.
Pending test-cases are simply the test-cases without a callback. Pending tests will be reported as such:
describe('String', function() {
describe('#charAt()', function() {
// pending test below
it('should return -1 when the value is not present');
});
});
Exclusive tests allow users to run the specified suite or test case by appending 'only()' to the function.
describe('String', function() {
describe.only('#charAt()', function() {
// ...
});
});
This is the opposite of the exclusive test. By appending the 'skip()' to a function, you can make Mocha ignore some these suites or test case.
describe('String', function() {
describe('#charAt()', function() {
it.skip('should return -1 unless present', function() {
// ...
});
it('should return the character when present', function() {
// ...
});
});
});
Dynamically Generating Tests
[edit]Mocha provides a function to dynamically generate test: function.prototype.call and function expressions to define suites and test cases. Users don’t need to use special syntax.
var assert = require('assert');
function add() {
return Array.prototype.slice.call(arguments).reduce(function(prev, curr) {
return prev + curr;
}, 0);
}
describe('add()', function() {
var tests = [
{args: [1, 2], expected: 3},
{args: [1, 2, 3], expected: 6},
{args: [1, 2, 3, 4], expected: 10}
];
tests.forEach(function(test) {
it('correctly adds ' + test.args.length + ' args', function() {
var res = add.apply(null, test.args);
assert.equal(res, test.expected);
});
});
});
Timeouts
[edit]Timeouts are used to introduce delays in the program. Since JavaScript is asynchronous, the timeouts help in situations where the program relies on the result of some operations that might not have completed processing yet. There are 2 types of timeouts:
Suite Level
[edit]Suite- level timeouts are applied to the entire test suite and all is inherited by all the nested-suites and test case provided they don’t explicitly override the timeout function.This call to the timeout function has to be made from within the suite. Syntax: this.timeout(<ms>) To disable the timeout call: this.timeout(0)
Test level
[edit]Test-level timeouts are applicable to individual test cases when called from within the particular test case. They, too, get disabled when this.timeout(0) is called.
Diffs
[edit]With “Diffs”, Mocha attempts to display the difference between the expected and the actual values. From the Assertion libraries, Mocha can use the err.expected and err.actual when the AssertionError is thrown . The string diffs, a type of diff used to compare small strings, was added to Mocha in the 0.14.0 update and is one of the most handy feature for comparing the strings for the expected and the actual value in templates engines, transpilers and other string based libraries. The diff is represented in the same code with the actual value highlighted in green and the expected value in red.
Usage:
mocha [debug] [options] [files]
Commands:
init <path> initialize a client-side mocha setup at <path>
| Command | Detail |
|---|---|
| -h, --help | output usage information |
| -A, --async-only | default all tests to take async callback or return a promise |
| -c, --colors | enable colors |
| -V, --version | output version number |
| -C, --no-colors | disable colors |
| -G, --growl | enable growl notification. |
| -O, --Reporter-options <> | reporter specific options |
| -R, -- reporter <name> | specify the reporter to use |
| -S, --sort | sort the test files |
| -b, --bail | bail after first test fails. |
| -d, --debug | enable the invoker. |
| -grep, --grep <pattern> | run test only for matching pattern |
| -r, --require <name> | require the given module. |
| -t, --timeout | set test cases timeouts to sync an async code. |
| -w, --watch | read the files for changes. |
| -ui, --ui <name> | specify user interface. |
| --check-leaks | check for global variable leaks |
| --compilers <ext>:<module>,... | use the given module(s) to compile files |
| --debug-brk | enable node's debugger breaking on the first line |
| --delay | wait for async suite definition |
| --full-trace | display the full stack trace |
| --globals <names> | allow the given comma-delimited global [names] |
| --inline-diffs | display actual/expected differences inline within each string |
| --interfaces | display available interfaces |
| --no-deprecation | disable deprecation warnings |
| --no-exit | shut the loop down without the process.exit() method |
| --no-timeouts | disables timeouts, given implicitly with --debug |
| --opts <path> | specify opts path |
| log statistical profiling information | |
| --recursive | include sub directories |
| --reporters | display available reporters |
| --throw-deprecation | throw an exception anytime a deprecated function is used |
| --trace | trace function calls |
| --trace-deprecation | show stack traces on deprecations |
Mocha provides the user with multiple interface systems to allow the developers to choose their style of domain specific language (DSL). Mocha has BDD, TDD, Exports, QUnit and Require-style interfaces.
BDD
[edit]The BDD interface provides describe(), context(), it(), before(), after(), beforeEach() and afterEach() functions/hooks. context() and describe() behave in the same way except that context() makes tests easier to read and keeps them organized.
TDD
[edit]The TDD interface provides suite(), test(), suiteSetup(), suiteTeardown(), setup() and teardown() functions/hooks. With TDD, the developer can test each unit seperately.
Exports
[edit]The Exports interface is derived from Mocha’s predecessor expresso. Here, the keys (before, after, beforeEach and afterEach) are special-cased, the suites act as the object values and the test cases are passed as the test-cases.
QUnit
[edit]This, as the name suggests, is inspired from the QUnit - the interface looks flat. The test case suite is defined first followed by the test cases that fall under this suite. Although it is inspired form the QUnit interface, it lacks assertions, the asyncTest method and other things that QUnit provides.
Require
[edit]The require interface allows the developer to require the describe, before, it, after and other methods directly using require, once and then allowing the to be called whenever needed.
As the name suggests, the Mocha reporters adjust the terminal window so as to ‘report’ the errors easily to the user. It disables the ANSI-escape coloring when the stdio stream and the TTY are not associated. There are many types of reporters out of which some are listed below.
Spec
[edit]This is the default reporter. This reporter follows the nested test hierarchy and outputs the test results in the same hierarchy.
Dot Matrix
[edit]The dot matrix or dot represent the output in a rather minimalistic way. The output on the terminal window is just a series of dots, 1 for each test case. Each dot is color-coded to see the state of the test case - red is failure, blue is pending, yellow is slow.
As the name suggests, the terminal window shows a character representation of Nyan cat with the rainbow colors. The same color scheme is used in the Nyan cat video, Pink (being closest to red) suggests error and the error line is highlighted with pink.
Other Reporters
[edit]Landing Strip
[edit]shows a plane landing, it lands when the testing is completed 100%.
JSON stream
[edit]outputs the result as a JSON object.
List
[edit]Lists all the results of the test cases whether pass or fail. The errors are detailed at the bottom.
Min
[edit]Only displays the summary while still outputting errors when encountered.
Doc
[edit]Reports the output as a hierarchical HTML body representation of the tests.
Running Mocha in browser
[edit]One of the features of Mocha is that it runs in the browser. To support this, Mocha has several browser-only functions like mocha.allowUncaught() which allows the uncaught errors to be be ignored by the error handler. Typically, a BDD interface is used where the scripts starts off with a mocha.setup(‘bdd’) before the onload and mocha.run() methods are used run the the test scripts. Although, these can be overriden by using the mocha mocha.setup() method. Example, to use a TDD interface, mocha.setup(‘tdd’) will change the interface to TDD.
mocha.opts
[edit]This is a default configuration file which Mocha will load on the server as ./test/mocha.opts. This contains the default configuration of the results. If we also pass command line arguments, then these arguments take precedence over the mocha.opts and override the configuration settings in the mocha.opts file:
--require should
--reporter nyan
--ui tdd
This suggests that the default configuration is set to a TDD interface with a nyan reporter and must require the should library. Although, we may invoke mocha with additional (command line) arguments by enabling growling like
$ mocha --reporter doc --growl
This above line changes the reporter to 'doc' while the other two parameters remain the same.
Editor Plugins
[edit]For various IDE or editors, Mocha packages are available as plugins
TextMate
[edit]For the TextMate editor for Mac OS, a mocha package is available. To install it, clone a copy of the Mocha repo on Github and run the following command:
$ make ™
JetBrains provide a NodeJS plugin for both is intelliJ IDEA as well as webstorm IDE (both are compatible with JavaScript). The plugin is named NodeJS and contains a Mocha test runnner and other NodeJS components. it can be installed by searching NodeJS in the File > Settings> plugins > Browse Repositories > Search "NodeJS" > install. from the settings menu.
Once the NodeJS plugin is set up, the working environment needs to be set up before beginning the testing.
Wallaby.js
[edit]It is a testing tool that allows real time coverage for Mocha. It also allows support for the assertion libraries in JetBrains IDE and Visual studio along with browser and NodeJS support for both.
See also
[edit]
References
[edit]- ^ "Mocha(JavaScript Framework)".
- ^ a b c d "Mocha JS homepage".
- ^ "Mocha - Unit JS". unitjs.com. Retrieved 2016-02-07.
- ^ "mocha-phantomjs". www.npmjs.com. Retrieved 2016-02-07.
- ^ "mocha-funnynyan-reporter". www.npmjs.com. Retrieved 2016-02-07.
- ^ "IntelliJ IDEA 15.0 Help :: Running Mocha Unit Tests". www.jetbrains.com. Retrieved 2016-02-07.
{{cite web}}: line feed character in|title=at position 19 (help)
External links
[edit]Category:JavaScript libraries Category:Software using the MIT license