Assertion Styles

This section of the guide introduces you to the three different assertion styles that you may use in your testing environment. Once you have made your selection, it is recommended that you look at the API Documentation for your selected style.

Assert

View full Assert API

The assert style is exposed through assert interface. This provides the classic assert-dot notation, similiar to that packaged with node.js. This assert module, however, provides several additional tests and is browser compatible. 

var assert = require('chai').assert
  , foo = 'bar'
  , beverages = { tea: [ 'chai', 'matcha', 'oolong' ] };

assert.typeOf(foo, 'string', 'foo is a string');
assert.equal(foo, 'bar', 'foo equal `bar`');
assert.lengthOf(foo, 3, 'foo`s value has a length of 3');
assert.lengthOf(beverages.tea, 3, 'beverages has 3 types of tea');

In all cases, the assert style allows you to include an optional message as the last parameter in the assert statement. These will be included in the error messages should your assertion not pass.

BDD

View full BDD API

The BDD style comes in two flavors: expect and should. Both use the same chainable language to construct assertions, but they differ in the how an assertion is initially constructed. In the case of should, there are also some caveats and additional tools to overcome the caveats.

Expect

The BDD style is exposed through expect or should interfaces. In both scenarios, you chain together natural language assertions. 

var expect = require('chai').expect
  , foo = 'bar'
  , beverages = { tea: [ 'chai', 'matcha', 'oolong' ] };

expect(foo).to.be.a('string');
expect(foo).to.equal('bar');
expect(foo).to.have.length(3);
expect(beverages).to.have.property('tea').with.length(3);

Expect also allows you to include arbitrary messages to prepend to any failed assertions that might occur. 

var answer = 43;

// AssertionError: expected 43 to equal 42.
expect(answer).to.equal(42); 

// AssertionError: topic [answer]: expected 43 to equal 42.
expect(answer, 'topic [answer]').to.equal(42);

This comes in handy when being used with non-descript topics such as booleans or numbers.

Should

The should style allows for the same chainable assertions as the expect interface, however it extends each object with a should property to start your chain. This style has some issues when used Internet Explorer, so be aware of browser compatibility. 

var should = require('chai').should() //actually call the the function
  , foo = 'bar'
  , beverages = { tea: [ 'chai', 'matcha', 'oolong' ] };

foo.should.be.a('string');
foo.should.equal('bar');
foo.should.have.length(3);
beverages.should.have.property('tea').with.length(3);

Differences

First of all, notice that the expect require is just a reference to the expect function, whereas with the should require, the function is being executed. 

var chai = require('chai')
  , expect = chai.expect
  , should = chai.should();

The expect interface provides a function as a starting point for chaining your language assertions. It works on node.js and in all browsers.

The should interface extends Object.prototype to provide a single getter as the starting point for your language assertions. It works on node.js and in all browsers except Internet Explorer.

Should Extras

Given that should works by extending Object.prototype, there are some scenarios where should will not work. Mainly, if you are trying to check the existence of an object. Take the following psuedocode: 

db.get(1234, function (err, doc) {
  // we expect error to not exist
  // we expect doc to exist and be an object
});

Given that err should be null or undefined, err.should.not.exist is not a valid statement as undefined and null haven't been extended with a should chain starter. As such, the appropriate few assertions for this scenario are as follows: 

var should = require('chai').should();
db.get(1234, function (err, doc) {
  should.not.exist(err);
  should.exist(doc);
  doc.should.be.an('object');
});

Provided you assigned should to a var, you have access to several quick helpers to keep you out of trouble when using should.

  • should.exist
  • should.not.exist
  • should.equal
  • should.not.equal
  • should.Throw
  • should.not.Throw

Configuration

By default, Chai does not show stack traces upon an AssertionError. This can be changed by modifying the includeStack parameter for chai.Assertion. For example: 

var chai = require('chai');
chai.Assertion.includeStack = true; // defaults to false