はじめに
Realmを使ったアプリで本番用とテスト用とで*.realmファイルを分ける方法を試した.
RenamingDelegatingContextを使ってファイル名にデバッグ用prefix(“test_”等)を付けるとか, テストではRealmインスタンスを直接操作する方法があるが, 今回は下記の理由からDI(Dagger2)で頑張る方法を採用した.
- Realmのmigrationテストやencryptテストにも備えて, RealmConfigurationレベルでカスタムしたい.
- Realmインスタンスを直接操作せず, できるだけ本番に近いアーキテクチャでテストしたい.
今回の例ではわかりやすく, *.realmファイル名を本番用とテスト用とで分けることを題材にしている.
ただし, 本番用プロダクトへの影響を懸念するならtestApplicationIdでユーザランドを分けてしまうのが無難.
ApplicationIdについて, Google APIやWeb Service系でパッケージ名を一種の認証識別情報としているものがあったり, アプリ間連携で呼出し元のパッケージ名が重要な意味を持つ設計思想もあったりで, パッケージ名変更するのも気を付けないといけないポイントがいくつかある.
とはいえ, ApplicationIdを分けないと本番用/デバッグ用を完全に分離するのが困難なケース(後述)もあるため, その点には注意したい.
今回はこちらのレポジトリからの抜粋となる.
Realm factory
Realmのインスタンス生成は専用のFactoryクラスRealmFactory内にカプセル化する.
public class RealmFactory {
public Realm getRealm() {
if (realmConfiguration == null) {
DiContainer.getInstance().getApplicationComponent().inject(this);
}
return Realm.getInstance(realmConfiguration);
}
}このクラスはRealmConfigurationの生成責務も持ち, テスト専用のRealmConfigurationを生成するメソッドが実装される.
また, Configurationの異なるRealmがアプリ内に生成されるのを避けるためにRealmFactoryはSingletonオブジェクトにする.
// 製品用RealmConfigurationの生成
public static RealmConfiguration newRealmConfiguration(@NonNull Context context) {
return new RealmConfiguration.Builder(context)
.name(REALM_FILE)
.schemaVersion(REALM_SCHEME_VERSION)
.migration(new RealmMigrator())
.build();
}
// デバッグ用RealmConfigurationの生成
@VisibleForTesting
public static RealmConfiguration newDebugRealmConfiguration(@NonNull Context context, @Nullable String fileName) {
return new Builder(context)
.name((fileName == null || fileName.length() == 0) ? "test_" + REALM_FILE : fileName)
.schemaVersion(REALM_SCHEME_VERSION)
.migration(new RealmMigrator())
.build();
}RealmConfigurationを後からDIでInjectするためにfactoryメソッドの公開範囲はpublicとしておく.
Rebuild component
よくあるApplication.onCreateでObject graphを構築する場合を考える.
コードの中で登場するDiContainerはObject graphを管理するコンポーネント.
Androidのコンポーネントをテスト環境から疎にするためApplication経由ではなくDiContainerを経由させる.
public class App extends Application {
@Override
public void onCreate() {
super.onCreate();
// よくある方法を使う
DiContainer.getInstance().setApplicationComponent(
DaggerApplicationComponent.builder()
.applicationModule(new ApplicationModule(this))
.build());
}
}Unit Test実行時にはデバッグ用のObject graphに再構築する必要がある.
デバッグ用にRealmConfigurationを作成するAPIは既に用意してあるため, DIでこれを差し替える方法を実装していく.
まずはRealmConfigurationをinjectするための本番用moduleを定義する.
@Module
public class ModelModule {
@Provides @Singleton
RealmConfiguration provideRealmConfiguration(@NonNull Context context) {
RealmConfiguration configuration = RealmFactory.newRealmConfiguration(context);
return configuration;
}
}続いてデバッグ用moduleを定義.
public class DebugModelModule extends ModelModule {
@Provides @Singleton
RealmConfiguration provideRealmConfiguration(@NonNull Context context) {
RealmConfiguration configuration
= RealmFactory.newDebugRealmConfiguration(context, null /* test_ prefixed */);
return configuration;
}
}あとはObject graphをテスト前に再構築すればデバッグ用のRealmConfigurationがinjectできるようになる.
public class DebugHelper {
public static void setupDiContainer() {
DiContainer.getInstance().setApplicationComponent(
DaggerApplicationComponent.builder()
.modelModule(
new DebugModelModule())
.applicationModule(
new ApplicationModule(
(App) InstrumentationRegistry.getTargetContext().getApplicationContext()))
.build());
RealmFactory.getInstance().deprecateConfigration();
}
}他にもSchemeVersionを指定するテストであったり, encryptしてのテストなども同じようにmoduleを用意すれば事足りる.
Unit Testの実行前にはApplication.onCreateが実行される.
そのため, Object graphは一旦本番用のRealmConfigurationで初期化されることになる.
Unit TestのsetupでRealmConfigurationが差替えられるのはその後になるため, Application.onCreate内でRealmにアクセスするようなケースがある場合は対策を打つ必要がある.
(その場合はtestApplicationIdでパッケージを分ける方策を探るのが無難だと思う)
以上.