Posts by Emil van Galen

AngularConnect 2016 conference report episode 1

Posted on by  
Emil van Galen

AngularConnect 2016, held on the September 27th and 28th, was the first Angular conference since the final release of Angular 2.0. From our company (JDriven) we, 3 front-end loving colleagues, attended this conference and would like to share some of the noteworthy things we’ve learned during the conference. To allow us some time to write things down as well digest what we have learned, we intend to publish this conference report as a series of 2 or 3 episodes. In the (first) episode we will go into the topics of performance, support (also for Angular 1.x) , tooling and security. Future episodes will most likely go into the topics architecture, mobile, data, seo and / or testing.

One of the hottest topics during the AngularConnect 2016 was performance.

Continue reading →

Grasping AngularJS 1.5 directive bindings by learning from Angular 2

Posted on by  
Emil van Galen

In AngularJS 1.5 we can use attribute binding to allow easy use of input-only, output-only and two-way attributes for a directive or component. Instead of manually parsing, watching and modifying attribute values through code, we can simply specify an attribute binding by adding a property to the object hash of:

Continue reading →

Using `$q.defer()` in AngularJS? Try the $q 'constructor' instead.

Posted on by  
Emil van Galen

Although I'm a great fan of using the ($q) Promise API in AngularJS, I never really liked using $q.defer() and its Deferred API. I always found using var deferred = $q.defer() together with $.resolve(..) and $.reject(..) to be too verbose. After recently checking the $q service documentation I stumbled upon the $q constructor that results in way less verbose code. To illustrate the usage of the $q constructor I will create a function that wraps the result of a Geolocation#getCurrentPosition invocation as an AngularJS $q promise. Using the traditional $q.defer() approach the function wrapper will look like this.

/\*\* @return {Promise} \*/
function getGeoLocation() {
    var deferred = $q.defer();

    $window.navigator.geolocation.getCurrentPosition(
        function(position) { // success callback
            return deferred.resolve(position);
        },
        function(positionError) { // error callback
            return deferred.reject(positionError);
        });

    return deferred.promise;
}

Continue reading →

ngImprovedTesting 0.3: improved ModuleBuilder with lots of bug fixes

Posted on by  
Emil van Galen

NOTE: ngImprovedTesting is AngularJS library to make mock testing AngularJS code more easy.
For more information about ngImprovedTesting be sure to read its (updated) introductory blog post.

Just released version 0.3 ngImprovedTesting with a much improved ModuleBuilder. Prior to 0.3 usage of ngImprovedTesting might be troublesome due to fact that the ModuleBuilder:

Continue reading →

ngImprovedTesting 0.2: adding $q.tick() to improve testing promises

Posted on by  
Emil van Galen

NOTE: Just released version 0.2.2 of ngImprovedTesting to fix issue #6 causing chained promises (i.e. .then(...).then(...)) not to executed by a $q.tick(); also see README of the GitHub repo.

After quite a while I finally got round to creating version 0.2 of ngImprovedTesting. The ModuleBuilder API is unchanged and still makes mock testing AngularJS code much easier (be sure to read this blog post if you are unfamiliar with ngImprovedTesting). Version 0.2 of ngImprovedTesting brings you the following interesting improvements:

Continue reading →

ngEurope: about AngularJS 1.3, new router and the future 2.0

Posted on by  
Emil van Galen

Being passionate about AngularJS, me and two fellow JDriven colleagues visited the ngEurope conference. The amount of presentations during ngEurope was somewhat overwhelming, especially during the mornings without any scheduled break. Good thing I made some notes, that the slides are already available on-line and that someone published quite detailed notes for all sessions. Without all this I might simply have forgotten about some very interesting and relevant details. During ngEurope there was a all lot of attention for the just released 1.3 version of AngularJS and the coming 2.0 release.

The latest AngularJS 1.3 release features some great performance improvements (3.5x faster digest and 4.4x faster DOM manipulation) and much less pressure on the garbage collector (GC). However in order to achieve this the AngularJS team did decide drop the support for Internet Explorer 8 (which is default IE version on Windows 7). To allow for even more (optional) speed improvement one time (one way) binding support has been added. Using one time binding no $watch will be registered for the binding; typically you would use one time bindings to speed up rendering the elements of ngRepeat. Additionally a lot of improvements are done on the ngModel directive. First of all a $validators pipeline had been introduced as an alternative to invoking $setValidity from a parser / formatter function. Which also fixes the "input not showing invalid model values” bug ( #1422). Yet another great improvement are the new async validators that allows for (asynchronous) model validation on the back-end. The ngModel directive is now accompanied by the ngModelOptions directive that allows you to configure (the controller of) the ngModel directive. We now can specify when we want the model value to be updated. For instance after a short delay (a so called debounce) or on blur (i.e. when focussing another field). And using ngModelOptions we can now configure the usage of (jQuery) style getter / setter function on our model (instead of using plain data properties). Using ngMessages (multiple different) error messages can now be shown much easier in a switch–case like style for a form element. Besides preformance- and ngModel (related) improvements AngularJS also features some other noteworthy features:

Continue reading →

ngImprovedTesting: mock testing for AngularJS made easy

Posted on by  
Emil van Galen

NOTE: Just released version 0.3 of ngImprovedTesting with lots of bug fixes.
Check out this blog post or the README of the GitHub repo for more info.

Being able to easily test your application is one of the most powerful features that AngularJS offers. All the services, controllers, filters even directives you develop can be fully (unit) tested. However the learning curve for writing (proper) unit tests tends to be quite steep. This is mainly because AngularJS doesn't really offer any high level API's to ease the unit testing. Instead you are forced to use the same (low level) services that AngularJS uses internally. That means you have to gain in dept knowledge about the internals of $controller, when to $digest and how to use $provide in order to mock these services. Especially mocking out a dependency of controller, filter or another service is too cumbersome. This blog will show how you would normally create mocks in AngularJS, why its troublesome and finally introduces the new ngImprovedTesting library that makes mock testing much easier.

Continue reading →

Joy of Coding... and mutation testing in Java

Posted on by  
Emil van Galen

For many years now it has been good practice to write unit tests for your source-code. And also to use test coverage reporting to see how much of your code is covered by tests. Although line + branch coverage reporting is quite useful, it doesn't tell you how good your unit tests actually are. Hence it's even possibly to achieve 100% coverage without even a single assert in your tests. Being interested in better ways of testing I attended the "Mutation testing" workshop during this years Joy of Coding conference. Mutation testing is a radical different approach of executing and analyzing the result and coverage of your unit tests. Instead of measuring how much of your code is "accessed from" your unit tests it determines how much of your code is actually "tested by" your unit tests.

The basic idea behind mutation testing is to make a small change (a mutation) to the (byte) code and then execute your tests to see if it is detected by the unit tests. Possible mutations are altering a ">" into ">=", replacing "++" with "--" and removing "void" method invocations. Each mutation therefor creates an altered version of your code called a "mutant". Prior to the actual mutation testing our unit tests first need to be executed against the original code to see if no tests are failing. Then the unit tests will be run for each "mutant" (making it possibly very time consuming) the see if:

Continue reading →

Integrating Karma 0.10 tests in Maven with Sonar(Cube) test coverage

Posted on by  
Emil van Galen

NOTE: this post updates an earlier blog post written for version 0.8 of the Karma test runner.

For my current project we are using Maven to build our AngularJS application. Furthermore we use Sonar (recently renamed to SonarCube) to monitor our code standards / best practices and unit test coverage. In this blog post we describe how to integrate version 0.10 of the the Karma test runner with Maven and how to add your AngularJS (or any JavaScript) application to SonarQube.

Continue reading →

Understanding and fixing AngularJS directive rendering and parsing

Posted on by  
Emil van Galen

NOTE: This blog post is originally written for AngularJS 1.2.x; in 1.3.x the "input not showing invalid model values" has been fixed.
Although 1.3.x still has the "inconsistencies in how AngularJS parses data entry" the solution from this blog post isn't working for 1.3.x but I will try to find a fix for this within the next few weeks.

A while ago I noticed that AngularJS doesn't show invalid model values bound to an <input/> There is also an open bug report about this: issue #1412 - input not showing invalid model values The bug can be easily illustrated through the following example:

Continue reading →

Integrating Karma 0.8 tests in Maven with Sonar(Cube) test coverage

Posted on by  
Emil van Galen

NOTE: this blog post was written for version 0.8 of the Karma test runner. An updated blog post for the new Karma 0.10 can be found here.

For my current project we are using Maven to build our AngularJS application. Furthermore we use Sonar (recently renamed to SonarCube) to monitor our code standards / best practices and unit test coverage. In this blog post we describe how to integrate the Karma (Testacular) test runner with Maven and how to add your AngularJS (or any JavaScript) application to SonarQube.

Continue reading →

Integrating Karma (Testacular) test runner in WebStorm 6 / IDEA 12

Posted on by  
Emil van Galen

NOTE: version 7 of WebStorm already comes with built-in Karma support.
However IntelliJ IDEA 12 users will have to wait for v. 13, making this article still relevant for them.

Recently I started using the Karma (previously called Testacular) test runner for JavaScript, as an alternative for the “Jasmine Maven Plugin”. The primary reason for switching is that Karma uses actual browsers (like Chrome, Firefox, Safari and even IE) to execute the tests instead of the emulated Mozilla Rhino JavaScript engine. To increase productivity I wondered if I could also integrate Karma into WebStorm / IDEA. Currently WebStorm doesn't offer out of the box support the Karma test runner. However it does support executing any kind of NodeJS application (like Karma). Installing the NodeJS plugin (only needed when using IDEA Ultimate) When using IntelliJ IDEA Ultimate you first have to manually install the NodeJS plugin. To install this plugin:

Continue reading →

shadow-left