1
単体テストでいくつかのクラスをテストするために、私はCoredataというモックを書きました。プロダクションアプリでProcessInfo.processInfo.environmentを使用するのはどれほど危険ですか？
私はDatabaseManagerというクラスからNSManagedObjectContextという約10のクラスを持っています。ユニットテストが実行されているかどうかを判断しましたが、Coredata NSManagedObjectContextを処理せず、Mock CoredataクラスにリダイレクトしてNSManagedObjectContextを取得してください。
func getContext() -> NSManagedObjectContext {
if ProcessInfo.processInfo.environment["XCTestConfigurationFilePath"] == nil
{
return persistentContainer.viewContext
}
else
{
return MockDatabaseController.instance.managedObjectContext()
}
}
これは単体テストとデバッグで、またアドホックを使って配布した場合でもうまく動作します。
しかし私の懸念は、ProcessInfo.processInfo.environment["XCTestConfigurationFilePath"]から正しい値を得ることができない場合、おそらく役に立たないでしょう。
生産コードでProcessInfo.processInfo.environment["XCTestConfigurationFilePath"]を使用するにはどうすればよいですか？
あなたのアプリのリポジトリ（env varsを含む）の外部に依存することは頭痛になるので、もしあれば避けたいと思います。 – Alexander
それでは、coredataの問題をどうやって解決しますか？私は単体テストを実際のcoredataの文脈とやりとりしたくない。 –
あなたのモックについて何か知ることは、このクラスの仕事ではありません。コアデータサービス（モックまたはリアル）に依存するコードは、依存関係をイニシャライザのパラメータとして使用する必要があります。テストコードはモックを提供するのに対して、プロードコードは実際の実装を提供します。 – Alexander