Jasmine and Karma


Let's talk about testing again, and will surely again in the future :) Last time I introduced the JavaScript Testing with Jasmine and we ran a few specs, however it seemed some how half baked - you were required to create a special page and open it in the browser to see the results. I you wanted to check in various browsers, you should have iterated the same procedure on each browser again and again.

This is not how we do things in 2014! We want to streamline the process! This is where Karma comes. It is built on Node.js and allows you to run the tests of your front end code automatically on various browsers.

Installation


In order to install Karma on your computer, run the following npm command. If you're not familiar with the tool, please read the JavaScript Developer Toolkit article first: 
npm install -g karma
After you try to call karma though, you'll get unknown command error, which can be easily solved by installing karma command-line interface (CLI): 
npm install -g karma-cli
To initiate the framework, just run karma init and follow the steps. 
Which testing framework do you want to use ?
Press tab to list possible options. Enter to move to the next question.
> jasmine

Do you want to use Require.js ?
This will add Require.js plugin.
Press tab to list possible options. Enter to move to the next question.
> no

Do you want to capture any browsers automatically ?
Press tab to list possible options. Enter empty string to move to the next quest
ion.
> Chrome
>

What is the location of your source and test files ?
You can use glob patterns, eg. "js/*.js" or "test/**/*Spec.js".
Enter empty string to move to the next question.
> spec/*.js
> src/*.js
>

Should any of the files included by the previous patterns be excluded ?
You can use glob patterns, eg. "**/*.swp".
Enter empty string to move to the next question.
>

Do you want Karma to watch all the files and run the tests on change ?
Press tab to list possible options.
> yes
Please notice the positive answer for the last question. If you running Karma stand alone, it should be set to true. On contrary it can be integrate with IDE and be executed from there, for instance WebStorm. Watch a very short tutorial about the integration of Karma with WebStorm. In the end of the initiation process, a configuration file karma.conf.js will be created, which will be used to run our tests. If you didn't specify the browsers or wanted to add another one, on which you'd like to run your tests, you can install them later from the list of supported browser launchers. To add Firefox support, run the following command to install it and add Firefox key to the browsers array in the configuration file:
npm install -g karma-firefox-launcher
Last touch is needed to be completely ready to go. Karma is a framework, which executes Jasmin's spec using karma-jasmine plugin. Once you specify it in the initiation process, the plugin is downloaded and installed in the global repository. However it installs 1.3 version and not the latest 2.0. To fix this, we'll download the correct version manually: 
npm install -g karma-jasmine@2_0

Running the tests


We'll be using our test specs from our previous Jasmine article and the source code can be found in GitHub. 
karma start karma.conf.js

INFO [karma]: Karma v0.12.21 server started at http://localhost:9876/
INFO [launcher]: Starting browser Chrome
INFO [Chrome 36.0.1985 (Windows 8.1)]: Connected on socket DOFTiS5FuL20HriB6iUZ
with id 19929084
Chrome 36.0.1985 (Windows 8.1): Executed 5 of 5 SUCCESS (0.021 secs / 0.006 secs
Pardon my using Windows 8 - I had to give my Ubuntu laptop for repair :) Anyway, you'll notice your browser being stuck and closing it will just rerun all the tests. To fix this, set singleRun property in your configuration file to true. Also be aware of the localhost:9876 address. It is used by Karma to run the specs, which means you can test it on any device connected to your network. Try pointing your phone’s browser to Karma by looking at the URL of one of the browser windows running the tests. Because Karma is running an instance of Node.js, your test machine is acting like a server and will send the tests to any browser that is pointed to it.

We'll talk about using Jasmine with your server side using jasmine-node package in the next article.

Comments

Post a Comment

Popular posts from this blog

CAP Theorem and blockchain

Image
In theoretical computer science, the CAP theorem states that it is impossible for a distributed data store (such as a blockchain network) to simultaneously provide more than two out of the three guarantees: Consistency, Availability & Partition tolerance. CAP Theorem – the parts C: Consistency – At any given time, all nodes in the network have exactly the same (most recent) value. A: Availability – Every request to the network receives a response, though without any guarantee that returned data is the most recent. P: Partition tolerance – The network continues to operate, even if an arbitrary number of nodes are failing. Due to the nature of distributed data stores (such as blockchain), Partition tolerance is a given fact; there will always be failing/unreachable nodes in the network (not least because of the unstable nature of the internet). CAP Theorem states that one has to choose between C (Consistency) or A (Availability) when in the presence of P (Partition): Av...
Read more

Length extension attack

Image
What is length extension? When a Merkle–Damgård based hash is misused as a message authentication code with construction H(secret ‖ message), and message and the length of secret is known, a length extension attack allows anyone to include extra information at the end of the message and produce a valid hash without knowing the secret. Quick sidebar, before you freak out: Since HMAC does not use this construction, HMAC hashes are not prone to length extension attacks. So, a length extension attack is a type of attack where an attacker can use Hash(message1) and the length of message1 to calculate Hash(message1 ‖ message2) for an attacker-controlled message2, without needing to know the content of message1. Algorithms like MD5, SHA-1 and most of SHA-2 that are based on the Merkle–Damgård construction are susceptible to this kind of attack. Truncated versions of SHA-2, including SHA-384 and SHA-512/256 are not susceptible, nor is the SHA-3 algorithm. A bit more details ...
Read more

Contract upgrade anti-patterns

Image
A popular trend in smart contract design is to promote the development of upgradable contracts . To be fair, existing techniques to upgrade contracts have flaws, increase the complexity of the contract significantly, and ultimately introduce bugs - even in the Zeppelin contract upgrade strategy. In this article, we are going to detail our analysis of existing smart contract upgrade strategies, describe the weaknesses we have observed in practice, and provide recommendations for contracts that require upgrades. In a follow-up blog post, we will detail a method, contract migration, that achieves the same benefits with few of the downsides. An overview of upgradable contracts Two ‘families’ of patterns have emerged for upgradable smart contracts: Data separation, where logic and data are kept in separate contracts. The logic contract owns and calls the data contract. Delegatecall-based proxies, where logic and data are kept in separate contracts, also, but the data contr...
Read more