Roomのマイグレーション をテストする方法

自己紹介 ● 名前：若松 健斗 ● 所属：DeNA SWETグループ ○ Androidエンジニア ● アプリの設計を考えることが好き

今日話すこと ● 業務で行なったマイグレーション ● Roomのマイグレーションテストの基本 ● 業務で作成したマイグレーションのテスト ● まとめ

業務で行なったマイグレーション

マイグレーションを行った背景 独自に定義した型をそのまま保存 することができないので、Json形式 の文字列に変換する必要あり

マイグレーションを行った背景 難読化されないようにする設定が漏 れてしまった その結果、難読化の影響を受けた Jsonが生成された 難読化の影響を受けたJson 難読化ツールにProguardを使用している

マイグレーションを行った背景 ● Proguardの難読化の影響を受けたJson形式のデータがDBに保存されている ● Proguardのアルゴリズムが変更されると、DBからデータを読み込めなくなる可 能性がある id name age 1 {a: Taro, b: Tanaka} 20 1 {a: Hanako, b: Yamada} 34 1 {a: Jiro, b: Suzuki} 18 難読化の影響を受けたデータを含むテーブル データを難読化前の状態に 戻す必要がある

実施したマイグレーションの概要 Proguardで難読化された データを元に戻す マイグレーション前のデーターベース マイグレーション後のデーターベース id name age 1 {a: Tanaka, b: Taro} 20 1 {a: Yamada, b: Hanako} 34 1 {a: Suzuki, b: Jiro} 18 id name age 1 {last_name : Tanaka, first_name: Taro} 20 1 {last_name: Yamada, first_name: Hanako} 34 1 {last_name: Suzuki, first_name: Jiro} 18 id name age 1 {a: Tanaka, b: Taro} 20 1 {a: Yamada, b: Hanako} 34 1 {a: Suzuki, b: Jiro} 18 テーブルA（UserEntity） テーブルA (紐づくEntityはなし) テーブルB（UserEntity）

実施したマイグレーションの概要 id name age 1 {a: Tanaka, b: Taro} 20 1 {a: Yamada, b: Hanako} 34 1 {a: Suzuki, b: Jiro} 18 id name age 1 {last_name : Tanaka, first_name: Taro} 20 1 {last_name: Yamada, first_name: Hanako} 34 1 {last_name: Suzuki, first_name: Jiro} 18 元のテーブルは残す id name age 1 {a: Tanaka, b: Taro} 20 1 {a: Yamada, b: Hanako} 34 1 {a: Suzuki, b: Jiro} 18 マイグレーション前のデーターベース マイグレーション後のデーターベース すぐにロールバックできる状態にし ておく テーブルA（UserEntity） テーブルA (紐づくEntityはなし) テーブルB（UserEntity）

マイグレーションのシナリオ ● よくあるマイグレーションのシナリオ ○ 新しいテーブルを追加 ○ 既存のテーブルを削除 ○ 既存のテーブルのスキーマを変更 ● 今回のマイグレーションのシナリオ ○ 新しいテーブルを追加する ○ 既存のテーブルの値を元にレコードを生成する ○ 生成したレコードを、新しいテーブルに追加する

Roomのマイグレーションテストの基本

事前準備（1/2） ● スキーマをJSONファイルにエクスポートさせる設定 ○ エクスポート先のパスを追加する

事前準備（2/2） ● スキーマのJsonをテスト時にRoomが利用できるようにする設定 ○ AndroidTestのアセットにJsonのパスを追加する

Roomのマイグレーションテストの基本的な流れ マイグレーションのテストコードのサンプル

Roomのマイグレーションテストの基本的な流れ MigrationTestHelperの生成 マイグレーションのテストコードのサンプル 古いスキーマのデータベース生成 やマイグレーションの実行を行う

Roomのマイグレーションテストの基本的な流れ 古いスキーマのDBを作成 SQLを使いテーブルにデータを追加 する マイグレーションのテストコードのサンプル

Roomのマイグレーションテストの基本的な流れ マイグレーションを実行する runMigrationsAndValidateでマイグ レーションの実行とスキーマの検証 を行う Entityに紐づいていないテーブルが データベース上に存在することを許 可しない場合 validateDroppedTablesをtrueにす る マイグレーションのテストコードのサンプル

Roomのマイグレーションテストの基本的な流れ 値の検証を行う runMigrationsAndValidateではス キーマのチェックしか行わない マイグレーションのテストコードのサンプル

業務で作成したマイグレーションのテスト

作成したマイグレーションのテスト ● 難読化されたデータを元に戻すロジックのテスト ● データベースの振る舞いのテスト

作成したマイグレーションのテスト ● 難読化されたデータを元に戻すロジックのテスト ● データベースの振る舞いのテスト

難読化されたデータを元に戻すロジックとそのテスト 今回テストしたいロジック obfuscatedJsonがnullの場合にnull を返すこと obfuscatedJsonがnullでない場合に 難読化が解除された文字列を返すこ と テストコードの一例 難読化されたJson形式のデータを元に戻すロジック

難読化されたデータを元に戻すロジックとそのテスト テストコードの一例 難読化されたJson形式のデータを元に戻すロジック 単体テストを作成 値の変更ロジックは単体テスト可能 単体テストでカバーできる範囲を広げ ることで、テストにかかる労力や時間を 削減することができる

単体テストと統合テストの比較 単体テスト 統合テスト 単体テストの方が圧倒的に簡単 テストにかかる労力や時間を削減できる

作成したマイグレーションのテスト ● 難読化されたデータを元に戻すロジックのテスト ● データベースの振る舞いのテスト

データベースの振る舞いのテスト

データベースの振る舞いのテスト 古いスキーマのDBを準備 スキーマバージョン1のDBを用意して難 読化されたデータを追加

データベースの振る舞いのテスト マイグレーションを実行 難読化の影響を受けたデータを元に戻 すマイグレーションを実行する validateDroppedTablesをFalseに設定 しEntitiyに紐づかないテーブルの存在を 許容してもらえるようにする

データベースの振る舞いのテスト 値の検証 new_userテーブルに意図した値が含ま れているかを確認する

マイグレーション後にデータを読み込む際の注意点 部分的なバージョン移行のテストで はSQLを使う Daoを経由してデータを取得しないように する。Daoは常に最新のスキーマを扱う ため再度スキーマを変更するとテストが 壊れてしまう 全てのマイグレーションをまとめたテスト ではDaoを使ってもOK マイグレーション後のデータベースが常 に最新のスキーマになるため

まとめ ● 業務で行ったマイグレーションテストと簡単なRoomの使い方について解説した ● マイグレーションの種類によっては単体テストを導入できる ● テストで扱うスキーマのバージョンからSQLとDaoの使い分けを行う