往々にして、新しいソフトウェアは、既存の製品に残された空間を埋める必要がある誰かにより開発されるものである。使っているツールがわれわれのニーズに添わない場合、ソフトウェアは更なる発展を遂げる。Evan Light氏によって開発された振る舞い駆動開発(BDD) ツール Couldaはこれに当てはまるだろう。
アナウンスによると、Couldaは以下のように説明されている。
名前からも推測できるように、couldaのコンセプトはCucumberとshouldaから拝借したものです。 ただしおまけとしてthorを付け加えました。couldaは、Cucumberと同じ情報を扱うシンプルな内部DSLですが、Gherkinを含みません。Cucumberから極限まで機能を削減したので、コンシューマよりの開発者にはあまり役に立たないかもしれません。couldaは再利用のために単純なolメソッド呼び出しを使用されるため、thorを導入しました。
われわれはEvan氏よりCouldaについてより詳しく学ぶ機会を与えられた。Couldaはとても新しいソフトウェアであるため、Couldaの定義、位置づけをその開発者自身に確認するのが自然だと考えている。
Couldaは、Test::Unitを使用し、受け入れテストを定義するためのRubyの内部ドメイン固有言語(DSL)です。
BDDツールそれ自身は全く新しいというわけではない。事実Ruby開発者にとって、ソフトウェア仕様やストーリを記述するツールとしては、RSpecやCucumberなど既に親しまれているものが存在する。マーケット初期に発表されたツールは、時に新たな世代のツールの序章となる場合がある。Couldaを創造するにあたり何にインスパイアされたか、とわれわれが尋ねたら、Evan氏は以下のように説明した。
Couldaの実装に関して、私はREADMEの中でCucumber、Shoulda、そしてThorに言及しています。さらに、Jeremy McAnally氏のContext、Pending (Couldaは実際にPendingを使用している)、 StumpyそしてMatchyもインスピレーションの源であったといえるでしょう。Jeremy氏は意図的にいくつかの直行するテストライブラリを設計していて、 それらのライブラリは独立しても、Test::Unitと一緒でも動かすこともできるものでした。私はそのアプローチがとても気に入りました。特定の問題を解決するために、ターゲットを絞ってツールを開発する、というそのアプローチが。Lone Star Ruby ConferenceでのRich Kilmer氏の終わりの基調講演は内部DSLのパワーと表現力を思い出させてくれました。最後にAndrea Wright氏とのディナーチャットで、面倒なことへ泣き言を言うのをやめとにかく直す、という基本的なことを再認識しました;-)
しかし、Couldaを書こうと思った背景についてはもう少し語らせてください。
私はRSpecのプレーンテキストストーリとCucumberを使用していました。私はそれらのツールの背景にあるアイディアは好きです。つまり、テストの前提条件をひとつ("Given"), イベントをもうひとつ("When")、最後にに期待値をさらにもうひとつ("Then")のコードブロックで表現するというアイディアです。ただしCucumberでは常にプレーンテキストを正規表現にマッピングしなければならない点にはうんざりしていました。特にCucumberがこれらの正規表現を別のファイルに保存させることに関してです。
私は、どんどん複雑になっていく物理的（ファイル）論理的（この場合はテスト記述と例）単位に注力することになりました。 そこで私は物理的、あるいは論理的にどのように分割するのか、自分自身で決定したいという思うようになりました。CucumberではひとつのファイルにGherkin, その上最低あとひとつ、テストの"ステップ"を記述したファイル、という風に書かなければいけません。ただ、例えば特定のベストプラクティスが正しいかどうか尋ねられた場合、経験豊富なプログラマーならこう答えるでしょう。"場合による"と。テスト記述とテストステップがただのブロックであるがゆえに、Couldaでは、テスト記述とテストステップを分離させる場合を自身で決断したいと考えました。 Couldaでは私が適当だと思うときと場合にのみテストの構造を複雑にすることができます。
加えて、Gherkin (開発者とユーザがCucumberを制御するために記述する英語に似たDSL) は"正規表現を呼び出すこと"によりコードとマッピングを行います。しかし重要なことは、この英語のような言語が、実際はコードであると認識することです。しかも計算完備ではない言語で書かれているコードなのです。 このような言語があるのなら、受け入れテストを記述する場合に計算完備な言語へのアクセスを潜在ユーザ（ あるいは最低限私たち、開発者）に提供して何が悪いというのでしょう。 私は他の開発者を代弁しているわけではないですが、受け入れテストも書きますし、たまに受け入れテストの記述に関してステークホルダの相談に乗ることもあります。けれども、もしユーザに権限を委譲することが望ましいならば、われわれはユーザに、Rubyを教えることなく、外部DSLを教えるのと同じ容易さでシンプルな内部DSLの書き方を教えることができます。
Aslak Hellesoy氏によって開発されたCucumberはアプリケーションの振る舞いをプレーンテキストで記述することができる ツール (DSL)である。CouldaはCucumberの代用として開発されたのか、という問いに対して以下のように答えた。
Cucumberとは違う新たな選択肢にはなると思いますが、取って代わることはないでしょう。
一部既に的確に指摘されている通り、CouldaはRSpec Story Runnerに似ています。しかしCouldaのような、BDD 受け入れテスト(http://dannorth.net/introducing-bdd参考)を記述するための同様のツールで、特にTest::Unitに対応したものは今現在存在しません。 単体テストはShouldaでよく書いているので、私はCucumberの表現力をもち、ただし余計な抽象化はのぞかれ、さらにTest::Unit上で実行できるものを望みました。T::U が習慣化していましたので。
Couldaは、Cucumberに影響を受け、Cucumberの実装の簡潔な側面をさらにそぎ落とした若いプロジェクトであるが、これから先のプロジェクトのゴールが知りたいとわれわれは考えた。
正直に言ったほうがいいのでしょうか？ クライアントや組織と働く場合にCucumberを使えと指図される代わりにCouldaを使用するという選択肢をもてるようになることです。これが、私がCouldiaを書いた理由です!
技術的なことを言えば、私のゴールは控えめです。バグフィックスを除き、Couldaの記述を以下のようなプレーンテキストに整理したいと考えています。Feature "My feature" do
in_order_to "ゴールを達成する"
as_a "やつ"
i_want_to "何かする"Scenario "シリアライゼーションが動くかどうか示す"
Given "Couldaの機能" do
...
endWhen "オブジェクトモデルをプレーンテキストに整理するrakeタスクを実行する" do
...
endThen "Gherkinと同じように読めるプレーンテキストが出力される" do
出力は以下のようになるでしょう。
...
end
end
endFeature: My feature
In order to ゴールを達成する
As a やつ
I want to 何かするScenario: シリアライゼーションが動くかどうか示す
上記に加え、あとRailsのサポート(今のところ機能はTest::Unit::TestCasesのみ)と、 それ以外で追加したい機能などの目論見はありません。 Couldaのゴールのキーのひとつは、小さくシンプルであり続けるということです。
Given Coulda 機能
When オブジェクトモデルをプレーンテキストに整理するrakeタスクを実行する
Then Gherkinと同じように読めるプレーンテキストが出力される
例えば、今のところCucumberのFITのようなテーブルをエミュレートしようという計画はありません。 私の考えでは、それらは、選択した実装のファクトリが使用している"与えられた"ブロックで解決されるべきです。これは完全にCouldaと直行します。
どんなに新しいオープンソースプロジェクトも他人に助けてもらい貢献してもらうことができる。 貢献とドキュメント化の命題は、プロジェクトを助け形付ける機会があることを表している、とEvan氏は言う。
RDocは現時点ではほぼなにもありません。;-) 誰か手伝ってくれる人はいませんか?
小さなサンプルファイル がgithub のレポジトリ (自分自身へのメモ: gemに入れろ) の examples/sample.rbにあります。ただし、現状ではREADME.rdocに埋もれていますが。 これもCouldaで実行可能です。
ただし、冗談抜きに、APIはとてもシンプルです。"Feature", "Scenario", "Given", "When", "Then", "Feature#in_order_to", "Feature#as_a", and "Feature#i_want_to"で構成されています。大体そんなところです。このまま小さくいつづけようと思っています。
Couldaは進化中で、他の人も多いに貢献するだろう。 Couldaに関する詳しい情報は Github プロジェクトページまたはEvanのブログで確認することができる。