Behavioral Driven Development and Test Driven Development utilizing Chai.js

Writing quality tests ensures that code will respond in the way that it was intended to. The process of writing tests keeps projects on track and ensures that quality code is produced, with the expected outcomes being the end result.

Test Driven Development (TDD) vs Behavioral Driven Development (BDD)

There are two common trains of thought when it comes to writing tests: behavioral driven development (BDD), and test driven development(TDD). When implementing TDD, automated test cases are built at the beginning of a project and tested against code features that are available (since this is written before anything is built, there aren’t any features written). Inevitably, because theres no code to test against, the tests will fail. Code is then written to satisfy the test’s requirements ran against the built out tests until they pass and refactored for optimization after that.

Test Driven Development Cycle

BDD styled testing, takes into consideration the end users’ behavior before writing any code or tests — meaning that an end product is already established before any test code is written. This is typically written out in plain English (think user stories) and is easier for larger teams, that include more than just devs, to understand. This plain English is then converted to scripts that are ran against code. From here, the process is much the same as TDD, in that the code fails initially because no code has been written. Code is then written, tested, and checked against the scripts written until it passes.

Behavioral Driven Development Cycle

At the base level, BDD defines the behavior of an application in relation to the end user, while TDD focuses on execution of functionality.

What is Chai?

Chai is an assertion library (tool to verify that things are correct) that can be used with any Javascript testing framework. Chai provides syntax/style for both TDD and BDD that is pretty straightforward to get started with.

BDD with Chai assert library Syntax (expect and should)

BDD-styled testing in Chai chains together understandable English to write tests that are extremely easy to jump in and understand. They come in two forms: expect and should.

//EXPECT STYLING/SYNTAX
let 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.lengthOf(3);
expect(beverages).to.have.property(‘tea’).with.lengthOf(3);
//SHOULD STYLING/SYNTAX
let should = require(‘chai’).should() //actually call the function,
    foo = ‘bar’,
    beverages = { tea: [ ‘chai’, ‘matcha’, ‘oolong’ ] };
foo.should.be.a(‘string’);
foo.should.equal(‘bar’);
foo.should.have.lengthOf(3);
beverages.should.have.property(‘tea’).with.lengthOf(3);

As you can see, expect and should styling are very readable and explicit in what each test’s expectations are. With this knowledge, writing concise, readable and understandable testing becomes easier to maintain. Take a look at the documentation on writing more BDD style testing here.

Chai assert library style

// ASSERT STYLING/SYNTAX
let assert = require(‘chai’).assert,
   foo = ‘bar’,
   beverages = { tea: [ ‘chai’, ‘matcha’, ‘oolong’ ] };
assert.typeOf(foo, ‘string’); // without optional message
assert.typeOf(foo, ‘string’, ‘foo is a string’); // with optional message
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’);

This testing doesn’t lend the same amount of readability that the expect and should styles do, making it a bit more difficult to hop in. Check out more on assert styling here.