Зависимости от насмешек в тестах AngularJS

 module(function($provide) {
  $provide.provider('sample', function() {
    this.register = jasmine.createSpy('register');

    this.$get = function() {
      var getRegisteredVals = jasmine.createSpy('getRegisteredVals');

      return {
        getRegisteredVals: getRegisteredVals
      };
    };
  });
});

//Getting reference of the provider
var sampleProviderObj;

module(function(sampleProvider) {
  sampleProviderObj = sampleProvider;
});

Разница между получением ссылки на провайдеров и другими синглетонами заключается в том, что провайдеры недоступны в inject () блокировке, поскольку к этому времени провайдеры преобразованы в фабрики. Мы можем получить их объекты с помощью блока module () .

В случае определения провайдеров реализация метода $ get также обязательна в тестах. Если вам не нужна функциональность, определенная в функции $ get в тестовом файле, вы можете назначить ее пустой функции.

Mocking Modules

Если для модуля, загружаемого в тестовый файл, требуется набор других модулей, тестируемый модуль не может быть загружен, пока не будут загружены все необходимые модули. Загрузка всех этих модулей иногда приводит к плохим тестам, так как некоторые из реальных методов обслуживания могут быть вызваны из тестов. Чтобы избежать этих трудностей, мы можем создать фиктивные модули для загрузки тестируемого модуля.

Например, предположим, что следующий код представляет модуль с добавленным примером сервиса:

 angular.module('first', ['second', 'third'])
  //util and storage are defined in second and third respectively
  .service('sampleSvc', function(utilSvc, storageSvc) {
    //Service implementation
  });

Следующий код является блоком beforeEach в тестовом файле примера сервиса:

 beforeEach(function() {
  angular.module('second',[]);
  angular.module('third',[]);
  
  module('first');
  
  module(function($provide) {
    $provide.service('utilSvc', function() {
      // Mocking utilSvc
    });

    $provide.service('storageSvc', function() {
      // Mocking storageSvc
    });
  });
});

В качестве альтернативы, мы также можем добавить фиктивные реализации сервисов к фиктивным модулям, определенным выше.

Насмешливые методы, возвращающие обещания

Может быть сложно написать сквозное приложение Angular без обещаний. Это становится проблемой для тестирования фрагмента кода, который зависит от метода, возвращающего обещание. Простой шпион Jasmine приведет к провалу некоторых тестовых случаев, так как тестируемая функция ожидает объект со структурой фактического обещания.

Асинхронные методы можно смоделировать с помощью другого асинхронного метода, который возвращает обещание со статическими значениями. Рассмотрим следующую фабрику:

 angular.module('moduleUsingPromise', [])
  .factory('dataSvc', function(dataSourceSvc, $q) {
    function getData() {
      var deferred = $q.defer();

      dataSourceSvc.getAllItems().then(function(data) {
        deferred.resolve(data);
      }, function(error) {
        deferred.reject(error);
      });

      return deferred.promise;
    }

    return {
      getData: getData
    };
  });

Мы протестируем функцию getData () на вышеупомянутой фабрике. Как видим, это зависит от метода getAllItems () сервиса dataSourceSvc . Нам нужно смоделировать сервис и метод перед тестированием функциональности метода getData () .

У службы $ q есть методы when () и reject (), которые позволяют разрешать или отклонять обещание со статическими значениями. Эти методы пригодятся в тестах, которые имитируют метод, возвращающий обещание. Следующий фрагмент проверяет фабрику dataSourceSvc :

 module(function($provide) {
  $provide.factory('dataSourceSvc', function($q) {
    var getAllItems = jasmine.createSpy('getAllItems').andCallFake(function() {
      var items = [];

      if (passPromise) {
        return $q.when(items);
      }
      else {
        return $q.reject('something went wrong');
      }
    });

    return {
      getAllItems: getAllItems
    };
  });
});

Обещание $ q завершает свое действие после следующего цикла дайджеста. Цикл дайджеста продолжается в реальном приложении, но не в тестах. Итак, нам нужно вручную вызвать $ rootScope. $ Digest () для принудительного выполнения обещания. Следующий фрагмент кода показывает пример теста:

 it('should resolve promise', function() {
  passPromise = true;

  var items;

  dataSvcObj.getData().then(function(data) {
    items=data;
  });
  rootScope.$digest();

  expect(mockDataSourceSvc.getAllItems).toHaveBeenCalled();
  expect(items).toEqual([]);
});

Дразнящие глобальные объекты

Глобальные объекты поступают из следующих источников:

1. Объекты, которые являются частью глобального объекта ‘окна’ (например, localStorage, indexedDb, Math и т. Д.).
2. Объекты, созданные сторонней библиотекой, такой как jQuery, подчеркивание, момент, ветерок или любая другая библиотека.

По умолчанию глобальные объекты не могут быть смоделированы. Нам нужно выполнить определенные шаги, чтобы сделать их насмешливыми.

Мы можем не захотеть высмеивать служебные объекты, такие как функции объекта Math или _ (созданные библиотекой Underscore), поскольку их операции не выполняют никакой бизнес-логики, не манипулируют пользовательским интерфейсом и не общаются с источник данных. Но такие объекты, как $ .ajax, localStorage, WebSockets, breeze и toastr, должны быть смоделированы. Потому что, если их не смоделировать, эти объекты будут выполнять свою фактическую работу при выполнении модульных тестов, и это может привести к некоторым ненужным обновлениям пользовательского интерфейса, сетевым вызовам, а иногда и ошибкам в тестовом коде.

Каждый фрагмент кода, написанный на Angular, тестируется из-за внедрения зависимостей. DI позволяет нам пропускать любой объект, который следует за оболочкой фактического объекта, чтобы просто заставить тестируемый код не прерываться при его выполнении. Глобальные объекты могут быть смоделированы, если они могут быть введены. Есть два способа сделать глобальный объект инъекционным:

1. Введите $ window в сервис / контроллер, которому нужен глобальный объект, и получите доступ к глобальному объекту через $ window. Например, следующий сервис использует localStorage через $ window:

 angular.module('someModule').service('storageSvc', function($window) {
  this.storeValue = function(key, value) {
    $window.localStorage.setItem(key, value);
  };
});

1. Создайте значение или константу, используя глобальный объект, и вставьте его, где это необходимо. Например, следующий код является константой для toastr:

 angular.module('globalObjects',[])
  .constant('toastr', toastr);

Я предпочитаю использовать константу сверх значения для обертывания глобальных объектов, поскольку константы могут быть введены в блоки конфигурации или поставщики, а константы не могут быть декорированы.

Следующий фрагмент демонстрирует насмешку над localStorage и toastr:

 beforeEach(function() {
  module(function($provide) {
    $provide.constant('toastr', {
      warning: jasmine.createSpy('warning'),
      error: jasmine.createSpy('error')
    });
  });

  inject(function($window) {
    window = $window;

    spyOn(window.localStorage, 'getItem');
    spyOn(window.localStorage, 'setItem');
  });
});

Вывод

Насмешка является одной из важных частей написания юнит-тестов на любом языке. Как мы видели, внедрение зависимостей играет важную роль в тестировании и макете. Код должен быть организован таким образом, чтобы функциональность легко тестировалась. В этой статье приведен список наиболее распространенных наборов объектов при тестировании приложений AngularJS. Код, связанный с этой статьей, доступен для скачивания с GitHub .