संभावना से अधिक, आप परीक्षण के तहत सिस्टम में इनपुट के सभी संभावित संयोजनों की गणना करके या साइक्लोमैटिक जटिलता की गणना करके और इन अद्वितीय निष्पादन पथों में से प्रत्येक के लिए एक परीक्षण लिखा होना चाहिए, 65 बिलियन परीक्षणों के आपके आंकड़े पर पहुंचे।
ऐसा नहीं है कि वास्तविक परीक्षण कैसे लिखे जाते हैं, क्योंकि जैसा कि अन्य पोस्टरों और टिप्पणीकारों ने संकेत दिया है, 65 अरब को निष्पादित करने के लिए आवश्यक तकनीकी शक्तिपरीक्षण चौंका देने वाला है। यह एक परीक्षण लिखने जैसा होगा जो दो 32-बिट मानों के हर संभावित क्रम में प्लग इन करके और परिणाम की जांच करके दो पूर्णांकों को जोड़ने की विधि का अभ्यास करता है। यह पूरी तरह पागलपन है। आपको लाइन खींचनी होगी और सभी संभावित परीक्षण मामलों के एक सबसेट की पहचान करनी होगी, जो उनके बीच यह सुनिश्चित करेगा कि सिस्टम इनपुट की पूरी सीमा में अपेक्षित व्यवहार करेगा। उदाहरण के लिए। आप कुछ "साधारण" संख्याओं को जोड़कर परीक्षण करते हैं, आप कुछ नकारात्मक-संख्या परिदृश्यों का परीक्षण करते हैं, आप तकनीकी सीमाओं जैसे अतिप्रवाह परिदृश्यों का परीक्षण करते हैं, और आप किसी भी परिदृश्य का परीक्षण करते हैं, जिसके परिणामस्वरूप त्रुटि होनी चाहिए। जैसा कि उल्लेख किया गया था, ये विभिन्न प्रकार के परीक्षण "समतुल्यता वर्ग" का प्रयोग करते हैं; वे आपको किसी भी ज्ञात "आउटलेर" के साथ संभावित इनपुट का प्रतिनिधि नमूना लेने की अनुमति देते हैं:
मूल कोड कटाओं में से एक पर विचार करें, रोमन अंक जेनरेटर। टाडीडी तकनीकों का उपयोग "डोजो" शैली में किया जाने वाला कार्य, एक फ़ंक्शन लिखना है जो किसी भी संख्या को 1 से 3000 तक स्वीकार कर सकता है और उस संख्या मान के लिए सही रोमन अंक का उत्पादन कर सकता है।
आप एक बार में 3000 यूनिट परीक्षण, एक बार लिखकर, और उन्हें पास करके इस समस्या को हल नहीं करते हैं। वह लंपट है; व्यायाम आम तौर पर एक और दो घंटे के बीच होता है, और आप प्रत्येक व्यक्तिगत मूल्य का परीक्षण करने वाले दिनों के लिए होंगे। इसके बजाय, आप स्मार्ट हो जाओ। आप सबसे सरल आधार मामले (1 == "मैं") से शुरू करते हैं, "न्यूनतम-कोड" रणनीति ( return "I";) का उपयोग करके कार्यान्वित करते हैं , और फिर यह देखते हैं कि आपके पास जो कोड है वह किसी अन्य अपेक्षित परिदृश्य में गलत व्यवहार करेगा (2 ==) द्वितीय ")। धोये और दोहराएं; संभावना से अधिक, आपने अपने प्रारंभिक कार्यान्वयन को किसी ऐसे चीज़ से बदल दिया जो "I" वर्ण को जितनी बार आवश्यक हो (जैसे return new String('I',number);) दोहराता है । यह स्पष्ट रूप से III के लिए एक परीक्षा उत्तीर्ण करेगा, ताकि आप परेशान न हों; इसके बजाय, आप 4 == "IV" के लिए परीक्षण लिखते हैं, जिसे आप जानते हैं कि वर्तमान कार्यान्वयन जीता है '
या, अधिक विश्लेषणात्मक शैली में, आप प्रत्येक सशर्त निर्णय की जांच करते हैं जो कोड द्वारा किया जाता है (या होना चाहिए), और प्रत्येक निर्णय के प्रत्येक संभावित परिणाम के लिए कोड दर्ज करने के लिए डिज़ाइन किया गया परीक्षण लिखें। यदि आपके पास 5 हैं यदि कथन (प्रत्येक के पास एक सच्ची और झूठी शाखा है), उनमें से प्रत्येक पूरी तरह से दूसरे से स्वतंत्र है, तो आप 10 परीक्षणों को कोड करते हैं, 32 को नहीं। प्रत्येक परीक्षण को किसी विशेष संभावित निर्णय के बारे में दो बातों का दावा करने के लिए डिज़ाइन किया जाएगा; पहले कि सही निर्णय किया गया है, और फिर उस स्थिति को देखते हुए दर्ज किया गया कोड सही है। आप स्वतंत्र निर्णयों के प्रत्येक संभावित क्रमांकन के लिए एक परीक्षण को कोड नहीं करते हैं । यदि निर्णय निर्भर हैं, तो आपको संयोजन में उनमें से अधिक का परीक्षण करना होगा, लेकिन ऐसे संयोजन बहुत कम हैं क्योंकि कुछ निर्णय केवल तब किए जाते हैं जब किसी अन्य निर्णय का एक विशेष परिणाम होता है।