CoreData单元测试获取ViewItem报同名类型不匹配致命错误

这个崩溃本质是Swift命名空间隔离机制和CoreData实体类加载逻辑共同导致的类型不匹配问题：

• Swift中类型的唯一标识是模块名.类名，不同编译Target属于不同模块，哪怕两个模块里的类实现代码完全一致、短类名相同，运行时也会被判定为完全不同的类型。
• 你当前的配置下，ViewItem类被同时编译进了主App Target和单元测试Target：CoreData从主App Bundle加载实体类，fetch返回的实例实际属于主模块下的ShopEasy.ViewItem；但测试代码中书写NSFetchRequest<ViewItem>时，Swift默认从当前测试模块的命名空间解析类型，把泛型参数识别为测试模块下的ShopEasyTests.ViewItem。
• 当你访问fetch返回的数组元素时，Swift运行时会做强制类型校验，发现数组里存的实际类型和泛型声明的类型不匹配就触发崩溃。报错日志只打印类的短名、不显示模块前缀，所以才会出现"Expected ViewItem but found ViewItem"这种看起来两个类型名完全一致的迷惑提示。

你可以根据自己的项目配置选下面任意一种方案修复：

• 调整CoreData实体的模块配置
  打开项目的.xcdatamodeld模型文件，选中ViewItem实体，在右侧数据模型检查器的Class配置区，把Module选项从默认的Current Product Module手动设置为主App的模块名ShopEasy；如果你是手动编写NSManagedObject子类，把Codegen选项设置为Manual/None，确保CoreData加载实体时始终从主App模块找对应类，不会随当前运行Target切换模块。
• 移除测试Target下重复编译的ManagedObject类
  选中单元测试Target，进入Build Phases > Compile Sources列表，把所有主Target已经编译过的NSManagedObject子类（包括ViewItem.swift）从列表中删除，避免测试模块生成重复的同名类。测试代码通过@testable import ShopEasy导入主模块即可访问这些类，不会出现类型解析冲突。
• 显式指定fetch请求的泛型所属模块
  如果暂时不想调整编译配置，可以在测试代码中写fetch请求时，显式标注泛型类型为主模块下的类，强制Swift做正确的类型解析：

  let viewItemFetchRequest = NSFetchRequest<ShopEasy.ViewItem>(entityName: "ViewItem")
  

调试时可以在断点处通过LLDB执行下面两个命令，直接查看两个类型的全限定名，如果输出的模块前缀不一致，就确认是命名空间冲突问题：

po ViewItem.self
po type(of: fetchedViewItems.first!)

内容的提问来源于stack exchange，提问作者Reinhard Männer