Chai assertion

What is assertion?

An assertion is a form of validation statement in the programming language which verifies if the given result or outcome is correct and valid. The purpose of using assertions in test automation is to identify if the given outcome of a particular scenario is equal to the actual outcome. In other words, checking the expected vs actual result for a test. If they are not the same then the test would fail with the failure message shown after execution.

What is chai assertion?

chai assertion

Chai Assertion is a JS library for TDD and BDD that provides assertions for comparing the actual vs expected values for a test. It is one of the most popular assertion libraries out there and is usually goes together with the Mocha testing framework. It can be integrated with any Javascript testing framework and it has a couple of main interfaces that are used for asserting and checking the validity of an output.

How do you install chai assertion library?

Chai assertion library is available for Node.js and the browser for any testing framework:

  • Chai package is available by using npm: npm install chai
  • Including chai in the script tag src=”chai.js” type=”text/javascript

At the moment, chai assertion library supports multiple browser versions:

  • IE 9+
  • Chrome 7+
  • FireFox 4+
  • Safari 5+

What assertion styles are included in Chai assertion library?

Three different assertion styles are included as part of the Chai assertion library:

  • Should
  • Expect
  • Assert


The first BDD style should allow an assertion that is chainable by extending each result with a should keyword in order to start the chain assertion. It extends the Object.prototype and it allows an easier, natural, and more readable way of creating an assertion and understanding its concept.

However, this interface style is rarely used in real life application since it has some browser compatibility issues.

Examples of assertions using the should() interface:

const test = 'test value''string')
test.should.equal(test value)

From the example above, we can easily understand that a test variable is a string, has 10 characters long, and is equal to the value specified at the beginning.


The BDD style expect is used for chainable assertions and it is easy to read, write, and understand while writing a set of assertions. The good thing about using this style is that many assertions can be written by using only one expect chain even though that is not often a recommended way.

Let’s use the same example as above:

const test = 'test value'
expect(test).to.equal(test value)

More preferred style compared to the should() style. On the left side, we have the actual value which in this case is test, and on the right side, we are trying to validate that the element is of some type or has some specific length or it is maybe equal to something else.


This style is exposed by the assert interface and it allows you to include and optional message in the assert statement as a last parameter. It is not chainable as expect or should style. As a result we would have this:

const test = 'test value'
assert.typeOf(test, 'string', 'It is of type:string')
assert.lengthOf(test, 10, 'The variable has length of 10')
assert.equal(test, 'test value', 'Checking the equality of the values')

All of the asserts have the same concept where we are passing the variable we want to check, then we pass the value we want to compare with and as a last and optional argument, we write some message which will be included in the console when the tests fail.

How do you run a chai test?

By now you have a clear picture of how to write Chai assertion. We will look at a simple example of chai assertions used in practice.

Let’s take Dummy Rest API Example. We will use the API endpoint: which we getting the data of all employees. In Postman, that would look like this:

Chai assertion

We’re fetching a list of employees in a JSON format. But what if we want to run a collection of tests as a suite or maybe we want to have some checks at the end of the tests which will give us the validation of the result? Notice the Tests tab? In there, we can write tests and we will use Chai assertion library to validate the JSON.

Let’s write some validations:

const employees = pm.response.json(); const assert = require('chai').assert const should = require('chai').should()

pm.test("Check Status Code & not null response", () => {     pm.expect(pm.response.code).to.eql(200);     pm.response.status.should.equal("OK");     assert.isNotEmpty(employees);});

pm.test("Check status and message value", () => {     pm.expect(employees.status).to.eql("success");     employees.message.should.equal("Successfully! All records has been fetched.");});

pm.test("Check list of employees", () => {     const data =>;    assert.isNotNull(;     assert.isNumber( data.employee_name.should.have.lengthOf(11);'number');
pm.expect(data.employee_age).to.eql(61);     pm.expect(data.profile_image).empty;});

Chari assertion

As you can see from the example above, we have three tests. We’re sending a GET employees request and as a result, we have a successful employee list response. At first, we define the response as JSON and we store it in a variable. Then we define the should and assert statements (expect is included by default in Postman).

In the first test, we’re using the expect keyword for checking the status code and using the assert keyword to validate that the JSON response is not null

The second test checks for two of the response fields by using the expect and should keywords. The last test is basically getting the fields in the data list of objects for an employee. We’re using all of the Chai assertions for different checks like not null value, length of the value, equality, or type of value.

Last few words

There is no such thing as using the correct assertions for your test. Any assertion that can validate the outcome successfully can be used depending on the complexity of the system. Chai assertion is just another library that makes the assertion process a lot easier, readable, and understandable. Which style would you use depends on the AUT, requirements, and test automation strategy.

Share this Post

Latest Posts

Vladimir Simonovski
Vladimir Simonovski

Software Automation Engineer with almost 5 years of experience. Involved in many QA activities for the insurance and banking platforms. Follow QAMIND on Twitter and LinkedIn to get fresh content around Software Testing.