8

Cucumberユーザー仕様を統合テストに結び付ける方法が気に入っています。そのCucumber部分は多かれ少なかれ私には明らかです。
rspec (非統合テスト) で何をテストし、何をすべきでないかということになると、私は苦労します。すでにテスト済みのもので
単体テストを行うのは正しいですか(たとえば、Cucumber テストが失敗すると単体テストは 100% 失敗し、Cucumber テストが成功すると単体テストは 100% 成功します)?rspecCucumber

具体的には、解決したい例が 3 つあります。

  1. これは RSpec book のケースです。次のものがありますCucumber scenario。

    Given I am not yet playing
When I start a new game
Then I should see "Welcome to Codebreaker!"
And I should see "Enter guess:"

    rspec-tests次の直後に2 つビルドします。

    describe "#start" do
     it "sends a welcome message" do

     end
     it "prompts for the first guess" do

     end
end

  2. 別の例として、ルーティングまたはアクション リダイレクトのテストがありますが、次のシナリオがあります。

    Given I am at the login page
When I fill in the right username and password
Then I should be at the index page

  3. すでにテスト済みのヘルパーをテストすることがありますCucumber:

    Given Mike has spent 283 minutes online
When I go to the Mike's profile page
Then I should see "4:43" for "Time online:"

    おそらく、283 分を「4:43」に分割するヘルパーをテストする必要がありますが、既に でテストされていることがわかりましたCucumber。

これは最良の例ではないかもしれませんが、私が話していることを示しています。
私にとって、これらのテストは重複しています。

上記の例についてコメントしていただけますか？

rspecすでにある場合、何をテストする必要があるかについての原則またはガイドラインはありますCucumber testsか?

4

1 に答える 1

10

これはすべて、この広く開かれたトピックに関する私の個人的な意見にすぎません。一部の人々は、同意できず、十分に面白いかもしれません。

一般的なガイドラインとして、ユーザー エクスペリエンスと呼ばれるアプリケーション スタック全体をテストするには、 Cucumberを使用する必要があります。このアプリケーション スタックは、多くの小さな独立したオブジェクトで構成されている可能性がありますが、アプリケーションを使用するユーザーがそれらの詳細に関心がないのと同じように、キュウリテストはそれらを気にせず、代わりにアプリケーションの外層に焦点を当てる必要があります。

一方、 RSpec (セットアップ内! ) は、アプリケーションの構成要素である小さなオブジェクトに主な焦点を当てる必要があります。

本の小さなアプリケーションの例には大きな問題があります:それらは小さすぎます!

アプリケーションの外層とその内部の間の境界がぼやけます。アプリケーション全体が 2 つのオブジェクトでビルドされます! 何をテストすべきかを区別するのは困難です。アプリケーションのサイズが大きくなるにつれて、ユーザー エクスペリエンス テスト(cucumber) とは何か、オブジェクトとは何か (状態テスト/メッセージ期待値テスト(RSpec)) がより明確になります。

2番目の例を使用：

このキュウリの話で:

Given I am at the login page
When I fill in the right username and password
Then I should be at the index page

Rspec:

おそらく、ある種の User モデルがあるでしょう:

  • ユーザー名の構文をテストします (たとえば、大文字で始める必要があります)
  • テスト パスワードは 7 文字で、数字などを含む必要があります...

ある種の認証オブジェクトを持つことができます:

  • 有効および無効なログインなどのテスト
  • スローされる例外をテストします ....

認証データベースが別のサーバーにある場合はどうなりますか?

そしてやだやだやだ...きゅうりのテストは、アプリケーションのユーザーログインの一般的な目的を永遠に守ります。内部で動作を追加または変更した場合でも、このテストに合格する限り、ユーザーがログインできることを確信できます。

  • 一度（一箇所で）テストする必要があります
  • 受信メッセージ (オブジェクト パブリック インターフェイス) の状態 (戻り値) をテストする責任があるオブジェクト
  • オブジェクトが他のオブジェクトに依存している（メッセージを送信する）場合、オブジェクトがそれを担当している状態（戻り値）についてテストしないでください。
  • オブジェクトが他のオブジェクトに依存する（メッセージを送信する）場合、その2番目のオブジェクトをモックし、メッセージを受信するかどうかをテストします。

一般的に、あなたの質問は広すぎて、単一の答えを見つけることができず、人によって考えが異なります。あなたが集中すべきことは、できる限りテストすることであり、時間の経過とともに、あなたにとって正しい方法が間違いなく見つかります. 優れたテスト スーツがない場合よりもはるかに優れているわけではありません。

優れた設計は優れたテストを作成するのに役立つため、Sandi Metz 著の Practical Object-Oriented Design in Ruby: An Agile Primerをお勧めします(これは私が読んだ中で最高の本の 1 つです)。

于 2013-03-31T01:52:56.213 に答える