This month I decided to sail into the vast sea of open source. This is part of my program as a Nearsoft Academy intern.

We had to choose two Open Source projects that are widely used and accepted by the community and it is also used by a Nearsoft customer. Then we have to analyze them and try to figure out how their insides work.

For this particular task, I chose Karma and Mocha.js.


First, I needed to understand what Karma is.

According to its creator, Karma is a tool which spawns a web server that executes source code against test code for each client connected to it. A client is a web browser (e.g., Chrome, Firefox) or a web app. The results for each test are examined and displayed via the command line.

Karma executes Mocha test suites in different web browsers. It has two main parts,

  • The server part runs on Node.js
  • The client runs in a web browser

The server component is the master part of the system. It can run on the developer’s machine so it has fast access to all project sources and tests. This is the way I used it.

The client part of the system is where all the tests are actually executed. It is a web app that communicates with the server through and executes the tests in an Iframe.

The communication between client and server is implemented on top of, which provides an event-based communication channel.

How the Karma Server is Constructed

Here is an example,

When the server is constructed it calls this function,

Magic! Your server is now running.

How Does Karma Help You Debug?

Once the server starts, all the clients defined in the Karma.config file are called one by one,

Calling browser.start will open a session on each browser using localhost and whatever port you indicated on the Karma.config file,

This is what the resulting login session looks like,


Now the server is running, the browsers are ready, and the test are executed automagically.


Mocha is a framework to create test suites. It makes asynchronous testing simple and fun.

What I wanted to learn about Mocha is how it can actually run a series of tests using the it function.

Then describe defines an test suite. Within the suite, the it function describes a test-case,

For each it in the “Simple Testing” suite, we attach a addTest() function,

When all test suites are ready, Mocha iterates over and executes each it within it. The results are thrown in the console.

There are times when we want to test an asynchronous function and we don’t know when it is going to finish. In this case, we use the, to me, enigmatic done function,

When an asynchronous function is called we specify it has ended by calling the done. If the process has’t come back “done” or failed an assertion in a certain amount of time (the default is 2000ms), then the test fails.

As you can see, done has lost every drop of mystery.

The Reporter Feature

A reporter shows you the results of the tests. They come in various forms and colors, literally.


Mocha reporters adjust to the terminal window. The default reporter, provided by Mocha is spec.js.

For example, here is the default behavior when a test passes,

The reporter architecture is very flexible. The only requirement is that they let the developer know if a suite is failing or passing.

And Finally …

I hope you had fun learning about these two bigs because I really did while dismembering them.

I really aim to achieve this month’s objectives and become a sailor in the vast sea of Open Source.