In the model's test example, we'll write two tests that verify the model save method. To begin testing your Article Mongoose model, you will need to create a new file named article.server.model.tests.js in your app/tests folder. In your new file, paste the following lines of code:

var app = require('../../server.js'),
    should = require('should'),
    mongoose = require('mongoose'),
    User = mongoose.model('User'),
    Article = mongoose.model('Article');

var user, article;

describe('Article Model Unit Tests:', function() {
  beforeEach(function(done) {
    user = new User({
      firstName: 'Full',
      lastName: 'Name',
      displayName: 'Full Name',
      email: '[email protected]',
      username: 'username',
      password: 'password'
    });

    user.save(function() {
      article = new Article({
        title: 'Article Title',
        content: 'Article Content',
        user: user
      });

      done();
    });
  });

  describe('Testing the save method', function() {
    it('Should be able to save without problems', function() {
      article.save(function(err) {
        should.not.exist(err);
      });
    });

    it('Should not be able to save an article without a title', function() {
      article.title = '';

      article.save(function(err) {
        should.exist(err);
      });
    });
  });

  afterEach(function(done) {
    Article.remove(function() {
      User.remove(function() {
        done();
      });
    });
  });
});

Let's start breaking down the test code. First, you required your module dependencies and defined your global variables. Then, you began your test using a describe() method, which informs the test tool this test is going to examine the Article model. Inside the describe block, we began by creating new user and article objects using the beforeEach() method. The beforeEach() method is used to define a block of code that runs before each test is executed. You can also replace it with the before() method, which will only get executed once, before all the tests are executed. Notice how the beforeEach() method informs the test framework that it can continue with the tests execution by calling the done() callback. This will allow the database operations to be completed before actually executing the tests.

Next, you created a new describe block indicating that you were about to test the model save method. In this block, you created two tests using the it() method. The first test used the article object to save a new article. Then, you used the Should.js assertion library to validate that no error occurred. The second test checked the Article model validation by assigning an invalid value to the title property. This time, the Should.js assertion library was used to validate that an error actually occured when trying to save an invalid article object.

You finished your tests by cleaning up the Article and User collections using the afterEach() method. Like with the beforeEach() method, this code will run after each test is executed, and can also be replaced with an after() method. The done() method is also used here in the same manner.

Congratulations, you created your first unit test! As we stated earlier, you can continue expanding this test suite to cover more of the model code, which you probably will when dealing with more complicated objects. Next, we'll see how you can write more advanced unit tests when covering your controller's code.

In the controller test example, we'll write two tests to check the controller's methods that retrieve articles. When setting out to write these tests, we have two options: either test the controller's methods directly or use the defined controller's Express routes in the tests. Although it is preferable to test each unit separately, we would choose to go with the second option since our routes' definition is quite simple, so we can benefit from writing more inclusive tests. To begin testing your articles controller, you will need to create a new file named articles.server.controller.tests.js in your app/tests folder. In your new file, paste the following code snippet:

var app = require('../../server'),
    request = require('supertest'),
    should = require('should'),
    mongoose = require('mongoose'),
    User = mongoose.model('User'),
    Article = mongoose.model('Article');

var user, article;

describe('Articles Controller Unit Tests:', function() {
  beforeEach(function(done) {
    user = new User({
      firstName: 'Full',
      lastName: 'Name',
      displayName: 'Full Name',
      email: '[email protected]',
      username: 'username',
      password: 'password'
    });

    user.save(function() {
      article = new Article({
        title: 'Article Title',
        content: 'Article Content',
        user: user
      });

      article.save(function(err) {
        done();
      });
    });
  });

  describe('Testing the GET methods', function() {
    it('Should be able to get the list of articles', function(done){
      request(app).get('/api/articles/')
        .set('Accept', 'application/json')
        .expect('Content-Type', /json/)
        .expect(200)
        .end(function(err, res) {
          res.body.should.be.an.Array.and.have.lengthOf(1);
          res.body[0].should.have.property('title', article.title);
          res.body[0].should.have.property('content', article.content);

          done();
        });
    });

    it('Should be able to get the specific article', function(done) {
      request(app).get('/api/articles/' + article.id)
        .set('Accept', 'application/json')
        .expect('Content-Type', /json/)
        .expect(200)
        .end(function(err, res) {
          res.body.should.be.an.Object.and.have.property('title', article.title);
          res.body.should.have.property('content', article.content);

          done();
        });
    });
  });

  afterEach(function(done) {
    Article.remove().exec();
    User.remove().exec();
    done();
  });
});

Just as with your model test, first you required your module dependencies and defined your global variables. Then, you started your test using a describe() method, which informs the test tool this test is going to examine the Articles controller. Inside the describe block, we began by creating new user and article objects using the beforeEach() method. This time, we saved the article before initiating the tests, and then continued with test execution by calling the done() callback.

Next, you created a new describe block indicating that you were about to test the controllers' GET methods. In this block, you created two tests using the it() method. The first test uses the SuperTest assertion library to issue an HTTP GET request at the endpoint that returns the list of articles. It then examines the HTTP response variables, including the content-type header and the HTTP response code. When it verifies the response is returned properly, it uses three Should.js assertion expressions to test the response body. The response body should be an array of articles that includes a single article that should be similar to the article you created in the beforeEach() method.

The second test uses the SuperTest assertion library to issue an HTTP GET request at the endpoint that returns a single article. It then examines the HTTP response variables including the content-type header and the HTTP response code. Once it verifies that the response is returned properly, it uses three Should.js assertion expressions to test the response body. The response body should be a single article object and should be similar to the article you created in the beforeEach() method.

Just as before, you finished your tests by cleaning up the Article and User collections using the afterEach() method. Once you're done setting up the testing environment and creating your tests, all you have left to do is run them using Mocha's command-line tool.

The Karma test runner is a utility developed by the AngularJS team that helps developers with executing tests in different browsers. It does so by starting a web server that runs source code with test code on selected browsers, reporting the tests result back to the command-line utility. Karma offers real test results for real devices and browsers, flow control for IDEs and the command line, and framework-agnostic testability. It also provides developers with a set of plugins that enables them to run tests with the most popular test frameworks. The team also provides special plugins called browser launchers that enable Karma to run tests on selected browsers.

In our case, we will use the Jasmine test framework along with a PhantomJS browser launcher. However, testing real applications will require you to expand Karma's configuration to include more launchers and execute tests on the browsers you intend to support.

The easiest way to start using Karma is to globally install the command-line tool provided using npm. To do so, just issue the following command in your command-line tool:

$ npm install -g karma-cli

This will install the latest version of Karma's command-line utility in your global node_modules folder. When the installation process is successfully finished, you'll be able to use the Karma utility from your command line. Next, you'll need to install Karma's project dependencies.

Before you can start writing your tests, you will need to install Karma's dependencies using npm. To do so, change your package.json file as follows:

{
  "name": "MEAN",
  "version": "0.0.10",
  "dependencies": {
    "express": "~4.8.8",
    "morgan": "~1.3.0",
    "compression": "~1.0.11",
    "body-parser": "~1.8.0",
    "method-override": "~2.2.0",
    "express-session": "~1.7.6",
    "ejs": "~1.0.0",
    "connect-flash": "~0.1.1",
    "mongoose": "~3.8.15",
    "passport": "~0.2.1",
    "passport-local": "~1.0.0",
    "passport-facebook": "~1.0.3",
    "passport-twitter": "~1.0.2",
    "passport-google-oauth": "~0.1.5",
    "socket.io": "~1.1.0",
    "connect-mongo": "~0.4.1",
    "cookie-parser": "~1.3.3"
  },
  "devDependencies": {
    "should": "~4.0.4",
    "supertest": "~0.13.0",
    "karma": "~0.12.23",
    "karma-jasmine": "~0.2.2",
    "karma-phantomjs-launcher": "~0.1.4"
  }
}

As you can see, you added Karma's core package, Karma's Jasmine plugin, and Karma's PhantomJS launcher to your devDependencies property. To install your new dependencies, go to your application's root folder and issue the following command in your command-line tool:

$ npm install

This will install the specified version of Karma's core package, Karma's Jasmine plugin, and Karma's PhantomJS launcher in your project's node_modules folder. When the installation process is successfully finished, you will be able to use these modules to run your tests. Next, you'll need to configure Karma's execution by adding a Karma configuration file.

In order to control Karma's test execution, you will need to configure Karma using a special configuration file placed at the root folder of your application. When executed, Karma will automatically look for the default configuration file named karma.conf.js in the application's root folder. You can also indicate your configuration file name using a command-line flag, but for simplicity reasons we'll use the default filename. To start configuring Karma, create a new file in your application folder, and name it karma.conf.js. In your new file, paste the following code snippet:

module.exports = function(config) {
  config.set({
    frameworks: ['jasmine'],
    files: [
      'public/lib/angular/angular.js',
      'public/lib/angular-resource/angular-resource.js',
      'public/lib/angular-route/angular-route.js',
      'public/lib/angular-mocks/angular-mocks.js',
      'public/application.js',
      'public/*[!lib]*/*.js',
      'public/*[!lib]*/*[!tests]*/*.js',
      'public/*[!lib]*/tests/unit/*.js'
    ],
    reporters: ['progress'],
    browsers: ['PhantomJS'],
    captureTimeout: 60000,
    singleRun: true
  });
};

As you can see, Karma's configuration file is used to set the way Karma executes tests. In this case, we used the following settings:

These properties are project-oriented, which means it will change according to your requirements. For instance, you'll probably include more browser launchers in real-world applications.

While testing an AngularJS application, it is recommended that unit tests execute quickly and separately from the backend server. This is because we want the unit tests to be as isolated as possible and work in a synchronous manner. This means we need to control the dependency injection process and provide mock components that emulate real components' operation. For instance, most of the components that communicate with the backend server are usually using the $http service or some sort of abstraction layer, such as the $resource service. Furthermore, the $http service sends requests to the server using the $httpBackend service. This means that by injecting a different $httpBackend service, we can send fake HTTP requests that won't hit a real server. As we previously stated, the AngularJS team is very committed to testing, so they already created these tools for us, wrapping these mock components in the ngMock module.

$httpBackend.expect('GET', '/user').respond({userId: 'userX'});

$httpBackend.when('GET', '/user').respond({userId: 'userX'});

{
  "name": "MEAN",
  "version": "0.0.10",
  "dependencies": {
    "angular": "~1.2",
    "angular-route": "~1.2",	
    "angular-resource": "~1.2",
    "angular-mocks": "~1.2"
  }
}

$ bower update

Once you're done configuring your test environment, writing unit tests becomes an easy task. To do so, you will use the ngMock module's supplied tools to test each component. While the general structure is the same, each entity test is a bit different and involves subtle changes. In this section, you'll learn how to test the major AngularJS entities. Let's begin with testing a module.

describe('Testing MEAN Main Module', function() {
  var mainModule;

  beforeEach(function() {
    mainModule = angular.module('mean');
  });

  it('Should be registered', function() {
    expect(mainModule).toBeDefined();
  });
});

describe('Testing Articles Controller', function() {
  var _scope, ArticlesController;

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

    inject(function($rootScope, $controller) {
      _scope = $rootScope.$new();
      ArticlesController = $controller('ArticlesController', {
        $scope: _scope
      });
    });
  });

  it('Should be registered', function() {
    expect(ArticlesController).toBeDefined();
  });

  it('Should include CRUD methods', function() {
    expect(_scope.find).toBeDefined();
    expect(_scope.findOne).toBeDefined();
    expect(_scope.create).toBeDefined();
    expect(_scope.delete).toBeDefined();
    expect(_scope.update).toBeDefined();
  });
});

describe('Testing Articles Service', function() {
  var _Articles;

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

    inject(function(Articles) {
      _Articles = Articles;
    });
  });

  it('Should be registered', function() {
    expect(_Articles).toBeDefined();
  });

  it('Should include $resource methods', function() {
    expect(_Articles.get).toBeDefined();
    expect(_Articles.query).toBeDefined();
    expect(_Articles.remove).toBeDefined();
    expect(_Articles.update).toBeDefined();
  });
});

describe('Testing Articles Routing', function() {
  beforeEach(module('mean'));

  it('Should map a "list" route', function() {
    inject(function($route) {
      expect($route.routes['/articles'].templateUrl).toEqual('articles/views/list-articles.view.html');
    });
  });
});

describe('Testing The ngBind Directive', function() {
  beforeEach(module('mean'));

  it('Should bind a value to an HTML element', function() {
    inject(function($rootScope, $compile) {
      var _scope = $rootScope.$new();
      element = $compile('<div data-ng-bind="testValue"></div>')(_scope);

      _scope.testValue = 'Hello World';
      _scope.$digest();

      expect(element.html()).toEqual(_scope.testValue);
    });
  });
});

describe('Testing The Lowercase Filter', function() {
  beforeEach(module('mean'));

  it('Should convert a string characters to lowercase', function() {
    inject(function($filter) {
      var input = 'Hello World';
      var toLowercaseFilter = $filter('lowercase');

      expect(toLowercaseFilter(input)).toEqual(input.toLowerCase());
    });
  });
});

A common requirement is testing your controller's methods. Since the ArticlesController methods use the $http service to communicate with the server, it would be appropriate to use the $httpBackend mock service. To begin writing the ArticlesController unit test, you will first need to create a new tests folder inside the public/articles folder. In the public/articles/tests folder, create a new folder for unit tests, called unit. Finally, in your public/articles/tests/unit folder, create a new file named articles.client.controller.unit.tests.js.

In your new file, paste the following code snippet:

describe('Testing Articles Controller', function() {
  var _scope, ArticlesController;

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

    jasmine.addMatchers({
      toEqualData: function(util, customEqualityTesters) {
        return {
          compare: function(actual, expected) {
            return {
              pass: angular.equals(actual, expected)
            };
          }
        };
      }
    });
    inject(function($rootScope, $controller) {
      _scope = $rootScope.$new();
      ArticlesController = $controller('ArticlesController', {
        $scope: _scope
      });
    });
  });

  it('Should have a find method that uses $resource to retrieve a list of articles', inject(function(Articles) {
    inject(function($httpBackend) {
      var sampleArticle = new Articles({
        title: 'An Article about MEAN',
        content: 'MEAN rocks!'
      });
      var sampleArticles = [sampleArticle];

      $httpBackend.expectGET('api/articles').respond(sampleArticles);

      _scope.find();
      $httpBackend.flush();

      expect(_scope.articles).toEqualData(sampleArticles);
    });
  }));
  it('Should have a findOne method that uses $resource to retreive a single of article', inject(function(Articles) {
    inject(function($httpBackend, $routeParams) {
      var sampleArticle = new Articles({
        title: 'An Article about MEAN',
        content: 'MEAN rocks!'
      });

      $routeParams.articleId = 'abcdef123456789012345678';

      $httpBackend.expectGET(/api/articles/([0-9a-fA-F]{24})$/).respond(sampleArticle);

      _scope.findOne();
      $httpBackend.flush();

      expect(_scope.article).toEqualData(sampleArticle);
    });
  }));
});

Let's break down the test code. First, you required your module dependencies, and defined your global variables. You started your test using a describe() method, which informs the test tool this test is going to examine ArticlesController. Inside the describe block, we began by creating a new controller and scope objects using the beforeEach() method.

Inside the beforeEach() method, we created a new custom Jasmine Matcher, called toEqualData. This matcher will compare a regular object and a $resource wrapped object using the angular.equal() method. We added this matcher because $resource adds quite a few properties to our objects, so the basic comparison matcher will not work.

You then created the first specification that is going to test the controller's find() method. The trick here is to use the $httpBackend.expectGET() method, which sets a new backend request assertion. This means that the test expects an HTTP request that fulfills this assertion, and will respond with a certain response. You then used the controller's find() method, which will create a pending HTTP request. The cycle ends when you call the $httpBackend.flush() method, which will simulate the server's response. You concluded the test by testing your model's values.

The second specification is almost identical to the first one but will test the controller's findOne() method. On top of the $httpBackend service, it also uses the $routeParams service to set the articleId route parameter. Now that you have your first unit test, let's see how you can execute it using Karma's command-line utility.

To run your AngularJS tests, you will need to use Karma's command-line utility you previously installed. To do so, use your command-line tool and navigate to your project's base folder. Then issue the following command:

$ NODE_ENV=test karma start

Windows users should first execute the following command:

> set NODE_ENV=test

Then run Karma using the following command:

> karma start

The preceding command will do a few things. First, it will set the NODE_ENV variable to test, forcing your MEAN application to use the test environment configuration file. Then, it will execute the Karma command-line utility. The test results should be reported in your command-line tool similar to the following screenshot:

Karma's test results

This concludes the unit test coverage of your AngularJS application. It is recommended that you use these methods to expand your test suite and include more components tests. In the next section, you'll learn about AngularJS E2E testing, and to write and run a cross-application E2E test.

To execute E2E tests, you will need some sort of tool that emulates user behavior. In the past, the AngularJS team advocated a tool called Angular scenario test runner. However, they decided to abandon this tool and create a new test runner called Protractor. Protractor is a dedicated E2E test runner that simulates human interactions and runs tests using the Jasmine test framework. It is basically a Node.js tool, which uses a neat library called WebDriver. WebDriver is an open source utility that allows programmable control over a web browser behavior. As we stated, Protractor is using Jasmine by default, so tests will look very similar to the unit tests you wrote before, but Protractor also provides you with several global objects as follows:

Using these utilities, you'll be able to perform browser operations inside your tests' specifications. For instance, the browser.get() method will load a page for you to perform tests on. It is important to remember that Protractor is a dedicated tool for AngularJS applications, so the browser.get() method will throw an error if the page it tries to load doesn't include the AngularJS library. You'll write your first E2E test in a moment, but first let's install Protractor.

Protractor is a command-line tool, so you'll need to globally install it using npm. To do so, just issue the following command in your command-line tool:

$ npm install -g protractor

This will install the latest version of Protractor command-line utilities in your global node_modules folder. When the installation process is successfully finished, you'll be able to use Protractor from your command line.

Since Protractor will need a working WebDriver server, you will either need to use a Selenium server or install a standalone WebDriver server. You can download and install a standalone server by issuing the following command in your command-line tool:

$ webdriver-manager update

This will install the Selenium standalone server, which you'll later use to handle Protractor's tests. The next step would be to configure Protractor's execution options.

In order to control Protractor's test execution, you will need to create a Protractor configuration file in the root folder of your application. When executed, Protractor will automatically look for a configuration file named protractor.conf.js in your application's root folder. You can also indicate your configuration filename using a command-line flag, but for simplicity reasons, we'll use the default filename. So begin by creating a new file named protractor.conf.js in your application's root folder. In your new file, paste the following lines of code:

exports.config = {
  specs: ['public/*[!lib]*/tests/e2e/*.js']
}

Our Protractor's configuration file is very basic and only includes one property. The specs property basically tells Protractor where to find the test files. This configuration is project-oriented, which means that it will change according to your requirements. For instance, you'll probably change the list of browsers you want your tests to run on.

Since E2E tests are quite complicated to write and read, we'll begin with a simple example. In our example, we'll test the Create Article page and try to create a new article. Since we didn't log in first, an error should occur and be presented to the user. To implement this test, go to your public/articles/tests folder and create a new folder named e2e. Inside your new folder, create a new file named articles.client.e2e.tests.js. Finally, in your new file, paste the following code snippet:

describe('Articles E2E Tests:', function() {
  describe('New Article Page', function() {
    it('Should not be able to create a new article', function() {
      browser.get('http://localhost:3000/#!/articles/create');
      element(by.css('input[type=submit]')).click();
      element(by.binding('error')).getText().then(function(errorText) {
        expect(errorText).toBe('User is not logged in');
      });
    });
  });
});

The general test structure should already be familiar to you; however, the test itself is quite different. We began by requesting the Create Article page using the browser.get() method. Then, we used the element() and by.css() methods to submit the form. Finally, we found the error message element using by.binding() and validated the error text. While this is a simple example, it illustrates well the way E2E tests work. Next we'll use Protractor to run this test.

Running Protractor is a bit different than using Karma and Mocha. Protractor needs your application to run so that it can access it just like a real user does. So let's begin by running the application; navigate to your application's root folder and use your command-line tool to start the MEAN application as follows:

$ NODE_ENV=test node server

Windows users should first execute the following command:

> set NODE_ENV=test

Then run their application using the following command:

> node server

This will start your MEAN application using the test environment configuration file. Now, open a new command-line window and navigate to your application's root folder. Then, start the Protractor test runner by issuing the following command:

$ protractor

Protractor should run your tests and report the results in your command-line window as shown in the following screenshot:

Protractor's test results

Congratulations! You now know how to cover your application code with E2E tests. It is recommended that you use these methods to expand your test suite and include extensive E2E tests.