24

Rails Webアプリの統合テストには、Steak（Cucumberなど）を使用します。Steakのスペックは、spec/acceptanceという名前のフォルダーにあります。ステーキ/キュウリは現在、統合または受け入れテストのために使用されていますか？これは違うといつも思っていました。

4

1 に答える 1

76

まず、用語に関する注意： TDDコミュニティでは、統合テストという用語は少しあいまいです。JavaまたはRails（Test :: Unitを使用）のどちらから来たかによって、理解できることは異なります。Rails（Test :: Unitを使用）では、統合テストはフルスタックをテストするテストですが、機能テストはコントローラーをテストするテストです。Javaコミュニティのほとんどの人は（少なくとも私の観察では）それは逆だと思うでしょう。私は個人的に、エンドツーエンドのテストを受け入れテストと呼ぶことを好みますが、システムのいくつかの層（すべてではない）にヒットするテスト-統合テスト。全体として、それはあなたがいる文化にかなり依存しています。

CucumberとSteakに関しては、どちらもビヘイビア駆動開発（または略してBDD）として知られる開発スタイルを可能にするフレームワークです。重要なのは、2つのレベルのテストがあるということです。

  • エンドツーエンドのテスト。フルスタックでテストします。ブラウザをシミュレートし、コントローラーを調べてデータベースにアクセスします。きゅうりとステーキはこのニッチに合います。
  • 単体テスト。機能の一部を分離してテストします（通常は単一のクラスで、共同作業者をモックします）。これがRSpecが適している場所です。

BDDでは、失敗したエンドツーエンドテスト（愛情を込めて「アッパーギア」として知られています）から始め、次に機能テストの実装を開始します-最初にRSpec（「ロワーギア」）を使用して、最後まで-テストに合格しました。このように、エンドツーエンドのテストが単体テストを推進し、それが実装を推進します。主な利点は、スコープクリープを回避することです。つまり、必要のないユーザーに表示される機能を実装する必要がありません（エンドツーエンドのテストを作成しないため）。

これについてさらに情報が必要な場合は、 Behavior DrivenDevelopmentWikipediaの記事が驚くほど優れていると聞きました。また、RSpecブック。

つまり、CucumberとSteakはどちらも、「アッパーギア」でテストを作成できるフレームワークです。違いはスタイルにあります-キュウリはあなたに自然言語であなたのテストを書かせます。これにはいくつかの利点があります。

  • テストはビジネスマンが読むことができます。プログラマー以外の人がテストを書くことは期待できませんが、テストはあなたがやろうとしていることを伝えるのに素晴らしい仕事をします。機能を記述し（最初にキュウリテスト）、それを顧客に見せて、これが実際に必要なものであるかどうかについてのフィードバックを得ることができます。これはとても便利だと思いました。
  • きゅうりの機能は意図をよりよく伝えます-英語のフルパワー（または実際にはどれでも）を使用できるので、この機能が関連する理由と、ユーザーがRubyでは許可されないレベルで目標を達成する方法を伝えることができますあなたに。
  • Cucumberは、ユビキタス言語の発見に役立ちます。ドメインには、顧客との会話で飛び交う多くの用語が含まれています。Cucumberを使用すると、機能の実装を開始する前に、それらを検出してキャプチャできます。そして、それはすべてテスト駆動です。
  • キュウリの機能はやや高レベルであるため、機能（ステップ定義ではない）はインターフェイスからより独立しています。このように、インターフェースを変更する必要がある場合、機能を作り直す必要はありません。

欠点は、それをうまく適用する方法を学ぶのが少し難しいことと、もう少し（機能とステップ定義の両方）書く必要があることです。次の機能をより速く書くことを可能にする一連の再利用可能なステップが得られるので、しばらくそれをしていれば、2番目は実際には問題ではないことがわかりました。

一方、ステーキはもっとシンプルで、Rubyです。あなたは英語を使うことのすべての利点を失います、しかしあなたはより少なく書くことができて、そしてそれはより速く（いくらか）実行されます。

結論としては、両方を使用して、開発を推進するエンドツーエンドのテストを作成します。

于 2010-10-27T10:24:45.477 に答える