MockJS - Mockito syntax for JavaScript Unit Testing

A couple of weeks ago I’ve learnt  about Mockito.
(yes, I’ve been hiding under a rock all this time)

Like most developers, I instantly found that Mockito’s API syntax makes it really easy to learn and use mock objects.

I’ve looked around for an equivalent in JavaScript but found nothing suitable…
Most solutions rely on unfriendly syntaxes or strange dependencies and, in my view, none was able to implement JavaScript mock objects in a simple and reliable way.

So, as a part-time project, I developed an alternative Mock object library in JavaScript.
I ported the raw concepts of Mockito, thrown in the JavaScript specifics, added a fresh perspective and some ECMA5 magic, mixed everything up in a repo and came up with something new.

The resulting project is MockJS and can be followed at https://github.com/badoo/MockJS

Proper continuous integration using Github

Hours of dealing with painful merges, rollbacks and fixing commits have driven me to write this post.

Be it open source or enterprise, it is very common seing developers using GiT as a single central repository. And common errors like copy/pasting code across branches or moving files around in the filesystem are, unfortunately, very common.

No, no, no! Oh no, no, no!

One can argue that GiT and Github may be used in a number of different setups, but never with the practices above.

Allow me to explain.

Great video on HTML5 browser rendering and JavaScript performance.

Reflows, Hardware Acceleration, requestAnimationFrame(), Web Workers.

Javascript code performance review

Within the scope of my latest projects, I had to review a lot of performance details on JavaScript to determine best possible solutions for core functionalities and architecture.

If you follow the classic “by the book” rules, you should avoid, when possible:

1.  loops
2. closures
3. object spawning
4. DOM access, specially DOM writes
5. DOM queries (find DOM objects)

Ok, but how bad is it?
How do they compare to each other?
What options do I have?
Which are the best ways to get the same result?

This study focuses on answering these questions as best as possible in order to achieve an approximate scale on comparative performance results in JavaScript. 

Working on jqMobi 1.1 update

Recently I have been deeply involved in the 1.1 development of jqMobi (core) and jqMobi UI, and here I will try to point out some technical details of what was done, how, and why.

For those of you unaware, jqMobi is a jQuery-like framework - a DOM element(s) wrapper with common functionalities which jQuery’s success as made a standard in the industry.
The main difference is jqMobi focuses exclusively on webkit-based mobile touch devices - iOS, Android 2+ and Blackberry OS6+; So, although not nearly as featured as jQuery itself, it’s performance is highly optimised for these devices.

On top of the core framework it has a neat UI plugin similar to many other “new age” mobile UIs ( Sencha, Enyo, jQuery Mobile, Kendo UI, etc).