【问题标题】:XCTest with Core DataXCTest 与核心数据
【发布时间】:2017-11-24 19:25:23
【问题描述】:
  1. XCTests 是否并行运行(也就是说,是否允许同时运行多个测试?)。考虑包含多个测试的单个测试文件,以及每个包含多个测试的多个测试文件。
  2. 如果在某些被测组件中使用了核心数据,并且测试可以并行运行,那么在测试中使用核心数据的正确方法是什么?例如,测试应该从“干净”的数据存储开始,然后根据需要添加对象,然后根据存储的内容进行测试。听起来,如果它们都使用相同的托管对象上下文/存储,它们将指向相同的数据,因此存在相互冲突的风险。

【问题讨论】:

    标签: ios unit-testing core-data xctest


    【解决方案1】:

    测试在测试运行进程的主线程上连续运行。然而,没有什么可以自动防止您启动异步操作,这些操作可能会延伸到未来测试用例的执行中。

    例如,对NSManagedObjectContext 上的perfomBlock 的调用不能保证在下一个测试开始之前执行。如果您的测试触发异步传播到父托管对象上下文的保存,这可能会特别成问题。

    我发现编写易于测试的代码很有价值,这意味着将托管对象上下文或其他依赖项注入到被测代码中。这应该允许您为每个测试用例构建一个独立的核心数据堆栈,而不是在单个上下文中意外地共享一些全局状态。那么你只需要提防过于宽容的通知观察者,它们不会费心检查NSNotification的发件人(即在观察NSManagedObjectContextDidSaveNotifications时)。

    【讨论】:

    • “例如,对 NSManagedObjectContext 上的 perfomBlock 的调用不能保证在下一次测试开始之前执行。”如果你对考试有期望怎么办?测试不会等到期望达到后再完成吗?
    • 可能,如果您使用XCTestExpectation 或等效的异步断言。例如,您可以编写一个测试 tearDown 方法,该方法等待异步事件完成,然后再进行下一个测试。您确定此类异步操作已完成的确切方式取决于您的应用程序,并且可能很棘手。我发现如果可能的话,首先避免共享状态通常更安全。
    【解决方案2】:

    1.测试用例一一执行,测试文件也一一执行。

    2.您的核心数据托管对象上下文应该通过在您的测试用例(@testable import product_name)文件中导入您的应用程序并访问测试用例文件中的核心日期对象来创建。所有测试用例都将独立运行。 所以正如你提到的,测试应该从“干净”的数据存储开始,然后根据需要添加对象,然后根据存储的内容进行测试。是的,这是正确的方法。确保创建核心数据托管对象在测试文件中。测试用例可以在测试导航部分进行测试。

    【讨论】:

      【解决方案3】:
      1. 每个 XCTest 方法都按顺序运行(目前一个)

      2. 为了测试我经常在内存 Persistance Store 中创建的核心数据,在这里你有很好的截图:code 使用这种 MOC 你总是有清晰的核心数据状态

      请检查Rays tutorial

      【讨论】:

        猜你喜欢
        • 2018-01-08
        • 2013-04-06
        • 2015-10-06
        • 2013-04-21
        • 2023-03-11
        • 1970-01-01
        • 1970-01-01
        • 2015-12-24
        • 1970-01-01
        相关资源
        最近更新 更多