Monthly Archives: February 2015

Variable hoisting in Javascript

Variable Hoisting in Javascript
If you are coming from C# or Java background into C#, you might find scopes as very strange in java script. In this post, we will be trying to understand the scopes in C#. Specially, how javascript uses hoisting to for these out-of-ordinary scopes.

In other programming languages, we limit the scopes by introducing some explicit or implicit BEGIN and END markers (curly braces {} in C# / Java & indentation in Python). Since syntactically, javascript is Cish, it also has those curly braces. If you are coming from the background of C’ish languages, you might assume that they would limit the scope.

Let’s see the following code:

Here we have added a variable internaVar. We have tried limiting scope of the variable by keeping them inside the statement block. We are trying to access the block’s local variable outside the statement block. You might assume that this should fail at compile time. Well we don’t have that luxury in javascript. Actually the code still runs. If you add a breakpoint in chrome, you might see something like this:

hoistedInternalVar

The variable not only has it’s lifetime by maintaining the value assigned in the scope, it also has visibility outside the statement scope. So what is going on? Actually, this is a feature of java script called Variable hoisting, where it finds all declarations within a function and move them at them at the start of function. Since javascript has caused the declaration of internalVar in the function scope, it is available throughout the function, hence maintaining its lifetime and visibility.

How to avoid this?
In order to avoid this, we can use javascript lint library (jshint). Let’s move this code in a javascript (lintEx.js) file first, and remove all document.writeln methods. Linting allows us to identify the bad parts of javascript and gives suggestions to avoid the unexpected.

Now let’s install node module for jshint using node package manager (npm).

npm_install_jshint

As we run the jshint tool for our javascript, it recognizes the issue and notifies us to fix the usage of a local variable out of our intended scope.

jshint_scope

Best Practice
Since javascript doesn’t recognize a local scope, I think we should avoid declarations in a local scope. It’s like assembly where we have separate data segments. We can do all declarations in the beginning of the function and use the variables throughout the function. This is obviously different than our regular use of variables where we like to declare them in the least possible scope.

Unit testing Javascript using Karma & Jasmine

In this post, we will be trying to understand how we can unit test javascript code using Karma and Jasmine.

Karma

Let’s first install Karma. It is available as a node package, so we can use npm to install it.

mehrofiq

Here we are using Karma for running our unit tests. Karma launches a web server that executes the test code against connected web browsers. The tests can run manually or it can also watch files, matching certain grep pattern. After running tests, it can show the results in the command line console. You can read more about karma here.

karma_web

Jasmine

We will be writing our tests using Jasmine for writing unit tests. It provides an easy to use framework for introducing javascript tests.

install-karma-jasmine

Further info about Jasmine’s unit testing features can be found here:
jasmine_further_info

We also need to add support to run it in a browser. Here we are installing chrome launcher for karma.

karma-chrome-launcher

After installing the above packages, you should have a folder created node_modules containing the following packages.

installed-packages

npm – Node Package Manager

Here we are using npm to install these node packages. If you don’t have it installed already, you can get it directly from npmjs.com.

npm-install

Configuring Karma

Now we need to configure karma to run the unit tests. This can be used to automatically set karma to watch files matching certain grep pattern. Here we want to watch all javascript files in the current folder. We will be using jasmine and would be using chrome to run our tests.

configuring_karma

After the above configuration, you should have the following file created in your folder.

karma_conf_js

Writing Unit Tests

Let’s see below how easy is to write our first unit tests. We need to group the tests in describe blocks. Each test is blocked in it blocks. The assertions are added using various expect features provided by the framework.

Running Tests

Before running the tests, we first need to launch karma. If you have followed the above steps, it should also launch chrome and connect it to the karma.

karma_start

Now the server is continuously watching the folder. It would run the test if a new javascript file is added to the folder or an existing file is updated.

test_run

Zindabad!