इसमें से टेकवे फेल फास्ट है ।
हमारे पास कोड नहीं है, और न ही हमारे पास उपसर्गों के कई उदाहरण हैं जो कोड के अनुसार शाखा उपसर्ग हैं या नहीं। हमारे पास यह है:
- 089 - 100 => परीक्षण शाखा
- 10 बी, 10 सी => परीक्षण शाखा
- <088 => संभवतः वास्तविक शाखाएँ
- > 100 => संभवतः वास्तविक शाखाएँ
तथ्य यह है कि कोड संख्याओं की अनुमति देता है और तार थोड़ा अजीब से अधिक है। बेशक, 10B और 10C को हेक्स संख्या माना जा सकता है, लेकिन अगर उपसर्गों को सभी हेक्स संख्याओं के रूप में माना जाता है, तो 10B और 10C परीक्षण सीमा से बाहर हो जाते हैं और उन्हें वास्तविक शाखाओं के रूप में माना जाएगा।
इस संभावना का मतलब है कि उपसर्ग को एक स्ट्रिंग के रूप में संग्रहीत किया जाता है लेकिन कुछ मामलों में संख्या के रूप में माना जाता है। यहाँ सबसे सरल कोड है जो मैं सोच सकता हूँ कि इस व्यवहार की नकल करता है (उदाहरण के लिए C # का उपयोग करके):
bool IsTest(string strPrefix) {
int iPrefix;
if(int.TryParse(strPrefix, out iPrefix))
return iPrefix >= 89 && iPrefix <= 100;
return true; //here is the problem
}
अंग्रेजी में, यदि स्ट्रिंग एक संख्या है और 89 और 100 के बीच है, तो यह एक परीक्षण है। यदि यह एक संख्या नहीं है, तो यह एक परीक्षण है। अन्यथा यह एक परीक्षण नहीं है।
यदि कोड इस पैटर्न का अनुसरण करता है, तो जिस समय कोड तैनात किया गया था, उस समय कोई इकाई परीक्षण ने इसे नहीं पकड़ा होगा। यहाँ कुछ उदाहरण इकाई परीक्षण हैं:
assert.isFalse(IsTest("088"))
assert.isTrue(IsTest("089"))
assert.isTrue(IsTest("095"))
assert.isTrue(IsTest("100"))
assert.isFalse(IsTest("101"))
assert.isTrue(IsTest("10B")) // <--- business rule change
यूनिट टेस्ट से पता चलता है कि "10 बी" को एक परीक्षण शाखा के रूप में माना जाना चाहिए। उपर्युक्त उपयोगकर्ता @ gnasher729 का कहना है कि व्यवसाय के नियम बदल गए हैं और यही ऊपर के अंतिम दावे से पता चलता है। कुछ बिंदु पर जो मुखर होना चाहिए एक में बदल गया है isFalse, लेकिन ऐसा नहीं हुआ। इकाई परीक्षण विकास और निर्माण-समय पर चलते हैं, लेकिन बाद में बिना किसी बिंदु पर।
यहाँ क्या सबक है? कोड को यह संकेत देने के लिए किसी तरह की आवश्यकता है कि उसे अप्रत्याशित इनपुट मिले। इस कोड को लिखने का एक वैकल्पिक तरीका है जो इस बात पर जोर देता है कि यह उपसर्ग को एक संख्या होने की उम्मीद करता है:
// Alternative A
bool TryGetIsTest(string strPrefix, out bool isTest) {
int iPrefix;
if(int.TryParse(strPrefix, out iPrefix)) {
isTest = iPrefix >= 89 && iPrefix <= 100;
return true;
}
isTest = true; //this is just some value that won't be read
return false;
}
जो लोग सी # नहीं जानते हैं, उनके लिए रिटर्न वैल्यू इंगित करता है कि कोड दिए गए स्ट्रिंग से एक उपसर्ग पार्स करने में सक्षम था या नहीं। यदि रिटर्न वैल्यू सही है, तो कॉलिंग कोड का उपयोग कर सकते हैं कि क्या शाखा उपसर्ग एक परीक्षण उपसर्ग है, यह जांचने के लिए चर का उपयोग कर सकते हैं। यदि रिटर्न मान गलत है, तो कॉलिंग कोड को रिपोर्ट करना चाहिए कि दिए गए उपसर्ग अपेक्षित नहीं है, और सबसे बाहर का चर अर्थहीन है और इसे अनदेखा किया जाना चाहिए।
यदि आप अपवादों के साथ ठीक हैं, तो आप इसके बजाय ऐसा कर सकते हैं:
// Alternative B
bool IsTest(string strPrefix) {
int iPrefix = int.Parse(strPrefix);
return iPrefix >= 89 && iPrefix <= 100;
}
यह विकल्प अधिक सीधा है। इस मामले में, कॉलिंग कोड को अपवाद को पकड़ने की आवश्यकता है। या तो मामले में, कोड में कॉलर को रिपोर्ट करने का कुछ तरीका होना चाहिए कि यह एक स्ट्रेपफिक्स की उम्मीद नहीं करता है जिसे एक पूर्णांक में परिवर्तित नहीं किया जा सकता है। इस तरह से कोड तेजी से विफल हो जाता है और बैंक एसईसी फाइन शर्मिंदगी के बिना समस्या का तुरंत पता लगा सकता है।