इसके बहुत से कारण हैं। एरिक लिपर्ट ने कई बार कहा है कि इसका कारण feature XC # में नहीं है क्योंकि यह उनके बजट में नहीं है। भाषा डिजाइनरों के पास चीजों को लागू करने के लिए न तो अनंत समय होता है और न ही पैसा, और प्रत्येक नई सुविधा के साथ रखरखाव की लागत होती है। भाषा को यथासंभव छोटा रखना भाषा डिजाइनरों के लिए आसान नहीं है - यह वैकल्पिक कार्यान्वयन और उपकरण लिखने वाले किसी भी व्यक्ति के लिए भी आसान है (उदाहरण के लिए IDEs) इसके अलावा, जब किसी चीज को उसके हिस्से के बजाय भाषा के संदर्भ में लागू किया जाता है, तो आपको मिलता है मुक्त करने के लिए पोर्टेबिलिटी। यदि इकाई परीक्षण एक पुस्तकालय के रूप में लागू हो रहा है, तो आपको इसे केवल एक बार लिखने की आवश्यकता है और यह भाषा के किसी भी अनुरूप कार्यान्वयन में काम करेगा।
यह ध्यान देने योग्य है कि डी में यूनिट परीक्षण के लिए सिंटैक्स-स्तरीय समर्थन है । मुझे नहीं पता कि उन्होंने इसे क्यों फेंकने का फैसला किया, लेकिन यह ध्यान देने योग्य है कि डी "उच्च स्तरीय सिस्टम-प्रोग्रामिंग भाषा" है। डिजाइनर चाहते थे कि यह असुरक्षित के प्रकार के लिए व्यवहार्य हो, निम्न-स्तरीय कोड C ++ पारंपरिक रूप से उपयोग किया गया है, और असुरक्षित कोड में एक गलती अविश्वसनीय रूप से महंगा है - अपरिभाषित व्यवहार। इसलिए मुझे लगता है कि इससे उन्हें किसी भी चीज पर अतिरिक्त प्रयास करने के लिए समझ में आता है जो आपको यह सत्यापित करने में मदद करता है कि कुछ असुरक्षित कोड काम करता है। उदाहरण के लिए, आप यह लागू कर सकते हैं कि केवल कुछ भरोसेमंद मॉड्यूल ही अनियंत्रित सरणी एक्सेस या पॉइंटर अंकगणित जैसे असुरक्षित ऑपरेशन कर सकते हैं।
त्वरित विकास भी उनके लिए एक प्राथमिकता थी, इतना ही नहीं, उन्होंने इसे एक ऐसा डिज़ाइन लक्ष्य बना दिया कि डी कोड तेजी से संकलन करता है ताकि इसे स्क्रिप्टिंग भाषा के रूप में प्रयोग करने योग्य बनाया जा सके। बेकिंग यूनिट भाषा में सही परीक्षण करता है ताकि आप अपने परीक्षणों को संकलक के लिए एक अतिरिक्त ध्वज को पारित करके चला सकें।
हालाँकि, मुझे लगता है कि एक महान इकाई परीक्षण पुस्तकालय कुछ तरीकों को खोजने और उन्हें चलाने की तुलना में बहुत अधिक करता है। उदाहरण के लिए हास्केल का क्विकचेक लें , जो आपको "सभी एक्स और वाई के लिए" जैसी चीजों का परीक्षण करने देता है f (x, y) == f (y, x)। क्विकचेक को एक इकाई परीक्षण जनरेटर के रूप में बेहतर रूप से वर्णित किया गया है और आपको "इस इनपुट के लिए, मैं इस आउटपुट की उम्मीद कर रहा हूं" की तुलना में उच्च स्तर पर चीजों का परीक्षण करने की अनुमति देता है। QuickCheck और Linq सभी अलग-अलग नहीं हैं - वे दोनों डोमेन-विशिष्ट-भाषाएं हैं। इसलिए यूनिट टेस्टिंग सपोर्ट के लिए एक भाषा पर बोलिंग करने के बजाय, डीएसएलएस को व्यावहारिक बनाने के लिए आवश्यक सुविधाओं को क्यों न जोड़ें? आप न केवल इकाई परीक्षण, बल्कि एक बेहतर भाषा के परिणामस्वरूप समाप्त करेंगे।