最近，在做项目时掉进了 AngularJS 异步调用 $q 测试的坑中，直接躺枪了。折腾了许久日子，终于想通了其中的道道，但并不确定是最佳的解决方案，最后还是决定总结成文以求能与其它的园友共同分享以求找到更好的解决方案。

首先，我的测试环境是 [Karma|http://karma-runner.github.io/0.12/index.html] + [Jasmine|http://jasmine.github.io/] ，这属于 AngularJS的其中一种配置，也是AngularJS官方所推荐的框架，Jasmine 用起来也确实很不错。

很多的spec都没有什么大问题，只是当我为其中的几重要的异步处理服务编写测试时就出事了，代码在实际运行环境中是能正常运行的，但在测试中却不能通过，这肯定是测试没写好。在网上google了多天，也对各种方案进行尝试一直也没有找到解决方法，然而这种问题不会是特例，而是经常会遇到的，那就是在Angular服务中返回的 promise 很难进行测试。

从代码入手会更容易了解问题的始末：

jasmine 的异步测试模式是实现一种简单的超时机制，通过等待 done() 方法对计时器重置，当在超时限制内（默认5s） done() 没有被调用则会引发测试失败的异常。在 1.3 之前是采用 runs 和 waitsFor 方法进行处理，在2.0后这两个方法被简化去除掉了，只能用 done，这里就以我们最经常会用到的 FileAPI 中的 FileReader 来做实例，FileReader 对文件对象(Blob)的读取是一个异步方法，那么将这个实现逻辑直接写在 jasmine 中应该是这样的：

测试结果是 pass , 这只是为了试用一下 jasmine 中 done 的效果。当然在项目中这样做是完全没有意义的，这只是一个引子，我会分三步来完整这个测试。

接下来是将这个实现逻辑封装成为 AngularJS的 service。由于是异步处理所以这个 service 应该是返回一个 promise 对象。 为了更具体地说明这个问题，这里只建立一个空白的 fileReader 服务，此服务只为了测试 then 的触发时机：

那么前文的测试就应该修改为：

问题开始来了，这个测试运行的结果是 Fail! 并且得到以下的提示：

超时！也就是说 由于then 并没有被调用，所以超时返回方法 done()没有被执行而直接出现这个测试错误。然而讽刺的是，fileReader 这个服务在浏览器内是可以直接运行而不会产生任何的错误的。

问题出在哪里 ？找了许久，最终发现,由于在 jasmine 中的环境是被 mock 出来的，是由 ngMock 对 angular 的对象和brower对象内的服务进行了重新的模拟，这个会与实际的运行有些许的差异，由其要使 then 方法被正确调用那需要在返回then之后调用 $rootScope.$apply() (这个内容可以直接参考：https://docs.angularjs.org/api/ng/service/$q) 也就是说，我们并不需要直接使用 jasmine 提供的“阻塞”模拟，而是直接用 $rootScope.$apply() 让异步方法直接返回。

这一次测试 pass 了。既然测试写好了，那么我们就回到最初那里，将实现逻辑真正地加入到 fileReader 服务中：

同样地，运行刚才写好的异步测试程序。 当然在运行前要修改一下 expected_text 为 expected_text = chance.sentence()。然而，运行结果是让人失望的:

很明显，then 方法又无法触发了，deferred.resolve 并没有如我们预期那般在文件读取时调用，而且 $rootScope.$apply() 也貌似失效了。在此时真正的问题才开始显现：

我的实际项目比这个要更为复杂，因为我的实际的服务是操控 indexedDB的，众所周知 indexedDB 里一切都是异步的，所以他们在测试中无一通过！

就是为了这个问题我折腾了好久，最好还是将视线落在 ngMock 上。

[ngMock|https://docs.angularjs.org/api/ngMock] 这个模块上只提供了最简单的三种异步服务 $httpBackend、$tiimeout 和 $interval ，??是因为他们的存在，在我们的测试中可以正常调用 $http 、$resource 等的常规异步服务。 然而， FileAPI, IndexedDB等这些 HTML5内的高等服务并没有提供 mock。当时我的测试初衷并不想mock而是期往能实际地调用，而然这种想法貌似不太容易实现，加之，自我看了 ["Mocking Dependencies AngularJS Tests"|http://www.sitepoint.com/mocking-dependencies-angularjs-tests/] 一文后，更加确定了我的想法。

我的结论是，如果在自定义的 Angular服务中返回的 promise 是在 Angular的 scope内调用 resolve 那么我们直接使用前面第二种测试方式就可以了，但如果 service 是包装了其它的依赖服务，如FileReader 、IndexedDB、WebSQL或其它的以异步方式为主的服务那么就只能通过 mock 来解决测试的问题，要不就不使用 $q而采用 callback 方式将回调方法直接传递给第三方依赖服务（我现在的IndexedDB服务就是这种方式）。

以本文中所提及的 FileReader 为例的话，要测试通过那可以自己写一个 mockFileReader，通过 jasmine 的 spyOn 方法截取方法调用：

笨一点的做法就是对有使用的第三方依赖都编写一个 Mock 加以取代，更快捷的方法就是看看谁已经将这个“轮子”发明了而不用我们重新造一次。

一些AngularJS相关文章链接：

希望你喜欢，并分享我的工作~带你走近AngularJS系列：