Espressoで実現するAndroid UIテストの自動化と品質向上 - Dev.

現代のアプリケーション開発において、ユーザーインターフェース（UI）テストは、製品の品質を保証し、ユーザーに最高の体験を提供するための不可欠なプロセスです。手動でのテストは時間とコストがかかり、ヒューマンエラーのリスクも伴います。ここで強力なソリューションとして登場するのが、Googleが提供するUIテストフレームワーク「Espresso」です。Espressoは、開発者が実際のユーザー操作をシミュレートするテストを自動化し、アプリケーションの安定性と信頼性を飛躍的に向上させることを可能にします。

この記事では、Espressoの基本的な概念から、環境構築、テストコードの作成、そして実際のプロジェクトで役立つ高度なテクニックや設計パターンに至るまで、包括的に解説します。単なるAPIの紹介に留まらず、なぜEspressoが多くの開発者に選ばれるのか、その核心的な思想や、テストを安定させるための秘訣、そして保守性の高いテストコードを書くためのベストプラクティスまでを深く掘り下げていきます。

Espressoを導入することで、開発サイクルが加速し、リグレッションバグを早期に発見し、最終的にはユーザー満足度の高い、高品質なアプリケーションを継続的に提供できるようになるでしょう。それでは、Espressoを用いたAndroid UIテストの世界へ足を踏み入れましょう。

目次

• 第1章: なぜUIテストにEspressoを選ぶのか
  • Androidテストの世界におけるEspressoの位置付け
  • Espressoの核となる3つの特徴
  • Espressoが解決する課題
• 第2章: Espressoテストのための完璧な環境構築
  • 前提条件の確認
  • Gradle依存関係の詳細設定
  • テストの安定性を確保する：アニメーションの無効化
  • セットアップの検証：最初のテストを実行する
• 第3章: Espressoの基本APIとテストケース作成
  • Espresso APIの三位一体：Matcher, Action, Assertion
  • ViewMatchers: UIコンポーネントの特定
  • ViewActions: UIコンポーネントの操作
  • ViewAssertions: UIコンポーネントの状態検証
  • 実践的なテストシナリオの作成
• 第4章: 複雑なUIのテスト：リストとカスタムビュー
  • RecyclerViewのテスト：espresso-contribの活用
  • ListViewとAdapterViews：onDataによるアプローチ
  • ToastメッセージとDialogのテスト
  • Espresso Test Recorderの賢い使い方
• 第5章: テストの実行、デバッグ、そして分析
  • 様々なテスト実行方法
  • CI/CD環境でのテスト実行
  • Espressoテストのデバッグ技術
  • テスト結果の分析とレポート
• 第6章: 高度なテクニックとアーキテクチャ
  • 非同期処理との同期：Idling Resources
  • 保守性を高める設計：Page Object Model
  • インテントのテスト：espresso-intents
  • WebViewのテスト：espresso-web
  • カスタムMatcherとActionの作成
• 第7章: 品質を追求するためのベストプラクティス
  • テストの独立性と焦点を保つ
  • IDの活用と文字列リテラルの排除
  • テストにおけるモックとスタブの活用
  • まとめ：継続的な品質向上のために

第1章: なぜUIテストにEspressoを選ぶのか

アプリケーション開発のライフサイクルにおいて、テストは品質を担保する最後の砦です。その中でもUIテストは、ユーザーが直接触れる部分の動作を保証する上で極めて重要な役割を担います。数あるUIテストフレームワークの中で、なぜEspressoがAndroid開発の標準として広く受け入れられているのでしょうか。この章では、Espressoの哲学、特徴、そしてそれが開発者にもたらす具体的なメリットについて深く探求します。

Androidテストの世界におけるEspressoの位置付け

Androidの自動テストは、大きく3つのカテゴリに分類できます。それぞれのテストは目的と実行環境が異なり、Espressoがどの領域を担当するのかを理解することが重要です。

• ローカルユニットテスト (Local Unit Tests):
  JVM上で直接実行されるテストです。Androidフレームワークへの依存が少ないロジック（ViewModel、Repository、UseCaseなど）のテストに使用されます。実行速度が非常に速いため、ロジックの正当性を迅速に検証するのに適しています。JUnitやMockito、Robolectricといったライブラリが主に利用されます。
• インストゥルメンテーションテスト (Instrumentation Tests):
  Androidデバイスまたはエミュレータ上で実行されるテストです。実際のAndroidフレームワークAPIを利用するため、ActivityのライフサイクルやUIコンポーネントの動作など、Android環境に依存する部分のテストが可能です。Espressoはこのカテゴリに属します。
• エンドツーエンド（E2E）テスト:
  複数のアプリケーションやシステムサービスをまたがるユーザーシナリオをテストします。例えば、「自社アプリでボタンをタップすると、マップアプリが起動して特定の場所が表示される」といったシナリオです。これにはUI Automatorのような、アプリのプロセス外も操作できるフレームワークが用いられます。

Espressoは、単一のアプリケーション内でのUI操作と状態検証に特化した、インストゥルメンテーションテストフレームワークです。その設計思想は「アプリ内のUIフローを、高速かつ確実にテストする」ことに集約されています。

Espressoの核となる3つの特徴

Espressoが他のフレームワークと一線を画す、強力な特徴を見ていきましょう。

1. 自動同期メカニズム (Automatic Synchronization)

UIテストが不安定になる最大の原因の一つは、タイミングの問題です。例えば、ボタンをクリックした後に表示されるはずのダイアログを、表示される前に検証しようとしてテストが失敗する、といったケースは頻繁に起こります。多くのフレームワークでは、これを解決するためにThread.sleep()のような固定長の待機処理を挿入しますが、これはテストを遅くし、デバイスの性能によって結果が変動する「Flaky Test（不安定なテスト）」の温床となります。

Espressoは、この問題を根本的に解決します。UIスレッドがアイドル状態（何も処理していない状態）になるまで、次のテストコードの実行を自動的に待機します。 また、AsyncTaskなどの非同期処理も監視対象に含まれます。これにより、開発者は待機処理を意識することなく、あたかも同期的であるかのようにテストコードを記述できます。この自動同期こそが、Espressoのテストを驚くほど安定させ、信頼性を高めている最大の理由です。

2. 流れるような（Fluent）で可読性の高いAPI

EspressoのAPIは、英語の文章を読むかのように、直感的で理解しやすいように設計されています。テストコードは一般的に以下の構造を取ります。

onView(ViewMatcher).perform(ViewAction).check(ViewAssertion);

これを日本語に訳すと、「（特定の条件に一致するビュー）に対して、（特定のアクション）を実行し、（特定の状態であること）を検証する」となります。例えば、

onView(withId(R.id.login_button)).perform(click()).check(matches(not(isEnabled())));

というコードは、「`login_button`というIDを持つビューをクリックし、そのビューが無効化されていることを確認する」という意図が明確に伝わります。この高い可読性は、テストコードの作成を容易にするだけでなく、後々のメンテナンスや、他の開発者によるコードレビューの効率を大幅に向上させます。

3. Android Studioとの緊密な連携

EspressoはGoogleによって開発されているため、公式IDEであるAndroid Studioとの連携が非常にスムーズです。プロジェクト作成時からテスト用のディレクトリ（androidTest）が用意されており、依存関係の追加も容易です。また、IDEから直接テストクラスや個別のテストメソッドを実行し、その結果を視覚的に確認できます。さらに、後述する「Espresso Test Recorder」機能を使えば、実際に行ったUI操作を自動でテストコードに変換することも可能で、初学者の学習コストを低減させます。

Espressoが解決する課題

• リグレッションの防止: 新機能の追加やリファクタリングによって、既存の機能が意図せず壊れてしまう「リグレッション」を自動的に検出します。
• 開発サイクルの高速化: 手動テストにかかる時間を削減し、開発者はより創造的な作業に集中できます。CI/CDパイプラインに組み込むことで、コード変更のたびに品質を自動でチェックできます。
• 仕様のドキュメント化: よく書かれたテストコードは、アプリケーションがどのように動作すべきかを示す「実行可能な仕様書」としての役割も果たします。

これらの強力な特徴とメリットにより、EspressoはAndroidアプリの品質を一段上のレベルに引き上げるための、現代の開発者にとって必須のツールとなっています。

第2章: Espressoテストのための完璧な環境構築

強力なEspressoの機能を最大限に活用するためには、まず正確な環境構築が不可欠です。この章では、プロジェクトにEspressoを導入し、安定したテストを実行するための準備をステップバイステップで詳しく解説します。

前提条件の確認

Espressoテストを開始する前に、以下の環境が整っていることを確認してください。

• Android Studio: 最新の安定版を推奨します。この記事ではAndroid Studio Iguana | 2023.2.1以降を想定しています。
• Androidプロジェクト: テスト対象となる既存のAndroidプロジェクト。
• テスト実行環境: Android APIレベル18（Jelly Bean MR2）以降の物理デバイスまたはAndroid Emulator。エミュレータを使用する場合、x86またはx86_64イメージを推奨します。

Gradle依存関係の詳細設定

Espressoを利用するには、プロジェクトのbuild.gradle.kts（またはbuild.gradle）ファイルにいくつかのライブラリを追加する必要があります。標準的なAndroid Studioプロジェクトでは、基本的な設定は既に含まれていることが多いですが、内容を理解し、必要に応じて追加することが重要です。

モジュールレベルのbuild.gradle.ktsファイルを開き、dependenciesブロックとandroid.defaultConfigブロックを確認・編集します。

1. テストランナーの設定

まず、defaultConfigブロック内で、インストゥルメンテーションテストを実行するためのテストランナーを指定します。AndroidJUnitRunnerが標準です。

// build.gradle.kts (Module: app)

android {
    // ...
    defaultConfig {
        // ...
        testInstrumentationRunner = "androidx.test.runner.AndroidJUnitRunner"
    }
    // ...
}

2. 必要なライブラリの追加

次に、dependenciesブロックにEspresso関連のライブラリを追加します。用途に応じて複数のライブラリが存在します。

// build.gradle.kts (Module: app)

dependencies {
    // ... 他の依存関係

    // JUnit4 (テストフレームワークの基盤)
    androidTestImplementation("junit:junit:4.13.2")

    // AndroidX Test Core (ActivityScenarioなど、テストのコア機能を提供)
    androidTestImplementation("androidx.test:core-ktx:1.5.0")
    androidTestImplementation("androidx.test.ext:junit-ktx:1.1.5")
    androidTestImplementation("androidx.test:runner:1.5.2")
    
    // Espresso Core (基本的なUIテスト機能を提供)
    androidTestImplementation("androidx.test.espresso:espresso-core:3.5.1")

    // Espresso Contrib (RecyclerView, DatePickerなどの高度なUIコンポーネント用)
    androidTestImplementation("androidx.test.espresso:espresso-contrib:3.5.1")

    // Espresso Intents (インテントの検証用)
    androidTestImplementation("androidx.test.espresso:espresso-intents:3.5.1")

    // Espresso Web (WebView内のコンテンツのテスト用)
    androidTestImplementation("androidx.test.espresso:espresso-web:3.5.1")
}

各ライブラリの役割は以下の通りです。

• espresso-core: 必須のライブラリ。onView(), perform(), check()など、Espressoの基本的なAPIを含みます。
• espresso-contrib: RecyclerView, DrawerLayout, ViewPager2, DatePickerなど、Coreには含まれない複雑なUIコンポーネントをテストするための便利な機能を提供します。特にRecyclerViewのテストには事実上必須です。
• espresso-intents: アプリケーションが発行するインテント（画面遷移、外部アプリ連携など）を検証したり、スタブ化（偽の応答を返す）したりするために使用します。
• espresso-web: WebViewコンポーネント内のHTML要素を操作・検証するために使用します。

依存関係を追加したら、Android Studioの上部に表示される「Sync Now」をクリックして、プロジェクトを同期します。

テストの安定性を確保する：アニメーションの無効化

EspressoはUIスレッドのアイドルを待ちますが、実行中のアニメーションはUIが「ビジー」であると判断させ、テストのタイムアウトを引き起こす可能性があります。そのため、インストゥルメンテーションテストを実行する際は、デバイスのアニメーションを無効化することが強く推奨されます。これはテストの安定性を劇的に向上させる、非常に重要なステップです。

方法1: adbコマンドによる無効化（推奨）

テストを実行するデバイス（物理またはエミュレータ）に対して、以下の3つのadbコマンドを実行します。これにより、システム全体のアニメーションスケールが0に設定されます。

adb shell settings put global window_animation_scale 0.0
adb shell settings put global transition_animation_scale 0.0
adb shell settings put global animator_duration_scale 0.0

テスト終了後に元に戻す場合は、0.0を1.0にして再度コマンドを実行します。

方法2: 開発者向けオプションでの手動設定

デバイスの「設定」→「開発者向けオプション」を開き、以下の3つの項目を「アニメーションオフ」または「アニメーションスケール .5x」から「アニメーションなし」に設定します。

• ウィンドウ アニメーション スケール
• トランジション アニメーション スケール
• アニメーター再生時間スケール

CI/CD環境など、自動化された環境では方法1が必須となります。

セットアップの検証：最初のテストを実行する

環境構築が正しく完了したかを確認するために、簡単なテストケースを作成して実行してみましょう。

Android Studioのプロジェクトビューで、app/src/androidTest/java/com.example.yourapp/ディレクトリに、新しいKotlinクラスを作成します。例としてMainActivityFirstTest.ktという名前にします。

package com.example.yourapp

import androidx.test.core.app.ActivityScenario
import androidx.test.espresso.Espresso.onView
import androidx.test.espresso.assertion.ViewAssertions.matches
import androidx.test.espresso.matcher.ViewMatchers.isDisplayed
import androidx.test.espresso.matcher.ViewMatchers.withText
import androidx.test.ext.junit.runners.AndroidJUnit4
import org.junit.Test
import org.junit.runner.RunWith

// このテストクラスがAndroidJUnit4ランナーで実行されることを示すアノテーション
@RunWith(AndroidJUnit4::class)
class MainActivityFirstTest {

    // 各テストメソッドは@Testアノテーションを付与する
    @Test
    fun activityLaunchesSuccessfully() {
        // MainActivityを起動する
        ActivityScenario.launch(MainActivity::class.java)

        // これで最低限、アプリがクラッシュせずに起動することを確認できる
    }

    @Test
    fun checkHelloWorldTextIsDisplayed() {
        // MainActivityを起動
        ActivityScenario.launch(MainActivity::class.java)

        // "Hello World!"というテキストを持つViewを探し、
        // そのViewが画面に表示されていることを確認する
        onView(withText("Hello World!")).check(matches(isDisplayed()))
    }
}

このコードの説明：

• @RunWith(AndroidJUnit4::class): このクラスがAndroidデバイス上で実行されるインストゥルメンテーションテストであることをJUnitに伝えます。
• @Test: これがテストメソッドであることを示します。
• ActivityScenario.launch(...): 指定したActivityを安全に起動し、テストが可能な状態にするためのAPIです。従来のActivityTestRuleよりも推奨されています。
• onView(withText(...)): 「"Hello World!"」というテキストが表示されているViewを探します。
• check(matches(isDisplayed())): 見つかったViewが画面上に表示されている（visibilityがVISIBLEである）ことを検証します。

このテストを実行するには、クラス名またはメソッド名の横にある緑色の再生ボタンをクリックし、「Run 'testName()'」を選択します。テストが成功すれば、画面下部の実行ペインに緑色のチェックマークが表示されます。これで、Espressoを実行するための環境が整いました。

第3章: Espressoの基本APIとテストケース作成

環境構築が完了したところで、いよいよEspressoの核心であるAPIの使い方を学び、実践的なテストケースを作成していきます。この章では、Espressoのテストコードを構成する3つの主要な要素を深く理解し、それらを組み合わせてユーザーの操作フローをシミュレートする方法を習得します。

Espresso APIの三位一体：Matcher, Action, Assertion

Espressoのテストは、基本的に以下の3つのコンポーネントの組み合わせで記述されます。この「探す(Find) → 操作する(Act) → 検証する(Assert)」という流れを理解することが、Espressoをマスターするための第一歩です。

1. ViewMatchers: onView()メソッドと共に使用され、画面上の特定のUIコンポーネント（View）を見つけ出すための条件を定義します。
2. ViewActions: perform()メソッドと共に使用され、見つけ出したViewに対してクリック、テキスト入力、スワイプなどの操作を実行します。
3. ViewAssertions: check()メソッドと共に使用され、見つけ出したViewが特定の状態（表示されているか、特定のテキストを持っているかなど）であることを検証します。

この3つの組み合わせにより、「IDがlogin_buttonのビューを見つけ、それをクリックし、プログレスバーが表示されることを確認する」といった一連のテストシナリオを、コードとして表現できるのです。

ViewMatchers: UIコンポーネントの特定

テスト対象のViewを正確に特定することが、安定したUIテストの基礎です。Espressoは、androidx.test.espresso.matcher.ViewMatchersクラスを通じて、豊富で強力なMatcherを提供しています。

よく使われるViewMatchers

• withId(R.id.your_id): 指定されたリソースIDを持つViewを検索します。最も信頼性が高く、推奨される方法です。
• withText("Some Text"): 指定されたテキストと完全に一致するテキストを持つView（TextView, Buttonなど）を検索します。
• withText(stringResource(R.string.your_string)): 文字列リソースIDを使ってテキストを照合します。多言語対応アプリでは必須です。
• withHint("Enter username"): EditTextのヒントテキストを元に検索します。
• withContentDescription("Settings button"): アクセシビリティのために設定されたcontentDescriptionを元に検索します。ImageButtonなど、テキストを持たないViewに有効です。
• isDisplayed(): 画面に表示されているViewを検索します。
• isEnabled(), isChecked(), isSelected(): Viewの状態に基づいて検索します。

Matcherの組み合わせ

単一の条件ではViewを特定できない場合、HamcrestライブラリのMatcherを使って条件を組み合わせることができます。

• allOf(...): 全ての条件に一致するViewを検索します。
  onView(allOf(withId(R.id.submit_button), withText("Submit"), isDisplayed()))
• anyOf(...): いずれかの条件に一致するViewを検索します。
• not(...): 指定された条件に一致しないViewを検索します。
  onView(allOf(withId(R.id.result_text), not(withText("Loading..."))))

ヒント: テストの安定性を最大限に高めるため、可能な限りwithId()を使用してください。テキストはローカライズによって変化する可能性があり、 brittle（壊れやすい）テストの原因となります。

ViewActions: UIコンポーネントの操作

Viewを特定したら、次はそのViewに対してユーザーが行うであろう操作を実行します。androidx.test.espresso.action.ViewActionsクラスが、一般的な操作を提供します。

よく使われるViewActions

• click(): Viewをシングルクリックします。
• doubleClick(): Viewをダブルクリックします。
• longClick(): Viewを長押しします。
• typeText("hello world"): EditTextなどのテキスト入力可能なViewに文字列を入力します。
• replaceText("new text"): View内の既存のテキストを、指定した新しいテキストで置き換えます。
• clearText(): View内のテキストをクリアします。
• pressKey(KeyEvent.KEYCODE_ENTER): ハードウェアキーの押下をシミュレートします。
• closeSoftKeyboard(): 表示されているソフトウェアキーボードを閉じます。
• scrollTo(): ScrollViewやNestedScrollView内のViewまでスクロールします。（対象のViewがScrollViewの子孫である必要があります）
• swipeLeft(), swipeRight(), swipeUp(), swipeDown(): Viewをスワイプします。ViewPagerなどで使用します。

複数のActionの実行

perform()メソッドには可変長引数を渡せるため、複数のアクションを連続して実行できます。

onView(withId(R.id.search_box))
    .perform(clearText(), typeText("Espresso"), closeSoftKeyboard())

ViewAssertions: UIコンポーネントの状態検証

アクションを実行した結果、UIが期待通りの状態に変化したかを検証するのがAssertionの役割です。androidx.test.espresso.assertion.ViewAssertionsクラスが、検証のためのメソッドを提供します。

よく使われるViewAssertions

最も一般的に使用されるのはmatches()で、引数にViewMatcherを取ります。これにより、Viewの特定に使った豊富なMatcherを、状態検証のためにも再利用できます。

• matches(isDisplayed()): Viewが画面に表示されていることを確認します。
• matches(not(isDisplayed())): Viewが画面に表示されていないことを確認します。
• matches(withText("Result Text")): Viewが指定されたテキストを持っていることを確認します。
• matches(isEnabled()), matches(not(isEnabled())): Viewが有効/無効状態であることを確認します。
• matches(isChecked()), matches(isNotChecked()): CheckBoxやRadioButtonがチェックされているかを確認します。

存在しないことの検証

特定のViewが画面上に存在しない（または、表示されていない）ことを確認したい場合もあります。その場合はdoesNotExist()アサーションを使用します。

// ログアウト後、ユーザー名が表示されていたTextViewが存在しないことを確認
onView(withId(R.id.user_name_text)).check(doesNotExist())

これは、onView()がViewを見つけられなかった場合にNoMatchingViewExceptionをスローするのではなく、テストを成功とみなします。

実践的なテストシナリオの作成

それでは、これらのAPIを組み合わせて、ログイン画面の簡単なテストシナリオを作成してみましょう。

シナリオ:

1. ユーザー名とパスワードを入力する。
2. ログインボタンをクリックする。
3. ログイン成功後、次の画面に「Welcome, (ユーザー名)!」というテキストが表示されることを確認する。

import androidx.test.core.app.ActivityScenario
import androidx.test.espresso.Espresso.onView
import androidx.test.espresso.action.ViewActions.*
import androidx.test.espresso.assertion.ViewAssertions.matches
import androidx.test.espresso.matcher.ViewMatchers.*
import androidx.test.ext.junit.runners.AndroidJUnit4
import org.junit.Test
import org.junit.runner.RunWith

@RunWith(AndroidJUnit4::class)
class LoginScreenTest {

    @Test
    fun login_withValidCredentials_showsWelcomeMessage() {
        // 1. テスト対象のActivityを起動
        ActivityScenario.launch(LoginActivity::class.java)
        
        val username = "android_dev"
        
        // 2. Arrange (準備): 必要な情報を入力
        // ユーザー名入力フィールドにテキストを入力
        onView(withId(R.id.edit_text_username))
            .perform(typeText(username), closeSoftKeyboard())

        // パスワード入力フィールドにテキストを入力
        onView(withId(R.id.edit_text_password))
            .perform(typeText("password123"), closeSoftKeyboard())

        // 3. Act (実行): アクションを実行
        // ログインボタンをクリック
        onView(withId(R.id.button_login)).perform(click())

        // 4. Assert (検証): 結果を確認
        // 次の画面（MainActivity）に遷移し、ウェルカムメッセージが表示されていることを確認
        val welcomeMessage = "Welcome, $username!"
        onView(withId(R.id.text_view_welcome))
            .check(matches(isDisplayed()))
            .check(matches(withText(welcomeMessage)))
    }
}

この例では、「Arrange-Act-Assert」というテストの基本パターンに従っています。このようにテストを構造化することで、何をしているのかが明確になり、可読性と保守性が向上します。この章で学んだ基本APIをマスターすれば、アプリケーションの主要なUIフローの多くをテストできるようになります。

第4章: 複雑なUIのテスト：リストとカスタムビュー

基本的なUIコンポーネントのテスト方法を習得したところで、次はより複雑で動的なUI、特にRecyclerViewのようなリスト表示や、Toastメッセージ、ダイアログなどのテスト方法について学びます。これらのUIは標準的なonView()だけではうまく扱えないことがあり、Espressoが提供する拡張ライブラリや特別なアプローチが必要になります。

RecyclerViewのテスト：espresso-contribの活用

RecyclerViewは、画面に表示されていないアイテムをリサイクルして効率的に大量のデータを表示するため、その内部構造は複雑です。そのため、特定のアイテムを見つけて操作するには、espresso-contribライブラリに含まれるRecyclerViewActionsクラスを使用する必要があります。

まず、build.gradle.ktsにespresso-contribの依存関係が追加されていることを確認してください。

androidTestImplementation("androidx.test.espresso:espresso-contrib:3.5.1")

RecyclerViewActionsは、主に3つの強力な機能を提供します。

1. 特定の位置のアイテムまでスクロールする: scrollToPosition()

長いリストの特定の位置にあるアイテムをテストしたい場合、まずそのアイテムが画面内に表示されるようにスクロールする必要があります。

// RecyclerViewのIDを指定し、15番目（0-indexed）のアイテムまでスクロール
onView(withId(R.id.my_recycler_view))
    .perform(RecyclerViewActions.scrollToPosition<MyViewHolder>(15))

2. 特定の条件に一致するアイテムまでスクロールする: scrollTo()

位置ではなく、アイテムの内容（例えば特定のテキスト）を頼りにスクロールしたい場合に使います。

// "Item 50" というテキストを持つアイテムまでスクロール
onView(withId(R.id.my_recycler_view))
    .perform(RecyclerViewActions.scrollTo<MyViewHolder>(
        hasDescendant(withText("Item 50"))
    ))

3. アイテムに対してアクションを実行する: actionOnItemAtPosition() と actionOnItem()

スクロール後、あるいは既に表示されているアイテムに対してクリックなどのアクションを実行します。

• 位置で指定: actionOnItemAtPosition()

// 10番目のアイテムをクリックする
onView(withId(R.id.my_recycler_view))
    .perform(RecyclerViewActions.actionOnItemAtPosition<MyViewHolder>(10, click()))

• 内容で指定: actionOnItem()

// "Delete This" というテキストを持つアイテムを探し、そのアイテム全体をクリック
onView(withId(R.id.my_recycler_view))
    .perform(RecyclerViewActions.actionOnItem<MyViewHolder>(
        hasDescendant(withText("Delete This")),
        click()
    ))

さらに、アイテム内の特定の子View（例えば、アイテム内の「削除」ボタン）をクリックすることも可能です。

// カスタムViewActionを作成して、特定の子Viewをクリック
fun clickChildViewWithId(id: Int): ViewAction {
    return object : ViewAction {
        override fun getConstraints(): Matcher<View>? = null
        override fun getDescription(): String = "Click on a child view with specified id."
        override fun perform(uiController: UiController, view: View) {
            val v = view.findViewById<View>(id)
            v.performClick()
        }
    }
}

// "Item with button" というテキストを持つアイテムを探し、その中にある R.id.delete_button をクリック
onView(withId(R.id.my_recycler_view))
    .perform(RecyclerViewActions.actionOnItem<MyViewHolder>(
        hasDescendant(withText("Item with button")),
        clickChildViewWithId(R.id.delete_button)
    ))

ListViewとAdapterViews：onDataによるアプローチ

RecyclerViewほど一般的ではありませんが、ListView, GridView, SpinnerなどのAdapterViewをテストする場合は、onView()ではなくonData()を使用します。onData()は、ビューの階層ではなく、アダプターに含まれるデータそのものを検索対象とします。

// アダプター内で "Item 10" という文字列データに一致するものを探す
onData(allOf(is(instanceOf(String::class.java)), `is`("Item 10")))
    .inAdapterView(withId(R.id.my_list_view)) // どのAdapterViewかを指定
    .perform(click()) // そのアイテムをクリック

// 5番目のアイテムをクリック
onData(anything())
    .inAdapterView(withId(R.id.my_list_view))
    .atPosition(5)
    .perform(click())

onData()はRecyclerViewには使用できないため、注意が必要です。

ToastメッセージとDialogのテスト

Toastメッセージ

Toastは標準のビュー階層に属さず、独自のウィンドウに表示されるため、特別な扱いが必要です。Toastメッセージのテキストを検証するには、以下のようにします。

// ボタンをクリックするとToastが表示されるシナリオ
onView(withId(R.id.show_toast_button)).perform(click())

// "Success!" というテキストのToastが表示されたことを確認
onView(withText("Success!"))
    // .inRoot() で検索対象をToastのウィンドウに絞り込む
    .inRoot(withDecorView(not(`is`(activity.window.decorView))))
    .check(matches(isDisplayed()))

withDecorView(not(is(activity.window.decorView)))という部分は、「現在のアクティビティのメインウィンドウではない、別のウィンドウ（この場合はToast）を検索する」というお決まりのパターンです。

Dialog

AlertDialogなどもToastと同様に独自のウィンドウを持つため、inRoot()を使って検索範囲を絞り込むのが一般的です。

// "Delete" ボタンをクリックすると確認ダイアログが表示される
onView(withId(R.id.delete_item_button)).perform(click())

// ダイアログ内のメッセージを検証
onView(withText("Are you sure you want to delete?"))
    .inRoot(isDialog()) // ダイアログのウィンドウに絞り込むヘルパー
    .check(matches(isDisplayed()))

// ダイアログの "OK" ボタンをクリック
onView(withText("OK"))
    .inRoot(isDialog())
    .perform(click())

Espresso Test Recorderの賢い使い方

Android Studioには、実際のUI操作を記録してEspressoのテストコードを自動生成する「Espresso Test Recorder」機能が搭載されています。これは、Espressoの学習初期や、複雑な画面の基本的なテストコードの雛形を作成する際に非常に便利です。

使い方:

1. Android Studioのメニューから「Run」→「Record Espresso Test」を選択します。
2. テスト対象のアプリがデバイス/エミュレータにインストールされ、起動します。
3. アプリを操作すると、その操作が記録され、リアルタイムでコードが生成されます。
4. 「Add Assertion」ボタンをクリックして、画面上の要素の状態（テキスト、表示状態など）を検証するコードを追加することもできます。
5. 記録が完了したら、「OK」をクリックすると、テストファイルが生成されます。

注意点:

• 生成されたコードは完璧ではない: Test Recorderは、しばしば冗長で、保守性の低いコードを生成することがあります。例えば、withId()が使える場面でも、テキストや階層構造に依存した脆いMatcherを生成することがあります。
• ロジックは含まない: 生成されるのはUI操作の記録のみであり、テストの意図やロジック（なぜその操作をするのか、なぜその状態を期待するのか）は開発者が後から追加・修正する必要があります。

Test Recorderはあくまで「出発点」として活用し、生成されたコードをリファクタリングして、より堅牢で保守性の高いテストに仕上げていくのが賢明な使い方です。

第5章: テストの実行、デバッグ、そして分析

テストコードを作成したら、次はそのテストを実行し、失敗した場合には原因を特定（デバッグ）し、結果を分析して品質改善に繋げるサイクルを回す必要があります。この章では、テストの様々な実行方法から、CI/CDへの統合、そしてデバッグのテクニックまでを解説します。

様々なテスト実行方法

1. Android Studioからの実行

最も手軽な方法で、開発中に頻繁に利用します。

• 単一テストメソッドの実行: テストメソッドの横にある緑色の再生アイコンをクリックします。
• テストクラス全体の実行: テストクラスの横にある緑色の再生アイコンをクリックします。
• 特定のパッケージ/ディレクトリ内の全テスト実行: プロジェクトビューで対象のディレクトリを右クリックし、「Run 'Tests in ...'」を選択します。

実行結果は、Android Studio下部の「Run」ウィンドウに表示され、各テストの成功（緑）、失敗（赤）、無視（黄）が一覧できます。失敗したテストをクリックすると、スタックトレースやエラーメッセージ（例：NoMatchingViewException）が表示され、原因究明の手がかりとなります。

2. Gradleコマンドラインからの実行

CI/CDサーバーでの自動実行や、ターミナルでの操作を好む開発者には、Gradlewコマンドが便利です。

# プロジェクトのルートディレクトリで実行

# 全てのインストゥルメンテーションテストを実行（全てのビルドバリアント）
./gradlew connectedAndroidTest

# 特定のビルドバリアント（例：debug）のテストを実行
./gradlew connectedDebugAndroidTest

# 特定のモジュールのテストを実行
./gradlew :your_module:connectedDebugAndroidTest

テストが完了すると、HTML形式の綺麗なレポートが生成されます。レポートは通常、[モジュール名]/build/reports/androidTests/connected/ディレクトリにあります。このレポートには、各テストの実行時間、結果、失敗したテストのスクリーンショット（設定による）などが含まれており、チームでの結果共有に役立ちます。

CI/CD環境でのテスト実行

Espressoテストの真価は、CI/CD（継続的インテグレーション/継続的デプロイメント）パイプラインに組み込むことで発揮されます。コードがリポジトリにプッシュされるたびに、自動的にテストが実行され、リグレッションを即座に検出できます。

GitHub Actionsでの設定例：

name: Android CI

on:
  push:
    branches: [ main ]
  pull_request:
    branches: [ main ]

jobs:
  test:
    runs-on: macos-latest # AndroidエミュレータはmacOSまたはLinux環境が必要
    steps:
    - name: Checkout code
      uses: actions/checkout@v3

    - name: Set up JDK
      uses: actions/setup-java@v3
      with:
        distribution: 'temurin'
        java-version: '17'

    - name: Grant execute permission for gradlew
      run: chmod +x gradlew

    - name: Run Espresso tests
      uses: reactivecircus/android-emulator-runner@v2
      with:
        api-level: 30
        script: ./gradlew connectedDebugAndroidTest

    - name: Upload test reports
      uses: actions/upload-artifact@v3
      with:
        name: test-reports
        path: app/build/reports/

この設定では、`android-emulator-runner`という便利なActionを使い、CI環境内でエミュレータを起動し、Gradleコマンドでテストを実行しています。これにより、プルリクエストがマージされる前に、UIテストがパスすることを保証できます。

Espressoテストのデバッグ技術

テストが失敗した時、迅速に原因を特定するためのデバッグは重要です。

ブレークポイントの設置

Espressoテストコードは、アプリケーションコードと同様にデバッグ可能です。テストコードの行番号の横をクリックしてブレークポイントを設置し、デバッグモード（虫のアイコン）でテストを実行すれば、その地点で実行が停止し、変数の状態やUIの階層をインスペクタで確認できます。

一般的な例外とその対処法

• NoMatchingViewException:
  • 原因: 指定したMatcherに一致するViewが見つからなかった。
  • 対処法: Matcherの条件が正しいか（ID、テキストのタイポなど）、対象のViewが画面に表示される前に検証しようとしていないか（非同期処理の待機漏れ）、そもそもViewが階層内に存在するかを確認します。
• AmbiguousViewMatcherException:
  • 原因: 指定したMatcherに一致するViewが複数見つかった。
  • 対処法: allOf()などを使って、Matcherの条件をより具体的にし、Viewが一意に特定できるようにします。例えば、withText("Next")だけではなくallOf(withId(R.id.next_button), withText("Next"))のようにします。
• PerformException:
  • 原因: Viewに対して不可能な操作を実行しようとした（例：表示されていないViewをクリックしようとした、ScrollViewの外にあるViewにscrollTo()しようとした）。
  • 対処法: アクションを実行する前に、Viewが適切な状態（表示されている、クリック可能であるなど）であることを確認します。必要であれば、適切なスクロールアクションを追加します。

カスタムFailureHandler

テストが失敗した際に、スクリーンショットを撮ったり、追加のログ情報を出力したりするために、カスタムのFailureHandlerを実装することもできます。これにより、特にCI環境での失敗原因の特定が容易になります。

テスト結果の分析とレポート

前述の通り、Gradleでテストを実行するとHTMLレポートが生成されます。このレポートは、テストスイート全体の健全性を把握するための重要な情報源です。

• 成功率: 全体的なテストの成功率を監視し、低下傾向にあれば原因を調査します。
• Flaky Testsの特定: 同じコードでも成功したり失敗したりする不安定なテストを特定します。これらのテストは、非同期処理の待機漏れや、テスト間の状態依存が原因であることが多く、優先的に修正すべきです。
• 実行時間の長いテスト: 実行時間が極端に長いテストは、CIの実行時間を圧迫します。テストのロジックを見直したり、不必要な待機処理がないかを確認したりします。

テストは書くだけでなく、実行し、その結果を分析してフィードバックを得るというサイクルを回すことで、初めてその価値を最大限に発揮します。

第6章: 高度なテクニックとアーキテクチャ

Espressoの基本をマスターしたら、次はより複雑なシナリオに対応し、テストコード自体の品質を高めるための高度なテクニックとアーキテクチャパターンを学びます。これらの知識は、大規模で長期的にメンテナンスされるプロジェクトにおいて、テストスイートの信頼性と保守性を維持するために不可欠です。

非同期処理との同期：Idling Resources

Espressoの自動同期機能は強力ですが、全ての非同期処理を自動で検出できるわけではありません。例えば、独自のバックグラウンドスレッド、RxJava/Kotlin Coroutinesによる非同期処理、ネットワーク通信、データベースアクセスなどは、Espressoがデフォルトでは完了を待ってくれません。これにより、データロードが完了する前にUIを検証しようとして、テストが失敗する（Flakyになる）原因となります。

この問題を解決するのがIdlingResourceです。これは、アプリが「ビジー状態」か「アイドル状態」かをEspressoに伝えるためのシンプルなインターフェースです。

使い方:

1. IdlingResourceを実装する: アプリの非同期処理の開始と終了を追跡するクラスを作成します。CountingIdlingResourceは、実行中のタスク数をカウントするだけで簡単に実装できる便利なクラスです。
2. アプリコードでIdlingResourceを操作する: 非同期処理を開始する直前にincrement()を呼び、終了した直後（成功時も失敗時も）にdecrement()を呼びます。
3. テストコードでIdlingResourceを登録する: @Beforeアノテーションを付けたセットアップメソッドでIdlingRegistry.getInstance().register()を呼び、@Afterアノテーションを付けたティアダウンメソッドでunregister()を呼び出します。

実装例 (CountingIdlingResource):

シングルトンやDIを使って、アプリ全体で共有されるIdlingResourceのインスタンスを用意します。

// アプリケーション全体で共有するIdlingResourceラッパー
object EspressoIdlingResource {
    private const val RESOURCE = "GLOBAL"
    @JvmField
    val countingIdlingResource = CountingIdlingResource(RESOURCE)

    fun increment() {
        countingIdlingResource.increment()
    }

    fun decrement() {
        if (!countingIdlingResource.isIdleNow) {
            countingIdlingResource.decrement()
        }
    }
}

非同期処理を行うクラス（例: ViewModel, Repository）でこれを呼び出します。

class MyViewModel : ViewModel() {
    fun fetchData() {
        EspressoIdlingResource.increment() // 非同期処理開始
        // ... ネットワークリクエストやDBアクセスなど ...
        // 処理が完了したら (onSuccess, onError, onCompleteなど)
        EspressoIdlingResource.decrement() // 非同期処理終了
    }
}

テストクラスで登録・解除します。

@RunWith(AndroidJUnit4::class)
class MyActivityTest {

    @Before
    fun registerIdlingResource() {
        IdlingRegistry.getInstance().register(EspressoIdlingResource.countingIdlingResource)
    }

    @After
    fun unregisterIdlingResource() {
        IdlingRegistry.getInstance().unregister(EspressoIdlingResource.countingIdlingResource)
    }

    @Test
    fun dataIsLoadedAndDisplayed() {
        // ... Activity起動 ...
        // このテストは、EspressoIdlingResourceのカウントが0になるまで自動で待機する
        onView(withId(R.id.result_text)).check(matches(withText("Loaded Data")))
    }
}

IdlingResourceを正しく実装することで、Thread.sleep()を完全に排除し、信頼性の高いテストを実現できます。

保守性を高める設計：Page Object Model

テストケースが増えるにつれて、同じUI要素への参照（onView(withId(...))）や操作が複数のテストクラスに散乱し、UIの変更（例：IDの変更）があった場合に多数のファイルを修正する必要が出てきます。これは保守性の低下に直結します。

Page Object Model (POM) は、この問題を解決するための設計パターンです。これは、アプリケーションの各画面（ページ）を一つのクラスとしてモデル化し、その画面内のUI要素と、それらに対する操作をメソッドとしてカプセル化するアプローチです。

POMを適用しない場合:

@Test
fun testLoginFailure() {
    onView(withId(R.id.edit_text_username)).perform(typeText("wrong"))
    onView(withId(R.id.edit_text_password)).perform(typeText("user"))
    onView(withId(R.id.button_login)).perform(click())
    onView(withText("Login Failed")).check(matches(isDisplayed()))
}

POMを適用した場合:

まず、LoginPageクラスを作成します。

class LoginPage {
    private val usernameField = onView(withId(R.id.edit_text_username))
    private val passwordField = onView(withId(R.id.edit_text_password))
    private val loginButton = onView(withId(R.id.button_login))

    fun enterUsername(username: String): LoginPage {
        usernameField.perform(typeText(username))
        return this // メソッドチェーンを可能にする
    }

    fun enterPassword(password: String): LoginPage {
        passwordField.perform(typeText(password))
        return this
    }

    fun clickLogin(): MainPage {
        loginButton.perform(click())
        // 成功した場合は次のページのオブジェクトを返す
        return MainPage()
    }
    
    fun clickLoginWithFailure(): LoginPage {
        loginButton.perform(click())
        return this
    }

    fun checkErrorMessage(message: String) {
        onView(withText(message)).check(matches(isDisplayed()))
    }
}

テストコードは、このLoginPageオブジェクトを使って、より宣言的で読みやすく記述できます。

@Test
fun testLoginFailure() {
    val loginPage = LoginPage()
    loginPage.enterUsername("wrong")
             .enterPassword("user")
             .clickLoginWithFailure()
             .checkErrorMessage("Login Failed")
}

POMのメリット:

• 保守性の向上: UIのIDが変更されても、修正はPage Objectクラスの1箇所だけで済みます。
• 可読性の向上: テストコードが「何を」しているのか（ビジネスロジック）に焦点を当て、「どのように」実現しているのか（UI操作の詳細）をカプセル化できます。
• 再利用性の向上: 同じ画面操作を複数のテストで再利用できます。

インテントのテスト：espresso-intents

アプリが正しく外部のActivity（ブラウザ、連絡先アプリなど）や、アプリ内の別のActivityを起動しているかをテストしたい場合があります。espresso-intentsライブラリは、テスト中に発行されるインテントを捕捉し、検証する機能を提供します。

// ActivityTestRuleの代わりにIntentsTestRuleを使用するか、
// @Before/@AfterでIntents.init()/release()を呼び出す
@get:Rule
val intentsTestRule = IntentsTestRule(MainActivity::class.java)

@Test
fun clickShareButton_launchesShareIntent() {
    // 期待するインテントを定義
    val expectedIntent = allOf(
        hasAction(Intent.ACTION_SEND),
        hasExtra(Intent.EXTRA_TEXT, "Check out this great app!"),
        hasType("text/plain")
    )

    // テスト中に発行されるACTION_SENDインテントをスタブ化（実際には起動させない）
    intending(expectedIntent).respondWith(Instrumentation.ActivityResult(Activity.RESULT_OK, null))

    // 共有ボタンをクリック
    onView(withId(R.id.share_button)).perform(click())
    
    // 期待したインテントが実際に発行されたかを検証
    intended(expectedIntent)
}

これにより、外部アプリに依存することなく、インテントが正しく構築・発行されたことを確実にテストできます。

WebViewのテスト：espresso-web

アプリ内にWebViewがあり、その中のWebコンテンツとインタラクションする必要がある場合、espresso-webライブラリが役立ちます。これは、EspressoのAPIを使いながら、JavaScriptを介してDOM要素を操作・検証する機能を提供します。

// WebView内のIDが'login_form'のフォームを操作
onWebView()
    .withElement(findElement(Locator.ID, "username"))
    .perform(webKeys("my_user"))
    .withElement(findElement(Locator.ID, "password"))
    .perform(webKeys("my_pass"))
    .withElement(findElement(Locator.ID, "submit"))
    .perform(webClick())

// 結果のテキストを検証
onWebView()
    .withElement(findElement(Locator.ID, "message"))
    .check(webMatches(getText(), containsString("Welcome")))

これにより、ネイティブUIとWeb UIが混在するハイブリッドアプリのテストも、一貫した方法で行うことができます。

カスタムMatcherとActionの作成

Espressoが提供する標準の機能だけでは不十分な、独自のカスタムビューや複雑な検証を行いたい場合、MatcherやViewActionを自作できます。例えば、「TextViewに特定のエラーテキストが設定されているか」を検証するカスタムMatcherは以下のようになります。

fun hasErrorText(expectedError: String): Matcher<View> {
    return object : BoundedMatcher<View, TextView>(TextView::class.java) {
        override fun describeTo(description: Description) {
            description.appendText("with error text: ").appendText(expectedError)
        }

        override fun matchesSafely(item: TextView): Boolean {
            return item.error?.toString() == expectedError
        }
    }
}

// 使い方
onView(withId(R.id.email_field)).check(matches(hasErrorText("Invalid email format")))

これらの高度なテクニックを駆使することで、Espressoの能力を最大限に引き出し、あらゆるUIテストシナリオに対応できるようになります。

第7章: 品質を追求するためのベストプラクティス

これまでEspressoの機能とテクニックを学んできましたが、ツールを使いこなすだけでは最高の品質は達成できません。ここでは、信頼性が高く、保守性に優れ、長期的に価値を提供し続けるテストスイートを構築するためのベストプラクティスを紹介します。

テストの独立性と焦点を保つ

各テストは独立しているべき (Independent):
一つのテストケースが、他のテストケースの結果に依存してはいけません。例えば、テストAが作成したデータをテストBが利用する、といった設計は避けるべきです。テストの実行順序は保証されず、テストAが失敗するとテストBも連鎖的に失敗し、問題の切り分けが困難になります。各テストは、@Beforeで必要な状態をセットアップし、@Afterでクリーンアップ（DBのクリア、SharedPreferenceの削除など）を行い、自己完結するように設計しましょう。

小さく、焦点を絞る (Focused):
一つのテストメソッドでは、一つのことだけを検証すべきです。ログイン機能、プロフィール編集機能、ログアウト機能を一つの巨大なテストで検証するのではなく、「有効な認証情報でのログイン成功」「無効な認証情報でのログイン失敗」「プロフィールの更新成功」のように、シナリオを細かく分割します。これにより、テストが失敗した際に、どの機能に問題があるのかが一目瞭然になります。

"Arrange, Act, Assert" (AAA) パターンに従う:
第3章で触れたこのパターンを常に意識しましょう。テストコードを「準備(Arrange)」「実行(Act)」「検証(Assert)」の3つのブロックに明確に分けることで、テストの意図が格段に理解しやすくなります。

IDの活用と文字列リテラルの排除

Viewの特定にはwithId()を最優先で使う:
テキスト（withText()）やコンテンツの説明（withContentDescription()）によるViewの特定は、ローカライゼーションやデザインの変更によって容易に壊れてしまいます。リソースIDは、これらの変更の影響を受けにくいため、最も堅牢な識別子です。テスト対象となる重要なUI要素には、必ずユニークなIDを割り当てるようにしましょう。

テストコード内のマジックナンバーや文字列リテラルを避ける:
テストで使用するテキストや数値は、定数として定義するか、アプリケーションの文字列リソース（R.string）を参照するようにしましょう。これにより、値の変更が容易になり、コードの意図も明確になります。

// 悪い例
onView(withId(R.id.username)).perform(typeText("test_user"))
onView(withId(R.id.result)).check(matches(withText("Welcome, test_user")))

// 良い例
private const val TEST_USERNAME = "test_user"

@Test
fun testLogin() {
    val welcomeMessage = context.getString(R.string.welcome_message, TEST_USERNAME)
    onView(withId(R.id.username)).perform(typeText(TEST_USERNAME))
    onView(withId(R.id.result)).check(matches(withText(welcomeMessage)))
}

テストにおけるモックとスタブの活用

UIテストを「UI」のテストに集中させる:
Espressoテストの目的は、UIの振る舞い（クリックしたらダイアログが表示される、データを受け取ったらリストが更新されるなど）を検証することです。ネットワーク通信やデータベースのロジックそのものをテストする必要はありません。これらの外部依存要素は、テストを遅くし、不安定にする最大の要因です。

依存性の注入(Dependency Injection)とモックライブラリの活用:
HiltやDaggerのようなDIフレームワークを使い、テスト時には本番用のRepositoryやAPIクライアントを、モック（偽のオブジェクト）に差し替えられるようにアプリケーションを設計しましょう。MockitoやMockKといったライブラリを使えば、「APIを叩いたら、常にこの成功レスポンスを返す」「データベースに問い合わせたら、この固定のデータを返す」といった振る舞いを簡単に定義できます。

これにより、テストは以下のようなメリットを得られます。

• 高速化: 実際のネットワーク通信やディスクI/Oがなくなるため、テストが劇的に速くなります。
• 安定化: ネットワークの不調やバックエンドの障害に影響されず、テストが常に同じ結果を返します。
• 網羅性: サーバーエラーや空のデータリストなど、通常では再現が難しいエッジケースも簡単にシミュレートできます。

UIテストを、外部要因から切り離された「密閉された（Hermeticな）」環境で実行することが、信頼性の高いテストスイートを構築する鍵となります。

まとめ：継続的な品質向上のために

Android Espressoは、単なるUIテストツールではありません。それは、アプリケーションの品質に対する開発チームの姿勢を形作るための強力なフレームワークです。この記事を通じて、基本的な使い方から高度なアーキテクチャ、そして信頼性を高めるためのベストプラクティスまでを網羅的に解説しました。

重要なのは、テストを一度書いて終わりにするのではなく、アプリケーションの進化と共にテストも継続的にメンテナンスし、改善していくことです。CI/CDパイプラインに組み込み、テスト結果を日常的にレビューし、不安定なテストを積極的に修正していく文化を育むことが、真の品質向上に繋がります。

Espressoを正しく活用することで、バグを早期に発見し、自信を持ってリファクタリングを行い、そして何よりも、ユーザーに安定した素晴らしい体験を提供し続けることができるのです。今日からあなたのプロジェクトにEspressoを取り入れ、品質向上の旅を始めましょう。