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

【问题标题】：How dangerous is it to use ProcessInfo.processInfo.environment in production app ?在生产应用程序中使用 ProcessInfo.processInfo.environment 有多危险？
【发布时间】：2017-05-11 18:49:18
【问题描述】：

我写了一个模拟Coredata 管理器，以便在单元测试中测试一些类。

我有大约 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"] 应用程序中获取正确的值，它可能会毫无用处。

在生产代码中使用ProcessInfo.processInfo.environment["XCTestConfigurationFilePath"] 的可行性如何？

【问题讨论】：

我会避免它，如果有的话，因为依赖于应用程序存储库外部的东西（包括环境变量）是一件令人头疼的事情。
那你将如何解决 coredata 问题？我不希望我的单元测试与实际的 coredata 上下文交互。
这门课的工作不是了解你的模拟。依赖于核心数据服务（模拟或真实）的代码应该将该依赖项作为其初始化程序的参数。 prod 代码将提供真正的实现，而 test 代码将提供 mock。
当然，定义一个由两个（或更多，谁知道）数据提供者共享的协议，并将所有内容都与协议耦合，而不是与任何一个具体实现紧密耦合

标签： ios swift unit-testing core-data production-environment

【解决方案1】：

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

【讨论】：