Are you over 18 and want to see adult content?
More Annotations
A complete backup of prakashsrivastava.com
Are you over 18 and want to see adult content?
A complete backup of meintranskript.de
Are you over 18 and want to see adult content?
A complete backup of marshmellomusic.com
Are you over 18 and want to see adult content?
A complete backup of philurbanlegends.blogspot.com
Are you over 18 and want to see adult content?
Favourite Annotations
A complete backup of www.www.amateur.tv
Are you over 18 and want to see adult content?
A complete backup of worldwidewives.com
Are you over 18 and want to see adult content?
A complete backup of www.neatmovies.com
Are you over 18 and want to see adult content?
A complete backup of www.kaufmich.com
Are you over 18 and want to see adult content?
A complete backup of www.lushstories.com
Are you over 18 and want to see adult content?
Text
method
RUNNER - DOCUMENTATION - MOCHA Properties: Emitted when Root Suite execution begins (all files have been parsed and hooks/tests are ready for execution) Emitted when delayed Root Suite execution is triggered by user via global.run () Runner -related constants. TUTORIAL: CREATE A CUSTOM REPORTER RUNNABLE - DOCUMENTATION - MOCHA string. Value of state prop when a Runnable has failed. STATE_PASSED. string. Value of state prop when a Runnable has passed. STATE_PENDING. string. Value of state prop when a Runnable has been skipped by user. Runnable -related constants.MOCHA
passes: 8 failures: 0 duration: 0.07s Array.push() should append avalue 2ms ‣ var
e=;e.push("foo"),e.push("bar"),expect(e).to.equal("foo"),expect(e).to SUITE.JS - DOCUMENTATION suite.js 'use strict'; /** * Module dependencies. * @private */ const {EventEmitter} = require('events'); const Hook = require('./hook'); var { assignNewMochaIDREPORTERS/HTML.JS
reporters/html.js 'use strict'; /* eslint-env browser */ /** * @module HTML */ /** * Module dependencies. */ var Base = require('./base');var utils = require
REPORTERS/LANDING.JS reporters/landing.js. * Module dependencies. * Expose `Landing`. * Airplane color. * Airplane crash color. * Runway color. * Constructs a new `Landing` reporter instance. * @param {Runner} runner - Instance triggers reporter actions. // if cursor is hidden when we ctrl-C, then it will remain hidden unless EXCLUDE - DOCUMENTATION Source: browser/growl.js, line 197; See: https://www.typescriptlang.org/docs/handbook/utility-types.html#excludetu MOCHA - THE FUN, SIMPLE, FLEXIBLE JAVASCRIPT TEST FRAMEWORK Mocha - the fun, simple, flexible JavaScript test framework. Mocha is a feature-rich JavaScript test framework running on Node.js and in the browser, making asynchronous testing simple and fun. Mocha tests run serially, allowing for flexible and accurate reporting, while mapping uncaught exceptions to the correct test cases. MOCHA - DOCUMENTATIONDOCUMENTATIONMOCHA parallelMode (enableopt) → { Mocha } Source: mocha.js, line 1127. Toggles parallel mode. Must be run before calling Mocha#run. Changes the Runner class to. use; also enables lazy file loading if not already done so. Warning: when passed false and lazy loading has been enabled via any means (including calling parallelMode (true) ), thismethod
RUNNER - DOCUMENTATION - MOCHA Properties: Emitted when Root Suite execution begins (all files have been parsed and hooks/tests are ready for execution) Emitted when delayed Root Suite execution is triggered by user via global.run () Runner -related constants. TUTORIAL: CREATE A CUSTOM REPORTER RUNNABLE - DOCUMENTATION - MOCHA string. Value of state prop when a Runnable has failed. STATE_PASSED. string. Value of state prop when a Runnable has passed. STATE_PENDING. string. Value of state prop when a Runnable has been skipped by user. Runnable -related constants.MOCHA
passes: 8 failures: 0 duration: 0.07s Array.push() should append avalue 2ms ‣ var
e=;e.push("foo"),e.push("bar"),expect(e).to.equal("foo"),expect(e).to SUITE.JS - DOCUMENTATION suite.js 'use strict'; /** * Module dependencies. * @private */ const {EventEmitter} = require('events'); const Hook = require('./hook'); var { assignNewMochaIDREPORTERS/HTML.JS
reporters/html.js 'use strict'; /* eslint-env browser */ /** * @module HTML */ /** * Module dependencies. */ var Base = require('./base');var utils = require
REPORTERS/LANDING.JS reporters/landing.js. * Module dependencies. * Expose `Landing`. * Airplane color. * Airplane crash color. * Runway color. * Constructs a new `Landing` reporter instance. * @param {Runner} runner - Instance triggers reporter actions. // if cursor is hidden when we ctrl-C, then it will remain hidden unless EXCLUDE - DOCUMENTATION Source: browser/growl.js, line 197; See: https://www.typescriptlang.org/docs/handbook/utility-types.html#excludetu SUITE - DOCUMENTATION - MOCHA Event emitted immediately after a test file has been loaded. Not emitted in browser. Event emitted when global.run () is called (use with delay option) Emitted after an "after all" Hook has been added to a Suite. Deprecated. Emitted after an "after each" Hook has been added to a Suite Deprecated. MOCHA.JS - DOCUMENTATION mocha.js 'use strict'; /*! * mocha * Copyright(c) 2011 TJ Holowaychuk * MIT Licensed */ var escapeRe = require('escape-string-regexp'); varpath
UTILS - DOCUMENTATION A "map" is an object with no prototype, for our purposes. In some cases this would be more appropriate than a Map, especially if your environment doesn't support it. SPEC - DOCUMENTATION - MOCHA new Spec (runner, optionsopt) Source: reporters/spec.js, line 37. Constructs a new Spec reporter instance. GROWL - DOCUMENTATION Checks if Growl notification support seems likely. Source: nodejs/growl.js, line 28. See: Prerequisite Installs. Mocha#growl. Mocha#isGrowlCapable. Glosses over the distinction between an unsupported platform. and one that lacks prerequisite softwareinstallations.
MOCHA
passes: 8 failures: 0 duration: 0.07s Array.push() should append avalue 2ms ‣ var
e=;e.push("foo"),e.push("bar"),expect(e).to.equal("foo"),expect(e).toINTERFACES/COMMON
Source: interfaces/common.js, line 47. This is only present if flag --delay is passed into Mocha. It triggers. root suite execution.PARALLELBUFFERED
The ParallelBuffered reporter is used by each worker process in "parallel". mode, by default. Instead of reporting to to STDOUT, etc., it retains a. list of events it receives and hands these off to the callback passed into. Mocha#run. That callback will then return the data to the main. process. XUNIT - DOCUMENTATION - MOCHA new XUnit (runner, optionsopt) Source: reporters/xunit.js, line 45. Constructs a new XUnit reporter instance.CLI/OPTIONS.JS
cli/options.js. * whether that's a config file or `package.json` or whatever. * lookups. * (e.g., `--foo bar baz quux`), so we fix the number of arguments to 1 across. * the board of non-boolean options. // save node-specific args for special handling. // are ALL booleanflags.
_simple_, _flexible_, _fun_ Mocha is a feature-rich JavaScript test framework running on Node.js and in the browser, making asynchronous testing _simple_ and _fun_. Mocha tests run serially, allowing for flexible and accurate reporting, while mapping uncaught exceptions to the correct test cases. Hosted on GitHub.
# BACKERS
Find Mocha helpful? Become a backer and support Mocha with amonthly donation.
# SPONSORS
Use Mocha at Work? Ask your manager or marketing team if they'd help support our project. Your company's logo will also be displayed on npmjs.com and our GitHub repository.
# FEATURES
* browser support
* simple async support, including promises * test coverage reporting * string diff support * javascript API for running tests * proper exit status for CI support etc * auto-detects and disables coloring for non-ttys * async test timeout support * test retry support * test-specific timeouts* Growl support
* reports test durations * highlights slow tests * file watcher support * global variable leak detection * optionally run tests that match a regexp * auto-exit to prevent "hanging" with an active loop * easily meta-generate suites & test-cases * config file support * mocha.opts file support * clickable suite titles to filter test execution * node debugger support * node native ES modules support * detects multiple calls to done() * use any assertion library you want * extensible reporting, bundled with 9+ reporters * extensible test DSLs or "interfaces" * before, after, before each, after each hooks * arbitrary transpiler support (coffee-script etc)* TextMate bundle
# TABLE OF CONTENTS
* Installation
* Getting Started
* Run Cycle Overview * Detects Multiple Calls to done()* Assertions
* Asynchronous Code
* Synchronous Code
* Arrow Functions
* Hooks
* Pending Tests
* Exclusive Tests
* Inclusive Tests
* Retry Tests
* Dynamically Generating Tests* Timeouts
* Diffs
* Command-Line Usage* Interfaces
* Reporters
* Node.JS native ESM support * Running Mocha in the Browser * Desktop Notification Support * Configuring Mocha (Node.js)* mocha.opts
* The test/ Directory* Error Codes
* Editor Plugins
* Examples
* Testing Mocha
* More Information
# INSTALLATION
Install with npm globally: $ npm install --global mocha or as a development dependency for your project: $ npm install --save-dev mocha > As of v7.0.0, Mocha requires Node.js v8.0.0 or newer.# GETTING STARTED
$ npm install mocha$ mkdir test
$ $EDITOR test/test.js # or open with your favorite editorIn your editor:
var assert = require('assert'); describe('Array', function() { describe('#indexOf()', function() { it('should return -1 when the value is not present', function() { assert.equal(.indexOf(4), -1);});
});
});
Back in the terminal: $ ./node_modules/mocha/bin/mochaArray
#indexOf()
✓ should return -1 when the value is not present1 passing (9ms)
Set up a test script in package.json:"scripts": {
"test": "mocha"
}
Then run tests with:$ npm test
# RUN CYCLE OVERVIEW A brief outline on the order Mocha's components are executed. Worth noting that all hooks, describe and it callbacks are run in the order they are defined (i.e. found in the file). run 'mocha spec.js'|
spawn child process|
|--------------> inside child process process and apply options|
run spec file/s
|
|--------------> per spec file suite callbacks (e.g., 'describe')|
'before' root-level pre-hook|
'before' pre-hook
|
|--------------> per test 'beforeEach' root-level pre-hook|
'beforeEach' pre-hook|
test callbacks (e.g., 'it')|
'afterEach' post-hook|
'afterEach' root-level post-hook |<-------------- per test end|
'after' post-hook
|
'after' root-level post-hooks |<-------------- per spec file end |<-------------- inside child process end # DETECTS MULTIPLE CALLS TO DONE() If you use callback-based async tests, Mocha will throw an error if done() is called multiple times. This is handy for catching accidentaldouble callbacks.
it('double done', function(done) { // Calling `done()` twice is an errorsetImmediate(done);
setImmediate(done);
});
Running the above test will give you the below error message: $ ./node_modules/.bin/mocha mocha.test.js✓ double done
1) double done
1 passing (6ms)
1 failing
1) double done:
Error: done() called multiple times at Object.# ASSERTIONS
Mocha allows you to use any assertion library you wish. In the above example, we're using Node.js' built-in assert module — but generally, if it throws an Error, it will work! This means you can use libraries suchas:
* should.js - BDD style shown throughout these docs * expect.js - expect()style assertions
* chai - expect(), assert() and should-style assertions* better-assert -
C-style self-documenting assert() * unexpected - "the extensible BDDassertion toolkit"
# ASYNCHRONOUS CODE
Testing asynchronous code with Mocha could not be simpler! Simply invoke the callback when your test is complete. By adding a callback (usually named done) to it(), Mocha will know that it should wait for this function to be called to complete the test. This callback accepts both an Error instance (or subclass thereof) _or_ a falsy value; anything else is invalid usage and throws an error (usually causing afailed test).
describe('User', function() { describe('#save()', function() { it('should save without error', function(done) { var user = new User('Luna'); user.save(function(err) { if (err) done(err);else done();
});
});
});
});
Alternatively, just use the done() callback directly (which will handle an error argument, if it exists): describe('User', function() { describe('#save()', function() { it('should save without error', function(done) { var user = new User('Luna');user.save(done);
});
});
});
# WORKING WITH PROMISES Alternately, instead of using the done() callback, you may return aPromise
.
This is useful if the APIs you are testing return promises instead oftaking callbacks:
beforeEach(function() { return db.clear().then(function() {return db.save();
});
});
describe('#find()', function() { it('respond with matching records', function() { return db.find({type: 'User'}).should.eventually.have.length(3);});
});
> The latter example uses Chai as Promised > for fluent promise> assertions.
In Mocha v3.0.0 and newer, returning a Promise _and_ calling done() will result in an exception, as this is generally a mistake: const assert = require('assert');// antipattern
it('should complete this test', function(done) { return new Promise(function(resolve) {assert.ok(true);
resolve();
}).then(done);
});
The above test will fail with Error: Resolution method is overspecified. Specify a callback *or* return a Promise; not both.. In versions older than v3.0.0, the call to done() is effectively ignored. # USING ASYNC / AWAIT If your JS environment supports async / await,
you can also write asynchronous tests like this: beforeEach(async function() {await db.clear();
await db.save();
});
describe('#find()', function() { it('responds with matching records', async function() { const users = await db.find({type: 'User'}); users.should.have.length(3);});
});
# SYNCHRONOUS CODE
When testing synchronous code, omit the callback and Mocha will automatically continue on to the next test. describe('Array', function() { describe('#indexOf()', function() { it('should return -1 when the value is not present', function() { .indexOf(5).should.equal(-1); .indexOf(0).should.equal(-1);});
});
});
# ARROW FUNCTIONS
Passing arrow functions (aka "lambdas") to Mocha is discouraged. Lambdas lexically bind this and cannot access the Mocha context. For example, the following codewill fail:
describe('my suite', () => { it('my test', () => { // should set the timeout of this test to 1000 ms; instead will failthis.timeout(1000);
assert.ok(true);
});
});
_If you do not need to use_ Mocha's context, lambdas should work. However, the result will be more difficult to refactor if the needeventually arises.
# HOOKS
With its default "BDD"-style interface, Mocha provides the hooks before(), after(), beforeEach(), and afterEach(). These should be used to set up preconditions and clean up after your tests. describe('hooks', function() { before(function() { // runs once before the first test in this block});
after(function() {
// runs once after the last test in this block});
beforeEach(function() { // runs before each test in this block});
afterEach(function() { // runs after each test in this block});
// test cases
});
> Tests can appear before, after, or interspersed with your hooks. > Hooks will run in the order they are defined, as appropriate; all > before() hooks run (once), then any beforeEach() hooks, tests, any > afterEach() hooks, and finally after() hooks (once).# DESCRIBING HOOKS
Any hook can be invoked with an optional description, making it easier to pinpoint errors in your tests. If a hook is given a named function, that name will be used if no description is supplied. beforeEach(function() { // beforeEach hook});
beforeEach(function namedFun() { // beforeEach:namedFun});
beforeEach('some description', function() { // beforeEach:some description});
# ASYNCHRONOUS HOOKS All hooks (before(), after(), beforeEach(), afterEach()) may be sync or async as well, behaving much like a regular test-case. For example, you may wish to populate database with dummy content before each test: describe('Connection', function() { var db = new Connection(), tobi = new User('tobi'), loki = new User('loki'), jane = new User('jane'); beforeEach(function(done) { db.clear(function(err) { if (err) return done(err);db.save(, done);
});
});
describe('#find()', function() { it('respond with matching records', function(done) { db.find({type: 'User'}, function(err, res) { if (err) return done(err); res.should.have.length(3);done();
});
});
});
});
# ROOT-LEVEL HOOKS
You may also pick any file and add "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 an _implied_ describe() block, called the "root suite"). beforeEach(function() { console.log('before every test in every file');});
# DELAYED ROOT SUITE If you need to perform asynchronous operations before any of your suites are run, you may delay the root suite. Run mocha with the --delay flag. This will attach a special callback function, run(), tothe global context:
setTimeout(function() {// do some setup
describe('my suite', function() {// ...
});
run();
}, 5000);
# PENDING TESTS
"Pending"--as in "someone should write these test cases eventually"--test-cases are simply those _without_ a callback: describe('Array', function() { describe('#indexOf()', function() { // pending test below it('should return -1 when the value is not present');});
});
Pending tests will be included in the test results, and marked as pending. A pending test is not considered a failed test.# EXCLUSIVE TESTS
The exclusivity feature allows you to run _only_ the specified suite or test-case by appending .only() to the function. Here's an example of executing only a particular suite: describe('Array', function() { describe.only('#indexOf()', function() {// ...
});
});
_Note_: All nested suites will still be executed. Here's an example of executing an individual test case: describe('Array', function() { describe('#indexOf()', function() { it.only('should return -1 unless present', function() {// ...
});
it('should return the index when present', function() {// ...
});
});
});
Previous to v3.0.0, .only() used string matching to decide which tests to execute; this is no longer the case. In v3.0.0 or newer, .only() can be used multiple times to define a subset of tests to run: describe('Array', function() { describe('#indexOf()', function() { it.only('should return -1 unless present', function() { // this test will be run});
it.only('should return the index when present', function() { // this test will also be run});
it('should return -1 if called with a non-Array context', function() { // this test will not be run});
});
});
You may also choose multiple suites: describe('Array', function() { describe.only('#indexOf()', function() { it('should return -1 unless present', function() { // this test will be run});
it('should return the index when present', function() { // this test will also be run});
});
describe.only('#concat()', function() { it('should return a new Array', function() { // this test will also be run});
});
describe('#slice()', function() { it('should return a new Array', function() { // this test will not be run});
});
});
But _tests will have precedence_: describe('Array', function() { describe.only('#indexOf()', function() { it.only('should return -1 unless present', function() { // this test will be run});
it('should return the index when present', function() { // this test will not be run});
});
});
_Note_: Hooks, if present, will still be executed. > Be mindful not to commit usages of .only() to version control, > unless you really mean it! To do so one can run mocha with the > option --forbid-only in the continuous integration test command (or > in a git precommit hook).# INCLUSIVE TESTS
This feature is the inverse of .only(). By appending .skip(), you may tell Mocha to simply ignore test case(s). Anything skipped will be marked as pending, and reported as such. Here's an example of skippingan individual test:
describe('Array', function() { describe('#indexOf()', function() { it.skip('should return -1 unless present', function() { // this test will not be run});
it('should return the index when present', function() { // this test will be run});
});
});
You can also put .skip() on an entire suite. This is equivalent to appending .skip() onto all tests in the suite. Hooks in the suite arealso skipped.
describe('Array', function() { describe.skip('#indexOf()', function() { it('should return -1 unless present', function() { // this test will not be run});
});
});
_Note_: Code in skipped suites, that is placed outside of hooks or tests is still executed, as mocha will still invoke the suite function to build up the suite structure for visualization. > _Best practice_: Use .skip() instead of commenting tests out. You may also skip _at runtime_ using this.skip(). If a test needs an environment or configuration which cannot be detected beforehand, a runtime skip is appropriate. For example: it('should only test in the correct environment', function() { if (/* check test environment */) { // make assertions} else {
this.skip();
}
});
The above test will be reported as pending. It's also important to note that calling this.skip() will effectively _abort_ the test. > _Best practice_: To avoid confusion, do not execute further > instructions in a test or hook after calling this.skip(). Contrast the above test with the following code: it('should only test in the correct environment', function() { if (/* check test environment */) { // make assertions} else {
// do nothing
}
});
Because this test _does nothing_, it will be reported as _passing_. > _Best practice_: Don't do nothing! A test should make an assertion > or use this.skip(). To skip _multiple_ tests in this manner, use this.skip() in a "beforeall" hook:
before(function() { if (/* check test environment */) {// setup code
} else {
this.skip();
}
});
This will skip all it, beforeEach/afterEach, and describe blocks within the suite. before/after hooks are skipped unless they are defined at the same level as the hook containing this.skip(). describe('outer', function() { before(function() {this.skip();
});
after(function() {
// will be executed});
describe('inner', function() { before(function() { // will be skipped});
after(function() {
// will be skipped});
});
});
> _Updated in v7.0.0:_ skipping a test within an "after all" hook is > disallowed and will throw an exception. Use a return statement or > other means to abort hook execution. Before Mocha v3.0.0, this.skip() was not supported in asynchronoustests and hooks.
# RETRY TESTS
You can choose to retry failed tests up to a certain number of times. This feature is designed to handle end-to-end tests (functional tests/Selenium...) where resources cannot be easily mocked/stubbed. IT'S NOT RECOMMENDED TO USE THIS FEATURE FOR UNIT TESTS. This feature does re-run a failed test and its corresponding beforeEach/afterEach hooks, but not before/after hooks. this.retries() has no effect on failing hooks. NOTE: Example below was written using Selenium webdriver (which overwrites global Mocha hooksfor Promise chain).
describe('retries', function() { // Retry all tests in this suite up to 4 timesthis.retries(4);
beforeEach(function() { browser.get('http://www.yahoo.com');});
it('should succeed on the 3rd try', function() { // Specify this test to only retry up to 2 timesthis.retries(2);
expect($('.foo').isDisplayed()).to.eventually.be.true;});
});
# DYNAMICALLY GENERATING TESTS Given Mocha's use of Function.prototype.call and function expressions to define suites and test cases, it's straightforward to generate your tests dynamically. No special syntax is required — plain ol' JavaScript can be used to achieve functionality similar to "parameterized" tests, which you may have seen in other frameworks. Take the following example: var assert = require('chai').assert;function add() {
return Array.prototype.slice.call(arguments).reduce(function(prev, curr) { return prev + curr;}, 0);
}
describe('add()', function() {var tests = ;
tests.forEach(function(test) { it('correctly adds ' + test.args.length + ' args', function() { var res = add.apply(null, test.args); assert.equal(res, test.expected);});
});
});
The above code will produce a suite with three specs:$ mocha
add()
✓ correctly adds 2 args ✓ correctly adds 3 args ✓ correctly adds 4 argsTEST DURATION
Many reporters will display test duration and flag tests that are slow (default: 75ms), as shown here with the SPEC reporter: There are three levels of test duration (depicted in the followingimage):
* FAST: Tests that run within half of the "slow" threshold will show the duration in green (if at all). * NORMAL: Tests that run exceeding half of the threshold (but still within it) will show the duration in yellow. * SLOW: Tests that run exceeding the threshold will show the durationin red.
To tweak what's considered "slow", you can use the slow() method: describe('something slow', function() { this.slow(300000); // five minutes it('should take long enough for me to go make a sandwich', function() {// ...
});
});
# TIMEOUTS
# SUITE-LEVEL
Suite-level timeouts may be applied to entire test "suites", or disabled via this.timeout(0). This will be inherited by all nested suites and test-cases that do not override the value. describe('a suite of tests', function() {this.timeout(500);
it('should take less than 500ms', function(done) { setTimeout(done, 300);});
it('should take less than 500ms as well', function(done) { setTimeout(done, 250);});
});
# TEST-LEVEL
Test-specific timeouts may also be applied, or the use of this.timeout(0) to disable timeouts all together: it('should take less than 500ms', function(done) {this.timeout(500);
setTimeout(done, 300);});
# HOOK-LEVEL
Hook-level timeouts may also be applied: describe('a suite of tests', function() { beforeEach(function(done) { this.timeout(3000); // A very long environment setup. setTimeout(done, 2500);});
});
Again, use this.timeout(0) to disable the timeout for a hook. > In v3.0.0 or newer, a parameter passed to this.timeout() greater > than the maximum delay value>
> will cause the timeout to be disabled.# DIFFS
Mocha supports the err.expected and err.actual properties of any thrown AssertionErrors from an assertion library. Mocha will attempt to display the difference between what was expected, and what the assertion actually saw. Here's an example of a "string" diff using--inline-diffs:
# COMMAND-LINE USAGEmocha
Run tests with MochaCommands
mocha inspect Run tests with Mocha mocha initRules & Behavior
--allow-uncaught Allow uncaught errors to propagate --async-only, -A Require all tests to use a callback (async) orreturn a Promise
--bail, -b Abort ("bail") after first test failure --check-leaks Check for global variable leaks --delay Delay initial execution of root suite --exit Force Mocha to quit after tests complete --forbid-only Fail if exclusive test(s) encountered --forbid-pending Fail if pending test(s) encountered --global, --globals List of allowed global variables --retries Retry failed tests this many times --slow, -s Specify "slow" test threshold (in milliseconds) --timeout, -t, --timeouts Specify test timeout threshold (in milliseconds) --ui, -u Specify user interface Reporting & Output --color, -c, --colors Force-enable color output --diff Show diff on failure --full-trace Display full stack traces --growl, -G Enable Growl notifications --inline-diffs Display actual/expected differences inline within each string --reporter, -R Specify reporter to use --reporter-option, --reporter-options, Reporter-specific options -O (Configuration
--config Path to config file --opts Path to `mocha.opts` (DEPRECATED) --package Path to package.json for configFile Handling
--extension File extension(s) to load --file Specify file(s) to be loaded prior to root suiteexecution
--ignore, --exclude Ignore file(s) or glob pattern(s) --recursive Look for tests in subdirectories --require, -r Require module --sort, -S Sort test files --watch, -w Watch files in the current working directory for changes --watch-files List of paths or globs to watch --watch-ignore List of paths or globs to exclude from watchingTest Filters
--fgrep, -f Only run tests containing this string --grep, -g Only run tests matching this string or regexp --invert, -i Inverts --grep and --fgrep matches Positional Arguments spec One or more files, directories, or globs to testOther Options
--help, -h Show usage information & exit --version, -V Show version number & exit --list-interfaces List built-in user interfaces & exit --list-reporters List built-in reporters & exitMocha Resources
Chat: https://gitter.im/mochajs/mocha GitHub: https://github.com/mochajs/mocha.git Docs: https://mochajs.org/# --ALLOW-UNCAUGHT
By default, Mocha will attempt to trap uncaught exceptions thrown from running tests and report these as test failures. Use --allow-uncaught to disable this behavior and allow uncaught exceptions to propagate. Will typically cause the process to crash. This flag is useful when debugging particularly difficult-to-trackexceptions.
# --ASYNC-ONLY, -A
Enforce a rule that tests must be written in "async" style, meaning each test provides a done callback or returns a Promise. Non-compliant tests will be marked as failures.# --BAIL, -B
Causes Mocha to stop running tests after the first test failure it encounters. Corresponding "after each" and "after all" hooks are executed for potential cleanup. --bail does _not_ imply --exit.# --CHECK-LEAKS
Use this option to have Mocha check for global variables that are leaked while running tests. Specify globals that are acceptable via the --global option (for example: --check-leaks --global jQuery--global MyLib).
# --COMPILERS
> _--compilers was removed in v6.0.0. See further explanation and> workarounds
> ._
# --EXIT
> _Updated in v4.0.0._ TL;DR: If your tests hang after an upgrade to Mocha v4.0.0 or newer, use --exit for a quick (though not necessarily recommended) fix. _Prior to_ version v4.0.0, _by default_, Mocha would force its own process to exit once it was finished executing all tests. This behavior enables a set of potential problems; it's indicative of tests (or fixtures, harnesses, code under test, etc.) which don't clean up after themselves properly. Ultimately, "dirty" tests can (but not always) lead to _false positive_ or _false negative_ results. "Hanging" most often manifests itself if a server is still listening on a port, or a socket is still open, etc. It can also be something like a runaway setInterval(), or even an errant Promise that neverfulfilled.
The _default behavior_ in v4.0.0 (and newer) is --no-exit, where previously it was --exit. THE EASIEST WAY TO "FIX" THE ISSUE IS TO SIMPLY PASS --EXIT TO THE MOCHA PROCESS. It _can_ be time-consuming to debug — because it's not always obvious where the problem is — but it _is_ recommended todo so.
To ensure your tests aren't leaving messes around, here are some ideasto get started:
* See the Node.js guide to debugging * Use the new async_hooksAPI (example )
* Try something like wtfnode * Use .only until you find the test that causes Mocha to hang# --FORBID-ONLY
Enforce a rule that tests may not be exclusive (use of e.g., describe.only() or it.only() is disallowed). --forbid-only causes Mocha to fail when an exclusive ("only'd") test or suite is encountered, and it will abort further test execution.# --FORBID-PENDING
Enforce a rule that tests may not be skipped (use of e.g., describe.skip(), it.skip(), or this.skip() anywhere is disallowed). --forbid-pending causes Mocha to fail when a skipped ("pending") test or suite is encountered, and it will abort further test execution. # --GLOBAL> alias._
Define a global variable name. For example, suppose your app deliberately exposes a global named app and YUI, you may want to add --global app --global YUI. --global accepts wildcards. You could do --global '*bar' and it would match foobar, barbar, etc. You can also simply pass in '*' to ignoreall globals.
--global can accept a comma-delimited list; --global app,YUI is equivalent to --global app --global YUI. By using this option in conjunction with --check-leaks, you can specify a whitelist of known global variables that you _expect_ to leak into global scope.# --RETRIES
Retries failed tests n times. Mocha does not retry test failures by default. # --SLOW marked as failed.
To override you may pass the timeout in milliseconds, or a value with the s suffix, e.g., --timeout 2s and --timeout 2000 are equivalent. To disable timeouts, use --no-timeout. Note: synchronous (blocking) tests are also bound by the timeout, but they will not complete until the code stops blocking. Infinite loops will still be infinite loops! # --UIbdd.
# --COLOR, -C, --COLORS > _Updated in v6.0.0. --colors is now an alias for --color._ "Force" color output to be enabled, or alternatively force it to be disabled via --no-color. By default, Mocha uses the supports-colormodule to decide.
In some cases, color output will be explicitly suppressed by certain reporters outputting in a machine-readable format.# --DIFF
When possible, show the difference between expected and actual values when an assertion failure is encountered. This flag is unusual in that it DEFAULTS TO TRUE; use --no-diff to suppress Mocha's own diff output. Some assertion libraries will supply their own diffs, in which case Mocha's will not be used, regardless of the default value. Mocha's own diff output does not conform to any known standards, and is designed to be human-readable.# --FULL-TRACE
Enable "full" stack traces. By default, Mocha attempts to distill stack traces into less noisy (though still useful) output. This flag is helpful when debugging a suspected issue within Mocha orNode.js itself.
# --GROWL, -G
Enable Growl (or OS-level notifications whereavailable).
Requires extra software to be installed; see the growl module's docs for more information.# --INLINE-DIFFS
Enable "inline" diffs, an alternative output for diffing strings. Useful when working with large strings. Does nothing if an assertion library supplies its own diff output. # --REPORTERDetails
Copyright © 2024 ArchiveBay.com. All rights reserved. Terms of Use | Privacy Policy | DMCA | 2021 | Feedback | Advertising | RSS 2.0