मैं नियमित रूप से इस समस्या में भाग लेता हूं, और मुझे यकीन नहीं है कि इस बाधा को कैसे दूर किया जाए। मैं वास्तव में टेस्ट-ड्राइव-डेवलपमेंट (या बीडीडी, या जो कुछ भी) सीखना और लागू करना चाहता हूं लेकिन ऐसा लगता है कि मैं जिस एप्लिकेशन को लागू करना चाहता हूं, वह यह है कि यह केवल मानक डेटाबेस सीआरयूडी सामान है, और मुझे यकीन नहीं है कि कैसे इसे लागू करने के लिए जाने के लिए। ऑब्जेक्ट्स डेटाबेस पर बने रहने के अलावा कुछ भी नहीं करते हैं; कोई जटिल तर्क नहीं है जिसे परीक्षण करने की आवश्यकता है। एक गेटवे है जिसे मुझे अंततः किसी तृतीय-पक्ष सेवा के लिए परीक्षण करने की आवश्यकता होगी, लेकिन मैं पहले ऐप का मूल प्राप्त करना चाहता हूं।आवेदन करते समय टीडीडी लागू करना 100% सीआरयूडी
जब भी मैं परीक्षण लिखने की कोशिश करता हूं, तो मैं केवल मूलभूत सामग्री का परीक्षण करना समाप्त करता हूं जो मुझे शायद पहले स्थान पर परीक्षण नहीं करना चाहिए (जैसे गेटर्स/सेटर्स) लेकिन ऐसा लगता है कि ऑब्जेक्ट्स के पास कुछ और नहीं है। मुझे लगता है कि मैं दृढ़ता का परीक्षण कर सकता हूं लेकिन यह मेरे लिए कभी भी सही नहीं लगता है क्योंकि आपको वास्तव में डेटाबेस नहीं मारा जाना चाहिए, लेकिन यदि आप इसे मजाक करते हैं तो आप वास्तव में कुछ भी परीक्षण नहीं कर रहे हैं क्योंकि आप वापस थूकने वाले डेटा को नियंत्रित करते हैं; जैसे मैंने कई उदाहरण देखे हैं जहां एक नकली भंडार है जो लूपिंग और ज्ञात मानों की एक सूची बनाकर डेटाबेस को अनुकरण करता है, और परीक्षण सत्यापित करता है कि "भंडार" एक निश्चित मूल्य को वापस खींच सकता है ... मैं हूं इस तरह के एक परीक्षण के बिंदु को नहीं देख रहा है क्योंकि निश्चित रूप से "भंडार" उस मूल्य को वापस करने जा रहा है; यह कक्षा में हार्ड कोडित है! खैर, मैं इसे एक शुद्ध टीडीडी दृष्टिकोण से देखता हूं (यानी आपको एक परीक्षण करने की आवश्यकता है कि आपके भंडार को GetCustomerByName विधि की आवश्यकता है या जो भी आप विधि लिख सकते हैं), लेकिन ऐसा लगता है कि इसके बाद किसी भी कारण से " रास्ता "- परीक्षण किसी विधि को न्यायसंगत बनाने के अलावा कुछ भी उपयोगी नहीं लगता है।
क्या मैं इस गलत तरीके से सोच रहा हूं?
उदाहरण के लिए मिल संपर्क प्रबंधन अनुप्रयोग का एक रन लें। हमारे पास संपर्क हैं, और मान लें कि हम संपर्कों को संदेश भेज सकते हैं। इसलिए हमारे पास दो इकाइयां हैं: Contact और Message, प्रत्येक सामान्य गुणों के साथ (जैसे पहला नाम, अंतिम नाम, संपर्क के लिए ईमेल, और विषय और शरीर और संदेश के लिए तिथि)। यदि इन वस्तुओं में से कोई भी वास्तविक व्यवहार नहीं है या किसी तर्क को करने की आवश्यकता है, तो इस तरह के ऐप को डिज़ाइन करते समय आप टीडीडी कैसे लागू करते हैं? ऐप का एकमात्र उद्देश्य मूल रूप से संपर्कों की सूची खींचना और उन्हें एक पृष्ठ पर प्रदर्शित करना, संदेश भेजने के लिए एक फॉर्म प्रदर्शित करना है, और इसी तरह। मुझे यहां किसी भी तरह के उपयोगी परीक्षण नहीं दिख रहे हैं - मैं कुछ परीक्षणों के बारे में सोच सकता हूं लेकिन वे कहने के लिए बहुत अधिक परीक्षण करेंगे "देखें, मेरे पास परीक्षण हैं!" वास्तव में किसी प्रकार के तर्क का परीक्षण करने के बजाय (रेल पर रूबी इसका अच्छा उपयोग करता है, लेकिन मैं वास्तव में "उपयोगी" परीक्षण होने के लिए परीक्षण सत्यापन पर विचार नहीं करता क्योंकि यह आपके लिए कुछ ढांचा का ख्याल रखना चाहिए)
मुझे बस कहना होगा ... मैं * प्यार * का शीर्षक सवाल। – Shog9
यह एक बहुत अच्छा सवाल है। मेरा मानना है कि ज्यादातर समय जब हमने टीडीडी की लागत-औचित्य पर तर्क सुना, तो वे वास्तव में सीआरयूडी जैसे आवेदन के बारे में बात करते हैं। – Sake
यही मैंने देखा है।मैं * चाहता हूं * टीडीडी (अच्छी तरह से जरूरी नहीं कि टीडीडी, लेकिन परीक्षण) का उपयोग करें, लेकिन जब कभी ऐप को डेटा खींचने की आवश्यकता होती है तो मैं कभी परीक्षण नहीं कर सकता - मुझे यहां कुछ शानदार जवाब मिल गए हैं। –