先週、Jeremy D. Miller氏はStoryTellerプロジェクトをプレビューリリースしたとアナウンスした。このプロジェクトは、「実行可能な仕様書」を実現しようとする.NETのオープンソースプロジェクトである。InfoQは、JeremyにStoryTellerがFit/FitNesseやCucumberなどのほかのツールとなにが違うのか、またこのプロジェクトを今後どうしていくのかなどについてたずねた。
InfoQ: StoryTellerについて詳しく教えてください。
Jeremy: StoryTellerは、.NETによる「実行可能な仕様書」を作成するためのツールキットです。あなたが開発者であるとして、ビジネスで対面している人が読むことができる書式とメカニズムで、曖昧さが完全になく、正しい振る舞いの条件が書かれた詳細な要求が作られ、さらに、チームの統合されたプロセスで継続的に使用できる自動化されたテストでも使うことができる。そんな世界を想像してみてください。StoryTellerは、.NETエコシステムにおいて、これを可能にします。
InfoQ:StoryTellerを書くためのモチベーションは何ですか？
Jeremy:私には少なくとも4人の雇い主と2、3の異なるプロジェクトを通じて、FitNesseを使った自動テストを作った経験があります。私は、FitNesseの人が読むことができる自動テストを書くというコンセプトを気に入っています。しかし、FitNesseによって、私のチームは恒久的に多くの摩擦が発生しました。私は、元々FitNesseDotNetライブラリのための異なるエディタとテスト管理基盤を構築するつもりでした。多少の進捗がありましたが、結局はそのアプローチを取りやめて、新しいテストエンジンをゼロから作ることにしました。そのため、これは.NETでの使用に最適化されています。考えていく中で、当初考えていたよりもよいツール体験を作成することができました。FitNesseがやっていることだけではなく、クリーナーテスト言語、開発者が自動テストコードを簡単に書くためのメカニズム、そしてソースコントロールとの継続的な統合を容易にして、FitNesseで可能なことが可能になりました。そして、ここにとどめるのをやめて、構築のために一度完全に破壊し、OSSサイドプロジェクトのように私をよりより開発者にしました。
InfoQ: StoryTellerと、Fit/FitNesseやCucumberとはどのように違うのですか？
Jeremy: これについては明確です。StoryTellerは、確実にFit/FitNesseよりも.NETエコシステムに適しており、FitNesseの経験から多くのインスピレーションを受けています。StoryTellerは、"Fixture"クラスの実装と"Grammars"が含まれます。英語に近いテスト仕様書を使うことができるという面では、FitNesseに非常に似ています。StoryTellerの最初に異なる点は、"計画編集(projection editing)"でHTMLを解析する代わりにHTMLで描画することです。ツールにはもうひとつの違いがあります。FitNesseはテストの編集にWikiのフォーマットが必要で、頻繁にソースの変更が必要です。StoryTellerのテストは、WPFのクライアントで書かれており、テストの作成プロセスを大いに加速します。
Cucumberは、StoryTellerと同じ問題を解決しようとするRubyツールですが、仕組みが異なります。あなたは、CucumberとIronRubyを.NETコードの実行可能な仕様書を書くのに使うことができます。これには、製品コードと同じ言語でテスト自動化コードを書くことができるという利点があります。あなたがテストコードにCucumberとRubyを使った場合、人間が読むことができるテストを作成することができます。しかし、StoryTellerを使った場合、開発者は技術者の受け入れテストにC#を使用することができます。
InfoQ: StoryTellerを開発者のみのツールだとお考えですか？
Jeremy: 現時点では、StoryTellerは、テストの作成という意味においては、開発者中心であるといえます。しかし、長期的な視点で見ると、StoryTellerは、テスターツールであり、ビジネスパートナーの要求に対して自動化された受け入れテストを迅速に行うツールであると考えています。私たちのテスターは、StoryTellerを手広く使用します。
InfoQ: StoryTellerは、CIツールと簡単に統合できるのでしょうか？
Jeremy: もちろん。そして、これはStoryTellerのアーキテクチャにおけるメインドライバのひとつでした。StoryTellerは、すべて"XCopyによる配置が可能"です。StoryTellerテストは、ファイルシステム上のXmlファイルに保存されており、テストがバイナリであると想定しません。CIビルドのために、StoryTellerは、コマンドラインの実行環境を提供しています。これにより、コマンドラインを呼び出すことができるあらゆるビルドツールから実行することができます。私たちはJetBrains Team City CIツールを使用して、カスケーディングビルド時に私たちのStoryTellerテストスイートの実行結果をTeam City Webサイト内に統合しています。
InfoQ: 私はあなたがDovetailでドッグフードを行ったと理解しました。アプリケーションを形成するのにどの程度役に立ちましたか？
Jeremy: 私は、StoryTellerのドッグフードの重要性を誇張して伝えることができませんでした。私は私たちの経験によりパフォーマンスのボトルネックを取り除きました。私は、最初のラウンドのテストからのネガティブなフィードバックにより、開発者のFixtureとGrammarsビルディングブロックのコーディング メカニズムを効率化するいくつかの方法を見つけました。早くから私たちはテスト文法を生成するために多くの繰り返しコードに注目してきました。そして私たちは、テスト自動化コードの複製を取り除く方法を見つけました。フィードバックを受けるためには、私たちのツールの使い方から改善し、StoryTellerのテストエラーと結果の表示をよりわかりやすくし、診断を容易にする必要がありました。最近、私はStoryTellerを強固にするため、開発者が書いたテスト自動化コードが正しく動かないときに、なにが起こっているのかを正しく理解することができるようにすることに時間を費やしています。つい先日、私たちのチームはテスターを雇いました。彼女の編集ツールの使い方とStoryTellerによって遭遇した摩擦により、機能に関する最後の波で、テストの編集を容易にする改良を行うことになりました。
InfoQ: 今後のStoryTellerにどんな期待ができますか？
Jeremy:直近ではそれほど多くのことを期待できないと思います。私は、早期導入者からいくつかのフィードバックがあることを望んでいます。StoryTellerは、とても開発者中心でテストを編集する前に最小のFixtureのスケルトンコードを必要とします。これは、私が意識している決定事項です。Devetailは、長い間「開発者のみ」のチームで、これは当然私のチームのために最適化されてきました。今後は、テスターとビジネスで対面するユーザーが開発者の仲介なしで、ツールを使って直接テストを作成できる手段を追加したいと考えています。これは、開発の前に実行可能な仕様書を書くことによって実現可能です。
InfoQ:ありがとう、Jermyさん。より詳しい情報とソースコードは、StoryTellerプロジェクトページをご覧ください。