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

Question

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

我正在寻找建议如何尽可能简单地执行应用程序的集成测试.我应该针对API还是针对模拟数据进行测试？但是,如果可以使用POST创建资源或使用PUT修改资源,如何正确模拟GET请求？

您使用哪些框架来解决这些问题？我和Frank一起玩,由于iOS应用程序中的快速UI更改,看起来不错但很复杂.您将如何在应用程序中测试"API请求层"？工作线程是队列中的NSOperations - 一切都是异步构建的.有什么建议？

Answer 1

我强烈建议你模拟服务器。服务器宕机，行为发生变化，如果测试失败意味着“也许我的代码仍然有效”，那么你就遇到了问题，因为你的测试不会告诉你代码是否被破坏，这就是全部观点。

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

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 来跟踪正在运行的单元测试并适当地隔离我的数据文件。

另一件要记住的事情是，不稳定是万恶之源。如果您有使用集合执行操作或获取当前日期等的代码，这往往会更改请求和响应，而这在离线场景中不起作用。所以要小心那些。