良い仕様とは何でしょうか？初心者のためのRspecの例

Question

固体仕様とは何でしょうか？

これは私がテストについて非常に抽象的であることがわかっているものです。私はモデル、コントローラー、そしてテストできる他のものについて、これに対する答えに興味があります。スペックのスペックを持っているのはクールですが、私の言うことを知っていますか？

モデル仕様べき（優先順位と関連性の順に）：

1. 試験すべての方法？
2. テストエラーアレイ？
3. CRUD（およびその方法）をテストしますか？
4. 他に何か？

コントローラ/ビュー仕様べき（優先/関連性の順に）：

1. はブランク...
2. に入力？

スペックの対象とするべきでないものをこのリストに展開することは素晴らしいことです。

私はまた、トリックと提案のリストもコンパイルしたいと思います。例：

キーワード「should」はまったく冗長です。

例：

この：

it "should be invalid without a firstname" 

と良いだろう。

it "is invalid without a firstname" 

さらに別のトリック、使用は読みやすくするために代わりにラムダの期待：

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 specsを参照してください。 - @ yfeldblum（下の回答を参照）

オンラインでは、基本的なものをテストする方法に関する非現実的なシナリオを説明する記事がたくさんありますが、それ以上にあなた自身がソートしています。私がこのトピックに関する記事を書く場合は、私のテスト（githubなど）にリンクして、それらの仕様の1つまたはいくつかに注釈を付けてください...これはrspecに関する記事を書く最善の方法のようですが、私の考えでは。私は自分でやっていますが、私はまだそこにはありません。

これを閉じるに投票した場合は、この投稿が所属すると思われる場所にコメントや提案を残すようにしてください。ありがとう！

Answer 1

良い仕様の例については、Mongoid specsを参照してください。

• 例ごとに1つのアサーションがあります。同じ例では2つのことを主張しないでください。例は、it、its、またはspecifyに渡されたブロックです。

Answer 2

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

が

方法を説明して、それが実際のようにあなたの方法を説明する良い方法です：「？#admin」を記述します等。 "クラスメソッドの接頭辞であり、 "＃"はインスタンスメソッドの接頭辞です。

テストケース

ごとに1つのアサートを使用すると、テストケースごとに1つのアサーションを持っていることを確認します。これにより、テストケースがきれいで分かりやすくなります。テストケースのポイントですが、そうではありませんか？あなたが動的にオブジェクトを作成し、DBにデータを保存することができないよう

をDBへデータを保存:)

は避けてください。各テストケースの前にdbをクリーンアップすることはできますが、「保存しない」とすると、テストケースが大きくスピードアップします。代わりに、@ user.createの：（何か）（：何か）

user.build @

エッジとこれはRSpecのに固有のものではない

無効の場合確かにエッジを作ることが重要ですケースはテストでカバーされます。これは、後でプロジェクトが成長し、維持管理が容易になったときに大いに役立ちます。

をcontexting

私は、個人的に、このように実際の使いすぎで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 

。

# 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のテストケースを改善することができる多くのことがあると確信しています。しかし、これは、素晴らしいテストケースを開始して書くのに十分なはずです。

Answer 3

私はRuby on Railsを学ぶチュートリアルに続き、テスト駆動開発の一環としてRspecを教えています。ここでの流れは、失敗したテストを書き、テストに合格するコードを書いてからテストに合格することです。その根拠は、失敗したテストから始めることで、これを行うことによって、あなたのコードがあなたが期待することをしているかどうかを確かめることができます。だから私は良い仕様は、あなたのコードは、それが想定されていることを確認するものだと思います。現在、他のポスターが書いたようにチュートリアルの中で私は大雑把なルールを集めていません。

はここのリンクです：http://ruby.railstutorial.org/

Answer 4

あなたがあなたのコントローラ内のテストのすべてのあなたの行動をカバーしたいあなたのコントローラーのテストを書いています。

例のように、コントローラのアクションのテストはどのように見えるべきか：あなたはcontroller tests hereについての詳細を調べることができます

describe "Stories" do 
    describe "GET stories#index" do 
    context "when the user is an admin" do 
     it "should list titles of all stories" 
    end 

    context "when the user is not an admin" do 
     it "should list titles of users own stories" do 
    end 
    end 

    describe "GET stories#show" do 
    it "should render stories#show template" do 
    end 
    end 

    describe "GET stories#new" do 
    it "should render stories#new template" do 
    end 
    end 

    describe "POST stories#create" do 
    context "with valid attributes" do 
     it "should save the new story in the database" 
     it "should redirect to the stories#index page" 
    end 

    context "with invalid attributes" do 
     it "should not save the new story in the database" 
     it "should render stories#new template" 
    end 
    end 

    describe "DELETE stories#delete" do 
    it "should delete the story from the database" 
    it "should redirect to the stories#index page" 
    end 
end 

。