在角度的单元测试指令控制器,而不使控制器全局

在Vojta Jina的卓越的存储库中，他演示了指令测试，他在模块包装器之外定义了指令控制器。看这里：
https://github.com/vojtajina/ng-directive-testing/blob/master/js/tabs.js

这不是坏的做法和污染全球命名空间吗？

如果一个人有另一个地方，它可能是合乎逻辑的调用的东西TabsController，不会打破东西吗？

所提到的指令的测试在这里：https://github.com/vojtajina/ng-directive-testing/commit/test-controller

是否可以测试指令控制器与指令的其余部分分离，而不将控制器放置在全局命名空间中？

这将是很好的封装整个指令在app.directive(…)定义。

优秀的问题！

因此，这是一个常见的问题，不仅是控制器，而且还可能包含指令可能需要执行其任务但不一定要将此控制器/服务暴露给“外部世界”的服务。

我坚信全球数据是邪恶的，应该避免，这也适用于指挥控制器。如果我们采用这个假设，我们可以采用几种不同的方法来在本地定义这些控制器。在这样做时，我们需要记住，控制器应该仍然“容易”访问单元测试，所以我们不能简单地隐藏它到指令的关闭。 IMO的可能性是：

1)首先，我们可以在模块级简单定义指令的控制器，例如：

angular.module('ui.bootstrap.tabs',[])
  .controller('TabsController',['$scope','$element',function($scope,$element) {
    ...
  }])
 .directive('tabs',function() {
  return {
    restrict: 'EA',transclude: true,scope: {},controller: 'TabsController',templateUrl: 'template/tabs/tabs.html',replace: true
  };
})

这是一个简单的技术，我们在https://github.com/angular-ui/bootstrap/blob/master/src/tabs/tabs.js使用，这是基于Vojta的工作。

虽然这是一个非常简单的技术，但应该注意，控制器仍然暴露于整个应用程序，这意味着其他模块可能会覆盖它。在这个意义上，它使控制器本地AngularJS应用程序(所以不污染全局窗口范围)，但它也是全局的所有AngularJS模块。

2)使用闭包范围和特殊文件设置进行测试。

如果我们想完全隐藏一个控制器函数，我们可以在一个闭包中包装代码。这是AngularJS使用的一种技术。例如，查看NgModelController，我们可以看到它被定义为一个“全局”函数在它自己的文件(因此很容易访问测试)，但整个文件包装在闭包中的构建时间：

> https://github.com/angular/angular.js/blob/master/src/angular.prefix
> https://github.com/angular/angular.js/blob/master/src/angular.suffix

总而言之：选项(2)是“更安全”，但需要一些前期设置的构建。