क्या यह रूबी के कर्नेल वर्ग में एक जोर() विधि जोड़ने के लिए मूर्खतापूर्ण रूबी है?

Question

मैं रूबी में केंट बेक के xUnit के बराबर कोडिंग करके अपनी रूबी समझ का विस्तार कर रहा हूं। पायथन (जो केंट लिखता है) में भाषा में एक जोर() विधि है जिसका व्यापक रूप से उपयोग किया जाता है। रूबी नहीं करता है। मुझे लगता है कि इसे जोड़ना आसान होना चाहिए, लेकिन इसे कर्नेल सही जगह रखने के लिए है?

बीटीडब्ल्यू, मुझे रूबी में विभिन्न यूनिट ढांचे के अस्तित्व के बारे में पता है - यह "कुछ करने के बजाय" रूबी मुहावरे सीखने का एक अभ्यास है।

Answer 1

नहीं, यह सबसे अच्छा अभ्यास नहीं है। सबसे अच्छा सादृश्य रूबी कहने देगी() सिर्फ

raise "This is wrong" unless expr 

बढ़ा रहा है और यदि आप और अधिक विशिष्ट अपवाद

Answer 2

कर्नेल मॉड्यूल में जोर विधि जोड़ने के लिए आपका क्या कारण है? क्यों न केवल Assertions या कुछ नामक एक और मॉड्यूल का उपयोग करें?

इस तरह

:

class Object 
    include Assertions 
end 

अस्वीकरण:: मैं कोड लेकिन सिद्धांत रूप में परीक्षण नहीं किया

module Assertions 
    def assert(param) 
    # do something with param 
    end 

    # define more assertions here 
end 

तुम सच में अपने दावे की जरूरत है हर जगह कुछ इस तरह करते हैं उपलब्ध होने की मैं इसे इस तरह करूँगा।

Answer 3

मेरी समझ यह है कि आप रूबी से अधिक परिचित होने के तरीके के रूप में अपना स्वयं का परीक्षण सूट लिख रहे हैं। तो जबकि टेस्ट :: यूनिट एक गाइड के रूप में उपयोगी हो सकता है, शायद यह वह नहीं है जिसे आप ढूंढ रहे हैं (क्योंकि यह पहले ही नौकरी कर चुका है)।

उस ने कहा, पाइथन का जोर (मुझे कम से कम), सी assert(3) के समान समकक्ष है। यह विशेष रूप से यूनिट-टेस्ट के लिए डिज़ाइन नहीं किया गया है, बल्कि उन मामलों को पकड़ने के लिए जहां "यह कभी नहीं होना चाहिए"।

कैसे रूबी के अंतर्निर्मित यूनिट परीक्षण समस्या को देखते हैं, तो यह है कि प्रत्येक व्यक्तिगत परीक्षण केस श्रेणी TestCase का उप-वर्ग है, और इसमें "जोर" कथन शामिल है जो इसे पारित करने की वैधता की जांच करता है और रिपोर्टिंग के लिए इसे रिकॉर्ड करता है।

Answer 4

यह विशेष रूप से मुहावरेदार नहीं है से निपटने के लिए प्रदान करना चाहते हैं आप अपने खुद के अपवाद लागू कर सकते हैं, लेकिन मुझे लगता है कि यह एक है अच्छा विचार। खास तौर पर अगर इस तरह किया:

def assert(msg=nil) 
    if DEBUG 
     raise msg || "Assertion failed!" unless yield 
    end 
end 

इस तरह वहाँ कोई प्रभाव है कि अगर आप डीबग साथ चलाने के लिए नहीं तय सेट (या कुछ अन्य सुविधाजनक स्विच, मैंने पहले भी Kernel.do_assert का उपयोग किया है)।

Answer 5

मुझे लगता है कि यह रूबी में आवेषण का उपयोग करने के लिए पूरी तरह से मान्य है। लेकिन अगर आप दो अलग बातें उल्लेख कर रहे हैं:

• XUnit चौखटे अपने परीक्षण उम्मीदों की जाँच के लिए assert तरीकों का उपयोग। उनका उपयोग आपके परीक्षण कोड में नहीं किया जाना चाहिए, न कि आपके आवेदन कोड में।
• सी, जावा या पायथन जैसे कुछ भाषाओं में assert निर्माण शामिल है जिसका उद्देश्य आपके कार्यक्रमों के कोड के अंदर उपयोग किया जाना है, ताकि आप अपनी ईमानदारी के बारे में धारणाओं को देख सकें। ये चेक कोड के अंदर ही बनाए जाते हैं। वे टेस्ट-टाइम उपयोगिता नहीं हैं, बल्कि विकास-समय एक हैं।

मैं हाल ही में solid_assert: a little Ruby library implementing a Ruby assertion utility और भी a post in my blog explaining its motivation लिखा .. यह आप के रूप में भाव लिखने करते हैं:

assert some_string != "some value" 
assert clients.empty?, "Isn't the clients list empty?" 

invariant "Lists with different sizes?" do 
    one_variable = calculate_some_value 
    other_variable = calculate_some_other_value 
    one_variable > other_variable 
end  

और वे assert और invariant खाली बयान के रूप में मूल्यांकन हो तो निष्क्रिय किया जा सकता। यह आपको उत्पादन में किसी भी प्रदर्शन की समस्या से बचने देता है। लेकिन ध्यान दें कि The Pragmatic Programmers उन्हें निष्क्रिय करने के खिलाफ अनुशंसा करते हैं। यदि आप वास्तव में प्रदर्शन को प्रभावित करते हैं तो आपको केवल उन्हें निष्क्रिय करना चाहिए।

उत्तर के संबंध में यह कहकर कि मूर्खतापूर्ण रूबी तरीका सामान्य raise कथन का उपयोग कर रहा है, मुझे लगता है कि इसमें व्यक्तित्व की कमी है। जोरदार प्रोग्रामिंग के सुनहरे नियमों में से एक सामान्य अपवाद हैंडलिंग के लिए दावा का उपयोग नहीं कर रहा है। वे दो पूरी तरह से अलग चीजें हैं। यदि आप उनमें से दो के लिए एक ही वाक्यविन्यास का उपयोग करते हैं, तो मुझे लगता है कि आप कोड अधिक अस्पष्ट होंगे। और निश्चित रूप से आप उन्हें निष्क्रिय करने की क्षमता खो देते हैं।

आप इस बात से आश्वस्त हो सकते हैं कि दावाों का उपयोग करना एक अच्छी बात है क्योंकि The Pragmatic Programmer From Journeyman to Master और Code Complete जैसे दो क्लासिक पुस्तकें पढ़नी चाहिए और उनके उपयोग की अनुशंसा करें। Programming with assertions शीर्षक वाला एक अच्छा लेख भी है जो बहुत अच्छी तरह से चित्रित करता है कि इसके बारे में ज़ोरदार प्रोग्रामिंग और इसका उपयोग कब किया जाता है (यह जावा में आधारित है, लेकिन अवधारणा किसी भी भाषा पर लागू होती है)।