こんにちは。BASE BANK 株式会社 Dev Division にて、 Software Developer をしている東口（@hgsgtk）です。
TL;DR
- July Tech Festa 2021 winter に「TDD から ATDD へ歩みをすすめる」というタイトルで登壇しました
- アジャイルテストとその中で有効なプラクティスとされる ATDD (Acceptance test-driven development）
- ATDD を実践するための E2E テスト基盤を gauge と CircleCI を用いて構築する
July Tech Festa 2021 winter
July Tech Festa はインフラエンジニアのための祭典と題したイベントです。昨年からオンラインでの開催となっており 500 名超えの参加者が集まった大規模イベントになっています。
ハッシュタグは #jtf2021w でして、ここから当日の盛り上がりを見ることができます。また、登壇者の発表資料一覧は conpass のイベント資料一覧にまとめられています。
私は、おもに CI/CD や DevOps といったテーマが多い C トラックにて 25 分時間をいただき発表しました。
発表資料
こちらが当日の発表資料になります。「TDD から ATDD へ歩みをすすめる」というタイトルです。アジャイルテストの実践や、シナリオテスト・E2E テストの整備に興味がある方にも参考になると思います。
この資料は、実際に BASE BANK の開発組織内で「イテレーションごとの（外部）品質を高める開発の方法は何か」というテーマについて考えて取り組み始めた内容をまとめました。
具体的には次のような内容をまとめています。
- アジャイルテストの考え方
- ATDD (Acceptance test–driven development) とはなにか
- ATDD を実践する開発文化とプロセス
- 受入テスト自動化フレームワーク gauge を用いたテスト作成環境
- エンドツーエンドテストの自動実行基盤
- CircleCI を用いた CI/CD パイプラインへの組み込み
- TDD から ATDD へ歩みをすすめた現場の実例
当イベントは「インフラエンジニアのための祭典」ですので、とくに参加者層にあわせてなるべく自動テストを実行する CI/CD 基盤について具体的に語っています。
以下、発表資料を用いて話した内容を少し省略しつつご紹介します。
アジャイルテスト
アジャイルテストという言葉はこの分野において著名な Lisa Crispin 氏と Janet Gregory 氏がこのように定義しています。
始まりからデリバリーまで、そしてそれ以降も継続的に実施される協調的なテストの実践 により、お客様への価値の頻繁な提供をサポートします。テスト活動は、高速なフィードバックループを用いて理解を検証しながら、プロダクトの品質を築くことに重点を置いています。このプラクティスは、品質に対するチーム全体の責任という考え方を強化し、サポートします。
このアジャイルプラクティスの中で役に立つプラクティスというものを紹介しており、その中のひとつが ATDD です。
ATDD
ATDD の開発ステップを簡易的にまとめるとこのようになります。
このステップの中で実装作業としてはまずは失敗する受け入れテストから始めます。
- 失敗するストーリー受け入れテストを最初に書く
- ストーリー受け入れテストを通す過程でユニットレベルのサイクルを回す
- n 回のチェックイン後、ストーリー受け入れテストを通す
いわば TDD Cycle よりもう一つ大きなフィードバックループをストーリー受け入れテストによって回す入れ子構造を作ることになります。
CircleCIとgaugeを用いたテスト実行基盤
この取組を実践するには、受け入れテストを自動化するというテスト実行基盤がセットになってついてきます。
当資料内ではCircleCIと gauge を用いた自動受け入れテスト基盤を紹介しています。
私が検討した際に感じたこととして、次のような特徴を持っています
- Markdown ベースのシンプルな仕様記述 Syntax
- ステップ実装のための言語は Java/JS/TS/Python/Ruby/C# をサポートしている
- Visual Studio Code との統合がよくできている
- メンテナンスが活発（Issue をあげたら数分後に返事が来た）
実際に gauge で作成したテストを CircleCI で実行するサンプルを作成したので実際に試してみたい方は参考にしてみてください（例では Python を用いています）。
gauge を用いた ATDD 開発ステップ
弊チームで実践し始めた gauge を用いた ATDD 開発ステップは次のようになります。
- スプリントプランニング等で、ユーザーストーリーの受入条件をチームで会話し特定する 「ストーリー受入条件」としてユーザーストーリーに記述
- 自動化可能なテストであれば、失敗する受け入れテストコードを記述（「仕掛中」マーキング）
- 機能実現に向けて実装する（n回のCycle）
- 機能完成後、「仕掛中」を外してテストが通ることを確認
「仕掛中」と「完成」を区別するというアイデアは、そもそも受け入れテストのフェーズが 2 つに区分されるため実施しています。
- 仕掛中
- 「まず最初に失敗する受け入れテストを書く」
- 進捗を測るテストであり失敗することがわかっている、ビルドフローには含めない
- 完成
- リグレッションを検出するテスト
- 完成したストーリーのテストは常に成功することが期待するためビルドに含める
具体的に gauge でこれらを区別するための活用アイデアは、発表資料内にツール仕様とともに解説しているので、実際に gauge を使ってみようと思った方はぜひご覧ください。
謝辞
2020 年に続き 2 年連続スピーカーとしてお邪魔させていただきました。
発表時間以外もとても楽しく参加させていただきました。基本的にずっと C トラックにいたのですが、直前で発表いただいた Masahiko Funaki さんが「縁の下をどう支えるか〜CI/CDの伝え方」にて CircleCI を用いた話をされていて、自分の発表内ととても関連していたので口頭で参照させていただいたりしていました。
14:20～14:45 / C4 -「TDDからATDDへ歩みを進める」 東口和暉 さん
— 舟木将彦/Masahiko FUNAKI (@mfunaki) January 24, 2021
CircleCIをご活用いただき、ありがとうございます！#CircleCIJp #JTF2021w #JTF2021w_C
たくさんのトラックが同時並行で走る中、運営いただいたスタッフの皆様ありがとうございました！特に、C トラックをご担当いただいた小松様が発表中に聴講者としてうなずく等オフラインのカンファレンスでは見られていた聴講者の反応を zoom 上でしていただいたおかげで、「今ちゃんとインターネットとつながってる」と安心しながら登壇できました。この場を借りて改めて御礼申し上げます。
おわりに
『実践テスト駆動開発 (Object Oriented SELECTION)』の「第 1 章テスト駆動開発のポイントとは？」では学習プロセスとしてのソフトウェア開発という捉え方を提示しています。
- 開発者は自分たちが使う技術はプロジェクト完成の過程で学ぶ
- 何を実現しようとしているかを理解をしていく
- 実地からのフィードバックを活用しシステムに活用していくこと
今回の発表で紹介した ATDD についてもフィードバックループをいかに回していくかというアイデアになります。当資料がアジャイルテストのマインドをベースとした開発戦略とそこから必要される基盤構築を試行錯誤する際の助けになれば幸いです。
後記
@CircleCIJapanさんに取り上げていただきました。CircleCIさんいつもありがとうございます。
今日のご紹介は @hgsgtk さんの #ATDD 実践とCircleCI・ #gauge でのE2E自動テスト基盤 です。昨日紹介させていただいた #JTF2021w にて中の人の後の登壇ということもあり聞かせていただいた話です。これぞリアルユースケースという深い内容です！多謝！#CircleCIJphttps://t.co/0KbPFDnf4D
— CircleCI Japan (@CircleCIJapan) January 26, 2021
