chai v4.0.0 Release Notes

Release Date: 2017-05-26 // almost 7 years ago
  • 4.0.0

    4.0 has been a huge undertaking by the chai community! A lot has changed to ensure Chai 4 is a stable, reliable, well documented codebase. Here are just some of the major improvements:

    📚 almost all documentation has been rewritten, with detailed instructions on how assertions work, which flags they can be combined with and the best practices for how to use them.

    🚀 deep equality has been rewritten from the ground up to support ES6 types like Map and Set, and better support existing types. It is now also much, much faster than before and allows us to bring some great improvements in upcoming releases.

    we have made sure the deep flag now only ever does deep equality. Beforehand, it would sometimes also be used to test nested properties (for example expect(foo).to.have.deep.property('bar.baz'). For nested assertions, please now use the .nested flag.

    0️⃣ many assertions have become more strict, which means you get better error messages explaining where things have gone wrong. For the most part, this wont mean error messages where there weren't error messages before, but it will mean better error messages to replace the, sometimes cryptic, default TypeError messages.

    📚 we've added detections and helpful error messages for common mistakes and typos. The error messages will, in some cases, point you to documentation or in other cases suggest alternatives. These messages will continue to be improved in future releases, so let us know if you have any suggestions!

    💥 Breaking Changes

    We no longer support Node v0.10 and v0.12 (since their LTS has ended) (PRs: #816, #901)

    Instead of allowing the user to write the path of a property, now the deep flag performs a deep equality comparison when used with the .property assertion.
    If you want the old behavior of using the dot or bracket notation to denote the property you want to assert against you can use the new .nested flag. (Related Issues: #745, #743, PRs: #758, #757)

    const obj = {a: 1};// The `.deep` flag now does deep equality comparisonsexpect({foo: obj}).to.have.deep.property('foo', {a: 1});// Use the `nested` flag if you want to assert against a nested property using the bracket or dot notationexpect({foo: obj}).to.have.nested.property('foo.a', 1);// You can also use both flags combinedconst obj2 = {a: {b: 2}};expect({foo: obj2}).to.have.deep.nested.property('foo.a', {b: 2});
    

    Please notice that the old methods which used the old behavior of the deep flag on the assert interface have been renamed. They all have had the deep word changed by the nested word. If you want to know more about this please take a look at #757.

    Previously, expect(obj).not.property(name, val) would throw an Error if obj didn't have a property named name. This change causes the assertion to pass instead.
    The assert.propertyNotVal and assert.deepPropertyNotVal assertions were renamed to assert.notPropertyVal and assert.notDeepPropertyVal, respectively. (Related Issues: #16, #743, #758)

    👀 You can now use the deep flag for the .include assertion in order to perform a deep equality check to see if something is included on the target.
    Previously, .include was using strict equality (===) for non-negated property inclusion, but deep equality for negated property inclusion and array inclusion.
    This change causes the .include assertion to always use strict equality unless the deep flag is set.
    Please take a look at this comment if you want to know more about it. (Related Issues: #743, PRs: #760, #761)

    const obj = {a: 1};expect([obj]).to.deep.include({a:1});expect({foo: obj}).to.deep.include({foo: {a:1}});
    

    🛠 Fix unstable behavior of the NaN assertion. Now we use the suggested ES6 implementation.
    The new implementation is now more correct, strict and simple. While the old one threw false positives, the new implementation only checks if something is NaN (or not if the .not flag is used) and nothing else. (Related Issues: #498, #682, #681, PRs: #508)

    // Only `NaN` will be considered to be `NaN` and nothing elseexpect(NaN).to.be.NaN;// Anything that is not `NaN` cannot be considered as `NaN`expect('randomString').not.to.be.NaN;expect(true).not.to.be.NaN;expect({}).not.to.be.NaN;expect(4).not.to.be.NaN;
    

    The Typed Array types are now truncated if they're too long (in this case, if they exceed the truncateThreshold value on the config). (Related Issues: #441, PRs: #576)

    var arr = [];for (var i = 1; i \<= 1000; i++) { arr.push(i); }// The assertion below will truncate the diff shown and the enormous typed array will be shown as:// [1, 2, 3, 4, 5, 6, 7, 8, 9, 10, ...] instead of printing the whole typed arraychai.expect(new Float32Array(100)).to.equal(1);
    

    The assertions: within, above, least, below, most, increase, decrease will throw an error if the assertion's target or arguments are not numbers. (Related Issues: #691, PRs: #692, #796)

    // These will throw errors, for example:expect(null).to.be.within(0, 1);expect(null).to.be.above(10);expect(null).to.be.at.least(20);expect(null).to.be.below(20);expect(null).to.be.at.most(20);expect(null).to.increase.by(20);expect(null).to.decrease.by(20);// This will not:expect('string').to.have.a.lengthOf.at.least(3);
    

    Previously, expect(obj).not.ownProperty(name, val) would throw an Error if obj didn't have an own property (non-inherited) named name. This change causes the assertion to pass instead. (Related Issues: #795, #, PRs: #744, #810)*

    expect({ foo: 'baz' }).to.not.have.own.property('quux', 'baz');
    

    The .empty assertion will now throw when it is passed non-string primitives and functions (PRs: #763, #812)

    // These will throw TypeErrors:expect(Symbol()).to.be.empty;expect(function() {}).to.be.empty;expect(true).to.be.empty;expect(1).to.be.empty
    

    Assertion subject (obj) changes when using ownProperty or own.property and thus enables chaining. (Related Issues: #281, PRs: #641)

    expect({val: 20}).to.have.own.property('val').above(10);
    

    The .change, .increase, and .decrease assertions changed from chainable method assertions to method assertions. They don't have any chaining behavior, and there's no generic semantic benefit to chaining them. (Related Issues: #917, PRs: #925)

    // This will not work anymore because there is no benefit to chaining these assertions:
    expect(function() {}).to.change.by(2)
    expect(function() {}).to.increase.by(2)
    expect(function() {}).to.decrease.by(2)
    

    The utils (second argument passed to the chai.use callback function) no longer exports the getPathValue function. If you want to use that please use the pathval module, which is what chai uses internally now. (Related Issues: #457, #737, PRs: #830)

    🔌 (For plugin authors) Throw when calling _superon overwriteMethodif the method being overwritten is undefined.
    Currently if the method you are trying to overwrite is not defined and your new method calls _super it will throw an Error.(Related Issues: #467, PRs: #528)
    Before this change, calling _super would simply return this.

    // Considering the method `imaginaryMethod` does not exist, this would throw an error for example:chai.use(function (chai, utilities) { chai.Assertion.overwriteMethod('imaginaryMethod', function (\_super) { return function () { \_super.apply(this, arguments); } }); });// This will throw an error since you are calling `_super` which should be a method (in this case, the overwritten assertion) that does not existexpect('anything').to.imaginaryMethod(); 
    

    🔌 (For plugin authors) Now showDiff is turned on by default whenever the showDiff flag is anything other than false.
    This issue will mostly affect plugin creators or anyone that made extensions to the core, since this affects the Assertion.assert method. (Related Issues: #574, PRs: #515)

    // Now whenever you call `Assertion.assert` with anything that is not false for the `showDiff` flag it will be true// The assertion error that was thrown will have the `showDiff` flag turned on since it was not passed to the `assert` methodtry { new chai.Assertion().assert( 'one' === 'two' , 'expected #{this} to equal #{exp}' , 'expected #{this} to not equal #{act}' , 'one' , 'two' ); } catch(e) { assert.isTrue(e.showDiff); }// The assertion error that was thrown will have the `showDiff` flag turned off since here we passed `false` explicitlytry { new chai.Assertion().assert( 'one' === 'two' , 'expected #{this} to equal #{exp}' , 'expected #{this} to not equal #{act}' , 'one' , 'two' , false ); } catch(e) { assert.isFalse(e.showDiff); }
    

    🆕 New Features

    Throw when non-existent property is read. (Related Issues: #407, #766 PRs: #721, #770)
    🏗 This is a potentially breaking change. Your build will fail if you have typos in your property assertions
    Before 4.x.x when using property assertions they would not throw an error if you wrote it incorrectly.
    The example below, for example, would pass:

    expect(true).to.be.ture; // Oops, typo, now Chai will throw an Error
    

    👍 Since this implementation depends on ES6 Proxies it will only work on platforms that support it.

    0️⃣ This property can be enabled (default) or disabled through the config.useProxy property, for example:

    chai.config.useProxy = false; // disable use of Proxy
    

    Add fix suggestions when accessing a nonexistent property in proxy mode. (Related Issues: #771, PRs: #782)
    When a nonexistent property is accessed in proxy mode, Chai will compute the levenshtein distance to all possible properties in order to suggest the best fix to the user.

    expect(false).to.be.fals; // Error: Invalid Chai property: fals. Did you mean "false"?expect('foo').to.be.undefind; // Error: Invalid Chai property: undefind. Did you mean "undefined"?// If the Levenshtein distance between the word and any Chai property is greater than 4, no fix will be suggestedexpect('foo').to.be.fdsakfdsafsagsadgagsdfasf // error thrown, no fix suggested
    

    When non-chainable methods (including overwritten non-chainable methods) are used incorrectly an error will be thrown with a helpful error message. (PRs: #789)

    expect(true).to.equal.true; // Invalid Chai property: equal.true. See docs for proper usage of "equal".
    

    ➕ Add a new configuration setting that describes which keys will be ignored when checking for non-existing properties on an assertion before throwing an error.
    Since this implementation depends on ES6 Proxies it will only work on platforms that support it. Also, if you disable config.useProxy, this setting will have no effect. (Related Issues: #765, PRs: #774)

    chai.config.proxyExcludedKeys.push('nonExistingProp');expect('my string').to.nonExistingProp; // This won't throw an error now
    

    Add script that registers should as a side-effect. (Related Issues: #594, #693 PRs: #604)

    // You can now write:import 'chai/should';// as opposed to:import {should} from 'chai';should();
    

    You can also register should via a mocha option: mocha --require chai/should.

    The change assertion accepts a function as object. (Related Issues: #544, PRs: #607)

    // Now you can also check if the return value of a function changes, for exampleassert.increases( someOperation, () =\> getSomething().length)
    

    You can also assert for a delta using the by assertion alongside the change, increase and decrease assertions. (Related Issues: #339, PRs: #621)

    // You can use `.by` to assert the amount you want something to changevar obj = { val: 10 };var increaseByTwo = function() { obj.val += 2 };var decreaseByTwo = function() { obj.val -= 2 };var increaseByThree = function() { obj.val += 3 };expect(increaseByThree).to.change(obj, 'val').by(3);expect(increaseByTwo).to.increase(obj, 'val').by(2);expect(decreaseByTwo).to.decrease(obj, 'val').by(2);// Please notice that if you want to assert something did change but not by some amount you need to use `.not` \*\*after\*\* the `change` related assertion// Take a look at the examples below:expect(increaseByThree).to.change(obj, 'val').but.not.by(5)expect(increaseByTwo).to.increase(obj, 'val').but.not.by(1)expect(decreaseByTwo).to.decrease(obj, 'val').but.not.by(1)
    
    • The .keys assertion can now operate on maps and sets. (Related Issues: #632, PRs: #633, #668)

      // The .keys assertion now works on maps and sets natively, like the examples below:expect(new Map([[{objKey: 'value'}, 'value'], [1, 2]])).to.contain.key({objKey: 'value'});expect(new Map([[{objKey: 'value'}, 'value'], [1, 2]])).to.contain.any.keys([{objKey: 'value'}, {anotherKey: 'anotherValue'}]);expect(new Map([['firstKey', 'firstValue'], [1, 2]])).to.contain.all.keys('firstKey', 1);expect(new Set([['foo', 'bar'], ['example', 1]])).to.have.any.keys('foo');// You can also use .deep when asserting agains Maps and Setsexpect(new Map([[{objKey: 'value'}, 'value'], [1, 2]])).to.contain.any.deep.keys([{objKey: 'value'}, {anotherKey: 'anotherValue'}]);expect(new Map([['firstKey', 'firstValue'], [1, 2]])).to.contain.all.deep.keys('firstKey', 1);expect(new Set([['foo', 'bar'], ['example', 1]])).to.have.any.deep.keys('foo');

    Add compatibility with strict mode. (Related Issues: #578, PRs: #665)

    // This means you can now run your code with the `--use_strict` flag on Node// If want to understand more about this please read the issue related to this change
    

    Add does and but as new no-op assertion. (Related Issues: #700, #339 PRs: #621, #701)

    // You can now write assertions forming phrases with these two new words:expect(increaseByThree).to.change(obj, 'val').but.not.by(5);expect(foobar).to.have.property("baz").which.does.not.have.property("thing");
    

    Allow use to be imported using new ES6 module syntax. (Related Issues: #718, PRs: #724)

    // You can now import `use` using the ES6 module syntax, like the example below:import sinonChai from "sinon-chai";import {expect, use} from "chai";use(sinonChai);
    

    You can also use require alongside the new ES6 destructuring feature:

    const sinonChai = require('sinon-chai');const {expect, use} = require("chai");use(sinonChai);
    

    Add ordered flag for members assertion. (Related Issues: #717, PRs: #728)

    // You can now use the `ordered` flag to assert the order of elements when using the `members` assertion:expect([1, 2, 3]).to.include.ordered.members([1, 2]); // This passesexpect([1, 2, 3]).to.include.ordered.members([2, 3]); // This will fail! Read the docs to know more.
    

    Add .own flag to .property assertion. It does the same thing as .ownProperty and cannot be used alongisde the new .nested flag. (Related Issues: #795, PRs: #810)

    expect({a: 1}).to.have.own.property('a');// The example below will thrown an Errorexpect({a: {b: 1}}).to.have.own.nested.property('a.b', 1);
    

    Add .deep support to .property assertion. (Related Issues: #795, PRs: #810)

    expect({ foo: { bar: 'baz' } }).to.have.deep.own.property('foo', { bar: 'baz' });expect({ foo: { bar: { baz: 'quux' } } }).to.have.deep.nested.property('foo.bar', { baz: 'quux' });
    

    The .empty assertion will now work with ES6 collections (PRs: #763, #812, #814)
    Please notice that this assertion will throw an error when it is passed a WeakMap or WeakSet.

    expect(new Set()).to.be.empty;expect(new Map()).to.be.empty;// The examples below will throw a TypeError:expect(new WeakSet()).to.be.empty;expect(new WeakMap()).to.be.empty;
    

    Add script that registers should as a side-effect. This change allows you to register should via a mocha option by using: mocha spec.js -r chai/register-should and also allows you to register the testing style globally. (Issues: #693, PRs: #868)

    require('chai/register-should'); // Using Should style
    

    Add script that registers assert as a side-effect. This change allows you to register assert via a mocha option by using: mocha spec.js -r chai/register-assert (Issues: #693, PRs: #868, #872)

    require('chai/register-assert'); // Using Assert style
    

    Add script that registers expect as a side-effect. This change allows you to register expect via a mocha option by using: mocha spec.js -r chai/register-expect (Issues: #693, PRs: #868, #872)

    require('chai/register-expect'); // Using Expect style
    

    When the length assertion is chained directly off of an uninvoked method, it references function's built-in length property instead of Chai's length assertion. This commit adds a guard to Chai methods to detect this problem and throw a helpful error message that advises the user on how to correct it. (Issues: #684, #841, PRs: #897)

    Allows the lockSsfi flag to be set when creating new Assertion. This flag controls whether or not the given ssfi flag should retain its current value, even as assertions are chained off of this object. This is usually set to true when creating a new assertion from within another assertion. It's also temporarily set to true before an overwritten assertion gets called by the overwriting assertion. (Issues: #878, #904, PRs: #922)

    // This will lock the stack stack function from this line on// The SSFI is the reference to the starting point for removing irrelevant frames from the stack tracenew Assertion(obj, msg, ssfi, true).to.have.property('length')
    

    The nestedInclude, deepNestedInclude, ownInclude and deepOwnInclude assertions and there negated pairs were added to the assert interface. (Issues: #905, PRs: #964)

    // '[]' and '.' in property names can be escaped using double backslashes.assert.nestedInclude({'.a': {'b': 'x'}}, {'\\.a.[b]': 'x'});assert.notNestedInclude({'.a': {'b': 'x'}}, {'\\.a.b': 'y'});assert.deepNestedInclude({a: {b: [{x: 1}]}}, {'a.b[0]': {x: 1}});assert.notDeepNestedInclude({a: {b: [{x: 1}]}}, {'a.b[0]': {y: 1}});assert.ownInclude({ a: 1 }, { a: 1 });assert.notOwnInclude({ a: 1 }, { b: 2 });assert.deepOwnInclude({a: {b: 2}}, {a: {b: 2}});assert.notDeepOwnInclude({a: {b: 2}}, {a: {c: 3}});
    

    🐛 Bug Fixes

    • Fix missing msg argument for change related assertions. (Related Issues: None, PRs: #606)
    • The addMethod function returns a new assertion with flags copied over instead of this. (Related Issues: #562, #684, #723, PRs: #642, #660)
    • Fix stacktraces for overwritten properties and methods. (Related Issues: #659, #661)
    • Fix bug when testing Symbol equality with should syntax. (Related Issues: #669, PRs: #672)
    • Fix bug when asserting some valid ES6 keys. (Related Issues: #674, PRs: #676)
    • Fix bug caused when custom inspect method is used and this method calls stylize. (PRs: #680)
    • Fix ownProperty on objects with no prototype. (Related Issues: #688, PRs: #689)
    • Fix swapped expected and actual results for the .members assertion. (Related Issues: #511, PRs: #702)
    • Fix same.members to properly handle duplicates by treating each one as a unique member. (Related Issues: #590, PRs: #739)
    • Fix deep.have.same.members() that was not printing a diff. (PRs: #509)
    • Diff will be shown for assert's equal and notEqual methods. (Related Issues: #790, PRs: #794)
    • The overwriteMethod, overwriteProperty, addChainableMethod, overwriteChainableMethod functions will return new assertion with flags copied over instead of this. (Related Issues: #562, #642, #791, PRs: #799)
    • Proxy-related implementation frames were showing up in the stack traces for failed property assertions. Now we remove them by setting the proxy getter (instead of the property getter) as the starting point to remove all implementation frames. (PRs: #884)
    • Negated keys assertions will now consider size of sets. (Related Issues: #919, PRs: #924)
    • Whenever passed something that is not an instance of a function, the instanceof assertion will now throw an error informing the user that he should pass a constructor to this assertion, but instead he has passed . (Related Issues: #893, PRs: #924)
    • Fix all issues on expect/should interfaces that were causing implementation frames to leak through. Also improve the internal Chai error test helper to validate stack traces. (Issues: #878, #904, PRs: #922)
    • This fixes custom messages not always being respected. (Issues: #922, #947, #904, PRs: #916, #923)
    • Fix PhantomJS 1.x incompatibility (Issues: #966, PRs: #890)