2010-03-17 8 views
14

एक बहुत ही विशिष्ट प्रश्न द्वारा मजबूर:बहुत सारे लोक तरीके TDD करने के लिए एक नौसिखिया से टेस्ट प्रेरित विकास

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

+0

मैं तुम्हें एक ही "कोड फ़ाइल इकाई" में परीक्षण चाहेगा के रूप में चीजों को परीक्षण किया जा रहा लगता होगा। इस तरह उनके पास आंतरिक हिम्मत तक पहुंच है। –

+0

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

उत्तर

18

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

परीक्षण प्रयोजनों के लिए निजी से सार्वजनिक में कभी भी कुछ न बदलें!

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

आइए कहें कि मेरे पास एक प्रकार है: MyClass और मैं DoStuff विधि का परीक्षण करना चाहता हूं। मेरी सभी परवाह है कि DoStuff विधि कुछ सार्थक है और अपेक्षित परिणाम देता है। यह उस बिंदु तक पहुंचने के लिए सौ निजी विधियों को बुला सकता है, लेकिन मुझे उस विधि के उपभोक्ता के रूप में परवाह नहीं है।

+4

लेकिन आप ** उन सैकड़ों आंतरिक तरीकों का परीक्षण करने का तरीका चाहते हैं, नहीं? –

+4

@Ian - यदि आप टीडीडी कर रहे हैं, तो उन्हें पहले ही परीक्षण किया जाना चाहिए। उनका अस्तित्व का मतलब है कि उन्हें टेस्ट पास करने के लिए वहां रखा गया था। हालांकि, वे विधियां एक कार्यान्वयन विवरण हैं जिन्हें कक्षा के उपभोक्ता को नहीं जाना चाहिए। अगर मुझे बाद में पता चलता है कि मैं उन 100 विधियों को 50 तरीकों से दोबारा कर सकता हूं, तो मुझे अपने परीक्षणों को फिर से लिखना नहीं चाहिए। तो ... हाँ आप उनका परीक्षण करते हैं, लेकिन सीधे नहीं क्योंकि आप केवल सार्वजनिक एपीआई की परवाह करते हैं। यदि कुछ निजी विधि हैं जिनका उपयोग सार्वजनिक एपीआई के माध्यम से नहीं किया जा सकता है, तो यह बेकार है और इसे हटाया जाना चाहिए। – Josh

+0

मैं दाऊद Astels 'प्रैक्टिकल गाइड' के बाद कर रहा हूँ - वह यह संकेत करता है कि आप उन चीजों का परीक्षण और फिर refactor है जब वहाँ बहुत ज्यादा intamacy है कि - मुझे निजी (जनता के लिए निजी नहीं) लेकिन फिर करने के लिए जनता से तरीकों का एक बहुत बदल होगा रिफैक्टर मेरे परीक्षण सेट उन लोगों को हटाने के लिए सेट करते हैं जो अब सार्वजनिक व्यवहार का परीक्षण नहीं कर रहे हैं - क्या यह ध्वनि उचित है? – RoryG

9

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

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

+3

मैं थोड़ी देर पहले सी # में इसी तरह की समस्या में भाग गया - उस भाषा/ढांचे में, आप 'InternalsVisibleTo' निर्देश चाहते हैं। – Tim

1

कम से कम जावा में, दो स्रोत पेड़, कोड के लिए एक और परीक्षण के लिए एक अच्छा अभ्यास है।

src/org/my/xy/X.java 
test/org/my/xy/TestX.java 

तो फिर आप अपने तरीकों पैकेज निजी बना सकते हैं: तो आप जब वे अलग निर्देशिका में अब भी कर रहे हैं, एक ही पैकेज में अपने कोड और अपने परीक्षण डाल सकते हैं।

+0

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

+0

@ माइक कृंतक: आप अभी भी "यूनिट-टेस्ट/संगठन/my/xy/UnitTestX.java" का उपयोग कर सकते हैं "और" कार्यात्मक परीक्षण/संगठन/मेरा/xy/FunctionalTestX.java "। इसके अलावा, पैकेज-प्राइवेट कोड को _all_ प्रकार के परीक्षणों तक एक्सेस करना आवश्यक नहीं हो सकता है। –

7

यह वह जगह है जहां पुरानी कहावत, "टीडीडी डिजाइन के बारे में है," अक्सर आता है। बहुत से सार्वजनिक तरीकों वाले वर्ग में शायद कई ज़िम्मेदारियां हैं - और तथ्य यह है कि आप परीक्षण-ड्राइविंग कर रहे हैं, यह केवल उसको उजागर करता है; यह समस्या का कारण नहीं है।

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

सब इसलिए क्योंकि टीडीडी ने आपकी कक्षा की विशेषताओं को उजागर किया है जो अन्यथा रडार के नीचे फिसल जाएगा। टीडीडी डिजाइन के बारे में है।

+0

यह बहुत समझ में आता है। अगर केवल एक वास्तविक पुस्तक थी जो आपको हाथ से ले जाती थी और आपको दिखाती है कि टीडीडी के लिए संवेदनशीलता विकसित करने के लिए आपको किस तरह की "डिजाइन गंध" को समझना है। (कड़वा) अनुभव से सीखना इसकी योग्यता है, लेकिन यह आधा समय लेने वाला नहीं है। –

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