Greg Conant - I Type Things In

AngularJS Unit Testing Notes

Wed, 17 Aug 2016 12:00:00 +0000

We’ve been doing more Angular work recently, and I’ve been getting back into it after being mostly away from Angular for a couple years. I never had very much experience with Jasmine tests for anything other than the most trivial or isolated functions. It seemed like a lot of work and magic to get all the bits working together, despite Angular’s focus on making everything testable.

I’m bound to forget again the next time I need it, so I wanted to take this time to record my notes about the different types of objects you may want to test, and the different ways you test them.

This will follow the basic layers of “Controller -> Service -> [Data]”, where “[Data]” is probably just an API call using the $http service (by default very mockable, thankfully). This should cover most cases I will need for the immediate future.

Testing Controllers Let’s say I have a trivial controller like this, that just populates some scope variables with data returned from a service:

angular
  .module('myModule')
  .controller('myFirstController', ['$scope', 'businessLogicService',
    function myFirstController($scope, businessLogicService) {
        $scope.games = {
            'name': 'My Games',
            'values': []
        };
        $scope.books = {
            'name': 'My Books',                    
            'values': []
        }            
    };
  
    businessLogicService.getAllData(function (response) {
        $scope.games = response.value.games;
        $scope.books = response.value.books;
    });
}]);

And I want to have tests to make sure it populates the right parts of the scope. I can inject a mock service like so, and assert that it sets the values on the scope:

describe('myFirstController',
    function () {
        var $rootScope,            
            createController,
            businessLogicService;

        beforeEach(function () {
            module('myModule');

            module(function ($provide) {
                $provide.constant('config', config);
            });
        });

        beforeEach(inject(function ($injector) {
            $rootScope = $injector.get('$rootScope');
            
            businessLogicService = $injector.get('businessLogicService');

            var $controller = $injector.get('$controller');

            createController = function () {
                return $controller('myFirstController',
                {
                    '$scope': $rootScope,
                    'businessLogicService': businessLogicService
                });
            };
        }));

    it('should set books and games correctly',
        function () {
            // Arrange
            var mockData = { 
                'books': {
                    'name': 'Mock Books',
                    'values': [{'title': 'Book 1' }, { 'title': 'Book 2' }]
                },
                'games': {
                    'name': 'Mock Games',
                    'values': [{'title': 'Game 1' }, { 'title': 'Game 2' }, , { 'title': 'Game 3' }]
                },
            }; ;
            
            businessLogicService.getAllData = function (func) {
                var response = { value: mockData };
                func(response);
            }

            // Act
            createController();

            // Assert
            expect($rootScope.games).toBe(mockData.books);
            expect($rootScope.games).toBe(mockData.games);
    });
});

The nice thing is that it isn’t doing anything too complex here. The most confusing bits to me were the ‘$injector’ and ‘$provide’ services. The angular documentation doesn’t help at all:

$injector is used to retrieve object instances as defined by provider, instantiate types, invoke methods, and load modules.

Oh, I… see. Maybe there is a useful example I can refer to:

var $injector = angular.injector();
expect($injector.get('$injector')).toBe($injector);
expect($injector.invoke(function($injector) {
  return $injector;
})).toBe($injector);

Of course. Now it makes sense. $injector. Maybe if I look up $provide?

The $provide service has a number of methods for registering components with the $injector.

Haha. Ugh. Nobody said it would be easy!

So from a unit testing perspective, these two things work together to let you mock out dependencies. So if I have a controller that needs some configuration value/options called ‘config’:

angular.module('myModule').controller('myFirstController', ['$scope', 'config', function myFirstController($scope, config) {
...
}]);

I can have the $injector, which is called for me, provide my stubbed config data by setting it up through $provider in the Jasmine test:

describe('myFirstController',
    function () {
        var config = { configValue: 'stubConfigValue' };
        ...
        beforeEach(function () {
            ...
            module(function ($provide) {
                $provide.constant('config', config);
            });
            ...
        });
    });

So now when my controller is created when running this test, it will get my ‘config’ variable passed in. Definitely useful, but not intuitive if you’re as used to more traditional server-side mocking frameworks.

I’ll write another post later about testing the service in isolation, which will involve testing its interactions with the $http service provided by Angular. Fortunately there is a lot of documentation already out there to get started as this is a pretty common need.

The Necessity of Abstractions

Wed, 30 Mar 2016 17:00:00 +0000

We’ve been dealing with some pretty old code lately. And by “lately”, I mean “always”. As a result, we have frequent discussions about refactoring (and, jokingly, rewriting the entire thing). Which, I think we can all agree, is rarely possible or realistic.

I’ve been encouraging the team to take more of a “do what we can to write tests around this, even if it’s ugly” mentality, because I don’t see another way to get the codebase to improve.

It’s been generally agreed that you should write tests around your legacy code as you’re refactoring it, assuming those tests don’t already exist, so you know that your refactoring won’t break anything.

In addition to making your code able to be tested, it should accomplish the additional benefits of making your code more loosely coupled, and more readable.

From a high level, this is done by adding abstractions. One of the biggest problems with legacy code is often is misuse (or complete lack) of abstractions.

You’ll often see some server-side code that contains the entire business case in one giant function, from handling UI logic down to persisting to the database. This tight coupling makes it much harder to test, and makes it so you have to understand every line of the function in order to work on any of it.

When we were discussing a case like this, and I recommended refactoring some of this logic into separate classes to test against, one of my teammates dismissively responded with something along the lines of, “yeah, great. More abstractions. Is our job to add more complexity?”

This blew my mind. I think creating abstractions is the only way to understand large or complicated applications. Limiting how much you need to know at any time so you know what to focus on is crucial to solve problems. Otherwise you spend valuable time trying to figure out what some confusing “for” loop is doing that could be completely unrelated.

A colleague at a former employer also verbally opposed the idea of putting logic in a clearly-named function, instead preferring to put all the code in that function inline with the rest of the complex logic. This person seemed to prefer to keep all of the logic in his head at once instead of “jumping around” to different functions and methods.

Maybe I’m just not smart enough to keep that much in my head at once. But I find it so much easier to be able to compartmentalize problems and only worry about certain parts of the code at a time.

I once heard someone advocate that all your code in a function should be at about the same level of abstraction and domain logic. So if you execute “DoABusinessThing()”, you shouldn’t then have, at the same level, a fiddly loop that handles lists or array indexes and does some math. Even if you just push that into a function that you give a clearer name to, the reader can keep only the high-level steps in mind without worrying about implementation details.

It surprises me that a developer would be so opposed to introducing abstractions. If you think that introducing abstractions adds complexity instead of reducing it, your abstractions are probably not very abstract at all.

Git - Diffing All Changed Files Between Branches

Fri, 26 Feb 2016 17:00:00 +0000

I’ve been pretty used to Git for years now, so I’ve gotten used to its standard workflow. I really enjoy seeing differences in files as a +/- system where you can compare the changes one after another.

At my latest company, we are heavily based in TFS, and are slowly moving to Git. It’s a pretty good reminder that things that are obvious to me aren’t necessarily obvious to anyone else, and I probably went through the same struggles myself, back when I first learned about Git.

A coworker is getting more used to collaborating in Git, and is more used to the “Visual Studio/TFS” workflow.

His concern was that, when doing code reviews, he is used to comparing two commits, getting a list of all the files that are changed, and going through them one at a time to review. Seeing that list of changed files up front is useful to him, and doing everything from one environment instead of switching from Visual Studio to the command line.

Either Visual Studio or Beyond Compare are acceptable solutions, as long as it’s not just ‘compare this file, close the window, compare the next file’.

It just took a bit of searching, but I learned something new about Git and diffing branches that I’ll probably use again.

Note that these findings were from the accepted answer here.

First, I set BC to be my default diff tool and set the path for it:

git config --global diff.tool bc3
git config --global difftool.bc3.path "<path_to_bcomp>"

Then, I can tell git to do ‘difftool’ instead of the standard ‘git diff’.

git difftool --dir-diff branch1 branch2

There are two things to note going on here.

If you do

git diff branch1 branch2

Then it will diff each hunk, one after another, file by file.

And the

--dir-diff

will still call out to Beyond Compare, but it will ask you file-by-file whether you’d like to diff it or move to the next one.

git diff branch1 branch2

Then it will diff each hunk, one after another, file by file.

which is the same as:

git difftool --d branch1 branch2

Once I do this, it will open a “folder compare” view in BC that shows all changed files in their respective files, and you can select them in any order and compare the files in each branch.

It’s one of my missions to get people who are unused to Git not to be afraid of trying without throwing them into the deep end.