2011-11-04 7 views
15

में कक्षा विधियों का परीक्षण कैसे करें मैंने एक साधारण वर्ग विधि Buy.get_days(string) लिखा है, और इसे विभिन्न टेक्स्ट स्ट्रिंग इनपुट के साथ परीक्षण करने का प्रयास कर रहा है। हालांकि मुझे लगता है कि यह बहुत verbose है।आरएसपीईसी

  • क्या निम्नलिखित का परीक्षण करने के लिए कोई और संक्षिप्त तरीका है?
  • वहाँ तरीकों जो मैं बस में विभिन्न मापदंडों गुजर रहें और परिणाम की जांच कर सकते के लिए subject के बराबर है?
  • क्या प्रत्येक it पर अनावश्यक विवरण से बचने का कोई तरीका है?

धन्यवाद

describe Buy do 
    describe '.get_days' do 
    it 'should get days' do 
     Buy.get_days('Includes a 1-weeknight stay for up to 4 people') 
     .should == 1 
     end 
    it 'should get days' do 
     Buy.get_days('Includes a 1-night stay in a King Studio Room with stone fireplace') 
     .should == 1 
    end 
    it 'should get days' do 
     Buy.get_days('Includes 4 nights/5 days at the Finisterra Hotel for up to two adults and two children (staying in the same room)') 
     .should == 4 
    end 
    end 
end 
+4

'यह विवरण अनावश्यक कैसे है? सिर्फ इसलिए कि आपने चश्मा के लिए एक ही पाठ लिखा है जो विभिन्न चीजों का परीक्षण करता है इसका मतलब यह नहीं है कि वर्णन वहां नहीं होना चाहिए - शायद उन्हें फिर से शब्द दें ताकि वे उपयोगी हों? –

+0

इनपुट/आउटपुट संयोजन वर्णनात्मक पर्याप्त है (कम से कम मेरे लिए)। – lulalala

+0

क्या आप इसे अधिक उपयोगी बनाने के लिए रीवॉर्डिंग का उदाहरण दे सकते हैं, @ डेव न्यूटन? – ahnbizcad

उत्तर

3

This क्लास विधियों के साथ 'विषय' ब्लॉक का उपयोग करने के लिए शायद अधिक दिलचस्प तरीका है।

संपादित करें: टूटा link जैसा कि मुझे लगता है कि वेबैक आर्काइव द्वारा रिपोर्ट की गई है, जो एक ही समस्या के लिए अतिसंवेदनशील है।

+1

[टूटा लिंक] (http://posterous.timocracy.com/a-pattern-for-testing-class-methods-in-ruby-w) कहता है "पोस्टर स्पेस अब उपलब्ध नहीं है" –

+0

@ जेरेडबेक संपादित। मैं आज रात प्रतिक्रिया का सारांश दूंगा। – TCopple

+0

सामग्री एक गिस्ट के रूप में भी उपलब्ध है: https://gist.github.com/timocratic/816049 – aingram

11

वहाँ एक विधि बुला, इसलिए it प्रयोग करने के लिए एक subject बराबर नहीं है यहां जाने का रास्ता है। प्रस्तुत किए गए आपके कोड के साथ जो मुद्दा मैं देखता हूं वह यह है कि यह वास्तव में को की व्याख्या नहीं करता है जिसके लिए आप परीक्षण कर रहे हैं। मैं लिखने के कुछ और की तरह होगा:

describe Buy do 
    describe '.get_days' do 
    it 'should detect hyphenated weeknights' do 
     Buy.get_days('Includes a 1-weeknight stay for up to 4 people').should == 1 
    end 
    it 'should detect hyphenated nights' do 
     Buy.get_days('Includes a 1-night stay in a King Studio Room with stone fireplace').should == 1 
    end 
    it 'should detect first number' do 
     Buy.get_days('Includes 4 nights/5 days at the Finisterra Hotel for up to two adults and two children (staying in the same room)').should == 4 
    end 
    end 
end 

मैं तुम यहाँ के बाद क्या कर रहे हैं, लेकिन उम्मीद है कि विचार स्पष्ट है के बारे में मान्यताओं बना रहा हूं। यह परीक्षण विफल होने पर भी अधिक उपयोगी त्रुटि आउटपुट का कारण बन जाएगा। उम्मीद है की यह मदद करेगा!

+0

मुझे लगता है कि अंत में जवाब है: इसे लिखने का कोई और संक्षिप्त तरीका नहीं है। – lulalala

+0

हाँ, डरते हैं। :) –

+0

@ लुलालाला आप * यह * संक्षिप्त नहीं होना चाहते हैं, आप चश्मा के संदर्भ में सटीक और वर्णनात्मक होना चाहते हैं। –

0

subject/it का उपयोग कर के लिए एक वैकल्पिक उपयोग करने के लिए है before/specify:

#destroy 
    with children 
    should be false 
5

यह एक पुरानी सवाल हो सकता है:

describe '#destroy' do 
    context 'with children' do 
    before { @parent = FactoryGirl.create(:parent, children: FactoryGirl.create_list(:child, 2) } 
    specify { @parent.destroy.should be_false } 
    end 
end 

यह RSpec के -fd उत्पादन प्रारूप में एक उचित विवरण का उत्पादन करेगा लेकिन आप हमेशा subject.class का उपयोग करके प्राप्त कर सकते हैं:

describe Buy do 
    describe '.get_days' do 
    it { expect(subject.class.get_days('Includes a 1-weeknight stay for up to 4 people')).to eq 1 } 
    end 
end 
+0

अच्छी पकड़ ! facepalm। मुझे यह पता होना चाहिए था। यह सही जवाब है! – ahnbizcad

+1

'subject.class'? 'खरीद' का उपयोग करने के लिए यह स्पष्ट नहीं होगा? –

+0

@ahnbizcad वास्तव में नहीं, क्योंकि यह केवल एक ही परीक्षण दिखाता है। Spec आउटपुट के बारे में सोचें और यह क्या दिखाना चाहिए। बिना किसी वर्णनात्मक परीक्षण के अन्य परीक्षणों को जोड़ना अनिवार्य रूप से बेकार spec आउटपुट के लिए बनाता है क्योंकि आप नहीं जानते (ए) spec क्या परीक्षण कर रहा है, और (बी) विभिन्न चश्मा क्या अंतर करता है। –

7

स्पष्ट रूप से described_class विधि है।

https://www.relishapp.com/rspec/rspec-core/docs/metadata/described-class

मैं इसे subject.class से क्लीनर है, क्योंकि यह एक और . विधि कॉल, जो पठनीयता कम कर देता है परिचय नहीं है लगता है।

या तो described_class या subject.class का उपयोग करके प्रत्येक उदाहरण में स्पष्ट रूप से कक्षा का उल्लेख करने से अधिक DRY हो सकता है। लेकिन व्यक्तिगत रूप से मुझे लगता है कि वर्ग नाम का उल्लेख करने के साथ सिंटैक्स हाइलाइटिंग नहीं मिलती है, यह स्पष्ट रूप से एक बमर की तरह है, और मुझे लगता है कि यह रखरखाव विभाग में पूरी तरह से जीतने के बावजूद पठनीयता को कम करता है।

एक सवाल सबसे अच्छा अभ्यास के बारे में उठता है:

आप described_class का उपयोग करना चाहिए जब भी संभव हो के अंदर और .expect() विधि के बाहर, या केवल expect() विधि के भीतर?

+0

यही वह है जो मैं अपने परीक्षणों में उपयोग करना पसंद करता हूं, जो कि विधियों के माध्यम से परीक्षण किए गए डेटा के लिए विषय छोड़ देता है। – DBrown