モバイル開発における統合テスト—構成、種類、実施方法

統合テストとは？

統合テストは、アプリケーションの個々のモジュールやサブシステム間の相互作用の正確さを評価するソフトウェア検証ステージです。単体テストが各コンポーネントをアイソレートして検証するのに対し、統合テストはこれらのコンポーネントを一緒に集め、それらが連携してどう動作するかを検証します。典型なシナリオには、ネットワークレイヤーとリポジトリの間のデータ転送、ORMを通してのデータベースへの書き込み、サードパーティAPIからの応答処理があります。

モバイル開発の文脈では、統合テストはUIレイヤー、ビジネスロジック、データソースの間の相互作用をカバーします。例えば、テストは「ログイン」ボタンをクリックした後に、アプリがサーバーにリクエストを送信し、トークンを受信し、ローカルストレージに保存することを検証できます。このような検証により、コンポーネントチェーンが障害なく動作することが確認されます。

World Quality Report 2023によると、定期的に統合テストを実施している企業は、単体テストのみに依存するプロジェクトに比べてプロダクションインシデントの数を35%減少させています。これにより、統合テストは商業開発における品質保証戦略の必須要素となっています。

モバイルアプリで統合テストが必要な理由

モバイルアプリは、ネットワークリクエスト、ローカルデータベース、プッシュ通知、システムサービス、サードパーティSDKなど、相互に関連した多くのコンポーネントから構成されています。これらの各コンポーネントは単独で開発されますが、ランタイムではリアルタイムでデータをやり取りします。統合テストは、アイソレートされたモジュール検証では見つけられない缺陷を検出します。

統合テストによって発見される典型的な問題には、APIとアプリモデルのデータ型の不一致、JSONシリアライゼーションエラー、ネットワークタイムアウトの不正な処理、RoomやCore Dataを通じた並行データベースアクセスの失敗があります。統合テストがなければ、こうした缺陷がプロダクションに到達し、実際のユーザーだけに現れます。

Google Testing Blog (2021)の研究によると、統合テスト中に発見された缺陷を修正するコストは、リリース後の5分の1です。これは、初期ステージでは開発者がエラーの全文脈を把握しており、緊急のホットフィックスサイクルなしで修正できるからです。統合テストの作成に時間を投資することは、保守コストの削減とユーザーの信頼性向上という形で優れた成果をもたらします。

統合テストのアプローチ

統合テストには主なアプローチがあります：Big Bang、Bottom-Up、Top-Downです。戦略の選択は、プロジェクトの規模、アプリのアーキテクチャ、テスト作成時のコンポーネントの利用可能性に依存します。各アプローチには、テストカバレッジを計画する際に考慮すべき利点と制約があります。

Big Bang

Big Bang — システムのすべてのコンポーネントを同時に接続し、その後に総合テストを実行するアプローチです。この方法はシンプルで実装できます：stubsを書く必要や個々のモジュールをエミュレートする必要がありません。ただし、エラーが発見された場合、どのコンポーネントが原因かを特定するのが難しくなります。Big Bangは、モジュール数が5つを超えないシンプルなアーキテクチャの小規模プロジェクトに適しています。

Bottom-Up

Bottom-Up — 低レベルコンポーネント（データベース、ネットワークレイヤー、システムサービス）から統合テストを始める戦略です。各レベルの検証後、テストは渐次的に上位のモジュール（リポジトリ、Use Caseクラス、ViewModel）を接続します。主な利点は、アプリの基礎レイヤーでの缺陷の早期発見であり、開発後期における連鎖的なエラーのリスクを低減させます。

Top-Down

Top-Down — UI画面やナビゲーションなど上位コンポーネントからテストを始め、下位モジュールはstubsやmocksを使ってシミュレートするアプローチです。これにより、サーバーサイドやデータベースが完全に実装される前にユーザーシナリオを検証できます。Top-Downは、バックエンドがまだ実際の統合に準備できていない場合のクライアントとサーバーの並行開発に特に役立ちます。

統合テストのツール

モバイルアプリの統合テストには、専門ツールが使用され、サーバーエミュレーションライブラリ、データベースフレームワーク、システムサービス検証ツールの3つのカテゴリに分けられます。具体的なツールの選択は、プラットフォーム（AndroidまたはiOS）とプロジェクトのテクノロジースタックに依存します。

• MockWebServer — Android用のSquareライブラリで、テスト環境でHTTPサーバーをエミュレートします。予期される応答の設定、リクエストボディとヘッダーの検証、ネットワークエラーのシミュレーションが可能です。
• OHHTTPStubs — iOS用のライブラリで、NSURLProtocolレベルでネットワークリクエストを拦戮し、事前に用意した応答を返します。遅延や接続エラーをサポートします。
• Room Testing — Androidの組み込みデータベーステスト機構：インメモリRoomインスタンスの作成、読み込みと書き込み操作の実行、マイグレーションとトリガーの検証。
• Core Data Testing — iOSのアプローチで、インメモリCore Dataコンテナーを作成し、永続的なストレージなしでクエリ、エンティティ関係、データ持続性をテストできます。

統合テストのコード例

AndroidとiOSの統合テストの実践例を見てみましょう。AndroidプラットフォームではJUnitと組み合わせてMockWebServerを使用し、iOSではOHHTTPStubsライブラリとXCTestを使用します。どちらの例も、APIからデータを受け取り、ローカルリポジトリに保存するシナリオを検証します。

Android: MockWebServerでネットワークレイヤーをテスト

このテストは、エミュレートされたサーバーへのRetrofitリクエストが正しいJSONを返すこと、およびリポジトリが応答をドメインモデルに変換することを検証します。MockWebServerはリクエストを拦戮し、指定されたJSONを返し、その後テストは予期結果と実際の結果を比較します。

class UserRepositoryTest {
    private val mockServer = MockWebServer()

    @Before
    fun setup() {
        mockServer.start()
    }

    @Test
    fun fetchUser_returnsCorrectData() {
        val json = "{ \`"id\`": 1, \`"name\`": \`"Alice\`" }"
        mockServer.enqueue(MockResponse()
            .setBody(json)
            .setResponseCode(200))

        val repository = UserRepository(
            createRetrofit(mockServer.url("/").toString()))
        val user = repository.fetchUser(1)

        assertEquals(1, user.id)
        assertEquals("Alice", user.name)
    }

    @After
    fun tearDown() {
        mockServer.shutdown()
    }
}

iOS: OHHTTPStubsでAPIリクエストをテスト

iOSでは、同様のテストでOHHTTPStubsを使用してURLリクエストを拦戮します。このライブラリは、URL Loading Systemのシステムフレームワークレベルでサーバー応答を置き換えるため、あらゆるネットワークライブラリ（URLSession、Alamofire、Moya）をテストできます。

import XCTest
import OHHTTPStubs
import OHHTTPStubsSwift

class UserRepositoryTests: XCTestCase {
    func testFetchUser_returnsCorrectData() {
        stub(condition: isPath("/users/1")) { _ in
            return HTTPStubsResponse(
                jsonObject: ["id": 1, "name": "Alice"],
                statusCode: 200,
                headers: nil
            )
        }

        let repository = UserRepository()
        let expectation = expectation(description: "fetch user")

        repository.fetchUser(id: 1) { user in
            XCTAssertEqual(user.id, 1)
            XCTAssertEqual(user.name, "Alice")
            expectation.fulfill()
        }

        waitForExpectations(timeout: 2.0)
    }
}

統合テストの最善実践

効果的な統合テストには、テストの穏定性を高め、保守コストを削減するプラクティスの守りが必要です。外部依存をアイソレートする：プロダクションインスタンスの代わりにインメモリデータベースを使用し、サードパーティAPIをstubライブラリでエミュレートします。これにより、ネットワークの利用可能性や外部サービスの状態による非検定的な障害を除去できます。

テストの独立性を維持する：各統合テストは、他のテストの結果に依存せずに独立して動作する必要があります。JUnitでは@Beforeや@After注釈を、XCTestではsetUpやtearDownを使用してテスト環境を準備およびクリーンアップします。これにより、テストの相互影響を防ぐことができ、エラー診断を簡素化できます。

エッジケースをカバーする：統合テストは、成功シナリオ（happy path）だけでなく、エラー処理—タイムアウト、HTTP 4xxおよび5xxコード、空の応答、正しくないJSONも検証する必要があります。Google Testing Blog (2022)によると、プロダクションインシデントの60%は、テストでかばりれていなかったエッジケースの不正な処理に関係しています。