それらに関する私の限られた経験では、実行可能な要件（つまり、すべての要件を壊れた自動テストとして指定すること）は、驚くほど成功することが証明されています。私は、特定のユースケース/ユーザーストーリーのすべての機能を実行する高レベルの自動テストの作成に重点を置いた1つのプロジェクトに取り組んできました。この練習を始めてから、開発がどれほど簡単になったのか、本当に驚きました。テストを作成した後、機能の実装が非常に簡単になり、システムに大きなアーキテクチャの変更を加えることができました。世界に自信を持って、すべてが昨日と同じように機能しました。
私たちが遭遇した最大の問題は、これらのタイプのテストを管理するためのツールがあまり良くないということでした。Fitnesseをかなり使用した結果、Fitフレームワークが嫌いになりました。
1）他の誰かがこのタイプのテスト駆動要件定義を使用して開発した経験があるかどうか、および2）これを容易にするためにすべてのツールを使用したかどうかを知りたいです。
私も使用した主なツールは FitNesse でした。私はいくつかの会社でそれを使用しましたが、非常に良い結果が得られました。何千ものテスト ケースがあったため、それらをどのように整理して使用するかについて、非常に厳格に管理する必要がありました。
独自の DSL (ドメイン固有言語) を作成したり、RSpec などを使用したりするなど、他のツールをいくつか試しました。私は RSpec が本当に好きですが、ビジネスツールというよりも開発者ツールであることは確かです。
Rick Mugridge が ZiBreve (http://www.zibreve.com/visit.php?page=index ) には、より強力なリファクタリングのサポートがあるはずです。私自身は使ったことはありませんが、Rick のことはよく知っていて、何度か話したことがあります。アジャイル 2008 で、Fitnesse テスト全般に対処するいくつかの異なる方法について議論があったことは知っています。
それ以外には、良いツールはあまり見たことがありません。WinRunner のようなツールでさえ、QA タイプのテストには問題ありませんが、ビジネスによる要件の探索的テストには、FitNesse またはカスタム DSL が現在の方法のようです。
Robot Framework ( http://robotframework.org ) を参照してください。FIT に似ていますが、さまざまなテスト ツール、バージョン管理、および継続的統合に簡単に統合できることを願っています。テスト データの抽象化レベルが異なると、データの保守も容易になります。別のテスト データ エディターが成熟すると、保守がさらに容易になります。クイック スタート ガイドは、フレームワークの最も重要な機能を紹介し、実行可能なデモとしても機能します。
私は自分の仕事のためにfitnesseとその競合他社の1つであるGreenPepperの両方を使用、テスト、およびセットアップする必要がありました。私が言えることは次のとおりです。
GreenPepper はコンフルエンス プラグイン (コンフルエンスはアトラシアンのエンタープライズ wiki) であり、「エンタープライズ」レベルのツールで必要なものの多くを備えており、追加の作業はほとんどまたはまったく必要ありません。
GreenPepper の大きな欠点は次のとおりです。構成は非常に難しく、ドキュメントは不十分です(ただし、彼らはそれに取り組んでいるようで、フォーラムで非常に迅速に回答します) 。かなり多くなる可能性があります。
私の意見では、Fitnesse は非常に基本的で、セットアップが非常に簡単で、動作しますが、それだけです。オープン ソース コミュニティによって開発されたいくつかの Fitnesse プラグインや、Eclipse プラグイン (スケルトンをビルドする) などの Fit プラグインを使用することもできます。 .fit 拡張子があれば、fitnesse テスト ファイルからフィクスチャを取得できます。非常に便利です)。統合は理想的ではなく、認証とアクセス権の管理は貧弱ですが、無料であり、オープンソースであるため、何かが必要な場合はそれを行うことができます.
私の経験は個人的なプロジェクトに限定されており、あなたが言及したのとほとんど同じ利点が見つかりました。テストベースの開発を試すためのインスピレーションとなったhttp://metacpan.org/pod/Test::Simple::Tutorialをお勧めします。perlテストモジュールは非常に便利で柔軟性があるように見えますが、比較するものは何もありません。
また、プロジェクトのメンテナンス期間にはテストが不可欠だと思います。そもそも良いテストがあれば、後で多くの時間と間違いを節約できます。現在のプロジェクトでもっと多くの作業をテストに入れていたらよかったのに。
契約を使用することは素晴らしいアプローチであることがわかりました。メタプログラミングコントラクトは、一般に、説明する統合テストのタイプよりも低レベルですが、この2つは確かに相互に排他的ではありません。コントラクトは、ドキュメント、実装、テストのすべての同期を維持するのに役立ちます。これはTDDの主要な問題です（非TDDでは問題ではありません）。
私はFitnesseを試してみましたが、本当にひどいものです（特にSVNとの統合）。また、当社はフィットエンジンを備えた同様のオープンソースツールを開発しています：FitPro
私が使用したもう 1 つの優れたツールはConcordionです。唯一の欠点があります-html形式の要件