Mild Hack for Unit Testing the Run Method of an Angular Module

AngularJS No Comments »

In Angular 1.x, the run() method of a module behaves similar to the main method or constructor method concept found in other languages:  it's a method that runs as soon as all of the dependencies have been resovled and the module has been configured.

Because of this, even if you use run() to execute a named method that can be called separately in your unit test, the code in that method gets executed during the process of instantiating the module to use in your tests.  That makes it difficult to do any testing that compares the state of data prior to running the method or tests that require mocking dependencies and dependency behavior inside of the method.

So when I ran into this problem, I came up with a mild "hack" to work around the immediate execution of the run() method.  I made the execution of the code inside my run method dependent on the value of a Boolean constant:


angular.module( 'mainModule', [] )
    .constant( 'executeRunMethod', true )
    .run( runMethod );

function runMethod( $rootScope, authService, executeRunMethod ) {
    if ( executeRunMethod ) {
        //Execute the code as expected
    }
}

runMethod.$inject = [ '$rootScope', 'authService', 'executeRunMethod' ];

With the executeRunMethod constant set to true, the runMethod() code executes via run() once the module is wired up as expected, so everything "runs" normally.

In my unit test however, I can override the executeRunMethod constant during the process of instantiating the module, setting it to false, effectively preventing the run() method from executing.


'use strict';

describe( 'mainModule', function () {
    var $rootScope,
        mockAuthService;

    beforeEach( function () {

        module( 'mainModule', function ( $provide ) {
            // The executeRunMethod constant is overridden to be false
            $provide.constant( 'executeRunMethod', false );
        } );

        inject( function ( $injector ) {
            $rootScope = $injector.get( '$rootScope' );
            mockAuthService = { requestUser: function() {} };
        } );

    });

Later in the test file, I can test the runMethod directly, passing in the needed arguments, including a "true" instance of the executeRunMethod argument allowing the code to be executed:


describe( 'the runMethod function', function() {

        var executeRunMethod = true;

        it( 'performs the expected action', function () {

            runMethod( $rootScope, mockAuthService, executeRunMethod );

            expect( result ).toEqual( expectation );
        });
});

So this arrangement lets me test the code used by the module run() method just as if it was a normal method.

Using a Route Naming Convention to Control View Access in AngularJS

AngularJS , JavaScript 1 Comment »

Suppose for a moment that you have an AngularJS single-page application, one with view routes managed with then ngRoute module, that is used by users with different roles.  A user in your company's Sales group has access to certain areas of the application, while a user in Accounting works in other parts of the application.  And there are also some areas of the application that are common to all users.

Now, you already have the navigation menu wired up so that users only see the navigation links appropriate to their user roles.  And even if a Sales user somehow ends up in a view meant for an Accounting user, the server answering the REST calls for the data powering that view is going to check the security token sent with the request and isn't going to honor that request.  But you'd still like to keep users out of UI views that aren't meant for them.

You could do a user access check at the start of each controller, or perhaps within the resolve property of each route, but that would be repetitive and it's something you could forget to do on occasion.

Read more...

Introducing Sparker: A Codebase Library Management Tool Showcasing AngularJS, Protractor, and Grunt Techniques

AngularJS , Grunt , JavaScript , Web development No Comments »

Sometimes projects take on a life of their own, and you end up with something unexpected.

I set out to create an template for CRUD-focused single page AngularJS web applications, something I and perhaps my colleagues could use as a foundation for writing new applications.  But under the momentum of self-applied scope creep, what I ended up creating was a Grunt-powered codebase library management tool, with my original template concept as the first codebase of potentially multiple foundational codebases.

Read more...

Lightning Talk Presentations from the Recent AngularJS DC Meetup

AngularJS 1 Comment »

Last week I participated in a series of lightning talks at the AngularJS DC Meetup, hosted by Difference Engine, and I thought I'd share the links to the slide decks and demos presented (unfortunately, the equipment recording the entire event failed, otherwise I would just share that).

Read more...

Using Grunt to Concatenate Only the JavaScript/CSS Files Used in Index.html

Grunt , JavaScript , Web development 1 Comment »

One of the most common uses of the Grunt task runner is to build a deployment package out of your development code for your website or web application, and part of that build process is usually a task that concatenates the CSS and JavaScript files into singular (or at least fewer) files for optimal download.

The grunt-contrib-concat Grunt plugin allows you to configure a concatenation task to target individual files or entire directories, like so:


concat: {
            js: {
                src: [ 'dev/jquery/jquery.js', 'dev/angular/services/*.js', 'dev/angular/directives/*.js' ],
                dest: '../build/combined.js',
                options: {
                    separator: ';'
                }
            },
        }

The only drawback is that you have to update the task's "src" property as you add or remove CSS and JavaScript assets from your web application.

As I was playing around with Grunt on a personal project, I came to wonder: could I create a Grunt task or set of tasks that could figure out which files to concatenate based on the <link> and <script> tags in my code?  Here's what I came up with.

Read more...