Improve this Doc  View Source

$httpBackend

  1. - service in module ngMock

Overview

Fake HTTP backend implementation suitable for unit testing applications that use the $http service.

Note: For fake HTTP backend implementation suitable for end-to-end testing or backend-less development please see e2e $httpBackend mock.

During unit testing, we want our unit tests to run quickly and have no external dependencies so we don’t want to send XHR or JSONP requests to a real server. All we really need is to verify whether a certain request has been sent or not, or alternatively just let the application make requests, respond with pre-trained responses and assert that the end result is what we expect it to be.

This mock implementation can be used to respond with static or dynamic responses via the expect and when apis and their shortcuts (expectGET, whenPOST, etc).

When an AngularJS application needs some data from a server, it calls the $http service, which sends the request to a real server using $httpBackend service. With dependency injection, it is easy to inject $httpBackend mock (which has the same API as $httpBackend) and use it to verify the requests and respond with some testing data without sending a request to a real server.

There are two ways to specify what test data should be returned as http responses by the mock backend when the code under test makes http requests:

Request Expectations vs Backend Definitions

Request expectations provide a way to make assertions about requests made by the application and to define responses for those requests. The test will fail if the expected requests are not made or they are made in the wrong order.

Backend definitions allow you to define a fake backend for your application which doesn't assert if a particular request was made or not, it just returns a trained response if a request is made. The test will pass whether or not the request gets made during testing.

Request expectationsBackend definitions
Syntax .expect(...).respond(...) .when(...).respond(...)
Typical usage strict unit tests loose (black-box) unit testing
Fulfills multiple requests NO YES
Order of requests matters YES NO
Request required YES NO
Response required optional (see below) YES

In cases where both backend definitions and request expectations are specified during unit testing, the request expectations are evaluated first.

If a request expectation has no response specified, the algorithm will search your backend definitions for an appropriate response.

If a request didn't match any expectation or if the expectation doesn't have the response defined, the backend definitions are evaluated in sequential order to see if any of them match the request. The response from the first matched definition is returned.

Flushing HTTP requests

The $httpBackend used in production always responds to requests asynchronously. If we preserved this behavior in unit testing, we'd have to create async unit tests, which are hard to write, to follow and to maintain. But neither can the testing mock respond synchronously; that would change the execution of the code under test. For this reason, the mock $httpBackend has a flush() method, which allows the test to explicitly flush pending requests. This preserves the async api of the backend, while allowing the test to execute synchronously.

Unit testing with mock $httpBackend

The following code shows how to setup and use the mock backend when unit testing a controller. First we create the controller under test:

// The module code
angular
  .module('MyApp', [])
  .controller('MyController', MyController);

// The controller code
function MyController($scope, $http) {
  var authToken;

  $http.get('/auth.py').then(function(response) {
    authToken = response.headers('A-Token');
    $scope.user = response.data;
  }).catch(function() {
    $scope.status = 'Failed...';
  });

  $scope.saveMessage = function(message) {
    var headers = { 'Authorization': authToken };
    $scope.status = 'Saving...';

    $http.post('/add-msg.py', message, { headers: headers } ).then(function(response) {
      $scope.status = '';
    }).catch(function() {
      $scope.status = 'Failed...';
    });
  };
}

Now we setup the mock backend and create the test specs:

// testing controller
describe('MyController', function() {
   var $httpBackend, $rootScope, createController, authRequestHandler;

   // Set up the module
   beforeEach(module('MyApp'));

   beforeEach(inject(function($injector) {
     // Set up the mock http service responses
     $httpBackend = $injector.get('$httpBackend');
     // backend definition common for all tests
     authRequestHandler = $httpBackend.when('GET', '/auth.py')
                            .respond({userId: 'userX'}, {'A-Token': 'xxx'});

     // Get hold of a scope (i.e. the root scope)
     $rootScope = $injector.get('$rootScope');
     // The $controller service is used to create instances of controllers
     var $controller = $injector.get('$controller');

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


   afterEach(function() {
     $httpBackend.verifyNoOutstandingExpectation();
     $httpBackend.verifyNoOutstandingRequest();
   });


   it('should fetch authentication token', function() {
     $httpBackend.expectGET('/auth.py');
     var controller = createController();
     $httpBackend.flush();
   });


   it('should fail authentication', function() {

     // Notice how you can change the response even after it was set
     authRequestHandler.respond(401, '');

     $httpBackend.expectGET('/auth.py');
     var controller = createController();
     $httpBackend.flush();
     expect($rootScope.status).toBe('Failed...');
   });


   it('should send msg to server', function() {
     var controller = createController();
     $httpBackend.flush();

     // now you don’t care about the authentication, but
     // the controller will still send the request and
     // $httpBackend will respond without you having to
     // specify the expectation and response for this request

     $httpBackend.expectPOST('/add-msg.py', 'message content').respond(201, '');
     $rootScope.saveMessage('message content');
     expect($rootScope.status).toBe('Saving...');
     $httpBackend.flush();
     expect($rootScope.status).toBe('');
   });


   it('should send auth header', function() {
     var controller = createController();
     $httpBackend.flush();

     $httpBackend.expectPOST('/add-msg.py', undefined, function(headers) {
       // check if the header was sent, if it wasn't the expectation won't
       // match the request and the test will fail
       return headers['Authorization'] === 'xxx';
     }).respond(201, '');

     $rootScope.saveMessage('whatever');
     $httpBackend.flush();
   });
});

Dynamic responses

You define a response to a request by chaining a call to respond() onto a definition or expectation. If you provide a callback as the first parameter to respond(callback) then you can dynamically generate a response based on the properties of the request.

The callback function should be of the form function(method, url, data, headers, params).

Query parameters

By default, query parameters on request URLs are parsed into the params object. So a request URL of /list?q=searchstr&orderby=-name would set params to be {q: 'searchstr', orderby: '-name'}.

Regex parameter matching

If an expectation or definition uses a regex to match the URL, you can provide an array of keys via a params argument. The index of each key in the array will match the index of a group in the regex.

The params object in the callback will now have properties with these keys, which hold the value of the corresponding group in the regex.

This also applies to the when and expect shortcut methods.

$httpBackend.expect('GET', /\/user\/(.+)/, undefined, undefined, ['id'])
  .respond(function(method, url, data, headers, params) {
    // for requested url of '/user/1234' params is {id: '1234'}
  });

$httpBackend.whenPATCH(/\/user\/(.+)\/article\/(.+)/, undefined, undefined, ['user', 'article'])
  .respond(function(method, url, data, headers, params) {
    // for url of '/user/1234/article/567' params is {user: '1234', article: '567'}
  });

Matching route requests

For extra convenience, whenRoute and expectRoute shortcuts are available. These methods offer colon delimited matching of the url path, ignoring the query string and trailing slashes. This allows declarations similar to how application routes are configured with $routeProvider. Because these methods convert the definition url to regex, declaration order is important. Combined with query parameter parsing, the following is possible:

$httpBackend.whenRoute('GET', '/users/:id')
  .respond(function(method, url, data, headers, params) {
    return [200, MockUserList[Number(params.id)]];
  });

$httpBackend.whenRoute('GET', '/users')
  .respond(function(method, url, data, headers, params) {
    var userList = angular.copy(MockUserList),
      defaultSort = 'lastName',
      count, pages, isPrevious, isNext;

    // paged api response '/v1/users?page=2'
    params.page = Number(params.page) || 1;

    // query for last names '/v1/users?q=Archer'
    if (params.q) {
      userList = $filter('filter')({lastName: params.q});
    }

    pages = Math.ceil(userList.length / pagingLength);
    isPrevious = params.page > 1;
    isNext = params.page < pages;

    return [200, {
      count:    userList.length,
      previous: isPrevious,
      next:     isNext,
      // sort field -> '/v1/users?sortBy=firstName'
      results:  $filter('orderBy')(userList, params.sortBy || defaultSort)
                  .splice((params.page - 1) * pagingLength, pagingLength)
    }];
  });

Methods