10年目を迎えたBDDツールCucumber - 作者のAslak Hellesøy氏に聞く

Cucumberは、プロジェクトチームの非技術メンバと技術メンバの両方を対象に、不明確な要件や誤解を克服する手段として開発された。しかし、もしもCucumberがテストツールだと考えているのならば、それは誤りだ — 2008年にCucumberを開発したAslak Hellesøy氏は数年前、このように述べていた。InfoQとのインタビューで氏は、振る舞い駆動開発(BDD)とCucumberを使用した自身の経験と、10年目を迎えた同ツールの今後について説明してくれた。

InfoQ: 現在のCucumberと振る舞い駆動開発(BDD)との関係性について、簡単に説明して頂けますか？

Aslak Hellesøy: Cucumberは、TDD(テスト駆動開発)の一種であるBDDをサポートするツールです。BDDでは、テストは*すべて*ユーザによる受け入れテストです。技術者でないステークホルダでも理解可能なように、平易な(人の)言語で記述されます。Cucumberでは、要求仕様と自動テストと“生きたドキュメント”を、Gherkinという、平易な英語と簡易な構造を持ったひとつのフォーマットにまとめています。

BDDから得られるメリットとしては、作業のやり直しが少ないこと、バグが少ないこと、コードのメンテナンス性がよいこと、などが挙げられます。これらのメリットを享受するためには、要件を検討し、テスト可能なソフトウェアを設計するために、ある程度の努力を払わなくてはなりません。要件の検討に関してのメリットはすぐに感じられると思いますが、テスト可能なソフトウェア設計によるメリットは長期的に得られる種類のものです。BDDはミスの早期発見を支援することで、ソフトウェア開発をより楽しく、持続可能なものにしてくれます。

InfoQ: 10年前にCucumberを開発した理由は何でしたか？

Hellesøy: Cucumberを開発するまでの10年間、私はソフトウェアコンサルタントとして働いていたのですが、キャリアの最初の5年間(1998～2003年)に参加したプロジェクトでは、いつも同じ問題を抱えていました。

• 要件を完全に理解しているのかどうか分からないことが多い
• 開発中のものが正しいという確信を得ることが難しい
• 何が壊れるのか分からないため、既存のコードを変更することに不安がある
• 遅れが定常化している

Cucumberを開発する5年前(2003年)、現在BDDと呼ばれている新しいアイデアに多くの貢献をした、3つのコミュニティに同時に関わるようになりました。それからの5年間は、それまでのキャリアでは経験したことのなかった、真に生産的なチームに取り組むことができたのです。達成感と確信を持って、楽しく仕事をしました。

最初のコミュニティは、TDDの発祥ともなったXPコミュニティでした。Ward Cunningham氏のFITと、Robert C. Martin氏のFitNesse(いずれも受入テストフレームワーク)からは、大きなインスピレーションを受けました。

2つめのコミュニティは、私が当時所属していたThoughtWorksです。 Dan North、Chris Matts、Liz Keogh、Joe Walnes、Paul Hammant、Chris Stevensonといった人たちが、ビジネス要件とプログラミングの間のギャップを埋めるべく、より言語に重点を置いた、さまざまなTDDの亜種を探求していました。

第3のコミュニティはRubyコミュニティで、David Chelimsky、Steven Baker、Dave Astelsの３氏が開発したRSpecが、最初のBDDツールとして大きな役割を果たしました。

Dan NorthとDavid Chelimksyが、RSPecのGiven-When-Then構文の初期バージョンのサポートを実装しました。私は実行可能な仕様というアイデアが気に入って、もっと追求してみたいと思ったのですが、RSpec自体の設計がもっと低いレベルにフォーカスしていたため、設計判断面での制約を感じていました。

そこで、RSpecのGiven-When-Thenパーザを独立したライブラリとして取り出し、よりユーザフレンドリにする作業に着手しました。エラーメッセージの改善、スニペットの表示、出力のカラー化、文法の拡張、高速化などを行いました。

妻がCucumberという名前にしたらどうか(特別な理由はないのですが)と言うので、それを名称にしました。同時にGiven-When-Then構文に名前を付けて、ツールとは別物にすることも決めました。Gherkin(小さなキュウリの漬物)という名前にしたのは、そういった理由からです。

InfoQ: この10年間のコミュニティでのCucumberの採用傾向や利用状況については、どのように思われますか？

Hellesøy: 期待以上でした！採用数は10年間で着実に増えていますし、ユーザ数も18ヶ月毎に倍増しています。成長の減速する兆しはまだ見えません。2017年だけを見ても、Cucumberは2,000万回(Java、.NET、Ruby、JavaScript、PHP、Pythonの実装を合計した数)ダウンロードされているのです。

最初の成長の波は2008～2011年頃、Ruby on Railsと共に訪れました。

第2の波は、Matt Wynneと私が“The Cucumber Book”を発表した2011年に始まりました。この本は20,000部近くを売り上げて、CucumberとBDDに新たな信奉者をもたらしました。要件に関する誤解を低減する手段になり得ると、プロダクトオーナとビジネスアナリストが理解し始めたのです。Gojko Adzic氏の著作である“Bridging the Communication Gap”と“Specification by Example”も、この考え方を広める一助となりました。

私たちの本はCucumberを、自動テストの方法として理解したテストコミュニティにまで拡げました。皮肉なことにこれが、BDDとCucumberがテストの手段であり、テスト専用のツールであるという誤解につながったのです。Dan North氏がBDDを発案した時、氏が目標としたのは、TDDをより使いやすくすることであり、TDDがソフトウェアのテストではなく、設計や開発のためのテクニックであることを開発者に理解してもらうことでした。

ですが、手にしている唯一のものがハンマーであれば、何でも釘に見えてしまうものです。

Cucumberは現在、多くの組織で標準的なツールセットの一部になっています。BDDに使用している組織もありますが、大部分は、それが何を意味するにせよ、単なる“BDDテスト”用に使用しているのが現状です。事実はその名のとおり、振る舞い駆動“開発”なのです。

InfoQ: 開発から10年間で、Cucumberはどのように発展したのでしょう？

Hellesøy: 2008年に最初のRubyバージョンがリリースされてからの数年間で、さまざまな言語の実装が公開されました。

• Gaspar Nagy氏が.NET用のSpecFlowを開発
• Julien Biezemans氏がCucumber.jsをJavaScriptとNode.js用に開発
• Konstantin Kudryashov氏がPHP版のBehatを開発
• 私がJavaを含むJVM言語用にCucumber-JVMを開発

現在では、主要な言語(と、知名度が多少低い言語)のすべてにCucumberの実装が用意されています。これら実装のほとんどは、オリジナルのRubyによる実装と非常に近いのですが、メンテナンスしている個々のチームが比較的独立した活動をしているため、多少のばらつきがあります。イノベーションを促進する上では、これがよい方向に働いています。アイデアをお互いにコピーするという点で、素晴らしい共生関係であると言えるでしょう。この数年で追加された最も重要な機能としては、次のものが挙げられます。

• Cucumber Expressions ― 正規表現のユーザフレンドリな代用
• Tag式 ― Gherkinタグ用のブール検索言語で、実行するシナリオを容易に選択できる
• Suite (当面はBehatのみ) ― 異なる構成で同じシナリオを(UI経由で、またはUIより下で)簡単に実行することが可能
• IDEA、IntelliJおよびVisual StudioでのIDE統合

実装間の相違はイノベーションを促す一方で、いくつか問題もあります。それぞれの実装やドキュメント管理の作業に、重複した部分がたくさんあるのです。これに対処するために、近々、公式のCucumber実装に関するすべてのドキュメントを一ヶ所に集めた、新たなWebサイトをリリースする予定です。これによって、各コントリビュータの実装が収束し、より一貫性を持てるようになると思っています。10年後には、初期段階のような分岐やイノベーションは必要ありません ― 今はそれよりも、一貫性と持続可能なメンテナンスのペースが必要なのです。

Cucumber.jsチームのCharlie Rudolph氏が先頃、Goの実験的な共有バイナリを作成しました。このバイナリが今後、すべてのCucumber実装の基盤として使用されるかも知れません。これによって、すべての実装を簡素化できる可能性があります。つまり、よりよい製品をユーザに提供できるのです。

最後に、長年にわたるBDDの実践の進化との一貫性を持たせるために、Gherkin言語自体にいくつか手を加える計画があります。下位互換性は必ず確保します ― 何百万ものEメールを受け取りたくはありませんから！

InfoQ: CucumberとBDDの関係について説明してください。

Hellesøy: 私自身(とCucumber/BDD仲間たち)のBDDに対するアプローチは、この10年間でかなり変わりました。これがCucumberに影響しています。時にはCucumberの変更が、人々のプラクティスを変えることもあります。CucumberとBDDは密接に関連しているのです。例をいくつかご紹介しましょう。

何年か前、BehatプロジェクトのKonstantinが私に、“Modelling by Example”という新しいBDDテクニックを教えてくれました。アイデアとしては単純で、意図する振る舞いを記述したいくつかのシナリオから始める、というものです。宣言的な(技術的な詳細を含まない)シナリオが命令的な(UIの詳細を記載した)シナリオよりも優れていることは、しばらく前から分かっていましたが、彼が教えてくれるまで、これが開発のための新たな出発点として選択できるものだとは考えていませんでした。

以前はいつもUIから始めていました。Konstantinが私に、UIやプロトコル層(HTTPなど)の下にあるドメインロジックの開発を進める場合にも、シナリオが使えることを教えてくれたのです。これによって、Cucumberと開発中のシステムを同じプロセスで実行することが可能になります。これらのテストは非常に高速で、通常はミリ秒単位なので、生産性の向上にも大きく影響します。安定したドメインモデルに向けて、イテレーションを迅速に進めることができるのです。

UI(やHTTPなどのプロトコル層)の開発に着手するには、ここが一番よいタイミングです。シナリオは実装の詳細に縛られないので、同じシナリオ(オートメーションコードの異なる)を使用して、UIやプロトコル層の開発を進めることができます。

Cucumberでそれぞれのシナリオを2回 — 1回目はUIより下で(信頼性よりも速度を優先)、2回目はUIを通じて(速度より信頼性を重視) — 実行することができれば、作業はずっと簡単になります。そのためにKonstantinは、Behatに“Suites”という特殊な機能を追加しました。他のCucumberの実装にも追加したい機能のひとつです。これはまさに、BDDの実践方法の変化がツールに影響した一例です。

Example Mappingも、最近のBDDプラクティスがCucumberに影響したと思われる例のひとつです。Example Mappingは私の同僚であるMatt Wynneが考え出した、ユーザストーリをシナリオに転化可能な例に分解するための、シンプルかつコラボレーティブな分析テクニックです。今となっては、最初にExample MappingをせずにCucumberのシナリオを書くことが考えられない程です。私たちのチーム(と、私たちが指導した何百というチーム)の要件分析とテスト設計のアプローチを根本的に変えました。

Example Mappingでは、ルールの下で例をグループ分けします。ですが、Gherkinにはルールのための構造がないので、Example MapをGherkinに“翻訳”しようとすると、多少のインピーダンスミスマッチが発生します。そのために、“Rule”というキーワードと“Scenario”の同義語としての“Example”を、Gherkinに追加する予定です。

InfoQ: あなたはBDDとCucumberの専門家ですが、この10年間で、ツールを使った仕事の仕方は変わりましたか？

Hellesøy: もちろんです。私がいつも気にしていることのひとつはテストのスピードですが、これには過去数年間で大きな進歩がありました。

Jakob Nielsen、Mihaly Csikszentmihalyi両氏の研究によると、フィードバックに10秒以上待たされた場合、大部分の人は実行中のタスクに集中し続けられなくなるということです。UXデザイナはこれを知っているので、処理時間を要する場合にはプログレスバーやスピナが表示されるのですが、プログラマやプログラマ向けツールを開発している人たちは、まだこれを意識していないようです。

テストのフィードバックが1～5秒で入手可能なプログラマと、30秒以上待たなくてはならないプログラマとでは、生産性に大きな差があります。1～5秒であれば、生産性の極めて高い状態に到達して、それを何時間も保つことが可能になります。何度も中断されるような状況では、こうは行きません。私たちはそのようなフィードバックの遅さになれているので、それを修正するのではなく、回避する手段を見つけ出して採用しています。テストピラミッドはそうした回避策のひとつです。一派的な通念として、UIを経由したフルスタックテストは遅くて脆弱です。従って私たちは、遅くて信頼性の低いテストは少なくし、より高速で一貫性のあるものを採用するようにしています。

この問題に対処するもっともよい方法は、遅いテストを速く、不安定なテストを安定化することです。信頼性とスピードを両立させてはいけないのでしょうか？

Nat Pryce氏とJosh Chisholm氏は、I/Oを排除し、すべてをプロセス内で実行することによって、フルスタックテストを1秒以内に実行する方法を独自に検討しました。それまではドメインレベルのテストでのみ知られていた方法です。例えば、DOM UI(Reactなど)を使ったNode.jsアプリを書いているならば、Cucumber-Electronを使ってクライアントとサーバを同じNode.jsプロセスで実行して、I/Oをまったく発生させなくすることが可能です。これにより、1秒あたり数十～数百のフルスタックテストが実行可能になります。この速度ならば、アイスクリームコーンのテストを気にする必要もありません。

脆弱性を軽減し、保守性を向上させるような新しい手法も普及しています。Antony Marcano、Andy Palmer、John Ferguson Smart、Jan Molakらが開発したScreenplayなどのパターンがその例です。

InfoQ: CucumberやBDD以外のツールも、同じ目標を達成するために使用されているのでしょうか？

Hellesøy: 目標が何であるかによって異なります。事実を言えば — Cucumber利用者の大部分は、BDDのために使用しているのではありません。テストに使用して、自身のテストをその後に書いているのです。それがワークフローならば、Cucumberは他のテストツールに比べて特段に優れている訳ではありません。ユーザやドメインの専門家、あるいはプロダクトオーナがGherkinのドキュメントを読まないのならば、一般的なxUnitツール(JUnit、RSpec、NUnit、Mochaなど)を使った方がよいでしょう。

私はいつも両方を使っています — 技術者でないステークホルダのフィードバックが必要ならばCucumber、技術的でビジネス要件に直接関連しないのであればxUnitです。

Cucumberは仮定の検証やあいまいさの発見、開発対象に関する共通理解の構築に適しています。同じような目標を持ったツールはCucumber以外にもいくつかありますが、従来のテストツールほど多くの選択肢はありません。どれが最も人気があるのかは分かりませんが、Concordion、Robot framwework、JBehave、Fitnesseなどは考え方としてCucumberに最も近いと思います。

InfoQ: CucumberとBDDは今後どうなるのでしょう？

Hellesøy: Cucumberは多くの実装を持つ一大エコシステムに成長しました。ユーザ数(数十万から数百万)数に対して常連のコントリビュータ(10人程度)が少ないので、作業上の負荷を軽減するか、あるいはチームを拡大していく必要があります。バイナリ共有も負荷軽減の一助となるかも知れませんが、語るにはまだ時期尚早です。

分散実行と並列実行に対しては、要望をたくさん受け取っています。回避策やサードパーティのツールはありますが、Cucumber自体にはない機能なので、追加したいと思っています。レポートも改善したいですね。

プラクティスとしてのBDDについて、私たちがコミュニティとしてできる最も重要なことは、ユーザにBDDを啓蒙することだと思っています。書籍はいくつかありますが、もう少し取付きやすい、適当なサイズの教育素材があればと思います。最近では、Example Mappingに関する教育に力を入れています — 必ずしもCucumberを使わなくても、チームにとって数多くのメリットがあるからです。

また、特にマイクロサービスやサーバレスアーキテクチャのような分散アーキテクチャでは、高速テストのためのパターンやテクニックを文書化する必要もあります。ポートやアダプタ、契約によるテスト(contract testing)といったパターンは主流とは言えませんが、これらの状況においてBDDが直面する多くの問題に対処できるのではないかと思います。

InfoQ: あなた方はCucumberによって自らの企業を立ち上げることができました。そのような観点から、今後について、どのように見ていますか？

Hellesøy: Cucumber Ltdを2014年に設立して以来、トレーニングを主要な収入源としてきました。その間に、CucumberのコラボレーションツールであるCucumber Proを開発しました。Cucumber Proは、Gherkinドキュメントとその実行結果を公開し、それらのドキュメントによるコラボレーションを可能にするツールです。ユーザが求めているものが別のものだと分かった時に、最初に開発したものを放棄して、新たな開発に着手しました。

私たちは当初から、外部の投資に頼らず、創業時から利益を上げられるブートストラップ企業を目指していました。現在は10名の社員と、世界中でトレーニングを提供するための10名のアソシエイトがいます。

当社にはオフィスがないので、毎日テレビ会議を行なっています。Cucumber Proの開発者はリモートでモブプログラミングを行っています。他は顧客を訪問して、トレーニングを提供しています。2ヶ月に1回ミーティングをして、戦略と社交の場としています。

外部の投資家によって業務の優先順位を決められることがないので、自分たちの望む企業を構築することができる反面、何十人もの開発者を雇用して商品開発を可能な限り早くすることもできません。大変ですが、楽しいですよ！