JavaScript Archives - Development Thoughts & Findings

Hiatus Over! Get More Efficient Today!

May 26, 2018

Reading Time: 1 minute

It’s been well over a year since I last made a write up. In that time I’ve seen contracts and projects come and go. I’ve created a full-stack startups MVP (Angular/Node) and continued building my client list. I’ve taken the time to get a great feature of using async/await in ES6 to good use – it makes reading async code a lot easier. And, I’ve also updated the theme for the blog.

Currently I’ve been looking to get further integrated with Blockchain and developing additional iOS apps. I already have a number of contributions to some additional Crypto currencies. Being able to work with many talented individuals over the last year has also been a great experience. I look forward to discussing these and other technologies as I work with them.

If there’s one thing you should start doing today it would be to get a Jenkins build server setup and working for the work that you’re doing, whether it’s Web or Mobile. The amount of additional efficiency that you’ll gain will be significant.

Here are some of my favorite Jenkin’s Plugins:

1) Slack Notification Plugin – Get slack notifications for your jobs as they build (or fail)

2) Publish Over SSH – Allows me to very easily setup everything to be pushed to the deployment target.

3) Embeddable Build Status – Whether your using a formal PR setup, thus allowing the code mergers to understand the build status of your branch, OR if you have a repo that you want others to know about the build status, this very handy plugin gives quick build details to a user.

4) Sounds Plugin – I sometimes don’t want to watch for build notifications, but would rather hear a sound on success / failure. This plugin allows just that.

MEAN Stack – Full Test Sample Application

August 28, 2015

Reading Time: 1 minute

In order to help the development community at large, I thought I’d push out the app that I had used in my write up for testing the MEAN stack. You can check it out on github here: https://github.com/SBero/mean-todo

It still has some work needing to be done to it, but enough is currently done to help others get started with fully testing their MEAN apps.

I’d like to get it to the point, where it’s the perfect sample project for someone new to the MEAN stack to be able to review, pick up some best practices and see exactly how to do the testing that’s involved (especially testing all of the isolate scope parts of an AngularJS directive!).

AngularJS Multiple Identical API Calls

August 11, 2015

Reading Time: 1 minute

With a large AngularJS application, and even smaller ones, you can run into this issue where you end up with multiple identical API calls being made if your using the $q service. This occurs because there is a conflict with overlapping calls, which basically re-try the last API call for all of the call conflicts.

This happens when you aren’t bundling all of the calls up with the $q.all() function. This function receives an array of $http service objects that will resolve to an array once they’re all returned from the server.

You need to pass into the $q.all() function http promise objects which can be retrieved from the $http service.

For example:

var req = {
 method: 'POST',
 url: 'http://example.com',
 headers: {
   'Content-Type': undefined
 },
 data: { test: 'test' }
}

$http(req).then(function(){...}, function(){...});

var req = {

method: 'POST',

url: 'http://example.com',

headers: {

'Content-Type': undefined

data: { test: 'test' }

}

$http(req).then(function(){...}, function(){...});

Eliminating the .then after the $http and doing just return $http(req); will get you the promise to add to the array which you’ll pass to $q.all().

Unit Testing Full Stack Part 2 – AngularJS Part 2 of 3

July 26, 2015

Reading Time: 5 minutes

This is part 2 of 3 unit testing full stack javascript. In this post we’ll talk about testing some more of Angular: Services, Directives and Filters.

In case you missed it, this unit testing series of posts are:

Part 2A – Installation, Routes, Controllers

Part 2B – Services, Directives, Filters

Part 2C – Coverage Reports, End to End (e2e)

So let’s get started with where we left off, testing services.

Services

Testing services is actually fairly straight forward. The thing to keep in mind is that you intercept all the requests that would normally go to a backend, and return the status code, etc. that you would expect.

describe('Unit: Services', function(){
	beforeEach(module('app'));

	describe('todoService', function(){
		var todoService;
		var $httpBackend;
		var baseUrl = "http://localhost:3000";


		beforeEach(inject(function($injector, _$httpBackend_){
			todoService = $injector.get('todoService');
			$httpBackend = _$httpBackend_;
		}));
		
		it('should have todoService as a service.', function(){
			expect(todoService).toBeDefined();
		});

		it('should get all todos', function(){
			$httpBackend.expectGET(baseUrl + '/todo')
			.respond(200, 'todo API');
		
			todoService.get();

			$httpBackend.flush();
		
		});

		it('should get one todo', function(){
			$httpBackend.expectGET(baseUrl + '/todo/1')
			.respond(200, 'todo API');

			todoService.get(1);

			$httpBackend.flush();
		});

		it('should update a todo item', function(){
			$httpBackend.expectPUT(baseUrl + '/todo')
			.respond(200, 'todo API');

			todoService.update({title: 'My Todo', description: 'Another Todo Update.'});

			$httpBackend.flush();
		});

		it('should delete a todo item', function(){
			$httpBackend.expectDELETE(baseUrl + '/todo/1')
			.respond(200, 'todo API');

			todoService.delete(1);

			$httpBackend.flush();
		});
	});
});

describe('Unit: Services', function(){

beforeEach(module('app'));

describe('todoService', function(){

var todoService;

var $httpBackend;

var baseUrl = "http://localhost:3000";

beforeEach(inject(function($injector, _$httpBackend_){

todoService = $injector.get('todoService');

$httpBackend = _$httpBackend_;

}));

it('should have todoService as a service.', function(){

expect(todoService).toBeDefined();

});

it('should get all todos', function(){

$httpBackend.expectGET(baseUrl + '/todo')

.respond(200, 'todo API');

todoService.get();

$httpBackend.flush();

});

it('should get one todo', function(){

$httpBackend.expectGET(baseUrl + '/todo/1')

.respond(200, 'todo API');

todoService.get(1);

$httpBackend.flush();

});

it('should update a todo item', function(){

$httpBackend.expectPUT(baseUrl + '/todo')

.respond(200, 'todo API');

todoService.update({title: 'My Todo', description: 'Another Todo Update.'});

$httpBackend.flush();

});

it('should delete a todo item', function(){

$httpBackend.expectDELETE(baseUrl + '/todo/1')

.respond(200, 'todo API');

todoService.delete(1);

$httpBackend.flush();

});

Let’s break down one of the unit tests:

it('should get all todos', function(){
	$httpBackend.expectGET(baseUrl + '/todo')
	.respond(200, 'todo API');
		
	todoService.get();

	$httpBackend.flush();
		
});

it('should get all todos', function(){

$httpBackend.expectGET(baseUrl + '/todo')

.respond(200, 'todo API');

todoService.get();

$httpBackend.flush();

});

As you can see the $httpBackend is where we describe the type of http call that the service will attempt to do, and we setup how to return back to the service. You can send data to the $httpBackend, having it expect a certain set of data, or have it return specific data to further test the directive. The link to the Angular Site for $httpBackend will help you read about the different ways to utilize it.

Once we call $httpBackend.flush() we flush all pending requests and respond with the pre-determined responses.

Moving further, you can obviously test any of the functions inside of a service quite easily. Services I would say are one of the easier components to test in Angular.

Directives

I thought that directives were actually one of the components in Angular that I had the hardest time trying to figure out how to properly test all the aspects of. It seems that most people never get into actually testing all of the pieces of them.

Let’s just get into it: isolate scopes are in the vast majority of directives, and most places that show you how to test directives, don’t really specify how to test those.

I’m here to hopefully clear that up. Lets look at en example directive and it’s corresponding code.:

(function(){
	'use strict';

	var directiveId = "todoItem";

	angular.module('app.directives').directive(directiveId, ['todoService', todoItem]);
		
	function todoItem(todoService){
		return {
			restrict: 'E',
			scope: {
				todo: '=',
				refreshFn: '&'
			},
			templateUrl: 'js/directives/todoItem/todoItem.html',
			link: function(scope, element, attr){
				scope.editing = false;

				scope.deleteItem = function(){
					todoService.delete(scope.todo._id).then(
						function(success){
							scope.refreshFn();
						},
						function(error){

						});
				}

				scope.updateItem = function(){
					todoService.update(scope.todo).then(
						function(success){
							scope.refreshFn();
						},
						function(error){

						});
				}

				scope.editItem = function(){
					scope.editing = true;
				}

				scope.cancelUpdate = function(){
					scope.editing = false;
				}

			}
		}
	}
		
}());

(function(){

'use strict';

var directiveId = "todoItem";

angular.module('app.directives').directive(directiveId, ['todoService', todoItem]);

function todoItem(todoService){

return {

restrict: 'E',

scope: {

todo: '=',

refreshFn: '&'

templateUrl: 'js/directives/todoItem/todoItem.html',

link: function(scope, element, attr){

scope.editing = false;

scope.deleteItem = function(){

todoService.delete(scope.todo._id).then(

function(success){

scope.refreshFn();

function(error){

});

}

scope.updateItem = function(){

todoService.update(scope.todo).then(

function(success){

scope.refreshFn();

function(error){

});

}

scope.editItem = function(){

scope.editing = true;

}

scope.cancelUpdate = function(){

scope.editing = false;

}

}());

When the user clicks edit, it sets $scope.editing flag to true, and gives them this view:

So with that in mind, let’s make a directive unit test that allows us to test those isolate scope functions, check the variables on it, and do a save to the API (intercepted with Mocks), and attempt to do things that give back errors and allow us to accommodate for that.

describe('Unit: Directives', function(){
	var elem,
		scope,
		$compile,
		$httpBackend,
		baseUrl = "http://localhost:3000";

	beforeEach(module('app'));
	beforeEach(module('app.directives'));

	/* Directive Templates */
	beforeEach(module('js/directives/todoItem/todoItem.html'));

	beforeEach(inject(function($rootScope, _$compile_, _$httpBackend_){
		scope = $rootScope.$new();
		$compile = _$compile_;
		$httpBackend = _$httpBackend_;
	}));

	describe('todoItem', function(){

		var directiveStr;

		beforeEach(function(){
			var todo = {
				title: "Todo Title",
				description: "Todo Description"
			}

			var refreshFn = function(){
				return "Todo Refresh Fn. Call";
			}

			scope.todo = todo;
			scope.refreshFn = refreshFn;
			scope.editing = false;

			directiveStr = "<todo-item todo='todo' refresh-fn='refreshFn()'></todo-item>";
		});
		
		it('should have a title and description', function(){
			elem = $compile(directiveStr)(scope);

			scope.$digest();

			var elemAsHtml = elem.html();

			expect(elemAsHtml).toContain(scope.todo.title);
			expect(elemAsHtml).toContain(scope.todo.description);
		});

		it('should execute the refreshFn scope function', function(){
			elem = $compile(directiveStr)(scope);

			scope.$digest();

			var elemAsHtml = elem.html();

			expect(elemAsHtml).toContain(scope.todo.title);
			expect(elemAsHtml).toContain(scope.todo.description);
		});

		it('should set the scope edit item to true', function(){
			elem = $compile(directiveStr)(scope);
			
			scope.$digest();
			
			var elemScope = elem.isolateScope();

			elemScope.editItem();		

			expect(elemScope.editing).toBeTruthy();
		});

		it('should set the scope edit item to false', function(){
			elem = $compile(directiveStr)(scope);

			scope.$digest();

			var elemScope = elem.isolateScope();

			elemScope.editItem();
			elemScope.cancelUpdate();

			expect(elemScope.editing).toBeFalsy();
		});

		it('should update the todo item', function(){
			$httpBackend.expectPUT(baseUrl + '/todo')
			.respond(200, 'todo API');

			scope.todo._id = 1;

			elem = $compile(directiveStr)(scope);

			scope.$digest();

			var elemScope = elem.isolateScope();

			elemScope.updateItem();

			$httpBackend.flush();
		});

		it('should throw an error when trying to update the todo item', function(){
			$httpBackend.expectPUT(baseUrl + '/todo')
			.respond(400, 'todo API');

			scope.todo._id = 0;

			elem = $compile(directiveStr)(scope);

			scope.$digest();

			var elemScope = elem.isolateScope();

			elemScope.updateItem();

			$httpBackend.flush();
		});

		it('should delete the todo item', function(){
			$httpBackend.expectDELETE(baseUrl + '/todo/1')
			.respond(200, 'todo API');

			scope.todo._id = 1;

			elem = $compile(directiveStr)(scope);

			scope.$digest();

			var elemScope = elem.isolateScope();

			elemScope.deleteItem();

			$httpBackend.flush();
		});

		it('should throw an error when trying to delete the todo item', function(){
			$httpBackend.expectDELETE(baseUrl + '/todo/0')
			.respond(400, 'todo API');

			scope.todo._id = 0;

			elem = $compile(directiveStr)(scope);

			scope.$digest();

			var elemScope = elem.isolateScope();

			elemScope.deleteItem();

			$httpBackend.flush();
		});

	});

	
});

100

101

102

103

104

105

106

107

108

109

110

111

112

113

114

115

116

117

118

119

120

121

122

123

124

125

126

127

128

129

130

131

132

133

134

135

136

137

138

139

140

141

142

143

144

145

146

147

148

149

150

151

152

153

154

155

156

157

158

159

describe('Unit: Directives', function(){

var elem,

scope,

$compile,

$httpBackend,

baseUrl = "http://localhost:3000";

beforeEach(module('app'));

beforeEach(module('app.directives'));

/* Directive Templates */

beforeEach(module('js/directives/todoItem/todoItem.html'));

beforeEach(inject(function($rootScope, _$compile_, _$httpBackend_){

scope = $rootScope.$new();

$compile = _$compile_;

$httpBackend = _$httpBackend_;

}));

describe('todoItem', function(){

var directiveStr;

beforeEach(function(){

var todo = {

title: "Todo Title",

description: "Todo Description"

}

var refreshFn = function(){

return "Todo Refresh Fn. Call";

}

scope.todo = todo;

scope.refreshFn = refreshFn;

scope.editing = false;

directiveStr = "<todo-item todo='todo' refresh-fn='refreshFn()'></todo-item>";

});

it('should have a title and description', function(){

elem = $compile(directiveStr)(scope);

scope.$digest();

var elemAsHtml = elem.html();

expect(elemAsHtml).toContain(scope.todo.title);

expect(elemAsHtml).toContain(scope.todo.description);

});

it('should execute the refreshFn scope function', function(){

elem = $compile(directiveStr)(scope);

scope.$digest();

var elemAsHtml = elem.html();

expect(elemAsHtml).toContain(scope.todo.title);

expect(elemAsHtml).toContain(scope.todo.description);

});

it('should set the scope edit item to true', function(){

elem = $compile(directiveStr)(scope);

scope.$digest();

var elemScope = elem.isolateScope();

elemScope.editItem();

expect(elemScope.editing).toBeTruthy();

});

it('should set the scope edit item to false', function(){

elem = $compile(directiveStr)(scope);

scope.$digest();

var elemScope = elem.isolateScope();

elemScope.editItem();

elemScope.cancelUpdate();

expect(elemScope.editing).toBeFalsy();

});

it('should update the todo item', function(){

$httpBackend.expectPUT(baseUrl + '/todo')

.respond(200, 'todo API');

scope.todo._id = 1;

elem = $compile(directiveStr)(scope);

scope.$digest();

var elemScope = elem.isolateScope();

elemScope.updateItem();

$httpBackend.flush();

});

it('should throw an error when trying to update the todo item', function(){

$httpBackend.expectPUT(baseUrl + '/todo')

.respond(400, 'todo API');

scope.todo._id = 0;

elem = $compile(directiveStr)(scope);

scope.$digest();

var elemScope = elem.isolateScope();

elemScope.updateItem();

$httpBackend.flush();

});

it('should delete the todo item', function(){

$httpBackend.expectDELETE(baseUrl + '/todo/1')

.respond(200, 'todo API');

scope.todo._id = 1;

elem = $compile(directiveStr)(scope);

scope.$digest();

var elemScope = elem.isolateScope();

elemScope.deleteItem();

$httpBackend.flush();

});

it('should throw an error when trying to delete the todo item', function(){

$httpBackend.expectDELETE(baseUrl + '/todo/0')

.respond(400, 'todo API');

scope.todo._id = 0;

elem = $compile(directiveStr)(scope);

scope.$digest();

var elemScope = elem.isolateScope();

elemScope.deleteItem();

$httpBackend.flush();

});

That’s quite a long set of unit tests, well, 8 of them to be exact.

Do you remember when we setup the testing in Karma, we added the html2js pre-processor? That’s what allows us to load the html template file in the unit test with this piece of code:

	beforeEach(module('js/directives/todoItem/todoItem.html'));

1	beforeEach(module('js/directives/todoItem/todoItem.html'));

To test any bits and pieces of the isolate scope, you need to do this:

it('should set the scope edit item to true', function(){
			elem = $compile(directiveStr)(scope);
			
			scope.$digest();
			
			var elemScope = elem.isolateScope();

			elemScope.editItem();		

			expect(elemScope.editing).toBeTruthy();
		});

it('should set the scope edit item to true', function(){

elem = $compile(directiveStr)(scope);

scope.$digest();

var elemScope = elem.isolateScope();

elemScope.editItem();

expect(elemScope.editing).toBeTruthy();

});

We need to call elem.isolateScope() on the compiled element, digest the scope, so that we get updated and bound scope items. Now with the elemScope variable that’s returned from calling elem.isolateScope() we can access any of the isolate scope items, functions, etc. as you can see here with the call to elemScope.editItem() .

Everything else is pretty typical standard stuff relating to testing of services with $httpBackend and doing a flush() to validate that the api call is being made and to test different return scenarios (http status codes).

Filters

Testing filters is really quite simple. You would basically invoke them as you would in a controller, testing the return results. Here’s an example:

describe('Unit: Filters', function(){
	var filter;

	beforeEach(module('app'));
	beforeEach(inject(function($filter){
		filter = $filter;
	}));

	it('should filter a number and give it two decimals', function(){
		var num = filter('number')(100, 2);

		expect(num).toEqual("100.00");
	});
});

describe('Unit: Filters', function(){

var filter;

beforeEach(module('app'));

beforeEach(inject(function($filter){

filter = $filter;

}));

it('should filter a number and give it two decimals', function(){

var num = filter('number')(100, 2);

expect(num).toEqual("100.00");

});

So that takes care of our 2nd part for testing Angular JS. Please let me know if you have further questions, so that I can enhance the post for others to learn from.

Our final post on Angular testing we’ll discuss coverage reports and End-to-End testing with Protractor.

Lessons Learned: Upgrading an Enterprise Angular App

July 23, 2015

Reading Time: 2 minutes

I recently completed an upgrade for an Enterprise Angular app from 1.2.24 to 1.3.15. Doing an upgrade on a large system is no small undertaking. Finding solutions to resolve upgrade incompatibilities can seem like a bit of black magic at times. This upgrade was no exclusion to just that.

The most common error I got was Error: $rootScope:infdig Infinite $digest Loop. Staring at these errors in the console all I could think about was how on earth was I going to fix them?! With a codebase that’s more than 45k lines for just the front end, I start questioning if I’m going to be able to even do this, if I’m a good enough developer, etc. The typical Imposter’s Syndrome that’s so prevalent in this line of work.

This error typically gives you 0 hints what’s causing it, and where it’s coming from, but I found some resources that helped me realize that anything that has a watcher needs to be Idempotent in AngularJS. If it’s not, it could be the source of an infinite digest loop.

So I thought rather than make a long write up of all the different pieces I solved in my project, I thought I’d supply the main resources that I had to read and understand in order to solve different errors. Let’s face it, all projects will be different, but the overall upgrade challenges I’d assume are going to be relatively similar. Here’s the list:

Scope Work

http://stackoverflow.com/questions/13743058/how-to-access-the-angular-scope-variable-in-browsers-console

https://github.com/angular/angular.js/wiki/When-to-use-$scope.$apply()

Infinite Digest

https://github.com/angular/angular.js/issues/705 (Idempotent – Important to know for usually fixing Infinite Digest Errors)

http://stackoverflow.com/questions/20567614/errors-in-angularjs-often-causes-infinite-loops

http://stackoverflow.com/questions/17466872/infinite-loop-with-angular-expression-binding

http://stackoverflow.com/questions/21322755/tracking-down-infinite-digest-errors

http://stackoverflow.com/questions/24592283/angular-infinite-digest-loop

Filters

http://stackoverflow.com/questions/25877704/what-is-stateful-filtering-in-angularjs

http://stackoverflow.com/questions/27402326/angularjs-1-3-async-filter-not-working

Grep/Ack Tricks

http://stackoverflow.com/questions/9081/grep-a-file-but-show-several-surrounding-lines

Enhanced performance is a major upgrade that you get when going from 1.2.x to 1.3.x. If you make sure your filters aren’t stateful and you start setting up all two-way data bindings that never change to use the ‘::’ one time binding syntax you can quite easily supercharge an app with performance issues. Feel free to connect with me if you have any particular difficult bug that you’re trying to fix during an upgrade.

Unit Testing Full Stack Part 2 – AngularJS Part 1 of 3

July 16, 2015

Reading Time: 6 minutes

This is part 2 of my multi part guide for setting up and testing a full stack JavaScript application. Next up is AngularJS. I’ve broken this up into 3 separate parts, as this is a bit more complex for testing the front end, since we have both unit tests and end to end tests. The parts will be broken up as follows:

Part 2A – Installation, Routes, Controllers

Part 2B – Services, Directives, Filters

Part 2C – Coverage Reports, End to End (e2e)

Installation & Configuration

To get started, install the following:

npm install karma --save-dev
npm install karma-jasmine karma-chrome-launcher --save-dev

1 2	npm install karma --save-dev npm install karma-jasmine karma-chrome-launcher --save-dev

Karma (test runner) in conjunction with Jasmine (unit testing framework). You can use other unit testing frameworks, if you so desire, just check here, under ‘Framework’, to see which ones are compatible.

So let’s start with our AngularJS project, with npm, it will install both karma, the jasmine plugin and the chrome launcher plugin, as well as any required dependencies for those packages.

Something to be aware of, is that because Angular runs in the browser, it requires the chrome browser to launch when running tests, so that they can execute. This will launch and destroy a chrome browser for you automatically, but if you’re not wanting to have a browser launch, you can use PhantomJS for everything to be just run in a headless browser (A browser engine without any graphical interface, it runs in memory only).

Once these are complete, you’re next goal is configure karma to run through the tests for us. To do this, we need to create a configuration for Karma. Navigate to your /test directory and we’ll type (where karma-unit.conf.js is the name of the configuration file):

karma init karma-unit.conf.js

1	karma init karma-unit.conf.js

You’ll be asked a series of question (see here), once done, you will inevitably go into the Karma configuration itself and setup the correct order for loading your project files under the ‘files’ property array. This will probably take looking at your own projects index.html file and making sure that the files are all there and in proper order. Everything source file that you use in your project will need to be loaded this way, and again, in proper order.

To do the unit tests, you will also need to load the angular-mock file. This allows us to mock the backend requests over http, as jasmine doesn’t actually process async calls to an api properly. So be sure to add that file to your files array. Here’s a link you can add to the array for the angular-mock.js file form the google api CDN, for v1.2.26:

https://ajax.googleapis.com/ajax/libs/angularjs/1.2.26/angular-mocks.js

1	https://ajax.googleapis.com/ajax/libs/angularjs/1.2.26/angular-mocks.js

My files array looks like this:

files: [
        "https://ajax.googleapis.com/ajax/libs/jquery/2.1.1/jquery.min.js",
        "https://maxcdn.bootstrapcdn.com/bootstrap/3.2.0/js/bootstrap.min.js",
        "https://ajax.googleapis.com/ajax/libs/angularjs/1.4.0-rc.0/angular.min.js",
        "https://ajax.googleapis.com/ajax/libs/angularjs/1.4.0-rc.0/angular-route.min.js",
        "https://ajax.googleapis.com/ajax/libs/angularjs/1.4.0-rc.0/angular-resource.min.js",
        "https://ajax.googleapis.com/ajax/libs/angularjs/1.4.0-rc.0/angular-animate.min.js",
        "https://ajax.googleapis.com/ajax/libs/angularjs/1.4.0-rc.0/angular-mocks.js",
        "https://ajax.googleapis.com/ajax/libs/angularjs/1.4.0-rc.0/angular-sanitize.min.js",
        "https://cdnjs.cloudflare.com/ajax/libs/toastr.js/latest/js/toastr.min.js",
        "js/**/*.js",
        "js/**/*.html",
        "app/**/*.js",
        "app/**/*.html",
        "../test/unit-angular/**/*.js"
    ],

files: [

"https://ajax.googleapis.com/ajax/libs/jquery/2.1.1/jquery.min.js",

"https://maxcdn.bootstrapcdn.com/bootstrap/3.2.0/js/bootstrap.min.js",

"https://ajax.googleapis.com/ajax/libs/angularjs/1.4.0-rc.0/angular.min.js",

"https://ajax.googleapis.com/ajax/libs/angularjs/1.4.0-rc.0/angular-route.min.js",

"https://ajax.googleapis.com/ajax/libs/angularjs/1.4.0-rc.0/angular-resource.min.js",

"https://ajax.googleapis.com/ajax/libs/angularjs/1.4.0-rc.0/angular-animate.min.js",

"https://ajax.googleapis.com/ajax/libs/angularjs/1.4.0-rc.0/angular-mocks.js",

"https://ajax.googleapis.com/ajax/libs/angularjs/1.4.0-rc.0/angular-sanitize.min.js",

"https://cdnjs.cloudflare.com/ajax/libs/toastr.js/latest/js/toastr.min.js",

"js/**/*.js",

"js/**/*.html",

"app/**/*.js",

"app/**/*.html",

"../test/unit-angular/**/*.js"

As you can tell, it has some wildcard symbols there, where ** means all sub-folders and * means all files, and in my file, *.js means all files ending in .js. So these are all of the files included in the testing.

Next up are the plugins. My plugins looks like:

plugins: [
        'karma-jasmine',
        'karma-chrome-launcher',
        'karma-ng-html2js-preprocessor',
        'karma-mocha-reporter',
        'karma-coverage'
    ],

plugins: [

'karma-jasmine',

'karma-chrome-launcher',

'karma-ng-html2js-preprocessor',

'karma-mocha-reporter',

'karma-coverage'

I have a few extra karma packages installed, if you’d like to use them, you can npm install them. karma-ng-html2js-preprocessor makes it possible to inject a directive template into the tests for testing. karma-mocha-reporter is the type of report that gets generated that I like, and finally karma-coverage is a coverage reporting tool built on istanbul.

Finally, here are the preprocessors, reports, and coverageReporter configs:

 preprocessors: {
        'app/**/*.html': ['ng-html2js'],
        'js/**/*.html': ['ng-html2js'],
        'app/**/*.js': ['coverage'],
        'js/**/*.js': ['coverage']
    },

    // test results reporter to use
    // possible values: 'dots', 'progress'
    // available reporters: https://npmjs.org/browse/keyword/karma-reporter
    reporters: ['mocha', 'coverage'],

    coverageReporter: {
        type: 'html',
        dir: 'coverage/',
        subdir: 'angular'
    },

preprocessors: {

'app/**/*.html': ['ng-html2js'],

'js/**/*.html': ['ng-html2js'],

'app/**/*.js': ['coverage'],

'js/**/*.js': ['coverage']

// test results reporter to use

// possible values: 'dots', 'progress'

// available reporters: https://npmjs.org/browse/keyword/karma-reporter

reporters: ['mocha', 'coverage'],

coverageReporter: {

type: 'html',

dir: 'coverage/',

subdir: 'angular'

I need to configure the preprocessor details for both ng-html2js and the coverage plugin, and configure the coverage reporter output details.

Finally, we’re ready to start writing some tests.

Once we write tests, we can run the tests by typing:

karma start /path-to/config.file.js

1	karma start /path-to/config.file.js

Routes

I have my route test spec file in /test/unit-angular/routeSpecs/routeSpec.js.

I need to create the file just like any typical mocha test, with the describe, beforeEach, it, etc. functions. So a very basic route spec file will look like this:

describe('Unit: Routes', function(){
	beforeEach(module('app'));

	var location, route, rootScope;

	beforeEach(inject(function(_$location_, _$route_, _$rootScope_){
		location = _$location_;
		route = _$route_;
		rootScope = _$rootScope_;
	}));

	describe('index route', function(){
		beforeEach(inject(function($httpBackend){
			$httpBackend.expectGET('app/todo/todo.html')
			.respond(200, 'todo HTML');
		}));

		it('should load the todo page on successful load of /', function(){
			location.path('/');
			rootScope.$digest();
			expect(route.current.templateUrl).toBe('app/todo/todo.html');
		});
	});

	describe('todo route', function(){
		beforeEach(inject(function($httpBackend){
			$httpBackend.expectGET('app/todo/todo.html')
			.respond(200, 'todo HTML');
		}));

		it('should load the todo page', inject(function(){

			location.path('/todo');
			rootScope.$digest();
			expect(route.current.templateUrl).toBe('app/todo/todo.html');
		}));
	});
});

describe('Unit: Routes', function(){

beforeEach(module('app'));

var location, route, rootScope;

beforeEach(inject(function(_$location_, _$route_, _$rootScope_){

location = _$location_;

route = _$route_;

rootScope = _$rootScope_;

}));

describe('index route', function(){

beforeEach(inject(function($httpBackend){

$httpBackend.expectGET('app/todo/todo.html')

.respond(200, 'todo HTML');

}));

it('should load the todo page on successful load of /', function(){

location.path('/');

rootScope.$digest();

expect(route.current.templateUrl).toBe('app/todo/todo.html');

});

describe('todo route', function(){

beforeEach(inject(function($httpBackend){

$httpBackend.expectGET('app/todo/todo.html')

.respond(200, 'todo HTML');

}));

it('should load the todo page', inject(function(){

location.path('/todo');

rootScope.$digest();

expect(route.current.templateUrl).toBe('app/todo/todo.html');

}));

});

Going through this, is pretty straight forward. we need to inject the different services location, route and rootScope. The inject function also ignores the surrounding ‘_’ for the service names. This is just to help readability within the test file. Now we can use these services in the tests themselves.

Any request made to any server requires us to use the $httpBackend to intercept the expected call and return what response the that should be expected.

In order to navigate, you need to use location.path(…) and follow it up with a manual call to $digest().

This is pretty much the entire pattern for testing your different routes. If your application requires you to login in order to test routes, you will need to create the objects, etc. to simulate a user logging. Remember, since it’s not actually making any calls to a server, you don’t need to worry about a token being authenticated, etc. Those kinds of tests should be run as unit tests against the API and/or end to end tests.

Controllers

I place my controllers in /test/unit-angular/controllerSpecs/<ctrlName>ControllerSpec.js.

Testing controllers is also fairly straight forward, but requires understanding a few important concepts.

1) We have to manually create and setup the scopes for the controllers we want to test.

2) You need to perform $httpBackend.flush() after we want to perform the $httpBackend calls in controllers.

Here’s a sample controller spec file:

describe('Unit: Controllers', function(){
	beforeEach(module('app'));

	//TODO: Get the service dependencies setup with $httpBackend?
	
	describe('todoCtrl', function(){
		var todoCtrl, 
			scope,
			$httpBackend,
			baseUrl = "http://localhost:3000";

		beforeEach(inject(function($controller, _$rootScope_, _$httpBackend_){
			scope = _$rootScope_.$new();

			todoCtrl = $controller('todoCtrl as vm', {
				$scope: scope,
			});

			$httpBackend = _$httpBackend_;
		}));

		it('should have a createTodo function', function(){
			expect(scope.vm.createTodo).toBeDefined();
		});

		it('should have a refreshTodos function', function(){
			expect(scope.vm.refreshTodos).toBeDefined();
		});

		it('should create a new todo item', function(){
			$httpBackend.when('POST', baseUrl + '/todo')
			.respond(200, 'todo API POST');

			$httpBackend.when('GET', baseUrl + '/todo')
			.respond(200, 'todo API');
	
			var todo = {
				title: "My Todo",
				description: "My Todo Description"
			}

			scope.vm.createTodo(todo);

			$httpBackend.flush();
		});

		it('should fail when trying to create a new todo item', function(){
			$httpBackend.when('POST', baseUrl + '/todo')
			.respond(400, 'todo invalid');

			$httpBackend.when('GET', baseUrl + '/todo')
			.respond(200, 'todo invalid');

			scope.vm.createTodo({});

			$httpBackend.flush();
		});

		it('should fail when trying to refresh the todo items', function(){
			$httpBackend.whenGET(baseUrl + '/todo')
			.respond(400, 'refresh invalid');
			

			scope.vm.refreshTodos();

			$httpBackend.flush();
		});
	});
});

describe('Unit: Controllers', function(){

beforeEach(module('app'));

//TODO: Get the service dependencies setup with $httpBackend?

describe('todoCtrl', function(){

var todoCtrl,

scope,

$httpBackend,

baseUrl = "http://localhost:3000";

beforeEach(inject(function($controller, _$rootScope_, _$httpBackend_){

scope = _$rootScope_.$new();

todoCtrl = $controller('todoCtrl as vm', {

$scope: scope,

});

$httpBackend = _$httpBackend_;

}));

it('should have a createTodo function', function(){

expect(scope.vm.createTodo).toBeDefined();

});

it('should have a refreshTodos function', function(){

expect(scope.vm.refreshTodos).toBeDefined();

});

it('should create a new todo item', function(){

$httpBackend.when('POST', baseUrl + '/todo')

.respond(200, 'todo API POST');

$httpBackend.when('GET', baseUrl + '/todo')

.respond(200, 'todo API');

var todo = {

title: "My Todo",

description: "My Todo Description"

}

scope.vm.createTodo(todo);

$httpBackend.flush();

});

it('should fail when trying to create a new todo item', function(){

$httpBackend.when('POST', baseUrl + '/todo')

.respond(400, 'todo invalid');

$httpBackend.when('GET', baseUrl + '/todo')

.respond(200, 'todo invalid');

scope.vm.createTodo({});

$httpBackend.flush();

});

it('should fail when trying to refresh the todo items', function(){

$httpBackend.whenGET(baseUrl + '/todo')

.respond(400, 'refresh invalid');

scope.vm.refreshTodos();

$httpBackend.flush();

});

The beforeEach is a bit more complex for the controller:

beforeEach(inject(function($controller, _$rootScope_, _$httpBackend_){
			scope = _$rootScope_.$new();

			todoCtrl = $controller('todoCtrl as vm', {
				$scope: scope,
			});

			$httpBackend = _$httpBackend_;
		}));

beforeEach(inject(function($controller, _$rootScope_, _$httpBackend_){

scope = _$rootScope_.$new();

todoCtrl = $controller('todoCtrl as vm', {

$scope: scope,

});

$httpBackend = _$httpBackend_;

}));

As you can see, I create the new controller and bind the scope to it by first creating the new scope with $rootScope.$new() and then setting it for the manual dependency injection with the $controller service {$scope: scope}.

Following this, I prefer to test all of the functions in a controller to be sure that they’re defined before I start testing them.

it('should have a createTodo function', function(){
			expect(scope.vm.createTodo).toBeDefined();
		});

it('should have a createTodo function', function(){

expect(scope.vm.createTodo).toBeDefined();

});

If the application is refactored, just realize if the function changes name or is removed, you’ll need to keep your controller test files current.

Finally, testing the actual scope functions is required. You’ll need to setup any $httpBackend expected calls first before you test the scope function, otherwise you’ll get errors for unexpected $http calls.

it('should create a new todo item', function(){
			$httpBackend.when('POST', baseUrl + '/todo')
			.respond(200, 'todo API POST');

			$httpBackend.when('GET', baseUrl + '/todo')
			.respond(200, 'todo API');
	
			var todo = {
				title: "My Todo",
				description: "My Todo Description"
			}

			scope.vm.createTodo(todo);

			$httpBackend.flush();
		});

it('should create a new todo item', function(){

$httpBackend.when('POST', baseUrl + '/todo')

.respond(200, 'todo API POST');

$httpBackend.when('GET', baseUrl + '/todo')

.respond(200, 'todo API');

var todo = {

title: "My Todo",

description: "My Todo Description"

}

scope.vm.createTodo(todo);

$httpBackend.flush();

});

Any required objects for the scope function should be passed in at this time as well so that the function runs properly.

You can see how in the one test I try and use an empty object, and what I expect the api to respond with.

The rest comes down to just writing test coverage for all of your controllers functions based on different scenarios. Time to write your test plans! 🙂

Next part in this series we’ll cover the Services, Directives and Filters. We’ll go in-depth with testing Directives, importantly, for how to test their isolate scopes and functions.

I hope you enjoyed the read, and let me know if you find any issues with the above so that I can edit any mistakes.

AngularJS Error: $compile:multidir Multiple Directive Resource Contention

May 12, 2015

Reading Time: 1 minute

I recently had been working on an upgrade from 1.2.x to 1.3.x branch of AngularJS for this project I’ve been working on.

While doing this, I got this error:

Error: $compile:multidir
Multiple Directive Resource Contention

1 2	Error: $compile:multidir Multiple Directive Resource Contention

Clicking on the link the Chrome console brought me to the AngularJS page giving me more details on the error thrown. It said that two different directives had a conflict with each other.

However, the code snippet gave me about 0 details, and the information was still, while something, a bit archaic.

The notes on the page mention to do a few different things to resolve it:

- Multiple directives requesting isolated scope.
- Multiple directives publishing a controller under the same name.
- Multiple directives declared with the transclusion option.
- Multiple directives attempting to define a template or templateURL.

- Multiple directives requesting isolated scope.

- Multiple directives publishing a controller under the same name.

- Multiple directives declared with the transclusion option.

- Multiple directives attempting to define a template or templateURL.

I checked the first scenario, and it wasn’t the case for the directive. I removed the third scenario, and it still was thrown. Next I checked to see if there was a directive naming conflict with ack:

ack -r "myDirective" .

1	ack -r "myDirective" .

Scrolling through the list to look at the filenames, I noticed that a third party library had the exact same name as one of my directive names. Building the library to not include that filename resolved my issue, and after a few more bug fixes, I successfully upgraded my app to the 1.3.x branch. It’s a LOT faster! I highly suggest upgrading your app as soon as possible.

If you would like to read the full write up of lessons learned which includes more of the issues I ran into, as well as a pretty solid list of the different resources I used to resolve many of the upgrade issues read this post: http://www.stephenbero.com/lessons-learned-upgrading-an-enterprise-angular-app-from-1-2-x-to-1-3-x/

Unit Testing Full Stack Part 1 – node/io.js with express

April 6, 2015

Reading Time: 2 minutes

This is going to be a multi-part series of posts to detail my current process for unit testing a full stack javascript application. Consider this my brain dump of information that I’ve either found from others posts, found in the official documentation or I’ve just been doing it that way because it makes sense in my head.

Unit testing has to be one of the most important aspects for any developer that’s serious about their work to start doing, and be disciplined enough to continue doing it regardless of some of the mind-numbing aspects of it.

Starting off we will be establishing the testing procedure for our javascript backend, which consists of node/io.js using express to serve up our restful api. I was shocked once I finally got everything working properly, with how easy it was to get going.

You will need to npm install the following modules:

mocha
supertest
chai

# npm install -g mocha
# npm install --save-dev supertest chai

1 2	# npm install -g mocha # npm install --save-dev supertest chai

These are the only modules necessary to do all your assertion/expect testing.

Once installed, I would suggest creating a test folder at the root of your application directory. Inside of this directory I will typically split groups of tests for each Controller in my application. Ending up with something like this:

/my-express-app
  /controllers
  /database
  /test
    /unit
      /fixtures
      myControllerSpec.js

/my-express-app

/controllers

/database

/test

/unit

/fixtures

myControllerSpec.js

The controller specs should be setup something like this:

var request = require('supertest'),
    express = require('express'),
    chai = require('chai');

var expect = chai.expect;

var app = require ('../app.js'); // path must be relative to current file.

describe('Unit: UserController', function(){
    var resource = 'user';

    describe('GET /user', function(){
  
        it('responds with all the users and status code 200', function(done){
            request(app)
                .get('/' + resource)
                .end(function(err, res){
                    expect(res.statusCode.to.equal(200);
                    expect(res.body.user).to.be.defined;
                    done();
            });
        });
    });
});

var request = require('supertest'),

express = require('express'),

chai = require('chai');

var expect = chai.expect;

var app = require ('../app.js'); // path must be relative to current file.

describe('Unit: UserController', function(){

var resource = 'user';

describe('GET /user', function(){

it('responds with all the users and status code 200', function(done){

request(app)

.get('/' + resource)

.end(function(err, res){

expect(res.statusCode.to.equal(200);

expect(res.body.user).to.be.defined;

done();

});

Now with that setup, you can just run from your project root, from the command line:

mocha -w test/unit/**/*.js

1	mocha -w test/unit/*/.js

and it will watch all test files for changes and run all your tests again, if a change is detected.

That’s all there is to it for getting true automatic testing going for your existing or next express api.

The next post will be for how to properly setup testing for the angular end of your application.

Node/ExpressJS Can’t Set Headers Bug…Possible solution

February 1, 2015

Reading Time: 1 minute

I was working on some of my more complex project aspects today, after spending an entire weekend setting up, and building out most of my applications unit and end-to-end tests when I noticed this issue when I moved onto the new build features inside of the Angular app:

Possibly unhandled Error: Can’t set headers after they are sent.

I’m scouring the code EVERYWHERE. How is this possible? According to my unit tests, I have code coverage across all of these functions with literally every permutation of tests imaginable, or did I???

Upon further inspection, I noticed that my AngularJS front end was making two identical calls to my API. This simultaneous connection request was enough to throw the error in the Node/ExpressJS backend.

tl:dr; – Check to be sure your AngularJS / Front End isn’t making simultaneous calls incorrectly to your API/Backend.

JavaScript Design Patterns

December 9, 2014

Reading Time: 1 minute

While in the process of needing to add some more complex functionality to my current ordering system project, I knew that I needed to start tackling the implementation for a number of design patterns for the front end. I finally took the time over the weekend to sit down and learn the ones that I needed to use and incorporated them with a basic AngularJS/Bootstrap/JQuery template.

Removing everything but exactly what I was trying to accomplish made understanding and implementing the patterns much more reasonable, as well as efficient.

I created a github repo to put them into in the event anyone else is looking to actually learn some design patterns in JavaScript as well. Check it out here:

https://github.com/SBero/JavascriptPatterns

I’ve so far implemented the following patterns:

Factory
Command
Memento
State
Strategy
Visitor
Chaining
Lazy Load

Hope this helps anyone out there looking to implement the same things themselves.