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.

Let’s break down one of the unit tests:

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.:

TODO Directive Items

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

MEAN Todo Directive - Edit Mode

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.

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:

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

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:

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.

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:

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):

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:

My files array looks like this:

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:

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:

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:

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:

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:

The beforeEach is a bit more complex for the controller:

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.

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.

 

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.

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

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:

The controller specs should be setup something like this:

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

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.