How To Test An Angular Js Service

Your new best friend.

If at that place was a way to reduce the number of defects in the code you write (or manage), improve the quality and fourth dimension to market place of deliverables, and make things easier to maintain for those who come later on you lot- would you lot do it?

Right most now, especially given the content of the article, you might exist sensing that I'g virtually to jump into the usual testing zealot rant. And you're right.

How many times accept you heard some variant on, "Writing tests isn't as important as delivering finished code?" If yous're similar me, it's manner too many, and god aid you if you're working with no tests at all. Programmers are human being and nosotros all make mistakes. So test your code. The number of times testing my lawmaking has helped me grab unforeseen issues earlier they became flat-out bugs, forbid hereafter regressions, or but architect better is pretty amazing. And this is coming from a guy who used to hate writing tests for code. Hated it.

I think that stemmed more than from a lack of agreement how to practise it than anything else. When systems get complex and have a lot of moving parts is when it is most critical to exam them, and that is likewise when information technology becomes the most difficult to exam them. Without an understanding of your tools (eastward.one thousand. mocks) or why each slice is of import, and peculiarly with a lack of easily attainable examples, testing code can be really intimidating and frustrating.

So what do you do? You commit code without tests. Y'all are cowboy. Cowboy no test.

But as some of yous probably know all too well, this is unsafe. It's like going on holiday in the Caribbean area using your credit card. Fun for a while, and everything seems nifty, until suddenly reality hits and it takes all the running you can do just to stay in the same place.

Fortunately Athwart treats us really well as far equally testing goes. It just requires some additional explanation, since the quality of resources available for both Athwart and Jasmine is actually not fantastic. It's better than a yr ago, definitely, simply not fantastic.

So here I am doing a encephalon dump of sorts of what I know about testing services, which are office of the lifeblood of any Angular application.

Section 1: In Which I Proclaim "I love Dependency Injection!"

When I first saw someone nowadays on Angular, they got kind of hand-wavey about Dependency Injection. "The way I see it, it'southward basically magic and I don't have to recall about it." Ahhh. Not what I like to hear.

I go that it can be kind of scary, hearing people throw around jargon similar injectors and providers and dependency injection like they're nothing, merely you can go information technology. I know y'all can.

Information technology's elementary. Non piece of cake, simply simple. When Angular runs the code that you define for a controller or a service, it looks at the parameters you have attached to the role and sets them correctly for that run based on their names. Allow's say that you have something like this:

          angular.module("foo").controller("NavCtrl", role ($scope, tabService) {   // ... });

The order of the parameters on your office doesn't affair. You could simply every bit hands take said part (tabService, $scope) and both of those values would still be gear up correctly. That's a prissy advantage in itself, and it's why you run across funny business like:

          angular.module("foo").controller("NavCtrl", [   "$scope",   "tabService",   function($scope, tabService) {     // ...   } ]);

That'southward so that minification, which renames all of your passed variables in functions, doesn't accident up Angular'south dependency injection. Angular knows how to handle this if y'all use the second form of notation.

But why are we even messing with this at all? It's considering if nosotros inject the dependencies, we can control them from the exterior earth. And this is eminently important for testing.

This kind of affair (admittedly contrived for effect):

          role mungeSomeData(data) {   var dataGetter, dataParser, dataTransformer;   dataGetter = new DataGetter();   dataParser = new DataParser();   dataTransformer = information.isXML() ? new XMLDataTransformer() : new JSONDataTransformer();   // ... }

Doesn't use Depdency Injection, and is a nightmare to test. Minimizing surface area to test is and so so important, and by writing code that manner y'all make your surface area HUGE and slippery.

Side note: It is Angular convention to accept a dollar sign ($) in the forepart of the names of things that are both injected ($scope, $timeout, $http) and congenital-in to Angular. If you lot meet $telescopic beingness used in the link function of a directive, that is both wrong and confusing since parameters are passed to the link function of directives, not injected. Please Blob out when y'all encounter this and correct the code. If y'all are using vim a simple :%s/$scope/scope/ (or possibly but :s in visual mode if you lot accept instances of $scope that shouldn't exist replaced) will practice the trick.

Q: So what does that have to do with unit testing AngularJS services, Nate?

It has everything to do with testing services since they are injected. So, in unit testing a service, you can control precisely what goes on in one in addition to all of its dependencies.

Q: Will you testify usa some actual Jasmine code already?

Getting there.

Department 2: In Which I Write an Bodily Service, and a Unit Test for Information technology

Allow's say that I'g writing an Angular app which interacts with the Reddit API. Since we know that services are the part which Angular uses to interact with the outside globe, we will write a service to handle our needs.

We are going to write one with a method getSubredditsSubmittedToBy(user) which returns a list of which subreddits a user has submitted to recently. We can employ promise chaining to attain this (aggregating the big glob of JSON returned by the API phone call) so that our controller stays super lean.

Writing the Service

Usage (inside controller):

          userService.getSubredditsSubmittedToBy("yoitsnate").and so(function(subreddits) {   $scope.subreddits = subreddits; });

So nice and readable!

Our service looks similar this:

          angular.module("reddit").service("userService", function($http) {   render {     getSubredditsSubmittedToBy: function(user) {       return $http.get("http://api.reddit.com/user/" + user + "/submitted.json").and then(office(response) {         var posts, subreddits;          posts = response.data.data.children;          // transform information to be only subreddit strings         subreddits = posts.map(function(mail) {           return post.data.subreddit;         });          // de-dupe         subreddits = subreddits.filter(function(element, position) {           return subreddits.indexOf(chemical element) === position;         });          return subreddits;       });     }   }; });

Writing the examination

We volition write a test using Jasmine. Jasmine is a Beliefs-Driven-Evolution framework, which is sort of a roundabout way of saying that our tests include descriptions of the sections that they are testing and what they are supposed to exercise. This is washed using nested draw and it blocks, which look really weird at first (something about a function as brusk every bit it is but unsettling to me ;) ) but can be helpful in understanding what the exam is intended to, well, test.

This is quite helpful as sometimes large elaborate codebases accept large elaborate tests and it tin can be hard to figure out what'southward what. For instance, in PHPUnit, this kind of "congenital-in documentation" is spread out and by and large optional, and makes complex unit tests a bit trickier to read.

Using Karma we first tell it what module we're working in ("reddit"), run an inject function to set up our dependencies and get the service under test (this allows u.s. access to Angular'southward injector so we can set local test variables), then run an actual test in the it block.

Discover that in the inject method we inject in _foo_, with an underscore on either side of the name of the actual service, and then that we tin can set it in the outer describe closure. This is by design, equally the Angular maintainers foresaw (or discovered) that:

          var userService; beforeEach(inject(userService) {   userService = userService; });

would outcome in an error.

So utilise _underscoreNotation_ to go the service that you want to test :)

          "use strict";  describe("reddit api service", function () {   var userService, httpBackend;    beforeEach(module("reddit"));    beforeEach(inject(function (_userService_, $httpBackend) {     userService = _userService_;     httpBackend = $httpBackend;   }));    it("should exercise something", function () {     httpBackend.whenGET("http://api.reddit.com/user/yoitsnate/submitted.json").respond({         data: {           children: [             {               data: {                 subreddit: "golang"               }             },             {               data: {                 subreddit: "javascript"               }             },             {               data: {                 subreddit: "golang"               }             },             {               data: {                 subreddit: "javascript"               }             }           ]         }     });     userService.getSubredditsSubmittedToBy("yoitsnate").and so(function(subreddits) {       expect(subreddits).toEqual(["golang", "javascript"]);     });     httpBackend.flush();   });  });

Our mock information here mimics the bodily data returned by the Reddit API, but only plenty that we get the necessary bits of construction in place and can account for, say, the duplicate case. If we wanted to add unlike functionality for dissimilar pieces of the API, or of this call, nosotros could merely ascertain new httpBackend responses in new it blocks and test things the same style without having to worry about the bits of the API response we don't need.

The provider idiom

Unfortunately my unproblematic example to a higher place breaks downwardly a footling chip if we have additional dependencies on other services in our service under test. What practice we do in this example? We need to command these injected parameters, and to do so we use $provide. $provide can accept the name of e.k. a service and dictate what to provide for it. In doing so we can, say, use a spy object instead of the "real deal".

          beforeEach(module(role($provide) {   $provide.value("myDependentService", serviceThatsActuallyASpyObject); }));

Note that $provide should always be called before your call to $inject, since the former dicates what the latter should employ.

Section 3: Helpful Tips

Stutter.

If you modify a describe or it cake to ddescribe or iit respectively Karma (Angular's examination runner) will run only that block. This is chosen stuttering and it is very useful if y'all don't desire to run your entire test suite every time, every bit the larger the codebase gets the longer this will have to practise.

Don't be agape to rearrange code that is difficult to test

If yous can movement lawmaking effectually to make it easier to test without changing other things, Exercise It (in a general sense I observe that this eases readability and maintainability too). For instance I found that in one instance in a service a colleague was relying on a function phone call that was both unneccesary and confusing, and ultimately broke the chain of promises. So I deleted the function definition and inlined the code it contained. The resulting lawmaking was a bit easier to read and exam.

Cheat.

You can create stubbed objects quite easily in JavaScript, so if there's no need to introduce the extra complexity of a spy (meet side by side section), then do and then. For example, if you tin just render iv from a method every time you phone call it instead of counting the elements or whatever information technology usually does, then do so.

Do you lot need a Spy?

If you need more than power / assertions out of the concluding indicate, Jasmine provides Spies for you to utilise.

They're a little out of telescopic for this article, but they should provide you all of the flexibility you demand for faking data / objects / calls and testing what was faked.

For a proficient reference, run across this Jasmine spy cheatsheet.

Or just apply `$q` / manually manage promises

I plant myself in kind of a funny situation at work recently. We utilize Angular for structure but the codebase we are working on has a lot of pre-existing bits/modules that were non actually moved over to Angular fully due to intense borderline pressure. So, we find ourselves making XMLHttpRequests outside of $http state, but the original programmers still return promises from their exterior world modules for us to use (it's kind of an odd setup that we don't really accept time to refactor). And then, I merely acquired the functions that accept care of those API calls render promises that I control using $q.

          var mockDeferred; mockDeferred = $q.defer(); someSpyObj.methodThatReturnsAPromise.andCallFake(function () {   return mockDeferred.promise; }); mockDeferred.resolve({   things: "foo",   otherThings: "bar" });

Determination.

Jasmine tests are pretty quick to write one time y'all become the hang of them. Seriously guys, at that place's no alibi.

The violent psychopath who ends up maintaining your code volition thank y'all. Or at least not murder you.

Until adjacent fourth dimension, stay sassy Cyberspace, and consider subscribing to my weblog.

Nathan