RSpecとCucumberは本当に価値がありますか？

私はほとんどのRoRプログラマーがテスト中毒者であり、大規模なテストスイートの利点を理解していますが、テストを開始したとき、そのような大規模なスイートを取得することはなく、「正しい方法でテストしていますか？本当に効率的ですか？」多くの場合、アプリケーションの動作のみをテストする統合テストを扱っています。

まず、テストする価値は本当にありますか？つまり、テストの作成に費やした時間は本当に価値があるのでしょうか？

次に、RSpecを使用し、最近Cucumberを発見し、しばらく使用しましたが、これらすべての手順を書くことが本当に面倒な価値があるかどうかわかりませんか？私はステップを再利用できることは知っていますが、これらのステップが完了しすぎているかどうかはわかりません：たとえば、aを使用していますが、作成した場合にユーザーを複製する可能性があるためGiven I am logged in as (.+)、その定義で言う必要があるかどうかはわかりませんGiven there's a user called $1しかし、それは常に一歩前にある価値はありませんGiven I am logged in as (.+)。非常に多くのコードであり、おそらくほとんど役に立たないでしょう。毎日テストされた部品に新しいバグはないのではないかと思います...それで、CucumberはRSpecと比較して本当に価値がありますか？

私の「あはは！」RubyとRailsでのテストについての瞬間は、私が実際に座って主題に関する決定的なリソースであるRspecとCucumberの本を読んだときでした。キュウリに対する最初の軽sharedを分かち合いましたが、その時、私は写真をかなり間違った角度から見ていることに気付きました。

基本的に、CucumberはBDD（ビヘイビアドリブン開発）に関するものです。Cucumberを使用して機能、次の作業を計画します。うーん、次に、ユーザーがフォーラムまたは何かに投稿を宣伝できるようにしたい（例を盗むために;））それで、あなたは簡単な何かを書きます。

Given I am logged in
And I can see the post "BDD is awesome"
When I vote the post up
Then the post should have one more vote
And the page should show a message thanking me for my vote.

そこに関連するコードへの参照はほとんどないことに注意してください。それはあなたのステップにあります。コードをリファクタリングする場合、ステップ定義を変更する必要があるかもしれませんが、動作（機能）を変更する必要はありません。

これで、Cucumberの機能を実行するたびに、TDD（テスト駆動開発）を使用して機能をテストする方法がほとんど案内されます。これは、RSpecを使用して下位レベルで行われます。

最初の実行-最初のステップ定義は未定義です。ブロックをコピーして、たとえばuser_steps.rbまたはsession_steps.rbで定義します。これは、ユーザーとそのセッションに関連しているためです。次に、ユーザーがログインしていることをどのように定義しますか？ログインプロセスを介してそれらを取ることができます。

Given /^I am logged in$/ do
  visit login_path
  fill_in :name, :with => 'Joe'
  fill_in :password, :with => 'Password'
  click_button 'submit'
end

すべての幸せになるはずです。第二段階。

Given /^I can see the post "(.+)"$/ do |name|
  visit post_path(Post.find_by_name(name))
end

繰り返しますが、とても簡単です。ログインプロセスを完全にやり直す場合、または投稿の定義と表示方法を完全にやり直す場合は、動作を変更する必要はありません。第三のステップ。

When /^I vote the post up$/ do
  pending 
end 

ここから新しい機能について説明し始めますが、どのように機能するかはまだよくわかりません。どうやって投稿に投票しますか？+1または何かの画像をクリックすると、コントローラーへのajaxポストが行われたり、JSONなどが返されたりします。これで、純粋なRspecテストに移行できます。

• ビューをテストして、+ 1画像が表示されることを確認します。
• 適切な形式の特定のajaxリクエストを受信したときにコントローラーが正しく動作することをテストします（幸福と不幸の両方のパス-無効な投稿IDが受信された場合はどうなりますか？投票数を正しく増やしますか？）
• 適切な形式のJSONのblobが与えられたときにJavaScriptが正しく応答することをテストします（使用されていることを示すために+1画像を更新しますか？（ここでGoogle+について考えます...）ありがとうメッセージを示しますか？ ）

これらはすべて動作に影響しませんが、下位レベルのテストの処理が終了したら、投稿の投票方法のステップ定義を記入するのは簡単です。それはのように簡単かもしれませんclick_link '+1'。そして、残りの手順はテスト結果であり、これも簡単に実行できるはずです。そして、完了したら、機能が完全で終了していることがわかります。必要な動作が変更された場合は、機能を微調整できます。それ以外の場合は、完全に安全に実装コードを微調整できます。

これが理にかなっていることを願っています。それはすべて私の頭の外にありましたが、BDDとTDDの違い、そしてCucumberとRSpecが異なるニーズに応える理由を示していると思います。

私の意見では、テストは芸術です。（RSpecまたは他のフレームワークを使用して）TDDを行うことは、最初は「時間を無駄にしている」ように感じます。量産コードを書いていないので、これは理解できます。

ただし、コードベースを強化しながら、他のすべてが引き続き機能することを保証する必要がある場合は、TDDの利点が見え始めます。 TDDを使用すると、回帰エラーをできるだけ早くキャッ​​チできます。これを行うと、私に保存された日、私は私の誤りを指摘集中テストを持っていたので、仕事のを。

さらに、レビュー担当者は、テストしているシナリオとコードの使用方法を確認できるため、テストを行うことはコードレビューに役立ちます。

TDDの波に乗ると、他のことをするのは間違っていると感じます。

私の意見は、あなたはキュウリの正面にいるということです。これらすべての手順を書くことは多くの面倒であり、その利点は痛みを正当化するものではありません。ここでCucumberを使用することの6つの欠点について広範囲に書きました。

RspecまたはTest :: Unitを使用して行われる単体テストと定期的な統合テストは非常に理にかなっていますが、幸いなことにこれらはCucumberテストよりもはるかに高速に記述できます。ガーキンの冗長で扱いにくい構文と戦う代わりに、純粋なRubyを使用できます。

私が個人的に信じているのはそれRSpec testing is a definite mustです。たとえば、新しい機能を作成し、他の機能への参照も持ち、その機能が他のモジュールまたはメソッドで参照される場合を考えてみましょう。それで、あなたが書いているものがアプリケーションの他の部分を壊していないことをどのように確認できますか？

大きなアプリケーションがあり、アプリケーション全体と比べて些細なコードをコーディングしていると仮定します。アプリケーションのすべてのリンクをクリックしてアプリケーション全体を再テストし、1行のコードを変更するたびに動作することを確認しますか？

しかし、キュウリのテストは必須ではないと思います。RSpec自体を使用した統合テストは、クライアントがテストをチェックする必要がある場合を除き、より理にかなっていると思います。私の経験ではこれはまれです。チームが完全に開発者で構成されている場合は、RSpec機能テストのCucumberステップを置き換える必要があると思います。そして、RSpec 3 DSLの後、テストはかなり読みやすいと思います。

例：

キュウリステップの定義：

Given /^I am logged in$/ do
  visit login_path
  fill_in :name, :with => 'Joe'
  fill_in :password, :with => 'Password'
  click_button 'submit'
end

RSpec機能テスト：

feature 'Given the user is logged in' do
      visit login_path
      fill_in :name, :with => 'Joe'
      fill_in :password, :with => 'Password'
      click_link_or_button 'submit'
end

RSpec機能は、Cucumber機能を使用するのではなく、別のステップ定義を記述するという余分な頭痛なしに同じことを行うと思います。

それ以外は、純粋にあなた自身の好みでもあります。

これが少し理解するのに役立つことを願っています。

私の意見では、最初に実践と具体的なフレームワークを区別することが重要です。キュウリはBDDではなく、RSpecはTDDではありません。

システムRSpecを優れたツールとしてテストする場合は、RSpecでTDDまたはBDDを実行できます。実際、TDDとBDDは同じものです。誰かが「TDDは正しく実行された」と言いますが、私はそれに完全に同意します。BDDは、主にメソッド/クラスのテストではなく、機能/動作のテストに関するものです。実際、Kent Beckが機能について説明しているTDDですが、BDDは多くの人々がこの重要な違いを理解し、Dan Northから開発コミュニティへの多大な貢献を理解するのに役立ちます。

キュウリがビジネスマンやプロダクトオーナーがシナリオの作成や修正にチームを助けることを許可している場合など、ビジネスマンとコミュニケーションをとるためのより良いツールが必要だと感じたら、キュウリを使用してください。このシナリオはシステムの非常に優れたライブドキュメントであるため、他の人はキュウリが好きです。このタイプのドキュメントが必要だと感じたら、キュウリを試してください。

要約すれば：

• TDD / BDDを自分で行う場合、またはチームで行う場合-> RSpecを試してください
• ユーザー履歴とシナリオを使用してビジネスと通信するためのより良い方法が必要な場合は、キュウリを試してください
• システム機能のライブドキュメントが必要な場合は、キュウリを試してください。

もちろん最後の2つには高いコストが伴います。本当にそれが必要で、努力する価値があるかどうかを評価する必要があります。このオフコースはプロジェクトと環境、そしてあなた次第です。

しかし、RSpecとCucumberは単なるツールであり、ツールは具体的な問題を解決すること、どのような問題を解決したいかを常に覚えておいてください。この質問を自問してください。XまたはYフレームワーク/ツール/ライブラリ/テクノロジーを使用することではなく、この決定を行うことについて、より良いプログラマーになります。