Cucumber が先日 .NET をサポートしたことについて，InfoQ は作者である Aslak Hellesøy 氏にインタビューを行った。Cucumber はビヘイビア駆動開発 (Behavior Driven Development，BDD) のための受入テスト (acceptance testing) ツールである。Agile 2009 の時，InfoQ の Mark Levison が 機能テストツールワークショップ のレポートとして，Matt Wynne，Richard Lawrence 両氏による Cucumber の .NETソリューション開発開始について伝えたことがある。これが後に Cuke4Nuke という名称になった。
InfoQ: Cucumber について簡単に説明してください。
Aslak: Cucumber はビヘイビア駆動開発(BDD)用にデザインされた受入テストツールで，最小限の技術知識でシステムの要求定義を記述できるようにするものです。システムに希望するビヘイビア(ふるまい)の具体的な例を，テキスト形式で記述することによって要求定義を行います。ビヘイビアは普通のことばで，例えば "Then there should be $5000 on Bob's savings account" のように表現します。
このテキストを，最初はソースコードが存在しない段階で要求仕様として記述します。コードの作成後は同じテキストを，今度は回帰／受入テストの自動実行に使用します。これを実行可能な要求(executable requirement)と呼ぶこともあります。
BDD ツールには２つの形式があります - ひとつは "ユニットテスト"風のツール (NSpec，RSpec など) で，もうひとつは Cucumber のような，より上流レベルの受入テストを行うツールです。いろいろな立場の人たちに受入テストや要件定義に関わってもらって，それを (病みつきになるくらい) 楽しい経験にしてもらおう，というのが Cucumber の最大の目標です。
InfoQ: Fti/Fitbesse など他のツールと Cucumber には，どのような違いがあるのでしょうか。
Aslak: Cucumber と FIT の共通点の話から始めましょう。それは，どちらもコマンドラインツールである，ということです (Fitnesse は基本的に FTT 上の wiki なので)。
テスト用言語
FIT/Fitnesse と Cucumber はどちらも，高水準言語で記述された受入テストを実行します。FIT が処理できるのは HTML だけです。ただし Fitnesse では Wiki 文法でのテスト記述が可能なので，この点は簡単になります。また FIT/Fitnesse では，すべてのテストをテーブル形式で定義する必要があります。これに対して Cucumber では，ユーザは通常のテキストとして，ほぼ自由形式の英語でテストを記述することができます。さらにフランス語(Ou Francais)，ノルウェー語(Eller norsk)，ロシア語(или Русский)など約４０カ国語をサポートします。 Cucumber は実際には，キーワード "Scenario"， "Given"， "When"， "Then" で始まる行を認識しているのです。 *ふるまい* を記述する上では，このような自然言語の方がテーブルよりも便利です。テーブルはもともと *データ* を扱うためのものですから。
もちろん Cucumber でも，テキスト形式の中でテーブルを自由に使うことができます。ですからビヘイビア志向とデータ志向のテストを混在して記述することも可能です。意外なことですが，Fitnesse もシナリオ(Scenario)，前提(Given)，時期(When)，結果(Then) をテーブルで記述できるようになりました。Fitnesse にもこの２つの方向へ進む兆候があるのは明らかです。おもしろい競争になりそうですね。
次の例は Cucumber の .feature ファイルを，テーブルを交えたテキストで記述したものです。
# language: en Feature: Addition In order to avoid silly mistakes As a math idiot I want to be told the sum of two numbers Scenario Outline: Add two numbers Given I have entered <input_1> into the calculator And I have entered <input_2> into the calculator When I press <button> Then the result should be <output> on the screen Examples: | input_1 | input_2 | button | output | | 20 | 30 | add | 50 | | 2 | 5 | add | 7 | | 0 | 40 | add | 40 |プログラム言語
Fit と Cucumber はどちらも，高水準言語とテスト対象コードの間に "グルー(glue)" コードを必要とします。これを FIT では fixture，Cucumber では step definition と呼んでいます。 Cucumber の step definition は C#，Java，Scala，Clojure，JavaScrtipt，Ioke，Ruby などの言語で記述することができますので，この面では FIT よりも柔軟性があると言っていいでしょう。次の例は，先ほどの calculator に数値を入力する step defintion を C# で記述したものです。
[Given(@"^I have entered (\d+) into the calculator$")] public void EnterNumber(double n) { _calculator.Push(n); }エディタ
FitNesse が Wiki をサポートしていることは，現時点で Cucumber に対して大きなアドバンテージでしょう。技術を専門としないユーザが受入テストを記述するための Web ベースのエディタが，Cucumber には(今のところ)ありません。Lowdown と呼ばれるツールはあるのですが，テーブルが使えない点がちょっと力不足です。また JetBrain の RubyMine にはしっかりしたエディタがありますが，これはプログラマ向けです。
InfoQ: 私の知る限りでは，Cucumber を .NET 上で使用する方法が現時点で２つあると思います。２つの方法とそれぞれの利点／欠点について，簡単に説明していただけますか。
Aslak: そのとおり，２つの方法があります。Cucumber 自体が Ruby で記述されているため，実行には Ruby インタプリタが必要になります。.NETでの最初の方法は IronRuby 上での実行です。この方法を選択した場合，現状では (.NET コードと接続する) step definition を Ruby コード で記述しなければなりません。ただし先の例のような C# が使用できるように，これを変更する計画があります。
もうひとつの方法選択は Cuke4Nuke というものを利用することです。これは Ruby コードのことをすべて忘れて，step definition を C# コードで記述できるようにするツールです。このツールは，実は MRI (Matz Ruby Interpreter，C で記述された Ruby オリジナルのインタープリタ) を使用しています。これが C# で記述されたローカルのソケットサーバにコマンドを送信して，そこで step defintion を実行します。これらすべてが透過的に行われるので，ユーザは .feature ファイル，.cs ファイル，cuke4nuke コマンドラインツールだけを操作すればよいのです。
第３のプロジェクトーSpecFlow についても説明しましょう。これは 100% .NET のプロジェクトで，Cucumber と一切のコードを共有せずに，Cucumber の動作を可能な限り再現しようとするものです。さらに Visual Studio へのインテグレーション機能も備えています。私は Cucumber との共同作業について SpecFlow チームと話をしています。その結果，同じ機能のファイルパーサを使用することになりそうです。これによって Cucumber のテスト言語 (Gherkin と呼ばれています) を，さらに各ツールで一貫したものにできるでしょう。
InfoQ: Cucumber に関して，今後優先して取り組んで行きたいことは何ですか。
Aslak:
短期的には:
- 処理速度，より高速なパーサの導入。この面では，Gherkin プロジェクトでの Ragel の使用によって大きな進展がありました。
- 新しい web サイト。現在の Wiki は重要なリソースではありますが，新規参加者や Ruby 以外の言語のプログラマ，プログラマでない人たちが容易にアクセスできるようにするためには，情報の再構築が必要でしょう。
長期的には:
- 機能定義の編集と実行のための使いやすい共同作業環境。すでに RubyMine や LowDown といったものもありますが，私自身，別のアイデアをいくつか持っています。
- より多くの種類のフォーマットやメディアでテストを編集・保存可能にすること。例えばイントラネット上の wiki ページや Microsoft Word のドキュメントなどです。FIT の初期においては，Excel をサポートしていることが人気の理由になっていました。非技術サイドの支持を得るためには，私たちも彼らが好むツールをサポートする必要があります。あるいはもっといいツールを提供する，というのもよいでしょう。
InfoQ: InfoQ のために時間を頂き，ありがとうございました。