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

Transcript

1. Roomのマイグレーション をテストする方法
2. 自己紹介 • 名前：若松 健斗 • 所属：DeNA SWETグループ ◦ Androidエンジニア • アプリの設計を考えることが好き
3. 今日話すこと • 業務で行なったマイグレーション • Roomのマイグレーションテストの基本 • 業務で作成したマイグレーションのテスト • まとめ
4. 業務で行なったマイグレーション
5. マイグレーションを行った背景 独自に定義した型をそのまま保存 することができないので、Json形式 の文字列に変換する必要あり
6. マイグレーションを行った背景 難読化されないようにする設定が漏 れてしまった その結果、難読化の影響を受けた Jsonが生成された 難読化の影響を受けたJson 難読化ツールにProguardを使用している
7. マイグレーションを行った背景 • 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 難読化の影響を受けたデータを含むテーブル データを難読化前の状態に 戻す必要がある
8. 実施したマイグレーションの概要 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）
9. 実施したマイグレーションの概要 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）
10. マイグレーションのシナリオ • よくあるマイグレーションのシナリオ ◦ 新しいテーブルを追加 ◦ 既存のテーブルを削除 ◦ 既存のテーブルのスキーマを変更 • 今回のマイグレーションのシナリオ ◦ 新しいテーブルを追加する ◦ 既存のテーブルの値を元にレコードを生成する ◦ 生成したレコードを、新しいテーブルに追加する
11. Roomのマイグレーションテストの基本
12. 事前準備（1/2） • スキーマをJSONファイルにエクスポートさせる設定 ◦ エクスポート先のパスを追加する
13. 事前準備（2/2） • スキーマのJsonをテスト時にRoomが利用できるようにする設定 ◦ AndroidTestのアセットにJsonのパスを追加する
14. Roomのマイグレーションテストの基本的な流れ マイグレーションのテストコードのサンプル
15. Roomのマイグレーションテストの基本的な流れ MigrationTestHelperの生成 マイグレーションのテストコードのサンプル 古いスキーマのデータベース生成 やマイグレーションの実行を行う
16. Roomのマイグレーションテストの基本的な流れ 古いスキーマのDBを作成 SQLを使いテーブルにデータを追加 する マイグレーションのテストコードのサンプル
17. Roomのマイグレーションテストの基本的な流れ マイグレーションを実行する runMigrationsAndValidateでマイグ レーションの実行とスキーマの検証 を行う Entityに紐づいていないテーブルが データベース上に存在することを許 可しない場合 validateDroppedTablesをtrueにす る マイグレーションのテストコードのサンプル
18. Roomのマイグレーションテストの基本的な流れ 値の検証を行う runMigrationsAndValidateではス キーマのチェックしか行わない マイグレーションのテストコードのサンプル
19. 業務で作成したマイグレーションのテスト
20. 作成したマイグレーションのテスト • 難読化されたデータを元に戻すロジックのテスト • データベースの振る舞いのテスト
21. 作成したマイグレーションのテスト • 難読化されたデータを元に戻すロジックのテスト • データベースの振る舞いのテスト
22. 難読化されたデータを元に戻すロジックとそのテスト 今回テストしたいロジック obfuscatedJsonがnullの場合にnull を返すこと obfuscatedJsonがnullでない場合に 難読化が解除された文字列を返すこ と テストコードの一例 難読化されたJson形式のデータを元に戻すロジック
23. 難読化されたデータを元に戻すロジックとそのテスト テストコードの一例 難読化されたJson形式のデータを元に戻すロジック 単体テストを作成 値の変更ロジックは単体テスト可能 単体テストでカバーできる範囲を広げ ることで、テストにかかる労力や時間を 削減することができる
24. 単体テストと統合テストの比較 単体テスト 統合テスト 単体テストの方が圧倒的に簡単 テストにかかる労力や時間を削減できる
25. 作成したマイグレーションのテスト • 難読化されたデータを元に戻すロジックのテスト • データベースの振る舞いのテスト
26. データベースの振る舞いのテスト
27. データベースの振る舞いのテスト 古いスキーマのDBを準備 スキーマバージョン1のDBを用意して難 読化されたデータを追加
28. データベースの振る舞いのテスト マイグレーションを実行 難読化の影響を受けたデータを元に戻 すマイグレーションを実行する validateDroppedTablesをFalseに設定 しEntitiyに紐づかないテーブルの存在を 許容してもらえるようにする
29. データベースの振る舞いのテスト 値の検証 new_userテーブルに意図した値が含ま れているかを確認する
30. マイグレーション後にデータを読み込む際の注意点 部分的なバージョン移行のテストで はSQLを使う Daoを経由してデータを取得しないように する。Daoは常に最新のスキーマを扱う ため再度スキーマを変更するとテストが 壊れてしまう 全てのマイグレーションをまとめたテスト ではDaoを使ってもOK マイグレーション後のデータベースが常 に最新のスキーマになるため
31. まとめ • 業務で行ったマイグレーションテストと簡単なRoomの使い方について解説した • マイグレーションの種類によっては単体テストを導入できる • テストで扱うスキーマのバージョンからSQLとDaoの使い分けを行う