यूनिट परीक्षण निजी विधियों के लिए लागू

Question

मैं वर्तमान में कुछ फूरियर ट्रांसफॉर्मेशन करने के लिए कुछ कक्षाएं बनाने की कोशिश कर रहा हूं। मैं पहले कुछ यूनिट परीक्षण बनाकर ऐसा करने की कोशिश कर रहा हूं, फिर मूल कार्यक्षमता बनाएं।

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

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

आप इससे कैसे निपटते हैं?

Answer 1

2 संभव तरीके देखें:

1. यदि संभव हो तो - एक और वर्ग के लिए एल्गोरिथ्म कार्यान्वयन स्थानांतरित करने के लिए और यह तरीकों को विभाजित कर दिया। परीक्षण के बाद के तरीके।
2. बस सामान्य परीक्षण, किनारे के मामलों और त्रुटि मामलों को कवर करने वाले परीक्षणों का एक समूह लिखें।

Answer 2

मैं हाल ही में "एक इकाई क्या है" से जूझ रहा हूं? जो वास्तव में एक मुश्किल सवाल है।

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

एक ही बात कहने का एक और तरीका उप-इकाई वास्तव में एक इकाई है जिसका सेवाओं का उपयोग एफएफटी द्वारा किया जाता है, और फिर आप कोई नियम तोड़ नहीं रहे हैं।

Answer 3

मुझे लगता है कि अगर आप अपने एल्गोरिदम के अलग-अलग घटकों का परीक्षण नहीं कर पा रहे हैं, तो कोड बहुत कसकर युग्मित है या कोड बहुत प्रक्रियात्मक है।

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

Answer 4

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

क्या कोई तरीका है कि आप कुछ मूल्यों के एल्गोरिदमिक सत्यापन कर सकते हैं, जैसे किसी ज्ञात-अच्छे दिनचर्या को कॉल करना, कुछ प्रमुख फूरियर से संबंधित पहचान का उपयोग करना, या शायद 0 एफकरने के लिए अपने एफएफटी का उपयोग करना?