जोर देकर कहा है कि एक विशेष अपवाद ककड़ी में फेंक दिया जाता है

Question

परिदृश्य

मैं एक पुस्तकालय (ऑन रेल्स कोई रूबी) है जिसके लिए मैं बहुत विस्तृत ककड़ी सुविधाओं करना चाहते हैं लिख रहा हूँ। इसमें विशेष रूप से त्रुटियों/अपवादों का वर्णन करना शामिल है जिन्हें विभिन्न मामलों में फेंक दिया जाना चाहिए।

उदाहरण

सबसे सहज तरीका शायद होगा

की तरह कुछ

When I do something unwanted 
Then an "ArgumentError" should be thrown 

समस्या

मैं पता करने के लिए है दो मुद्दों कर रहे हैं ककड़ी चरणों में लिखने के लिए:

1. अपवाद फेंकने पर पहला चरण विफल नहीं होना चाहिए।
2. कुछ दावा फेंकने के लिए पहला कदम फेंकने वाला अपवाद दूसरे चरण तक पहुंच योग्य होना चाहिए।

unelegant और बोझिल समाधान

सबसे अच्छा तरीका मैं के साथ पहले चरण में अपवाद कैशिंग और यह एक उदाहरण चर में डाल कि दूसरे चरण के लिए उपयोग कर सकते हैं है आने के लिए कर लिया है, जैसे इतना:

When /^I do something unwanted$/ do 
    begin 
    throw_an_exception! 
    rescue => @error 
    end 
end 

Then /^an "(.*)" should be thrown$/ do |error| 
    @error.class.to_s.should == error 
end 

हालांकि, इस दिशा में पहला कदम कम या ज्यादा बेकार मामलों में जहां मैं इसे विफल नहीं चाहते हो में है, और यह एक उदाहरण चर, जो एक अच्छी बात नहीं है की आवश्यकता है।

तो, क्या कोई मुझे कम से कम कम बोझिल समाधान के साथ मदद कर सकता है? या क्या मुझे अपनी विशेषताओं को अलग-अलग लिखना चाहिए? कोई भी सहायताकाफी प्रशंसनीय होगी।

Answer 1

मैं एक बार और इसके बारे में सोचा है, और शायद जवाब है:

वहाँ, कोई सुरुचिपूर्ण समाधान है, क्योंकि Given-When-Then -Scheme अपने मामले में उल्लंघन किया गया है। आप उम्मीद करते हैं कि "फिर एक अपवाद फेंक दिया जाना चाहिए" का परिणाम "जब मैं कुछ अवांछित करता हूं"।

लेकिन जब आप इसके बारे में सोचते हैं, तो यह सच नहीं है! अपवाद इस क्रिया का नतीजा नहीं है, वास्तव में अपवाद केवल दिखाता है कि "कब" - स्थिति विफल रही।

इस मेरे समाधान एक उच्च स्तर पर परीक्षण करने के लिए किया जाएगा:

When I do something unwanted 
Then an error should be logged 

या

When I do something unwanted 
Then the user should get an error message 

या

When I do something unwanted 
Then the program should be locked in state "error" 

या इनमें से एक संयोजन।

फिर आप अपने प्रोग्राम में "अपवाद कैश" करेंगे - जो सही समझ में आता है, क्योंकि आपको वैसे भी ऐसा करने की ज़रूरत है।

आपके द्वारा बताई गई दो समस्याएं भी हल की जाएंगी।

मामले में आप वास्तव में अपवाद के लिए परीक्षण करना चाहिए

ठीक है, मुझे लगता है कि तब ककड़ी नहीं सही टेस्ट स्वीट, है हम्म? ;-)

को देखते हुए-जब-तब-योजना वैसे भी उल्लंघन किया गया है, मैं बस

When I do something unwanted it should fail with "ArgumentError" 

लिखते थे के रूप में और इस तरह के कदम परिभाषाओं कुछ में (अपरीक्षित, मुझे सही करें यदि आप इसे करने की कोशिश)

When /^I do something unwanted it should fail with "(.*)"$/ do |errorstring| 
    expect { 
    throw_an_exception! 
    }.to raise_error(errorstring) 
end 

ऊपर बताए अनुसार, यह योजना गलत है क्योंकि यह योजना गलत है, लेकिन यह उद्देश्य को पूरा करेगा, है ना? ;-)

आपको परीक्षण त्रुटियों at rspec expectations पर और दस्तावेज़ीकरण मिलेगा।

Answer 2

एक विकल्प परिदृश्य को @allow-rescue के साथ चिह्नित करना और पृष्ठ का आउटपुट और स्टेटस कोड जांचना है। उदाहरण

my_steps.rb

Then(/^the page (?:should have|has) content (.+)$/) do |content| 
    expect(page).to have_content(content) 
end 

Then(/^the page should have status code (\d+)$/) do |status_code| 
    expect(page.status_code.to_s).to eq(status_code) 
end 

Then /^I should see an error$/ do 
    expect(400..599).to include(page.status_code) 
end 

में my_feature.feature

@allow-rescue 
Scenario: Make sure user can't do XYZ 
    Given some prerequisite 
    When I do something unwanted 
    Then the page should have content Routing Error 
    And the page should have status code 404 

या वैकल्पिक रूप में के लिए:

@allow-rescue 
Scenario: Make sure user can't do XYZ 
    Given some prerequisite 
    When I do something unwanted 
    Then I should see an error 

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

Answer 3

मैं किसी के परिप्रेक्ष्य जो एक व्यवहार संचालित विकास स्थिति में ककड़ी सुविधाओं का उपयोग करता से जवाब दे रहा हूँ, तो यह लेने के लिए या इसे छोड़ ...

परिदृश्य एक 'सुविधा' या कार्यक्षमता का परीक्षण करने के लिए लिखा जाना चाहिए आवेदन के रूप में, कोड का परीक्षण करने के लिए इस्तेमाल होने के विरोध में। एक उदाहरण से किया जा रहा:

When the service is invoked 
Then a success code should be returned 

यह अपने परीक्षण मामले की तरह लगता है (यानी मैं यह कर, तो यह अपवाद उत्पन्न किया जाना चाहिए) इकाई या एकीकरण परीक्षण के लिए एक उम्मीदवार है - मेरे मामले में, हम कुछ मजाक या प्रयोग करेंगे यूनिट परीक्षण ढांचा।

मेरा सुझाव यह देखने के लिए कि क्या वे वास्तव में परीक्षण करने का इरादा रखते हैं, वे आपके फीचर परिदृश्यों का फिर से मूल्यांकन करना चाहते हैं। व्यक्तिगत अनुभव से, मैंने पाया है कि यदि मेरी परीक्षा कक्षाएं असामान्य रूप से जटिल हो रही हैं, तो मेरी विशेषताएं 'गलत' हैं।

Answer 4

When ब्लॉक में अपवाद उठाना संभव है और उसके बाद निम्नलिखित Then ब्लॉक में इसके बारे में दावा करना संभव है।;

When /^I do something unwanted$/ do 
    @result = -> { throw_an_exception! } 
end 

Then /^an "(.*)" should be thrown$/ do |error| 
    expect{ @result.call }.to raise_error(error) 
end 

उदाहरण RSpec के matchers का उपयोग करता है कि लेकिन महत्वपूर्ण हिस्सा -> (लैम्ब्डा) है:

अपने उदाहरण का उपयोग जो throw_an_exception! विधि को पारित करने के लिए संदर्भ की अनुमति देता है।

मुझे उम्मीद है कि इससे मदद मिलती है!