एक अच्छा नमूना माना जाता है? शुरुआती के लिए रुपयेपीई उदाहरण

Question

ठोस नमूना माना जाता है?

यह मुझे परीक्षण के बारे में बहुत ही अमूर्त लगता है। मुझे मॉडल, नियंत्रकों और इसके परीक्षण के लिए और भी इसका जवाब देने में दिलचस्पी होगी। एक कल्पना के लिए एक नमूना होना अच्छा होगा, आप जानते हैं कि मेरा क्या मतलब है?

एक मॉडल कल्पना करना चाहिए (प्राथमिकता और प्रासंगिकता के क्रम में):

1. टेस्ट सभी तरीकों?
2. परीक्षण त्रुटियों सरणी?
3. टेस्ट सीआरयूडी (और कैसे)?
4. और क्या?

एक नियंत्रक/दृश्य कल्पना करना चाहिए (प्राथमिकता/प्रासंगिकता के क्रम में):

1. रिक्त स्थान भरें ...
2. ?

इस सूची को विस्तारित करने के लिए बहुत अच्छा होगा और इसमें क्या होना चाहिए।

मैं भी चाल और सुझावों की एक सूची संकलित करना चाहता हूं। उदाहरण के लिए:

कीवर्ड "चाहिए" सॉर्टा अनावश्यक है।

उदाहरण:

इस

:

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

यह परियोजनाओं जहां परीक्षण में अच्छी तरह से लागू किया जाता है की एक सूची है करने के लिए बहुत अच्छा होगा। चूंकि आरएसपीईसी इतना पठनीय है (कम से कम यही सब कुछ कहता है), उन परियोजनाओं के लिंक की सूची प्राप्त करना बहुत अच्छा होगा जिनके पास पढ़ने के लिए शानदार चश्मे हैं।

"अच्छे चश्मे के उदाहरण के लिए Mongoid specs देखें।" - @ yfeldblum (नीचे उत्तर देखें)

ऑनलाइन आपको मूलभूत सामग्री का परीक्षण करने के तरीके पर अवास्तविक परिदृश्यों का वर्णन करने वाले बहुत से लेख मिलेंगे, लेकिन इसके अलावा आप स्वयं ही क्रमबद्ध हैं।अगर मैं इस विषय पर एक लेख लिखना चाहता था तो मैं सिर्फ अपने परीक्षणों (उदाहरण के लिए जिथब पर) से लिंक करूंगा, फिर उन चश्मे में से एक या कुछ को अच्छी तरह से एनोटेट करें ... यह आरएसपीईसी पर एक लेख लिखने का सबसे अच्छा तरीका है, मेरी राय में। मैं इसे खुद कर दूंगा, लेकिन मैं अभी तक काफी नहीं हूं।

यदि आप इसे बंद करने के लिए वोट देते हैं, तो यह ठीक है, इस टिप्पणी पर कोई टिप्पणी या सुझाव छोड़ने का प्रयास करें जहां आपको लगता है कि यह पोस्ट संबंधित होगा। धन्यवाद!

Answer 1

अच्छी चश्मा के उदाहरण के लिए Mongoid specs देखें।

• प्रति उदाहरण बिल्कुल एक दावा है। एक ही उदाहरण में दो चीजें मत डालो। एक उदाहरण है कि ब्लॉक it, its, या specify पर पारित किया गया है।

Answer 2

यह वास्तव में एक अच्छा सवाल है क्योंकि जब मैंने परीक्षण के मामलों के साथ शुरुआत की, तो मुझे यकीन नहीं था कि एक अच्छा परीक्षण केस क्या माना जाता है। यहां कुछ चीजें हैं जिनका आप अनुसरण कर सकते हैं। यह सूची मेरा नहीं है; लेकिन कुछ स्रोतों और मेरे कुछ जोड़ों से संकलित।

का वर्णन तरीकों

जबकि विधियों का वर्णन है, यह एक अच्छा अभ्यास वास्तव में की तरह अपने विधि का वर्णन है: "#admin" का वर्णन आदि। "।" क्लास विधि के लिए एक उपसर्ग है और "#" उदाहरण विधियों के लिए एक उपसर्ग है। परीक्षण का मामला

प्रति

एक ज़ोर सुनिश्चित करें कि आप परीक्षण का मामला प्रति सिर्फ एक अभिकथन है कि सुनिश्चित करें। यह सुनिश्चित करता है कि आपके परीक्षण के मामले साफ और समझने में आसान हैं; जो परीक्षण मामलों का मुद्दा है, है ना? :)

बचें डेटा बचत db से

आप गतिशील रूप से करने के लिए वस्तुओं का निर्माण और डाटाबेस के लिए बचत डेटा बच सकते हैं। यद्यपि आप प्रत्येक टेस्ट केस से पहले डीबी को साफ कर सकते हैं, "बचत नहीं" परीक्षण मामलों को बड़े पैमाने पर तेज कर देगा।

@ user.build (: कुछ) के बजाय @ user.create की (: कुछ)

एज और अमान्य मामलों

यह Rspec के लिए विशिष्ट नहीं है लेकिन यह सुनिश्चित बढ़त बनाने के लिए महत्वपूर्ण है मामलों में परीक्षण शामिल हैं। इससे आपकी परियोजना बढ़ने पर बहुत मदद मिलती है और इसे बनाए रखना आसान हो जाता है।

तथ्य अति प्रयोग में Rspec में एक बहुत है और मैं contexting

मैं व्यक्तिगत रूप से इस तरह एक सा संदर्भों। शर्तों के साथ संदर्भों का उपयोग करने से आपके परीक्षण मामलों को विभाजित करने में मदद मिलती है।

# 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 } 

यहां कुछ ऐसी चीजें हैं जिन्हें मैं परीक्षण मामलों को लिखने के बाद पालन करने का प्रयास करता हूं। मुझे यकीन है कि बहुत अधिक चीजें हैं जो आरईपीसी परीक्षण मामलों में सुधार कर सकती हैं। लेकिन यह शुरू करने और भयानक परीक्षण मामलों को लिखने के लिए पर्याप्त होना चाहिए।

Answer 3

मैं रूबी पर रूबी सीखने के लिए एक ट्यूटोरियल का अनुसरण कर रहा हूं, और यह परीक्षण संचालित विकास के हिस्से के रूप में रुपेक पढ़ रहा है। यहां प्रवाह एक परीक्षण लिखना है जो विफल रहता है, परीक्षण पास करने के लिए कोड लिखें, और फिर परीक्षण पास करें। तर्क यह प्रतीत होता है कि ऐसा करने से - एक असफल परीक्षण से शुरू करके-आप बहुत अच्छी तरह से सुनिश्चित हो सकते हैं कि आपका कोड आपकी अपेक्षा करता है। तो मुझे लगता है कि एक अच्छा नमूना वह है जो सुनिश्चित करता है कि आपका कोड वह करता है जो इसे माना जाता है। अभी तक मैंने अन्य पोस्टर लिखे गए ट्यूटोरियल से अंगूठे के किसी भी नियम को नहीं मिला है, हालांकि।

यहाँ लिंक है: http://ruby.railstutorial.org/

Answer 4

आप अपने नियंत्रक परीक्षण आप परीक्षण सभी अपने नियंत्रक में अपने कार्यों के साथ कवर करना चाहते हैं लिख रहे हैं जब।

उदाहरण की तरह नियंत्रक कार्यों के लिए परीक्षण देखना चाहिए कि कैसे:

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 

आप controller tests here के बारे में और अधिक जानकारी प्राप्त कर सकते हैं।