तक पहुँचने के लिए जब भी मैं condition की तरह पुन: पेश करने कोड है कि अन्यथा केवल एक मुश्किल के तहत पहुँचा जा होगा की एक निश्चित पथ का प्रयोग करना चाहते हैं: मैं एक true मूल्य के साथ यह orपरीक्षण एक मुश्किल कोड पथ
if (condition) { code to be tested }
:
if (true || condition) { code to be tested }
क्या कोई और सुरुचिपूर्ण दृष्टिकोण है?
मुझे लगता है कि अधिक elegant way रूप the logical negation operator (!) उपयोग कर रहा है;
if (!condition) { code to be tested }
आप (मेरे commet के अनुसार) एक पूर्वप्रक्रमक निर्देश उपयोग कर सकते हैं डिबगिंग या परीक्षण प्रयोजनों के लिए और अधिक सुरक्षित तरीका लेकिन। जब आप परीक्षण समाप्त बस हटाने या बदलने #define UnreachableTest
#define UnreachableTest //should be on the top of the class/page
#if (UnreachableTest)
condition = !condition; //or
condition = true;
#endif
if (condition) { code to be tested }
हाँ यह मुझे और अधिक दिखता है सुरुचिपूर्ण। एकमात्र पकड़ के साथ कि स्थिति पूरी होने पर यह काम नहीं करेगी। लेकिन मुझे यह पसंद है और मुझे लगता है कि यह ज्यादातर उपयोग मामलों में अच्छा होगा। –
उस स्थिति में आप डीबग के दौरान परीक्षण उद्देश्य के लिए स्थिति बदलने के लिए 'प्रीप्रोसेसर निर्देश' का उपयोग कर सकते हैं। जैसा; शीर्ष पर '# पहुंच योग्य नहीं है' ... '#if (पहुंचने योग्य टेस्ट) स्थिति =! स्थिति # endif' फिर आपका वास्तविक कोड अनुसरण करने के लिए। – Kaf
क्षमा करें मुझे इस उत्तर पर -1 देना होगा। परीक्षण करने के लिए तार्किक स्थिति को बदलने के लिए यह एक बहुत ही खराब कोड गंध है। यह खतरनाक है क्योंकि इससे किसी को "!" को हटाने के लिए भूल जाना पड़ सकता है और उत्पादन कोड के साथ समाप्त हो गया है जिसमें स्थिति फिसल गई है और त्रुटियां/बग बना रही हैं। –
अधिक सुरुचिपूर्ण समाधान मैक्स का उपयोग कर रहा है। परीक्षण के अंतर्गत
var mock = new Mock<IFoo>();
mock.Setup(foo => foo.IsBar).Returns(true);
var sut = new Sut(mock.Object);
sut.DoSomething();
और आपके सिस्टम में: निर्भरता या मापदंडों के आधार पर निर्णय लेने के लिए
public void DoSomething()
{
if (_foo.IsBar)
// code path to test
}
पोस्ट करने से पहले प्रश्न पढ़ें - 'कोड के एक निश्चित पथ का प्रयोग करना चाहते हैं जो अन्यथा केवल स्थिति को पुन: पेश करने में मुश्किल हो जाएगा' ओपी लक्ष्य 'if' के अंदर कोड का परीक्षण करना है, यानी 100% मौका – Nogard
@Nogard के साथ वहां जाना है मैंने मोजे के उपयोग का जिक्र किया। और कोड नमूना जोड़ा गया। टिप्पणी करने से पहले अंत का जवाब पढ़ें। –
निश्चित रूप से मैंने इसे देखा, लेकिन आपका पूर्व-संपादित उत्तर (जिसे मैंने टिप्पणी की) ने कहा कि 'स्थिति को पुन: उत्पन्न करना मुश्किल है' - मॉकिंग भी इसका उपयोग कर सकता है। फिर नकली नमूना जोड़ा गया था और यह ओपी मुद्दा हल करता है। – Nogard
मैं मान लेंगे इस एक इकाई परीक्षण परिदृश्य के बाद से यह प्रश्न में उल्लेख नहीं किया गया था। इस तरह के कोड के ऑन-द-फ्लाई परीक्षण करने का सबसे आसान तरीका डीबगर के सेट नेक्स्ट स्टेटमेंट कमांड का उपयोग कर है।
यदि आवश्यक हो, तो if() कथन पर ब्रेकपॉइंट सेट करें, या उस कथन तक पहुंचने तक कोड को तब तक सेट करें। फिर if() कथन निकाय के अंदर, अगली पंक्ति पर राइट-क्लिक करें, और "अगला स्टेटमेंट सेट करें" का चयन करें। कोड उस लाइन पर निष्पादन फिर से शुरू करेगा, पूरी तरह से if() को छोड़ देगा।
अच्छा +1। मैं निश्चित रूप से इसका उपयोग करूँगा। लेकिन इस विशिष्ट मामले में जहां मैं कम से कम कुछ बार उस पथ को चलाने के लिए चाहता हूं यह अजीब है। –
आपका दृष्टिकोण, "सत्य या" के साथ, और यदि (! स्थिति) का दृष्टिकोण सबसे सरल है। यहां एक दृष्टिकोण है जो मुझे बड़े कार्यक्रमों के लिए पसंद है
फ़ंक्शन बनाएं, चलिए इसे testme (const string) कहते हैं। और यदि परीक्षण में सत्य डालने की बजाय, आप टेस्टमे डालें, कुछ स्ट्रिंग के साथ जो कोड के उस टुकड़े की पहचान करता है।
if (testme("Location 123") || condition) { code to be tested }
फिर, अपने कार्यक्रम (i config पसंद करते हैं) के लिए कॉन्फ़िग फ़ाइल किसी तरह का, या तर्कों का उपयोग, आप पूरी तरह से नियंत्रित करती हैं कि testme ("स्थान 123") सही वापस आ जाएगी कर सकते हैं। और आप कई स्थानों पर एक ही फ़ंक्शन का उपयोग कर सकते हैं। प्रत्येक का परीक्षण करने के लिए बस कॉन्फ़िगरेशन फ़ाइल बदलें।
+1। मैं उस उद्देश्य के लिए कहीं और परिभाषित एक बुलियन वैरिएबल का उपयोग कर रहा हूं। –
कोड को एक अलग विधि में जांचने के लिए रखें। फिर आप विधि को कॉल कर सकते हैं और सशर्त बाईपास कर सकते हैं। अब आपको इसे "सत्य" जोड़ने के बारे में चिंता करने की आवश्यकता नहीं होगी या इसे हटाने के लिए और अधिक महत्वपूर्ण रूप से भूलना होगा।
आप विधि के लिए यूनिट परीक्षण भी जोड़ सकते हैं ताकि आप इसमें पारित पैरामीटर को संशोधित कर सकें और अपने इच्छित परिदृश्यों का परीक्षण कर सकें।
क्या आप डीबगर के माध्यम से कोड चलाने की कोशिश कर रहे हैं? मैं सलाह देता हूं कि यह 'यूनिट परीक्षण' की तलाश में है। एक मॉकिंग समाधान आपके कोड को टेस्ट करने योग्य बनाने में मदद कर सकता है।इसे यूनिट टेस्ट के रूप में लिखकर आप न केवल अपने कोड का परीक्षण कर सकते हैं, लेकिन आपको परीक्षा भी मिलनी है! –