2010-04-30 16 views
11

मैं अपने ब्लॉग रीमेकिंग पर विचार कर रहा हूँ (PHP में वर्तमान में है, लेकिन < 100 गैर लेआउट कोड की लाइनें) सिर्फ मनोरंजन के लिए पर रूबी में। मैं रेल में एक और प्रोजेक्ट बनाना चाहता हूं, लेकिन मुझे एक पूर्ण परियोजना बनाने की कोशिश करने से पहले रेल (हैलो वर्ल्ड से अधिक) सीखना चाहिए।आप एक टीडीडी दृष्टिकोण के साथ ब्लॉग कैसे बनायेंगे?

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

हर बार जब मैं एक ब्लॉग लिखने की कल्पना करता हूं तो इसे पूरी तरह से परीक्षण करने के लिए एक घटक के लिए दस लाख परीक्षणों की आवश्यकता होती है। मैं बहुत सारे परीक्षण लिखने से कैसे बचूं?

इसके अलावा, मैं इस समुदाय विकी बनाने रहा हूँ क्योंकि मैं करने के लिए मूल रूप से एक मिनी ट्यूटोरियल/ज्ञान का आधार बनाया जा इस के लिए इरादा ...

मैं आगे चला गया और इसलिए शायद इस प्रश्न पर एक इनाम रखा मैं वास्तव में यह कर सकते हैं इसका अच्छा जवाब प्राप्त करें ..

+2

आप बहुत सारे परीक्षण लिखने से बचने की कोशिश क्यों कर रहे हैं? मेरे पास रिकर्सिव एल्गोरिदम वाले एक वर्ग के लिए टीडीडी के साथ 100 यूनिट परीक्षण थे। आवेदन जारी होने पर कभी भी कोई बग नहीं था और किसी ने कभी शिकायत नहीं की थी कि उसके पास इतने सारे परीक्षण थे। –

+3

@c_ma क्योंकि मैं अंततः अपना ब्लॉग समाप्त करना चाहता हूं :) – Earlz

+1

जब आप अपने विकास को चलाते हैं तो आप कृत्रिम रूप से परीक्षणों की संख्या को सीमित नहीं कर सकते हैं। यह कहकर कि आप इस मामले में बहुत से परीक्षण लिखने से बचना चाहते हैं, एक चित्रकार की तरह है कि वह उस अतिरिक्त ट्यूब को खोलने से बचना चाहता है। –

उत्तर

6

टीडीडी डिज़ाइन के बारे में अधिक है तो यह परीक्षण के बारे में है। बहुत से लोग इसे याद करते हैं और कुछ ऐसा अभ्यास करेंगे जो टीडीडी की तरह महसूस नहीं करता है। टीडीडी के साथ, आप अपने कोड में बदलाव चलाने के लिए एक परीक्षा लिख ​​रहे हैं। आपको बहुत से परीक्षण लिखने की चिंता करने की आवश्यकता नहीं है, क्योंकि आपको लिखने के लिए और अधिक उत्पादन कोड होना चाहिए (और इसलिए, परीक्षण करने के लिए अधिक कोड)। फिर, TDD नहीं के बारे में अभी परीक्षण के बहुत सारे अपने कोड के लिए लिख रहा है, लेकिन आप परीक्षण के बहुत सारे के साथ खत्म हो जाएगा और इसलिए, आप के रूप में अपने कोड बढ़ता है और परिवर्तन आप प्रतिक्रिया देने के लिए परीक्षण की एक बहुत शक्तिशाली सूट होगा।

इसके बजाय सॉफ़्टवेयर के किसी विशेष टुकड़े के विकास को ड्राइव करने के तरीके के बारे में बात करने के बारे में बात करते हुए, मैं आपको सलाह दूंगा कि टीडीडी का अभ्यास कैसे करें और जानें, जैसा आपने कहा था, इसके बारे में क्या है। विचार करने के लिए एक अच्छी किताब है: Growing Object Oriented Software, Guided by Tests। पुस्तक जावा का उपयोग करती है, लेकिन यह सॉफ्टवेयर का एक काफी जटिल टुकड़ा बनाने के लिए टीडीडी का उपयोग करने का एक महान वास्तविक जीवन अनुप्रयोग है।

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

0
ककड़ी सुविधाओं लेखन एक "बाहर-इन" कवरेज प्रदान करने के द्वारा शुरू

। ये आपके द्वारा अपनी कार्यक्षमता के बड़े बहुमत का परीक्षण करने में सक्षम होना चाहिए। लिखना बहुत आसान है। एक ब्लॉग में कई परीक्षण नहीं हैं, आखिरकार यह सिर्फ पोस्ट और टिप्पणियां है, है ना? मेरे blorgh एप्लिकेशन पर एक नज़र डालें जो ककड़ी का उपयोग करके विकसित एक रेल ऐप है।

0

दिलचस्प, यह वही है जो मैंने कुछ दिन पहले शुरू किया था। मैं RSpec और Cucumber का उपयोग कर रहा हूं। मैंने Article और Comment मॉडल के लिए कुछ चश्मा लिखकर शुरू किया। जब वे सभी हरे रंग में गए तो मैंने विचारों, नियंत्रकों इत्यादि को लागू करने के लिए ककड़ी परीक्षण लिखे।

यह मेरे लिए वास्तव में अच्छा काम करता है लेकिन मुझे लगता है कि ककड़ी के साथ शुरू करना बहुत अच्छा है क्योंकि बहुत से लोग इस दृष्टिकोण को पसंद करते हैं।

मामले में आप RSpec और ककड़ी का केवल कुछ ज्ञान है मैं अत्यधिक Railscasts की सिफारिश:

मैं भीपसंद आयास्क्रीनकास्ट लेकिन रेलवे के विपरीत वे 9 डॉलर प्रत्येक खर्च करते थे।

1

हितधारकों पर एक नज़र डालें, और वे क्या हासिल करना चाहते हैं। वहां शुरू करना महत्वपूर्ण है, क्योंकि यह आपको सही ढंग से प्राथमिकता देने की अनुमति देता है (यानी सबसे दिलचस्प तकनीकी भाग पर नहीं, बल्कि अधिकांश व्यावसायिक मूल्य के साथ)। डेवलपर एक हितधारक है, और अपने डर को कम करता है (कुछ बनाने में सक्षम नहीं है) एक वैध लक्ष्य है।

डिज़ाइन के बारे में सोच परीक्षणों में लिखी गई है। हितधारकों के अंत-लक्ष्यों के साथ शुरू करें, वहां से पीछे की तरफ से शुरुआत करें (समय-उलटा)। यह सुनिश्चित करता है कि आप किस पर ध्यान केंद्रित करते हैं, और कम कैसे करें। ऑब्जेक्ट विशेषताओं से सही प्राप्त करने के लिए ऑब्जेक्ट्स के बीच बातचीत अधिक महत्वपूर्ण है।

देखें:

1

मैं पीट, इसके बारे में और अधिक डिजाइन करने के लिए एक ऐसी ही राय है।

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

आपने कहा "वर्तमान में PHP में, लेकिन < गैर-लेआउट कोड की 100 पंक्तियां", यदि ऐसा है तो शायद कुछ हद तक विशेषताएं हैं। यदि आप आवश्यक वास्तविक सुविधाओं पर ध्यान केंद्रित करते हैं तो पाठ्यक्रम की विशेषताओं की तुलना में कुछ परीक्षण/उच्च होना चाहिए, लेकिन जब तक वे सही इकाई परीक्षण होते हैं तो संख्या को विस्फोट नहीं करना चाहिए - check this video

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