20

堅実な仕様と見なされるものは何ですか?

これは、テストについて非常に抽象的であることがわかりました。モデル、コントローラー、その他テストできるものについて、これに対する答えに興味があります。仕様のための仕様があればクールだろう。

モデル仕様は (優先度と関連性の順で):

  1. すべてのメソッドをテストしますか?
  2. エラー配列をテストしますか?
  3. CRUD をテストしますか (およびその方法)?
  4. ほかに何か？

コントローラー/ビューの仕様は (優先度/関連性の順で):

  1. 空欄を埋める...
  2. ?

仕様に含めるべきものと含めるべきでないもののリストを拡張できれば素晴らしいことです。

また、トリックや提案のリストもまとめたいと思います。例えば：

キーワード「should」はやや冗長です。

例：

これ：

it "should be invalid without a firstname"

次のようにするとよいでしょう:

it "is invalid without a firstname"

さらに別のトリックとして、読みやすくするために lambda の代わりに expect を使用します。

lambda { ... }.should be_valid

次のように読みやすくなります。

expect { ... }.should be_valid

始めるにあたって役立つ記事のリストをまとめており、それらが登場したらこの投稿で共有します。現時点で特に役立つと思われるものをいくつか紹介します。（お気軽に投稿してください。役立つと思われる場合は追加します）。

http://everydayrails.com/2012/03/19/testing-series-rspec-models-factory-girl.html http://nelvindriz.tumblr.com/post/835494714/rspec-best-practices

テストが適切に実装されているプロジェクトのリストがあると便利です。rspec は非常に読みやすいので (少なくとも誰もがそう言っています)、優れた仕様を持つプロジェクトへのリンクのリストを取得するのは素晴らしいことです。

「良い仕様の例については、 Mongoidの仕様を参照してください。」-@yfeldblum (下記の回答を参照)

オンラインでは、基本的なものをテストする方法に関する非現実的なシナリオを説明している記事がたくさんありますが、それ以上は自分で行う必要があります。このトピックに関する記事を書く場合は、自分のテスト (たとえば github) にリンクし、それらの仕様の 1 つまたはいくつかに完全に注釈を付けます... これは、rspec に関する記事を書く最良の方法のようです。私の意見では。私はそれを自分でやりますが、私はまだそこにいません。

これを閉じることに投票した場合は、それで問題ありません。この投稿がどこに属していると思うかについて、コメントや提案を残してください. ありがとう！

4

4 に答える 4

10

私がテスト ケースを使い始めたとき、何が良いテスト ケースと見なされるのか確信が持てなかったので、これは実際には良い質問です。ここにあなたが従うことができるいくつかのことがあります。このリストは私のものではありません。ただし、いくつかのソースといくつかの追加からコンパイルされています。

メソッドの説明

メソッドを説明するときは、次のように実際にメソッドを説明することをお勧めします。など。はクラス メソッドのプレフィックス、"#" はインスタンス メソッドのプレフィックスです。

テスト ケースごとに 1 つのアサート

テスト ケースごとにアサーションが 1 つだけであることを確認してください。これにより、テスト ケースがクリーンで理解しやすくなります。これがテストケースのポイントですよね？:)

データをデータベースに保存しない

オブジェクトを動的に構築し、データを db に保存しないようにすることができます。各テストケースの前にデータベースをクリーンアップできますが、「保存しない」とテストケースが大幅に高速化されます。

@user.create(:something) の代わりに @user.build(:something)

エッジと無効なケース

これは Rspec に固有のものではありませんが、エッジ ケースがテストでカバーされていることを確認することが重要です。これは、後でプロジェクトが大きくなり、保守が容易になったときに非常に役立ちます。

コンテキスト化

私は個人的に、Rspec でこれをとても気に入っており、実際にはコンテキストを少し使いすぎています。条件付きのコンテキストを使用すると、テスト ケースを区分するのに役立ちます。次に例を示します。

# Avoid
it "should have 200 status code if user is logged in" do
  response.should respond_with 200
end
it "should have 401 status code if user is not logged in" do
  response.should respond_with 401
end

# Use
context "when user is logged in" do
  it { should respond_with 200 }
end
context "when user is logged out" do
  it { should respond_with 401 }
end

件名の使用

同じことに関連するテスト ケースが多数ある場合は、subject() を使用して、同じことを繰り返さないようにすることができます。

# Avoid
it { assigns(:user).should be_valid }
it { assigns(:user).should_not be_dumb }
it { assigns(:user).should be_awesome }

# Use
subject { assigns("user") }
it { should be_valid }
it { should_not be_dumb }
it { should be_awesome }

テストケースを書くときに私が従おうとしていることがいくつかあります。Rspecテストケースを改善できるものがもっとたくさんあると確信しています。しかし、素晴らしいテスト ケースを作成して開始するには、これで十分なはずです。

于 2012-08-09T09:37:31.787 に答える
5

優れた仕様の例については、 Mongoidの仕様を参照してください。

  • 例ごとにアサーションを 1 つだけ持ってください。同じ例で 2 つのことを主張しないでください。例としてit、 、its、またはに渡されるブロックがありspecifyます。
于 2012-08-08T00:01:44.130 に答える