使用NSOperations和Coredata在iOS应用程序中测试API请求层的建议

我开发了一个使用RESTAPI的iOS应用程序。iOS应用程序在工作线程中请求数据，并将解析结果存储在核心数据中。所有视图都使用核心数据来可视化信息。RESTAPI变化很快，我无法真正控制接口

我正在寻找如何尽可能容易地为应用程序执行集成测试的建议。我应该根据API还是模拟数据进行测试？但是，如果您可以使用POST创建资源或使用PUT修改它们，那么如何正确地模拟GET请求呢

对于这类问题，您使用什么样的框架？我玩过，它看起来不错，但由于iOS应用程序的用户界面变化很快，所以很复杂。您将如何在应用程序中测试“API请求层”？工作线程是队列中的NSO操作-所有内容都是异步构建的。有什么建议吗？

（因为还没有人介入并为您提供完整的演练）我拙劣的建议：后退一步，去掉异步的魔力，将一切都视为同步（api调用、解析、持久化），并将每一步作为消费者/生产者进行隔离。毕竟，您不想对NSURLConnection、JSONKit或其他任何东西进行单元测试（如果您使用它们，应该对它们进行测试），而是想测试代码。您的代码接受一些输入并生成输出，而不知道输入实际上是在某个后台线程中生成的输出。您可以执行隔离测试所有同步

您的视图不关心模型数据是如何提供的，这一点我们能达成一致吗？如果是，那么就用模拟对象测试视图

您的解析器不关心数据是如何提供的，这一点我们能达成一致吗？如果是，那么用模拟数据测试解析器

网络层：如上所述同样适用，最后您将得到一个NSDictionary的标题，以及一些NSData或NSString的内容。我认为您不想单元测试NSURLConnection或任何您信任的第三方网络api（ASIHTT、afnetworking等等），那么最后，要测试什么呢？ 您可以为每个用例模拟URL、请求头和POST数据，并为预期响应设置测试用例

---

最后，IMHO，这一切都是关于“规范化”asyc。

我强烈建议您模拟服务器。服务器宕机，行为改变，如果测试失败意味着“也许我的代码仍然有效”，那么你就有问题了，因为你的测试没有告诉你代码是否被破坏，这就是关键所在

关于如何模拟服务器，对于执行此操作的单元测试：

first_results = list_things()
delete_first_thing()
results_after_delete = list_thing()

我有一个模拟数据结构，如下所示：

{ list_things_request : [first_results, results_after_delete], 
  delete_thing_request: [delete_thing_response] }

它是在您的请求上键入的，该值是该请求的响应数组，按照它们被看到的顺序排列。因此，您可以支持重复运行相同的请求（如列出内容）并获得不同的结果。我使用这种格式是因为在我的情况下，API调用的运行顺序可能与上次略有不同。如果您的测试更简单，那么您可能会得到一个简单的请求/响应对列表

我在单元测试中有一个标志，指示我是否处于“记录”模式（即，与真实服务器对话并将此数据结构记录到磁盘）或我是否处于“回放”模式（与数据结构对话）。当我需要处理测试时，我会“记录”与服务器的交互，然后播放它们

我使用鲜为人知的SenTestCaseDidStartNotification来跟踪哪个单元测试正在运行，并适当地隔离数据文件

另一件需要记住的事情是，不稳定是万恶之源。如果您有处理集合的代码，或者获取当前日期等，这会改变请求和响应，而这些在脱机场景中不起作用。所以要小心这些东西。

看看

---

有关更多信息，请查看类似问题

您是否查阅了Graham Lee最近出版的《测试驱动的iOS开发》一书？第8章和第11章讨论并发性，本书介绍了测试服务API异步使用的方面。我知道在你发帖的时候，这本书还没有出版，这就是我提到它的原因。@cardinal谢谢你的提示。我会查的！对于iOS集成测试，请全程进行。