Test driven development

Behavioral Driven Development (BDD) is an approach to building software. It helps to start your writing process with a brainstorm or an outline so that you always have an idea where you are headed. It’s like creating a plan before you write your program. With BDD you write the test first and code second. It’s the behavioral part of programming. It describes the expected behavior of the test.

The test can be done manually or automatically, here are some of the problems of using manual testing and advantages of automated testing.

Problems with Manual Testing

  1. Difficult to write effectively
  2. Impacts on the actual program
  3. Very hard to read
  4. Only a temporary fix

Automated Testing

  1. Results displayed in an informative way
  2. Test files are separate from the real code
  3. The output is easy to read and understand
  4. Guarantees code works as expected
  5. Instantly see if anything has broken when making changes

Different types of testing

  1. Unit testing: For code that has a clear specific purpose for their individual functions in the program. The unit test can then call the function without needing to run the entire application. To make sure that the application behaves as we expect. It helps us write better code and grow as developers as soon as you start using them.
  2. Integration test: This is used when you add new code to pre-existing code to make sure that the pieces work together without breaking.
  3. End-to-End test: This is done a few times during production. It is very expensive and time-consuming.


Test-driven development (TDD) on the other hand is a software development process that relies on the repetition of a very short development cycle: Requirements are turned into very specific test cases, then the software is improved to pass the new tests, only. This is opposed to software development that allows software to be added that is not proven to meet requirements. The development cycle is called red, green, refactor. It involves these three step process;

Test Driven Development


  • Red: The red error indicates failing test, when it does not meet expectation. Write the test even though they will fail
  • Green: indicate that code passes the test. Write the easiest code to pass the test.
  • Refactor: is the process of improving your code. Then go back and improve the passing code. Repeat the process again…

To begin testing first;

Install any of the test packages e.g.: npm install chai –save –dev

Chai is an expectation library. It throws an error when an expectation is not met.

Working with Mocha and Chai

Npm install –save –dev mocha chai

Ensure all tests are in one directory, because it makes it;

  • Easy to import code from other files;
  • Easy to organize our test
  • Easy to find a test file after seeing its output in the console
  • The directory should be named test

A test suite is a block of unit tests that are all closely related because they test the same function or they test part of a code base using describe.

Describe is a function that takes two arguments: a string and another function.

E.g. var expect = require (‘chai’).expect;

            Describe (‘mocha’, function () {

                        It (‘should run our test using npm’, function () {

                                    Expect (true).to.be.ok;



Each individual unit test is sometimes called a spec by containing them in a function.

 It: “It’ is similar to ‘describe’. It describes the particular behavior this unit test is responsible for.

Expectation: gives a separate state condition for a test to count as passing otherwise it throws an error.

Ok: is an assertion value for chai. It tells whether an assertion is true, i.e. any value besides not a number, undefined, false, an empty string or zero. Any value that will satisfy an if condition.

Set up Phase

This is the part of our test where we set up conditions for testing. This can be divided into two in mocha: before and beforeEach.

After block takes one function that will run at the end of the test suites when every spec has finished. Just like after, afterEach takes one function that runs at the end of the test spec.

Writing tests first as an outline

  • Write test retroactively
  • Only focus on what a function does
  • Write simpler expectations first
  • Get simple tests to pass before writing more involved ones

Edge cases: These are situations your function might end up in, but it isn’t how the function will work.

Other functions of Mocha

  • To show only failing test use mocha –reporter min
  • Marked down reporter shows how the code works  mocha --reporter markdown
  • Reporter flag  mocha –reporter nyan
  • Watch flag helps to continue running the test each time you make changes without typing npm test. E.g. mocha –watch.

In conclusion, cultivate the habit of writing tests, they save you development time and help you detect errors easily while developing. For more details on NPM, chai and Mocha, checkout the documentation. Thanks for reading. If you find it educative enough don’t forget to give it a clap.


Glory Agatevure is a software developer at KodeHauz. She's skilled in Mobile App Development.