अगर मुझे टीडीडी करना है तो क्या मुझे निजी तरीकों से बचना चाहिए?

Question

मैं अभी TDD सीख रहा हूँ। यह मेरी समझ है कि निजी तरीके अस्थिर हैं और इसके बारे में चिंतित नहीं होना चाहिए क्योंकि सार्वजनिक एपीआई किसी वस्तु की अखंडता की पुष्टि करने के लिए पर्याप्त जानकारी प्रदान करेगा।

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

खैर, मेरे लिए यह संभव है कि मैं एक ऐसी वस्तु बनाऊं जिसमें केवल निजी तरीके हों और उनकी घटनाओं को सुनकर अन्य वस्तुओं के साथ बातचीत करें। यह बहुत ही संक्षिप्त होगा, लेकिन पूरी तरह से अप्राप्य।

इसके अलावा, परीक्षण के लिए तरीकों को जोड़ना बुरा व्यवहार माना जाता है।

इसका मतलब यह है कि TDD एनकैप्सुलेशन के साथ बाधाओं पर है? उचित संतुलन क्या है? मैं अपने सभी तरीकों को अब सार्वजनिक करने के लिए इच्छुक हूं ...

Comments

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

— हारून मैकिवर

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

— S.Lott

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

— 18

परीक्षण निजी विधियों

— gnat

इसलिए @gnat आपको लगता है कि इसे उस प्रश्न के डुप्लिकेट के रूप में बंद किया जाना चाहिए जो इस प्रश्न के उत्तर से निकला है? * 8 ')

— मार्क बूथ 14

Answer 1

कार्यान्वयन पर परीक्षण के लिए इंटरफ़ेस के परीक्षण को प्राथमिकता दें।

यह मेरी समझ है कि निजी तरीके अप्राप्य हैं

यह आपके विकास के वातावरण पर निर्भर करता है, नीचे देखें।

[निजी तरीकों] के बारे में चिंतित नहीं होना चाहिए क्योंकि सार्वजनिक एपीआई किसी वस्तु की अखंडता की पुष्टि करने के लिए पर्याप्त जानकारी प्रदान करेगा।

यह सही है, टीडीडी इंटरफ़ेस का परीक्षण करने पर ध्यान केंद्रित करता है।

निजी तरीके एक कार्यान्वयन विवरण हैं जो किसी भी पुन: कारक चक्र के दौरान बदल सकते हैं। इंटरफ़ेस या ब्लैक-बॉक्स व्यवहार को बदलने के बिना पुन: कारक होना संभव है । वास्तव में, यह टीडीडी के लाभ का हिस्सा है, जिस आसानी से आप यह विश्वास पैदा कर सकते हैं कि किसी वर्ग में आंतरिक परिवर्तन उस वर्ग के उपयोगकर्ताओं को प्रभावित नहीं करेगा।

खैर, मेरे लिए यह संभव है कि मैं एक ऐसी वस्तु बनाऊं जिसमें केवल निजी तरीके हों और उनकी घटनाओं को सुनकर अन्य वस्तुओं के साथ बातचीत करें। यह बहुत ही संक्षिप्त होगा, लेकिन पूरी तरह से अप्राप्य।

यहां तक ​​कि अगर क्लास में कोई सार्वजनिक तरीका नहीं है, तो यह इवेंट हैंडलर है, यह सार्वजनिक इंटरफ़ेस है , और यह उस सार्वजनिक इंटरफ़ेस के खिलाफ है जिसे आप परीक्षण कर सकते हैं।

चूँकि घटनाएँ इंटरफ़ेस हैं, तो यह वह घटनाएँ हैं जिन्हें आपको उस वस्तु का परीक्षण करने के लिए उत्पन्न करना होगा।

अपने परीक्षण प्रणाली के लिए गोंद के रूप में नकली वस्तुओं का उपयोग करें। एक साधारण मॉक ऑब्जेक्ट बनाना संभव होना चाहिए जो एक घटना उत्पन्न करता है और राज्य के परिणामी परिवर्तन को चुनता है (एक अन्य रिसीवर मॉक ऑब्जेक्ट द्वारा संभव है)।

इसके अलावा, परीक्षण के लिए तरीकों को जोड़ना बुरा व्यवहार माना जाता है।

बिल्कुल, आपको आंतरिक स्थिति को उजागर करने से बहुत सावधान रहना चाहिए ।

इसका मतलब यह है कि TDD एनकैप्सुलेशन के साथ बाधाओं पर है? उचित संतुलन क्या है?

बिलकुल नहीं।

टीडीडी को शायद आपकी कक्षाओं के कार्यान्वयन को बदलने की तुलना में उन्हें सरल नहीं करना चाहिए ( पहले के बिंदु से YAGNI को लागू करके )।

टीडीडी के साथ सबसे अच्छा अभ्यास टीडीडी के बिना सर्वोत्तम अभ्यास के समान है, आप बस यह पता लगा सकते हैं कि क्यों जल्दी, क्योंकि आप इंटरफ़ेस का उपयोग कर रहे हैं क्योंकि आप इसे विकसित कर रहे हैं।

मैं अपने सभी तरीकों को अब सार्वजनिक करने के लिए इच्छुक हूं ...

यह स्नान के पानी के साथ बच्चे को बाहर फेंकना होगा।

आपको सभी विधियों को सार्वजनिक करने की आवश्यकता नहीं है ताकि आप TDD तरीके से विकसित हो सकें। यह देखने के लिए कि मेरे निजी तरीके वास्तव में अप्राप्य हैं या नहीं, नीचे मेरे नोट्स देखें।

निजी तरीकों के परीक्षण पर एक अधिक विस्तृत नज़र

यदि आपको भाषा / परिवेश के आधार पर किसी कक्षा के कुछ निजी व्यवहार का परीक्षण करना चाहिए , तो आपके पास तीन विकल्प हो सकते हैं:

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

जाहिर है तीसरा विकल्प अब तक का सबसे अच्छा है।

1) आप जिस कक्षा में परीक्षा देना चाहते हैं, उसमें परीक्षाएँ डालें (आदर्श नहीं)

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

2) उन निजी तरीकों को उजागर करें जिन्हें आप सार्वजनिक तरीकों के रूप में परीक्षण करना चाहते हैं (वास्तव में एक अच्छा विचार नहीं)

जैसा कि यह सुझाव दिया गया है कि यह बहुत खराब अभ्यास है, इनकैप्सुलेशन को नष्ट करता है और कोड के उपयोगकर्ताओं के लिए आंतरिक कार्यान्वयन को उजागर करेगा ।

3) बेहतर परीक्षण वातावरण का उपयोग करें (सबसे अच्छा विकल्प, यदि यह उपलब्ध है)

ग्रहण की दुनिया में, 3. अंशों का उपयोग करके प्राप्त किया जा सकता है । C # दुनिया में, हम आंशिक वर्गों का उपयोग कर सकते हैं । अन्य भाषाओं / वातावरणों में अक्सर समान कार्यक्षमता होती है, बस आपको इसे खोजने की आवश्यकता है।

ब्लाइंडली मानने वाले 1. या 2. एकमात्र विकल्प हैं जिसके परिणामस्वरूप उत्पादन सॉफ्टवेयर को परीक्षण कोड या गंदा वर्ग इंटरफेस के साथ फूला हुआ होगा जो सार्वजनिक रूप से अपने गंदे लिनन को धोता है। * 8 ')

• सभी के सभी - यह बेहतर है कि निजी कार्यान्वयन के खिलाफ परीक्षण न करें।

Comments

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

— मैगस

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

— मैगस

एक ही पैकेज के साथ एक परीक्षण परियोजना में विधि को डिफ़ॉल्ट / संरक्षित और परीक्षण बनाने के बारे में क्या?

— रिचर्डकियर

@RichardCypher प्रभावी रूप से 2 के रूप में एक ही है) क्योंकि आप बदल रहे हैं कि आपकी विधि चश्मा आदर्श रूप से आपके परीक्षण वातावरण में कमी को समायोजित करने के लिए होगा, इसलिए निश्चित रूप से अभी भी खराब अभ्यास।

— मार्क बूथ

Answer 2

बेशक आपके पास निजी तरीके हो सकते हैं, और निश्चित रूप से आप उनका परीक्षण कर सकते हैं।

या तो वहाँ है कुछ रास्ता चलाने के लिए निजी विधि प्राप्त करने के लिए, इस स्थिति में आप इसे उस तरह से परीक्षण कर सकते हैं, या वहाँ कोई चलाने के लिए निजी प्राप्त करने के लिए जिस तरह से, जिस स्थिति में: क्यों हो तुम यह परीक्षण करने के लिए कोशिश कर रहे हैं, बस धिक्कार है!

आपके उदाहरण में:

खैर, मेरे लिए यह संभव है कि मैं एक ऐसी वस्तु बनाऊं जिसमें केवल निजी तरीके हों और उनकी घटनाओं को सुनकर अन्य वस्तुओं के साथ बातचीत करें। यह बहुत ही संक्षिप्त होगा, लेकिन पूरी तरह से अप्राप्य।

ऐसा क्यों होगा? यदि किसी ईवेंट की प्रतिक्रिया में विधि को लागू किया जाता है, तो परीक्षण में ऑब्जेक्ट को एक उपयुक्त ईवेंट फ़ीड करना होगा।

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

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

इसलिए, आमतौर पर निजी तरीके केवल तब दिखाई देते हैं जब उन्हें पहले से ही परीक्षण किए गए सार्वजनिक तरीकों से निकाला जाता है और इस प्रकार पहले से ही परीक्षण किया जाता है।

Comments

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

— दान नीली

बड़े, जटिल निजी तरीके एक कोड गंध हैं। एक कार्यान्वयन जो इतना जटिल है कि इसे घटक भागों (सार्वजनिक इंटरफेस के साथ) में उपयोगी रूप से विघटित नहीं किया जा सकता है, परीक्षण क्षमता में एक समस्या है जो संभावित डिजाइन और वास्तु संबंधी समस्याओं को प्रकट करता है। जिन मामलों में निजी कोड बहुत बड़ा है, उनमें से 1% आमतौर पर rework से विघटित और उजागर होने से लाभान्वित होंगे।

— एस.लॉट

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

— बिल के

कक्षाओं internalमें कम से कम तरीकों या सार्वजनिक तरीकों को internalअक्सर काफी सीधे परीक्षण किया जाना चाहिए। सौभाग्य से .net इसका समर्थन करता है InternalsVisibleToAttribute, लेकिन इसके बिना, उन तरीकों का परीक्षण एक PITA होगा।

— कोडइन्चोस

Answer 3

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

परीक्षणों के माध्यम से, हम यह सत्यापित करते हैं कि कोड वह करता है जो वह करने की उम्मीद करता है , अपेक्षित होने पर उपयुक्त अपवाद फेंकता है, आदि हमें वास्तव में परवाह नहीं है कि कोड डेवलपर द्वारा कैसे लागू किया जाता है। हालांकि हम कार्यान्वयन के बारे में परवाह नहीं करते हैं, अर्थात कोड यह कैसे करता है, यह निजी तरीकों के परीक्षण से बचने के लिए समझ में आता है।

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

अंतिम लेकिन कम से कम, कुछ मामलों में यह निजी तरीकों का परीक्षण करने के लिए पूरी तरह से वैध है। यही कारण है कि .NET में उदाहरण के लिए, आप न केवल सार्वजनिक, बल्कि निजी कक्षाओं का भी परीक्षण कर सकते हैं, भले ही समाधान सार्वजनिक तरीकों की तरह सीधा न हो।

Comments

+1 टीडीडी की एक महत्वपूर्ण विशेषता यह है कि यह आपको यह परखने के लिए मजबूर करता है कि आवश्यकताएँ पूरी हो गई हैं, बजाय कि परीक्षण के कि वे क्या करते हैं, वे सोचते हैं। तो प्रश्न "क्या मैं एक निजी पद्धति का परीक्षण कर सकता हूं" यह टीडीडी की भावना के विपरीत है - प्रश्न इसके बजाय "क्या मैं एक आवश्यकता का परीक्षण कर सकता हूं जिसके कार्यान्वयन में निजी विधियां शामिल हैं"। और इस प्रश्न का उत्तर स्पष्ट रूप से हाँ है।

— दाऊद इब्न करीम

Answer 4

यह मेरी समझ है कि निजी तरीके अप्राप्य हैं

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

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

यही कारण है कि मैं कोबर्टा और एनसीओवर का बहुत उपयोग करता हूं, यह सुनिश्चित करने के लिए कि मेरी सार्वजनिक पद्धति का परीक्षण निजी तरीकों को भी कवर करता है। निजी तरीकों से अच्छी OO ऑब्जेक्ट लिखने के लिए स्वतंत्र महसूस करें और ऐसे मामले में TDD / परीक्षण को अपने रास्ते में न आने दें।

Answer 5

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

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

Comments

यह एक महान विचार है - "... कारखाना है जो ऑब्जेक्ट तार को घटनाओं को सार्वजनिक तरीकों से बनाता है। यह परीक्षण करना आसान है, और यह बाहरी रूप से दिखाई देता है कि किस प्रकार की घटनाओं के लिए CUT को परीक्षण करने की आवश्यकता है। "

— पिल्ला

Answer 6

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

ये वे चीजें हैं जो मैं काम करने योग्य संतुलन के लिए प्रयास करने और उन्हें स्वीकार करने के लिए ध्यान में रखता हूं।

1. आपके द्वारा उपयोग की जाने वाली निजी विधियों और गुणों की संख्या कम से कम करें। अधिकांश सामान जो आपको अपनी कक्षा की आवश्यकता है, वैसे भी सार्वजनिक रूप से उजागर करने की आवश्यकता है, इसलिए इस बारे में सोचें कि क्या आपको वास्तव में उस चतुर पद्धति को निजी बनाने की आवश्यकता है।
2. अपने निजी तरीकों में कोड के संशोधन को कम से कम करें - आपको वास्तव में वैसे भी ऐसा करना चाहिए - और परोक्ष रूप से परीक्षण करें जहां आप अन्य तरीकों के व्यवहार के माध्यम से कर सकते हैं। आप कभी भी 100% परीक्षण कवरेज प्राप्त करने की उम्मीद नहीं करते हैं, और शायद आपको डीबगर के माध्यम से कुछ मूल्यों की जांच करने की आवश्यकता होगी। अपवादों को फेंकने के लिए निजी तरीकों का उपयोग करके आसानी से अप्रत्यक्ष रूप से परीक्षण किया जा सकता है। निजी गुणों को मैन्युअल रूप से या किसी अन्य विधि के माध्यम से जांचने की आवश्यकता हो सकती है।
3. यदि अप्रत्यक्ष या मैनुअल चेकिंग आपके साथ अच्छी तरह से नहीं बैठती है, तो कुछ निजी सामान को उजागर करने के लिए एक इंटरफेस के माध्यम से एक संरक्षित घटना और एक्सेस जोड़ें। यह प्रभावी रूप से एनकैप्सुलेशन के नियमों को "झुकता" करता है, लेकिन वास्तव में जहाज कोड की आवश्यकता को टालता है जो आपके परीक्षणों को निष्पादित करता है। दोष यह है कि यह सुनिश्चित करने के लिए थोड़ा अतिरिक्त आंतरिक कोड हो सकता है कि घटना को आवश्यक होने पर निकाल दिया जाएगा।
4. यदि आपको लगता है कि एक सार्वजनिक विधि पर्याप्त "सुरक्षित" नहीं है, तो देखें कि क्या तरीके हैं जिनसे आप अपने उपयोग के तरीके को सीमित करने के लिए अपने तरीकों में कुछ सत्यापन प्रक्रिया को लागू कर सकते हैं। संभावना है कि जब आप यह सोच रहे हों या तो अपने तरीकों को लागू करने के लिए बेहतर तरीके से सोचें, या आप आकार लेने के लिए दूसरी कक्षा की शुरुआत देखेंगे।
5. यदि आपके पास अपने सार्वजनिक तरीकों के लिए "सामान" करने के लिए बहुत सारे निजी तरीके हैं, तो एक नया वर्ग निकाला जा सकता है। आप इसे सीधे एक अलग वर्ग के रूप में परख सकते हैं, लेकिन इसे उपयोग करने वाले वर्ग के भीतर एक समग्र रूप से लागू कर सकते हैं।

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

Answer 7

खैर, मेरे लिए यह संभव है कि मैं एक ऐसी वस्तु बनाऊं जिसमें केवल निजी तरीके हों और उनकी घटनाओं को सुनकर अन्य वस्तुओं के साथ बातचीत करें। यह बहुत ही संक्षिप्त होगा, लेकिन पूरी तरह से अप्राप्य।

यह वस्तु उन घटनाओं पर कैसे प्रतिक्रिया करती है? संभवतः, इसे अन्य वस्तुओं पर तरीकों को लागू करना चाहिए। आप यह जांच कर सकते हैं कि क्या उन तरीकों को बुलाया जाता है। क्या यह एक मॉक ऑब्जेक्ट है और फिर आप आसानी से दावा कर सकते हैं कि यह वही करता है जो आप उम्मीद करते हैं।

मुद्दा यह है कि हम केवल ऑब्जेक्ट की अन्य वस्तुओं के साथ बातचीत का परीक्षण करना चाहते हैं। हमें परवाह नहीं है कि किसी वस्तु के अंदर क्या चल रहा है। तो नहीं, आपके पास पहले और कोई सार्वजनिक तरीके नहीं होने चाहिए।

Answer 8

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

Answer 9

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

Comments

... यह मानते हुए जावा है।

— दाऊद इब्न करीम

या internal.नेट

— कोडइन्चोस

Answer 10

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

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

Answer 11

इसका मतलब यह है कि TDD एनकैप्सुलेशन के साथ बाधाओं पर है? उचित संतुलन क्या है? मैं अब अपने सभी तरीकों को सार्वजनिक करने के लिए इच्छुक हूं।

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

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

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

Answer 12

प्रयोग करने से बचें? नहीं। शुरू करने से
बचें ? हाँ।

मुझे लगता है कि आपने इस बारे में नहीं पूछा कि क्या टीडीडी के साथ सार कक्षाएं होना ठीक है; यदि आप समझते हैं कि टीडीडी के दौरान सार कक्षाएं कैसे उभरती हैं, तो यही सिद्धांत निजी तरीकों पर भी लागू होता है।

आप अमूर्त कक्षाओं में सीधे तरीकों का परीक्षण नहीं कर सकते हैं जैसे आप सीधे निजी तरीकों का परीक्षण नहीं कर सकते हैं, लेकिन यही कारण है कि आप अमूर्त कक्षाओं और निजी तरीकों से शुरू नहीं करते हैं; आप ठोस कक्षाओं और सार्वजनिक एपीआई से शुरू करते हैं, और फिर आप जाते ही सामान्य कार्यक्षमता को रिफलेक्टर करते हैं।