Agile Conference 4日め、9:00-10:30 に行われた Jeff Morgan さんのセッション “Acceptance Tests: Writing with the Future in Mind” に参加しました。
■スピーカーについて
Jeff Morgan さん
Website:CheezyWorld
愛称は Cheezy。技術プラクティスから PO までを守備範囲とする、アジャイル・XP・リーンのスペシャリストです。
2012年7月に『Cucumber & Cheese』という書籍を出版しています。「Cucumber」とは、今回のテーマである「A-TDD」(後述) を実現するツールの名称です。
- 参考:Cucumber
■参加目的
みなさん「A-TDD」ってご存知ですか?
“Acceptance Test Driven Development” の略称で、ユーザレベルの受け入れテストを、テストコードを作成して自動化しようという手法・考え方です。「BDD (Behavior Driven Development)」・「Executable requirement」・「Specification by example」とも呼ばれます。
欧米では、だいぶポピュラーになっているそうですが、日本ではまだなじみの薄い言葉です。
私は昨年関わったプロジェクトで、当時は「A-TDD」という言葉を知らずに、たまたま A-TDD を実現できるツールを自作しました。
この A-TDD を実現するための整理されたアイデアと専用ツールの使い方を教えてもらえるとのことだったので、自身のやってきたことの振り返りも含めて、是非お話を伺いたいと参加しました。
■セッションの概要
- 現在のテストの問題点
- A-TDD を実現する価値
- A-TDD を実現する際に気をつけるとよい点
- A-TDD の具体的な実施方法・デモ
(実際にCucumber を使い、Ruby で構築したサイトで A-TDD を実演)
■現在のテストの問題点
現在のテストでは、開発者とテスターとの間に「サイロ」( silo:縦割りによる分断) があり、これが情報伝達やコミュニケーションを阻害し、テストがうまくいかないという問題が多く見受けられます。
例えば、現状テストでバグが見つかった場合、開発者とテスターは、以下のような多くのやりとりをしなければなりません。
ご覧のとおり、非常に無駄なやりとりが多いことに気付きます。
上記の問題点に加え、現在のテストのやり方には、以下のような欠点があります。
- unhappy customers:コストが高い上に、顧客のニーズに合わないシステムが生まれてしまう。
- demoralize team:チームメンバーが心身共に疲弊して、相互不信に陥ったりしてしまう。
- pressure:納期やコストのプレッシャーがますます増大してしまう。
こうした問題点・欠点を克服するためには、テスター・品質管理担当者が仕様 (spec) という観点を乗り越えて、開発者やユーザとコラボレートしながらテストをしていく必要があるとのことです。
そのためには、時間短縮と再テストの容易化を実現できる「テストの自動化」が役立ちます。特に、ユーザ視点でのストーリーをほぼそのまま自動実行できる「A-TDD」が有用だそうです。
■A-TDD を実現する価値
Jeff さんは A-TDD を実現する価値として、以下の5つのポイントを挙げました。
いずれも、これまでサイロで区切られていた関係者同士をつないで、コミュニケーション・コラボレーションを図るものであることが興味深いです。
①Collaboration is the goal
開発者とテスター、そしてユーザも含めて協力し合えるようにすることが、A-TDD の目的です。
②Automation is necessary
短期間で繰り返し実行できるよう、自動化することが必須です。
③Quality is a team support
テストの品質は、チームメンバー同士およびチーム同士のサポートによって確保します。
④Getting the words right was the hardest part
テスト仕様書などによる用語の厳密化では、品質向上にはつながりませんでした。従って、関係者同士のコミュニケーションを密にする方向で品質向上を図ることが A-TDD の狙いです。
⑤Talk with Business Language Champion
業務知識・ドメインのスペシャリストの視点でテストを自動化し、彼らとのコミュニケーションをしやすくするのが A-TDD です。
ちなみに Jeff さんは「Done is Evil」ともおっしゃっていました。「俺達の担当分は終わった。後は君たちの責務だ」のような態度は、チーム間・関係者間のコラボレーションを壊すので避けるべしとのことでした。
■A-TDD を実現する際に気をつけるとよい点
一番重要・必要なことは、意志決定をユーザ (PO)・開発者・テスターで一緒に協力して行うことです。
そして、上述の価値でも触れましたが、これを A-TDD を介して実現します。具体的には、ユーザ視点で記述したテストシナリオを、テストスクリプトとしてそのまま実行可能にします。
Jeff さんは、具体的なプラクティスや Tips として、次の3点を挙げました。
①テスト作成にあたってのプラクティス (engineering practices)
シンプルで当たり前のことですが、改めて明示されるといろいろと考えさせられます。
- production code をテストすること
- コードを clean にすること
- DRY (Don’t Repeat Yourself:重複は避ける)
②テスト用データの作成方針
「most data doesn’t matter」
テスト実行・検証にあたって、必要最小限のものを用意できればよいとのことです。全てを完璧に検証しようとして、完全なデータを用意することに苦労する必要はありません。
③誰がテストを自動化すべきか?
次の2つのパターンがあるそうです。
■A-TDD の具体的な実施方法・デモ
A-TDD の具体的な実施方法として、実際に Cucumber と Ruby を使い、Web アプリケーションの構築・A-TDD・リファクタリングのサイクルを回し、10分程度でアプリケーションを構築するというデモがありました。
途中でコードの間違いなどがあると、参加者がその場で「セミコロンが足りてないよ〜」などと指摘、みんなでわいわいペアプロ (ペア?) をしているような感じでした。
Cucumber での A-TDD の作成方法は、テストシナリオの記述をそのまま、test code にして動かせば OKでした。
そのため、
- 理解しやすい (easy to understand)
- 会話しやすい (easy to communicate)
というメリットが享受できるものでした。
ちなみに Jeff さんのデモの流れは、以下のとおりでした。
- 単純なシナリオを書き、実行する。
- 各ケース共通の初期化設定を、1つのスクリプトにまとめて共通化する。
- テストデータも共通化する。
- 共通の検証コードも、1つのスクリプトにまとめて共通化する。
- 期待値もある程度同じならば、定数化して共通化する。
※Replace Magic Number with Symbolic Constraint (by Martin Fowler)
このあたりは、通常のプロダクションコードのリファクタリングと同じかなと感じました。
特に Jeff さんがおっしゃっていたことは、
- テストデータを多く準備し過ぎず、
- 必要なことを検証できるだけの必要最小限のコードに絞り、
- テストを堅牢にする
ということでした。この話は、書籍『xUnit Test Patterns』が参考になると思います。
■所感
昨年、私は担当システム専用の A-TDD ツールを自作して、システムの品質とテストコストを劇的に改善することができました。しかし一方で、ツールの作成自体に2か月ほどかかり、苦労しました。
こうした A-TDD を簡単に作成できるツールが既にあること、テストシナリオ自体をほぼそのまま自動テストコードとして使えること、そしてそれをデモで見れたことは、私にとっては非常に衝撃的でした。
また、A-TDD ツールを自作したときに私も痛感しましたが、テストに際してのユーザや業務知識・ドメインのスペシャリストとのコミュニケーション・コラボレーションは本当に重要です。こうしたサイロを超えたコラボレーションの必要性を強調していたことは、改めて考えてみる必要があると思いました。
「Individuals and interactions over processes and tools」ですね。
■参考資料
①Cucumber 使用方法
Cucumber の使い方については、角谷さんが InfoQ に翻訳記事を投稿しています。
②Cucumber 動画
(Jeff Morgan さん作ではありませんが) Cucumber の利用方法の動画が youtube にアップされています。
- 『名古屋Ruby会議01 / B2 Agile Web Development with Rails and Cucumber 1/3』
- 『(class 1 of 6) Efficient Rails Test-Driven Development – by Wolfram Arnold』
■おまけ
初日の「ICE BREAKER RECEPTION」でのロデオゲームの写真を改めて確認してみたら、Jeff Morgan さんが写っていました(笑)。
右端で、黒地に緑色のドロイド君のTシャツを着ている人です。