Intive Blog

Unit Testing on Frontend – Part 2: Karma

In our first article on Frontend Unitary Testing on this blog, we tackled the basic concepts and we introduced Jasmine. The code, although it was not eventually as good as we wanted, helped us as a kick-off. We will here develop on the same functionality, but this time with a revamped code.

Furthermore, we will introduce Karma and we will see how to test our code in a much-closer-to-real environment. As on our first article, we have a tag in the repository which allows us to start with the code ready, namely 0.0.2:

Setting up Karma

To get started, we need to set up Karma and all dependencies we will ultimately need. If we are “standing on” on the code of the first version, we can run the following from console and in the root of our project:

Conversely, if we are “standing on” the new tag, we can perform the installation through package.json which is already in the project with:

When the file path is prompted we can enter app/*.js y spec/*.spec.js. Then, when the browser is prompted, we will choose PhamtomJS instead of Chrome. Mind you, if we choose Chrome, tests should successfully work anyway.

To run tests, we can run karma start --single-run, however, if we want to save some time, we can edit the file package.json and add a script. In our case, it would be sort of an alias, a very powerful tool, like the ones in scripts npm.


What is Karma?

So far so good, isn’t it? We set up Karma, run tests, we check everything is ok, but… what is Karma? what does it do? Briefly, it is accountable for running tests. It is a test runner.

So, what does Jasmine do? This was an uncertainty which came up as we started developing. We built the tests with Jasmine. Karma, conversely, takes them and put them to work within a browser and shows us the results. A very interesting feature is that the browser running the tests can be one without a graphic interface, without windows. That is PhantomJS.

It is not the same to run javascript code “in the air” as to run it within a controlled environment.

Initially, we had all the code mixed up: the logic of the application together with the tests. It was something abstract, completely imaginary. On the one hand, because we did not expect that code to reach productive environments, since users are not interested in our tests and besides, we are saving some transference/bandwidth. On the other hand, we want them by separate since each performs completely different tasks.

Regarding this, with all being separated, Karma is in charge of “putting it together” and running the tests within the browser we choose to later show us the results.


Separation of concepts

Moving from the previous code, we will go modifying it as necessary along the way. Checking the history of commits, you will be able to see the evolution of the code and the project. We will try to make something similar to TDD (Test Driven Development).

First, we want the code of tests and the one of the application to be in different places. Aesthetically speaking, it will look fancier, also.

To do this, we just need to take our calculator and provide it with its own file. For this tutorial, we have created an app folder containing all the logic of the application. There we will create our calculator in the file calc.js.

So far, we have only moved a portion of the code and installed dependencies. If we ran the tests, we would see everything keeps working ok.


MVC (Model View Controller)

Now that we have our calculator, we need to use it. For this we need a view, which will be our index.html and a controller that connects the view with our calculator. We could first do the tests, but it actually makes no sense to transform something which is already complex into something even more complex. So we will leave TDD for further on.

Let’s see:

It is about a very simple code, in which the controller features the functions: Add, subtract, multiply and divide. Each of these operations is called from buttons which are in different divs. Our aim is not to develop from a calculator but to understand unitary testing on Frontend. To test our view, we need several elements within the html.

Our controller is not complex either. We have an object CalcController with init methods (which does not do much) Add, subtract, multiply and divide and calWithUserInput. The latter is the one having all the magic: it searches the user- entered values in the html and then calls the calculator to perform the operation.

Maybe it is not totally visible, but the call to our calculator is on this line result = calc[operationName](a, b);.



With this release we are paving the way for a cleaner, more testable code. We have separated the components and generated a functional code which can be used with any browser. Tests are even performed on a browser with no windows, modifiable, to make it “normal”.

But this is not everything. On our next release, we will generate the necessary tests to check our view and controller, we will perform integration tests and introduce the concept of spies and see what is better for testing at each stage. So far, anyway, it has been enough. Do not be anxious!

Fernando Lescano

He is one of our Tech Leaders and has been a developer at intive – FDV since March 2015. In the company, he works with technologies like Javascript ( NodeJS, AngularJS, MongoDB, Jquery, etc.), Python (Django), Java and PHP. He also takes part in the Frontend Team. He defines himself as “passionate about software development, but with many other interests”. Since December 2015 he has managed the development and maintenance of Java and of new JavaScript components (AngularJS). He is received a degree as a University Technician with a focus on software development and information technology from the Universidad Provincial de Ezeiza.

Add comment