在生产应用中使用 ProcessInfo.processInfo.environment 有多危险?
How dangerous is it to use ProcessInfo.processInfo.environment in production app ?
我写了一个模拟 Coredata
管理器,以便在单元测试中测试一些 classes。
我有大约 10 个 class 是从一个叫做 DatabaseManager
的 class 得到的 NSManagedObjectContext
。我已经决定如果单元测试是 运行,不处理实际的 Coredata NSManagedObjectContext
但重定向到 Mock Coredata
Class 以获得 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"]
的可行性如何?
我会使用 Swift 条件编译以及在构建参数中传递的 -D 标志,以确保代码仅在测试环境中处于活动状态,并且永远没有机会将其投入生产。
我写了一个模拟 Coredata
管理器,以便在单元测试中测试一些 classes。
我有大约 10 个 class 是从一个叫做 DatabaseManager
的 class 得到的 NSManagedObjectContext
。我已经决定如果单元测试是 运行,不处理实际的 Coredata NSManagedObjectContext
但重定向到 Mock Coredata
Class 以获得 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"]
的可行性如何?
我会使用 Swift 条件编译以及在构建参数中传递的 -D 标志,以确保代码仅在测试环境中处于活动状态,并且永远没有机会将其投入生产。