如何：模拟模块依赖

问题描述

撕裂我的头发就这一个。

Tearing my hair out on this one.

我有以下模块/控制器我想测试

I have the following module/controller I wish to test

angular
    .module('monitor.tableLord.controller', ['monitor.wunderTable'])
    .controller('TableLordController', TableLordController);

    TableLordController.$inject = ['$scope', 'historyState'];
    function TableLordController($scope, historyState) {
        ....some code....
    }

模块monitor.wunderTable包含应该控制器之前加载指令，但我想测试实际上并不取决于monitor.wunderTable控制器。然而monitor.wunderTable确实有其他依赖的很多....

The module monitor.wunderTable contains a directive that should be loaded before the controller, but the controller I want to test does not actually depend on monitor.wunderTable. monitor.wunderTable does however have a LOT of other dependencies....

我testfile的：

My testfile:

describe('TableLordController', function() {
    var $scope, historyState;

    beforeEach(function() {
        angular.module('monitor.wunderTable', []);
        module('monitor.tableLord.controller');
    });

    beforeEach(angular.mock.inject(function($rootScope, $controller) {
            $scope = $rootScope.$new();
            $controller('TableLordController', {$scope: $scope, historyState: {}});
    }));

    it('loads', function() {
        $scope.$digest();
    });
});

由于某些原因（我不认为这应该是可能的），我monitor.wunderTable的模拟版本的测试中，我有这个模块的干扰。现在这个模块中定义的控制器的每个测试失败：论证WunderTableController不是一个函数，得到了不确定的

For some reason (I didn't think this should be possible), my mock version of monitor.wunderTable is interfering with the tests i have for this module. Every test of the controller defined in this module now fails with: "Argument 'WunderTableController' is not a function, got undefined".

我情况下，它是相关的，这里是monitor.wunderTable我的定义是：

I case it is relevant, here is my the definition of monitor.wunderTable:

angular
    .module('monitor.wunderTable', [
        'ui.grid',
        'ui.grid.infiniteScroll',
        'ui.grid.autoResize',
        'monitor.wunderTable.service'
     ])
    .controller('WunderTableController', WunderTableController)
    .directive('wunderTable', wunderTable);

function wunderTable(){...}
WunderTableController.$inject = [];
function WunderTableController(...){...}

编辑：帖子暗示我删除模块依赖关系（因为它不是严格必要）将不被接受为正确答案（也可能downwoted）

Posts suggesting that I remove the module dependency (as it is not strictly needed) will not be accepted as correct answer (and possibly downwoted).

推荐答案

您的困惑来源于误解模块角是如何工作的。 都存储在角 。一旦他们被重写，它们被重写当前试运行，而不是目前的规范。模块嘲讽不支持ngMock（它需要在核心角一些实质性的变化）和 beforeEach 不会帮助任何东西。

Your confusion comes from misunderstanding how modules work in Angular. Modules are stored inside angular. Once they are overriden, they are overriden for the current test run, not for the current spec. Module mocking isn't supported by ngMock (it would require some substantial changes in Angular core) and beforeEach won't help anything.

除非你想运行在单独运行测试套件，解决的办法是备份嘲讽之前的模块。在某些情况下， angular.extend 和 angular.copy 无法妥善处理复杂的对象。 Object.assign ， jQuery.extend 或节点扩展可能是更好的候选者。在的情况下延长深沉的副本也可以在需要时使用。

Unless you want to run test suites in separate runs, the solution is to backup the module before mocking it. In some cases angular.extend and angular.copy are unable to handle complex objects properly. Object.assign, jQuery.extend or node-extend may be better candidates. In the case of extends deep copy can also used if necessary.

因此​​，在一个测试套件是

So in one test suite it is

var moduleBackup = angular.module('monitor.wunderTable');
angular.module('monitor.wunderTable', []);

describe('TableLordController', function() {
    ...

和在另一

Object.assign(angular.module('monitor.wunderTable'), moduleBackup);

describe('WunderTableController', function() {
    ...

有关TDD的好处是，它清楚地表明在应用程序设计的缺陷，并教导开发人员编写的直接和残酷的方式测试友好code。模块依赖意味着模块内的部件依赖于从另一个组件。如果他们不能或者他们被耦合得太紧，这可以被认为是一个潜在的缺陷和重构的主题。

The good thing about TDD is that it clearly indicates the flaws in app design and teaches the developer to write test-friendly code in immediate and ruthless manner. Module dependency implies that the components inside the module depend on the components from another one. If they doesn't or they are coupled too tightly, this can be considered a potential flaw and the subject for refactoring.

该解决方案是黑客十岁上下，而且往往打破的事实使得它不适合进行测试。

The fact that the solution is hack-ish and tends to break makes it unfit for testing.

TL; DR：是的，你必须删除模块依赖

TL;DR: Yes, you have to remove the module dependency.

这篇关于如何：模拟模块依赖的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！