2012-12-19 28 views
6

एक ठेठ ActiveRecord मॉडल को देखते हुए before_save परीक्षण करने के लिए कैसे, मैं अक्सर before_save कॉलबैक कि इनपुट को पार्स उदाहरण time_string उपयोगकर्ता से की तरह कुछ ले जा रहा है और एक time फ़ील्ड में पार्स करने के लिए है।रेल: कॉलबैक

सेटअप ऐसा दिखाई दे सकता है कि:

before_save :parse_time 
attr_writer :time_string 

private 
def parse_time 
    time = Chronic.parse(time_string) if time_string 
end 

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

तो, आपके लिए वहां रेलवे टेस्टर्स अनुभवी हैं, आप इस तरह की चीज़ों का परीक्षण कैसे करते हैं?

+0

आप उस 'समय' चर का उपयोग कहां करते हैं? क्या यह आपकी वस्तु का गुण है? –

+0

ऊपर दिया गया उदाहरण गढ़ा हुआ है, लेकिन हां, समय चर एक ऑब्जेक्ट विशेषता है। – Andrew

उत्तर

9

रूबी में, निजी तरीकों अभी भी Object#send

माध्यम से उपलब्ध हैं तुम इतनी तरह अपने इकाई परीक्षण के लिए इस दोहन कर सकते हैं:

project = Project.new 
project.time_string = '2012/11/19 at Noon' 
assert_equal(project.send(:parse_time), '2012-11-19 12:00:00') 
+0

दिलचस्प, मुझे एहसास नहीं हुआ कि '# send' इस तरह से काम करता है। धन्यवाद! – Andrew

3

मुझे क्या होगा एक new या build उदाहरण के राज्य को बचाने के है अपने वस्तु की, वस्तु बचाने के लिए और है कि before_save

post = Post.new 
post.time_string = '2012/11/19' 
expected_time = Chronic.parse(post.time_string) 
post.save 
assert_equal(post.time, expected_time) 
01 से बदल गया था विशेषता के मान के आधार पर दावे या उम्मीद करना

इस तरह आप इस व्यवहार का परीक्षण कर रहे हैं कि वस्तु को कैसे कार्य करना चाहिए और आवश्यक रूप से विधि के कार्यान्वयन को नहीं करना चाहिए।

+2

ठीक है, लेकिन इसके लिए दो प्रमुख डाउनसाइड्स हैं: (1) यह धीमा है। (2) '# save' सभी कॉलबैक चलाता है, और यदि इसके लिए परीक्षण की तुलना में एक और कॉलबैक त्रुटियां भी विफल हो जाएंगी, भले ही यह काम कर रही हो। – Andrew

+0

मुझे इस तरह से भी पसंद है, क्योंकि इससे कोई फर्क नहीं पड़ता कि आंतरिक कैसे काम करते हैं, जब तक कि अंत स्थिति सही न हो, लेकिन तरीकों का परीक्षण करने के लिए फायदे (गति, कवरेज, समझ) हैं। – Unixmonkey

+0

पुन: परीक्षण व्यवहार बनाम कार्यान्वयन, मैं समझता हूं कि आपका क्या मतलब है, लेकिन लक्ष्य यहां कई व्यवहारों को कवर करने वाले एकीकरण परीक्षण की बजाय अलगाव में विधि के व्यवहार का परीक्षण करना है। व्यक्तिगत रूप से परीक्षण विधियों का यह अर्थ यह नहीं है कि आप व्यवहार के बजाय कार्यान्वयन का जरूरी परीक्षण कर रहे हैं। – Andrew

0

ऐसे समय होते हैं जब मेरे पास if मेरी कॉलबैक पर स्थिति होती है, जिसमें मैं run_callbacks का उपयोग करता हूं।

before_save :parse_time, :if => Proc.new{ |post| post.foo == 'bar' } 

post = Post.new 
post.foo = 'wha?' 
post.run_callbacks :before_save 
assert_nil(post.time) 

द्वारा द्वारा

post = Post.new 
post.foo = 'bar' 
expected_time = Chronic.parse(post.time_string) 
post.run_callbacks :before_save 
assert_equal(post.time, expected_time) 

और नकारात्मक सकारात्मक परीक्षण किया जाता है अधिक जानकारी के लिए the API और a blog देखें।

 संबंधित मुद्दे

  • कोई संबंधित समस्या नहीं^_^