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)是“更安全”，但需要一些前期设置的构建。
