मैं एक निजी विधि का परीक्षण करना चाहता हूं - क्या मेरे डिजाइन में कुछ गड़बड़ है?

Question

तो मैं सॉफ्टवेयर परीक्षण के लिए बेहद नया हूं, और अपने अनुप्रयोगों में से एक को दो परीक्षण जोड़ने पर विचार कर रहा हूं। मेरे पास एक सार्वजनिक विधि addKeywords() है जिस तरह से एक निजी विधि को हटाएं InvalidOperations()। यह निजी विधि बाहरी एपीआई को कॉल करती है और कोड की ~ 50 लाइनें होती है। जैसा कि मैंने इसे कुछ जटिल विधि माना है, मैं addKeyword() विधि को कॉल करके ऐसा करने के बिना इसका परीक्षण करना चाहता हूं। फिर भी यह संभव नहीं प्रतीत होता है (कम से कम जुनीट हालांकि नहीं)।

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

मुझे सच में नहीं लगता कि मुझे अपने वर्तमान कोड डिज़ाइन में कोई समस्या क्यों है, लेकिन मेरे परीक्षण कोड को संपादित करने के लिए मेरे उत्पादन कोड को संपादित करने के विचार को भी पसंद नहीं है।

जैसा कि मैंने कहा - मैं परीक्षण करने के लिए नया हूं, इसलिए किसी भी मदद की बहुत सराहना की जाती है। साथ ही, कृपया मुझे बताएं कि क्या कोई और जानकारी है जो मैं उत्तर के साथ मदद करने के लिए प्रदान कर सकता हूं।

Answer 1

मैं इसे पुन: सक्रिय करने का सुझाव देता हूं।

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

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

class YourClass 
{ 
    private OperationRemover remover; 

    public void addKeywords() { 
     // whatever 
     removeInvalidOperations(); 
    } 

    private void removeInvalidOperations() { 
     remover.remove(); 
    } 
} 

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

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

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

असली दुनिया का उदाहरण: वर्ष 2007 है और आप संयुक्त राज्य अमेरिका में एक बड़े वित्तीय केंद्र में बैंक के लिए काम करते हैं। आपके आवेदन को खाता जानकारी का उपयोग करने की आवश्यकता है। आपका कोड बैंक के अंदर किसी प्रकार की वेब सेवा तक पहुंच जाता है और इसकी आवश्यकता के आकार में आवश्यक जानकारी प्राप्त करता है, फिर इसके प्रसंस्करण के बारे में चलता है। 2008 में, अमेरिकी वित्तीय क्षेत्र implodes, और आपके बैंक (जो पतन के कगार पर है) एक और बैंक द्वारा gobbled है। आपका आवेदन बचाया गया है, सिवाय इसके कि आपको एक अलग एपीआई तक पहुंचना है जो पहले से ही जीवित बैंक के भीतर मौजूद है, वहां से खाता जानकारी प्राप्त करने के लिए। क्या इस खाते की जानकारी का उपभोग करने वाला कोड बदलना चाहिए? जरुरी नहीं। यह पहले से ही एक अलग स्रोत से एक ही खाता जानकारी है। नहीं, सभी को बदलने की जरूरत है एपीआई का आह्वान कार्यान्वयन। उपभोग कोड को कभी नहीं पता होना चाहिए।

तथ्य यह है कि इस तरह के ढीले युग्मन परीक्षण को बढ़ावा देता है और सुविधा प्रदान करता है एक बोनस है।

Answer 2

यदि यह private है, तो इसे आपके एप्लिकेशन के एपीआई का हिस्सा नहीं माना जा सकता है, इसलिए परीक्षण वास्तव में एक कोड गंध है - जब परीक्षण टूट जाता है, तो क्या यह ठीक है या नहीं?

यूनिट परीक्षण कार्यक्षमता उन्मुख होना चाहिए, कोड उन्मुख नहीं है। आप कार्यक्षमता की इकाइयों का परीक्षण करते हैं, न कि कोड की इकाइयां।

दर्शन के बावजूद, आपके कार्यान्वयन के बाहर एक वर्ग JVM को हैक किए बिना निजी विधि तक नहीं पहुंच सकता है, इसलिए आप भाग्य से बाहर हैं - आपको या तो विधि की दृश्यता बदलनी है, protected परीक्षण API इकाई परीक्षण वर्ग का उपयोग करने के सार्वजनिक तरीकों को बुलाकर अप्रत्यक्ष रूप से कार्य का विस्तार करता है, या परीक्षण करता है।

Answer 3

यदि आप addKeywords() पर कॉल नहीं करना चाहते हैं, तो शायद आपको एक और सार्वजनिक विधि testRemoveInvalidOperations() जोड़नी चाहिए, जो केवल निजी removeInvalidOperations() पर कॉल करे। आप बाद की तारीख में परीक्षण को हटा सकते हैं।

Answer 4

आमतौर पर आप एक निजी विधि का परीक्षण नहीं करना चाहते हैं, लेकिन अपवाद हैं।

1. आप कैसे मौजूदा सार्वजनिक तरीकों को फोन करके परोक्ष रूप से निजी विधि का परीक्षण करने के बारे में ध्यान से नहीं सोचा:

   आप एक निजी विधि अगर परीक्षण करने के लिए परीक्षा हो सकती है।

2. आपकी कक्षा का एपीआई बहुत लचीला है। सार्वजनिक तरीकों को पैरामीटर की आवश्यकता है, या कुछ निजी तरीकों को सार्वजनिक करने की आवश्यकता है।

3. आपकी कक्षा का एपीआई पर्याप्त लचीला है, लेकिन जनता के नीचे विधियों के नीचे पर कुछ जटिल निजी विधियां चल रही हैं।

आपके प्रश्न के आधार पर, आप इनमें से किसी भी मामले में हो सकते हैं।

के लिए (1), जाहिर है कि आपको पहले मौजूदा सार्वजनिक तरीकों के साथ अपनी निजी विधि का परीक्षण करने का तरीका ढूंढने का प्रयास करना चाहिए।

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

(3) वह मामला है जहां निजी तरीकों का परीक्षण करना ठीक है। विभिन्न tricks for that हैं। उत्पादन कोड के लिए, ये एपीआई उपयोगकर्ता (इसे सार्वजनिक बनाने) में अपनी विधि को उजागर करने से बेहतर हैं ताकि आप इसका परीक्षण कर सकें। या 2 वर्गों में संबंधित कार्यक्षमता को विभाजित करना ताकि आप इसका परीक्षण कर सकें।

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

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