スマホアプリに必須なデータ永続化のためのDBテスト：Androidアプリ開発テスト入門（4）（3/3 ページ）

日本Androidの会テスト部が、いままで培ってきたAndroidアプリ開発におけるテストのノウハウを、実際のテストコード例とともに紹介していきます

[吉澤毅，日本Androidの会テスト部] PC用表示関連情報

LINE

Hatena

【2】マイグレーションのテスト

　アプリをリリースした後、アプリのアップグレードとともにDBの変更が発生することがあります。AndroidのSQLiteOpenHelperは、アップグレード時にDBを更新できる仕組みがあるので（API Level 11からはダウングレードも提供）、使ってみましょう。

　キャッシュ用途でDBを利用している場合はアップグレード時にテーブルをdropして再作成し直すこともありますが、データを永続化しておきたい場合はデータを破壊せずにデータ移行を完了しなければいけません。

バージョンアップのパターンはユーザーで異なる

　Webサーバを使うWebアプリのマイグレーションと違い、スマホのネイティブアプリでは各ユーザーごとにマイグレーションが必要です。Webサーバの場合はシステム側の任意のタイミングで実行できますが、クライアントの場合は、いつ実行されるか分かりませんし、バージョンアップごとにユーザーがインストールしてアップデートされる保証もありません。「もしかしたら1年ぶりにアップデートするユーザーがいる」と考える必要があります。

　アプリの成長とともに、すべてのバージョンアップのパターンを網羅して手動でテストすることは現実的ではありません。マイグレーション時にデータを移行するための変換作業があるのであれば、それなりの変換パターンを検証する必要があります。

マイグレーションテストのコード例

　そこで、各バージョンからのマイグレーションもテストするようにし、安心してDBをアップグレードできるようにしましょう。

　ここでは、「作成日時のほかに、更新日時も格納する必要が生じ、これまで登録してあるデータに関しては更新日時を作成日時と同じにする」という仕様を想定します。内部のDBバージョンを1から2に上げて対応してみます。

*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***

　ポイントは、親クラスのSQLiteOpenHelperのコンストラクタにバージョン番号を渡せるようにしておくことです。こうすることで、ユーザーが任意のDBバージョン、すなわち任意のアプリバージョンから最新のアプリをインストールすることをシミュレーションできます。

　また今回は、バージョンごとにSQLiteOpenHelperクラスを実装してみました。少し変わった作りになりましたが、すべてのバージョンに対応する新規テーブル作成SQL文を1つのSQLiteOpenHelperクラスには置ききれないと判断したためです。

　ここに関しては、まだ試行錯誤をしている段階で、ぜひ良い方法を皆さんも考えてみてください。

テストできるところはテストしておこう

　今回はDBへのテストの書き方について解説してきました。DBのテストをコードで記述してデータ処理のテストとマイグレーションのテストを個人環境に縛られず行えます。安心してデータを取り扱えて、バージョンアップも怖くなくなります。

　ビジネスロジック同様にテストが記述しやすい場所なので、ぜひ活用してみてください。

　今回の記事のサンプルコードは以下の場所にあります。

https://github.com/ussy/android-dbtest

著者紹介

Androidテスト部部員

吉澤毅（@ussy00）

株式会社ヌーラボにて、受託案件および自社サービスのサポート開発を行うプログラマ

「次回」へ

「Androidアプリ開発テスト入門」バックナンバー