टेस्ट-संचालित विकास की कोशिश कर रहे हैं

Question

इस post पढ़ने के बाद मैं इस सवाल को पूछने वाले व्यक्ति के समान स्थिति में महसूस किया। मुझे तकनीक पसंद है और वास्तविक दुनिया की समस्याओं को हल करने के लिए नए विचारों के साथ आना सिर्फ मेरे न्यूरॉन्स सींग का हो जाता है, लेकिन समीकरण के दूसरे भाग - वास्तव में चीजें (तेजी से) हो रही हैं - आमतौर पर गधे में दर्द होता है, खासकर जब मैं ' मैं अपने लिए यह कर रहा हूँ।

कभी-कभी मैं कोड के साथ सादा ऊबता महसूस करता हूं, कुछ अन्य बार मैं कर्सर को पाठ संपादक में ले जाने और मेरे कोड पर घूरने में अधिक समय बिताता हूं, जो मेरे पास पहले से बेहतर समाधान के साथ आने का प्रयास कर रहा है। मैंने सुना है कि यह बीमारी है जिसे पूर्णतावाद कहा जाता है।

मैंने उसी पोस्ट में पढ़ा है (और एसओ पर भी कुछ बार भी) कि टीडीडी coding like a girl को रोकने के लिए वास्तव में अच्छा है, हालांकि मैंने टीडीडी पर कभी मौका नहीं दिया है - या तो क्योंकि मैं बहुत आलसी हूं इसे सीखने/सेट करने के लिए या क्योंकि मुझे नहीं लगता कि मुझे इसकी आवश्यकता है क्योंकि मैं अपने सिर के अंदर आवश्यक सभी परीक्षण कर सकता हूं।

• क्या आप यह भी मानते हैं कि टीडीडी वास्तव में जीटीडी में मदद करता है?
• मुझे टीडीडी के बारे में क्या जानने की आवश्यकता है?
• टीडीडी के विकल्पों के बारे में क्या?
• टीडीडी वेब ऐप को व्यवस्थित/विकसित करने के लिए सबसे अच्छी पद्धति क्या होगी?
• मेरी जिंदगी को आसान बनाने के लिए मुझे किस लाइब्रेरी का उपयोग करना चाहिए (यदि कोई है)?

पीएस: मैं मुख्य रूप से (लेकिन विशेष रूप से नहीं) यहां PHP के साथ काम कर रहा हूं।

Answer 1

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

लेकिन नमक के अनाज के साथ मेरी राय लें। Kent Beck और How deep are your unit tests? से एक और अधिक दिलचस्प बात आती है।

Answer 2

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

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

टीडीडी के विकल्पों के बारे में क्या? जैसा कि मैंने कहा, मैं इसे एक पद्धति के लिए एक विकल्प नहीं मानूंगा। एक विकल्प है और इसका उपयोग नहीं करना है :)

टीडीडी वेब ऐप को व्यवस्थित/विकसित करने के लिए सबसे अच्छी पद्धति क्या होगी? यदि आप यही पूछ रहे हैं तो हम स्क्रम/फुर्तीली के साथ काफी सफल रहे हैं।

मेरे जीवन को आसान बनाने के लिए मुझे किस पुस्तकालयों का उपयोग करना चाहिए (यदि कोई है)? मेरा PHP ज्ञान 5 साल पहले समाप्त हो गया है, और मैं किसी और को इसका उत्तर दूंगा।

किसी भी तरह से, बस मेरे 2 सेंट। यदि आप यहां पढ़ना पसंद करते हैं तो यह एक अच्छा अवलोकन है: http://www.agiledata.org/essays/tdd.html

Answer 3

मैंने हाल ही में "वसा मॉडल पतले नियंत्रकों" http://www.amitshah.in/php/controller-vs-model.html का उपयोग करना शुरू कर दिया है: मॉडल (और दृश्य/नियंत्रक से बाहर) में जितना संभव हो उतना कोड ढंकना।

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

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

जहां मुझे लगता है कि टीडीडी में लाभ जटिलता को कम करने और गति में वृद्धि (जिस दर पर मैं समस्याओं को हल कर सकता हूं) को कम करने में है। अगर मैं कुछ परीक्षण लिखता हूं जो साबित करते हैं कि मेरा कोड काम कर रहा है, तो जैसे ही सभी परीक्षण पास होते हैं, मैं अगली समस्या पर जा सकता हूं। यह मज़ा मेरे लिए कोडिंग में वापस रखता है।