Ios 在生产应用程序中使用ProcessInfo.ProcessInfo.environment有多危险？

为了在单元测试中测试一些类，我编写了一个mock

Coredata

manager

我有大约10个类，它们从一个名为

DatabaseManager

的类中获得了

NSManagedObjectContext

。我已经决定如果单元测试正在运行，不要处理实际的

Coredata NSManagedObjectContext

，而是重定向到

Mock Coredata

类以获取

NSManagedObjectContext

func getContext() -> NSManagedObjectContext {
    if ProcessInfo.processInfo.environment["XCTestConfigurationFilePath"] == nil 
    {
        return persistentContainer.viewContext
    }
    else
    {
        return MockDatabaseController.instance.managedObjectContext()
    }
}

这在单元测试和调试以及通过adhoc分发时都非常有效

但我担心的是，如果它无法从

ProcessInfo.ProcessInfo.environment[“XCTestConfigurationFilePath”]

app中获取正确的值，那么它可能会毫无用处

---

在生产代码中使用

ProcessInfo.ProcessInfo.environment[“XCTestConfigurationFilePath”]

的可行性如何

我将使用Swift条件编译以及在构建参数中传递的-D标志，以确保代码仅在测试环境中处于活动状态，并且从未有机会将其投入生产。

我将避免它，如果有的话，因为它依赖于应用程序存储库外部的东西（包括env vars）这是一个令人头痛的问题。那么您将如何解决coredata问题？我不想让我的单元测试与实际的coredata上下文交互。这门课的任务不是了解任何有关模拟的内容。依赖于核心数据系列（mock或real）的代码应该将该依赖项作为其初始值设定项的参数。prod代码将提供真正的实现，而测试代码将提供模拟。当然，定义一个由两个（或更多，谁知道）数据提供者共享的协议，并将所有内容都耦合到该协议，而不是紧密耦合到其任何一个具体实现