Calabash-AndroidによるBDDの実践とJenkinsによる「Living documentation」：スマホ向け無料システムテスト自動化ツール（6）（3/4 ページ）

本連載では、AndroidおよびiOSアプリ開発における、システムテストを自動化するツールを紹介していきます。今回は、Calabash-AndroidによるBDD実践のポイント、表形式の活用による仕様の発見、「Living documentation」で「見せる化」を実現する方法などについて解説します。

[伊藤宏幸，テスト自動化研究会（STAR）,楽天株式会社]

「ステップ定義」の記述レベルを読者に応じて変える

　前回説明した、Calabash-Androidに事前に用意されている「ステップ定義」ですが、よくよく見てみると、（何番目の「ImageButton」を押すなど）技術的かつAndroidのUI操作に特化しているものが多いです。

　これらを多用し過ぎると、テストシナリオ内の記述内容がUI依存になりやすく、結果としてビジネスステークホルダーらにとって読みづらい／可読性の低いテストシナリオが出来上がってしまう恐れがあります。

　多くのステークホルダーを巻き込み、お互い共通のコミュニケーションツールとしてテストシナリオを活用したいならば、読みやすく理解しやすい「ステップ定義」を、必要に応じて独自に定義する必要があります。一方で、UXデザイナーなどが多く、UI操作を明示した方がプラスの場合は、事前に用意されているものを活用した方がいいかもしれません。

　この辺りは各チームの特性、コンテキストによって変わってきますので、自分のプロダクトにあったやり方を選択してください。

　ちなみに「｛プロジェクトのルート｝/features/step_definitions/PreviewCustomer_steps.rb」では、多くの人に読んでもらいやすくするため、以下のように一部の「ステップ定義」を工夫しています。

When go preview

　通常だと「When I tap button_preview menu」のような記述が妥当なのですが、以下の理由から「go preview」としています。

• UIコンポーネントの種類（「Menu」か「ImageButton」かなど）を意識したくない／してほしくない
• UIコンポーネントの操作方法（「tap」か「swipe」かなど）を意識したくない／してほしくない
• そもそも目的が「CustomerPreviewActivity画面へ移動すること」である

When wait for preview screen

　もともとは「Then I wait for the "([^\"]*)" screen to appear」なのですが、以下の観点から、「to appear」などの余計な単語をカットしています。

• CustomerPreviewActivity画面の表示待ちをすることが目的
• CustomerPreviewActivity画面が見られればいい

「Living documentation」で「見せる化」を実現する

　こと進捗（しんちょく）管理において、ビジネスステークホルダーやマネジャーといったロールの人たちは、個々のストーリーやバグの対応状況がどうなっているのかよりも、「そのフィーチャーがリリース可能なのか」（Feature readiness）により強い関心を持つものです。

　従って、プロダクト開発を行う際は、「Feature readiness」を簡潔に伝えられるリポーティングツールがあることが好ましいです（参考：『BDD in Action』の11.2 “Are we there yet? Reporting on feature readiness and feature coverage”より）。

「Living documentation」とは

　「Living documentation」とは、BDDテストの作成状況や実行結果をリポーティングツールでいつでも見られるようにすることで、その時点での進捗や開発状況、および「Feature readiness」を、開発者／ビジネスステークホルダー／マネジャーらプロダクト開発に関わる全員にリアルタイムに伝えるための仕組みのことです。

「Living documentation」実現のポイント

　まずは、CI（継続的インテグレーション）／CD（継続的デリバリ）の要領で自動的、定期的にテストを実行して、常に最新の情報を見られるようにしましょう。

　また、テスト量が多過ぎて時間がかかる場合などは、タグを活用しましょう（後述）。

テスト結果のリポート

　Calabash-Androidのラップ元であるCucumberでは、テスト結果リポートの作成機能も提供しています。

　次の例は、「calabash-result-reports」ディレクトリ以下に、「TEST-features-AddCustomer.xml」のように、JUnit形式のテストリポート用xmlファイルを作成します。

$ calabash-android run ｛YOUR_APK_FILE｝ -f junit -o calabash-result-reports

　Jenkinsを使用する場合、「ビルド後の処理」→「JUnitテスト結果の集計」に、上記で作成したxmlファイルを指定すると、下記のようにテストリポートを出力できます。

Jenkinsでのテスト結果リポートの例

Jenkinsでのテスト結果リポート詳細

　ちなみに指定できるフォーマットは、「cucumber -h」で確認できます。

-f, --format FORMAT              How to format features (Default: pretty). Available formats:
                                      debug       : For developing formatters - prints the calls made to the listeners.
                                      html        : Generates a nice looking HTML report.
                                      json        : Prints the feature as JSON
                                      json_pretty : Prints the feature as prettified JSON
                                      junit       : Generates a report similar to Ant+JUnit.
                                      pretty      : Prints the feature as is - in colours.
                                      progress    : Prints one character per scenario.
                                      rerun       : Prints failing files with line numbers.
                                      stepdefs    : Prints All step definitions with their locations. Same as
                                                    the usage formatter, except that steps are not printed.
                                      usage       : Prints where step definitions are used.
                                                    The slowest step definitions (with duration) are
                                                    listed first. If --dry-run is used the duration
                                                    is not shown, and step definitions are sorted by
                                                    filename instead.

　特にJSONは、JenkinsのCucumber関連プラグインと組み合わせて使用することで、非常に詳細かつ多くのステークホルダーに価値のある情報を提供できるフォーマットです。