- XCTests是否并行运行(即允许多个测试同时运行?)。考虑一个包含多个测试的单个测试文件,以及多个包含多个测试的测试文件。
- 如果在某些正在测试的组件中使用核心数据,并且测试可以并行运行,那么在测试中使用核心数据的正确方法是什么?例如,测试应以“干净”数据存储开始,然后根据需要添加对象,然后根据商店内容进行测试。听起来好像它们全都使用相同的托管对象上下文/存储,它们将指向相同的数据,因此存在彼此冲突的风险。
0
A
回答
1
每个XCTest方法运行顺序(一个在那一刻)
为了测试核心数据我经常在内存中创建持久性存储,在这里你有良好的文档片断:code使用这种MOC的你总是有明确的核心数据状态
也请您查看此Rays tutorial
0
1.测试案例逐个执行并测试文件。
2.您的核心数据管理对象上下文应该通过在您的测试用例(@testable import product_name)文件中导入您的应用程序并在测试用例文件中访问核心日期对象来创建。所有测试用例都将独立运行。 因此,正如你所提到的,测试应该从一个'干净'的数据存储开始,然后根据需要添加对象,然后基于store.yes的内容进行测试,这是正确的方式。确保核心数据管理对象是在测试文件中创建。测试案例可以在测试导航部分进行测试。
1
测试在测试运行器进程的主线程上串行运行。然而,没有什么能自动防范你启动异步操作,这些操作可能会延伸到未来测试用例的执行中。
例如perfomBlock
在NSManagedObjectContext
上的呼叫不保证在下次测试开始前执行。如果您的测试触发了异步传播到父管理对象上下文的保存,这可能尤其成问题。
我发现编写易于测试的代码非常有价值,这意味着将受管对象上下文或其他依赖项注入到被测代码中。这应该允许您为每个测试用例构建独立的Core Data堆栈,而不是在单个上下文中意外共享某个全局状态。那么你只需要提防过分宽容的通知观察员,这些观察员不会检查NSNotification
的发件人(即当观察NSManagedObjectContextDidSaveNotification
时)。
相关问题
- 1. 与核心数据
- 2. 与核心数据
- 3. 使用核心数据与核心图
- 4. UITableView与核心数据和非核心数据源
- 5. Swift与核心数据
- 6. 与核心数据实体
- 7. 核心数据与SQLite
- 8. NSFileProtectionComplete与核心数据
- 9. NSUserDefaults与核心数据
- 10. 核心数据与字典
- 11. 设置与核心数据
- 12. SQL SELECT与核心数据
- 13. 核心数据与SQLitePersistentObjects
- 14. 崩溃与核心数据
- 15. 使用与核心数据
- 16. 与核心数据的数据库
- 17. 核心数据支持的非核心数据数据UITableView
- 18. 核心数据和核心位置
- 19. mach_msg_trap核心数据
- 20. 在核心数据
- 21. NSManaged核心数据 -
- 22. 在核心数据
- 23. 核心数据NSFetchedResultsController
- 24. 核心数据iPhone
- 25. 核心数据书
- 26. 在核心数据
- 27. 核心数据:取
- 28. 在核心数据
- 29. csv核心数据
- 30. 从核心数据
“例如,在下一次测试开始之前,不能保证在NSManagedObjectContext上调用perfomBlock。”如果你对测试有期望,那么呢?在完成之前,测试是否等到预期完成? – Zach
可能的话,如果您正在使用'XCTestExpectation'或等效的异步断言。例如,您可能可以编写一个测试tearDown方法,在继续进行下一个测试之前等待异步事件完成。具体如何确定异步操作已完成取决于您的应用程序,可能会非常棘手。如果可能的话,我发现避免首先共享状态通常更安全。 – Jonah