टीडीडी, डीडीडी और एनकैप्यूलेशन

Question

काम के मेरे स्थान पर 'आर्किटेक्ट्स' से बुरी आदत का पालन करने के कई सालों बाद और सोच रहा था कि एक बेहतर तरीका होना चाहिए, मैं हाल ही में टीडीडी और डीडीडी और आई के आसपास पढ़ रहा हूं। सोचें कि हमारे द्वारा लिखे गए सॉफ़्टवेयर की जटिलता के लिए सिद्धांत और प्रथाएं बहुत अच्छी होंगी।

हालांकि, मैंने देखा है कि कई टीडीडी नमूने डोमेन ऑब्जेक्ट पर एक विधि कॉल करते हैं और फिर ऑब्जेक्ट का परीक्षण गुण सही तरीके से निष्पादित करने के लिए करते हैं।

दूसरी ओर, उद्योग में कई सम्मानित लोग (ग्रेग यंग सबसे महत्वपूर्ण रूप से सीक्यूआरएस पर उनकी वार्ता के साथ) वकील सभी 'गेटर्स' को हटाकर प्रत्येक डोमेन ऑब्जेक्ट को पूरी तरह से समाहित करते हैं।

मेरा प्रश्न इसलिए है: यदि कोई व्यक्ति अपने राज्य को पुनर्प्राप्त करने के लिए मना किया गया है तो किसी डोमेन ऑब्जेक्ट की कार्यक्षमता का परीक्षण कैसे करता है?

मेरा मानना ​​है कि मुझे कुछ मौलिक याद आ रही है, इसलिए कृपया मुझे बेवकूफ कहने और मुझे प्रबुद्ध करने के लिए स्वतंत्र महसूस करें - किसी भी मार्गदर्शन की सराहना की जाएगी।

Answer 1

आप जो वर्णन कर रहे हैं वह राज्य सत्यापन है जिसमें आप डोमेन ऑब्जेक्ट की स्थिति पर दावा करते हैं। टीडीडी की एक शाखा है जिसे व्यवहार सत्यापन कहा जाता है जो मॉक ऑब्जेक्ट्स का उपयोग करता है।

व्यवहार सत्यापन आपको यह निर्दिष्ट करने की अनुमति देता है कि किन विधियों को बुलाया जाना चाहिए और यदि आप चाहते हैं, तो कौन से तरीकों को नहीं कहा जाता है।

मार्टिन फाउलर द्वारा अधिक जानकारी के लिए इस आलेख को देखें: Mocks Aren't Stubs।

Answer 2

कुछ चीजें।

सबसे पहले, जब आप अपने कोड को टेस्ट करने योग्य बनाने के लिए टीडीडी जैसी चीजें करते हैं तो आप छोटी कक्षा के साथ समाप्त होते हैं। यदि आपके पास बहुत से निजी संपत्तियों वाला एक वर्ग है, तो आप निरीक्षण नहीं कर सकते हैं, यह एक अच्छा मौका है कि इसे कई वर्गों में तोड़ दिया जा सकता है और अधिक टेस्टेबल बनाया जा सकता है।

दूसरा, पुरानास्कूल ओओ आर्किटेक्चर चीजों को सुलभ होने से रोकने के लिए भाषा सुरक्षा उपायों का उपयोग करके सॉफ्टवेयर को सुरक्षित बनाने की कोशिश करता है। एक टीडीडी आर्किटेक्चर परीक्षण लिखकर सॉफ़्टवेयर को और अधिक मजबूत बनाता है जो यह सत्यापित करता है कि कोड वास्तव में क्या करता है, यह सुनिश्चित करने के लिए कि भाषा क्या नहीं करती है, भाषा संरचनाओं का उपयोग करने पर कम जोर देती है।

आखिरकार, संपत्ति की जांच करना कोड को सत्यापित करने का एकमात्र तरीका नहीं है जो इसे करना था। पुस्तक xUnit डिजाइन पैटर्न दस्तावेज़ अन्य दृष्टिकोण यहां: http://xunitpatterns.com/Result%20Verification%20Patterns.html

Answer 3

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

प्रैक्टिस में, मैंने बीडीडी को केवल राज्य परीक्षण के मुकाबले कई मामलों में अधिक भंगुर पाया है। जबकि कुछ लोग एक निश्चित सिद्धांत के लिए कॉल कर सकते हैं, यह केवल तभी काम करता है जब यह आपके लिए काम करता है। राज्य-आधारित परीक्षण अभी भी हमारे द्वारा लिखे गए सभी यूनिट परीक्षणों का 9 0% बनाता है, और हम अपनी टीम पर बीडीडी के बारे में अच्छी तरह जानते हैं।

क्या आपके लिए सबसे अच्छा काम करता है।

Answer 4

मैं सिस्टम की सार्वजनिक इनपुट विधियों को कॉल करता हूं (यानी मैं सिस्टम में इनपुट डेटा दबाता हूं), और फिर मुझे सिस्टम के आउटपुट (और जोर) मिलते हैं।मैं सिस्टम की आंतरिक स्थिति का परीक्षण नहीं कर रहा हूं, बल्कि इसके सार्वजनिक/दृश्य व्यवहार: Should one test internal implementation, or only test public behaviour?

Answer 5

जो आप उल्लेख करते हैं उसे राज्य परीक्षण कहा जाता है। व्यवहार परीक्षण भी है। इसके लिए उपयोग की जाने वाली तकनीकें निर्भरता इंजेक्शन, नियंत्रण में उलझन, और मॉकिंग:

आपकी कक्षा के सभी दुष्प्रभावों को इसकी "निर्भरताओं" पर विधि आमंत्रण के रूप में कार्यान्वित किया जाता है - यानी बाहर से आपूर्ति की जाने वाली वस्तुओं, आमतौर पर कन्स्ट्रक्टर में। फिर, अपने यूनिट-टेस्ट में, आप वास्तविक के बजाय नकली ऑब्जेक्ट की आपूर्ति करते हैं। नकली वस्तु याद रख सकती है अगर इसकी 'कुछ विधि कहा जाता है, और यही वह है जो आप अपने परीक्षण में करते हैं।

मॉकिंग फ्रेमवर्क की संख्या मौजूद है जो किसी दिए गए इंटरफ़ेस को लागू करने वाले वर्गों को गतिशील रूप से उत्पन्न करके नकली ऑब्जेक्ट सृजन को स्वचालित करती है। सबसे लोकप्रिय राइनो। मोक्स और मोक हैं।

Answer 6

हे जस्टिन, आपके जैसे, मैं हाल ही में यूनिट परीक्षण के लिए मेरे लेखन-केवल डोमेन ऑब्जेक्ट में गेटर्स जोड़ने के बारे में सोच रहा था, लेकिन अब मुझे विश्वास है कि मैं गलत था। मान लीजिए कि आपने केवल एक ही लिखने वाले डोमेन के विचार में खरीदा है, तो यदि आपके पास गेटर्स हैं, तो आप परेशानी के लिए पूछ रहे हैं। केवल-लिखने वाला डोमेन सिद्धांत चाहता है कि आप अपने डोमेन ऑब्जेक्ट से किसी ईवेंट को आग लगाना चाहें, या उस प्रोजेक्शन से पढ़ लें जो आपके डोमेन ऑब्जेक्ट ने लिखा था, या ऐसा कुछ। एक बार जब आप गेटर्स का पर्दाफाश करते हैं तो आप ऑब्जेक्ट के "आकार" का पर्दाफाश करना शुरू कर देते हैं, और जैसा कि ग्रेग यंग कहते हैं, "डोमेन ऑब्जेक्ट्स में व्यवहार है, आकार नहीं है"।

कहा जा रहा है कि, मैं आपके प्रश्न के साथ संघर्ष कर रहा हूं ... आप केवल एक लिखने वाली डोमेन ऑब्जेक्ट का परीक्षण कैसे करते हैं? मेरी वर्तमान योजना यहां दी गई है: मैं अपने डोमेन ऑब्जेक्ट को एक डोमेन इवेंट को आग लगाने के बारे में सोच रहा हूं, "ये गुण बदल गए हैं" और मेरे यूनिट टेस्ट में, मैं "एडिट कमांड" भेजने से पहले इसके लिए पंजीकरण करूंगा। डोमेन ईवेंट here पर उडी दहन की पोस्ट देखें, और what Eric Evans says about Domain Events भी देखें।

Answer 7

मैं वही बात सोच रहा था जब तक कि मैं अंततः निम्नलिखित कागजात पर ठोकर खाई। मैं उन्हें मिल गया मुझे कई "अहा क्षणों" उपलब्ध कराने के व्यवहार सत्यापन, विशेष रूप से पहले एक प्रदर्शन पर महान प्राइमरों होने के लिए:

1. Using Mocks and Tests to Design Role-Based Objects
2. Mock Roles, Not Objects

Answer 8

ठीक है, यह जवाब एक साल बहुत देर हो चुकी है ;-)

लेकिन जब आप सीक्यूआरएस मॉडल का परीक्षण करना चाहते हैं, तो आप इकाई स्थिति पर दावे के बजाय निकाल दिए गए डोमेन ईवेंट पर दावा कर सकते हैं।

उदा। यदि आप कॉल करना चाहते हैं तो परीक्षण करना चाहते हैं: ग्राहक। नाम बदलें ("Foo") सही व्यवहार में परिणाम देता है।

ग्राहक के नाम पर परीक्षण के बजाय "foo" बराबर है, तो आप अपने लंबित ईवेंट स्टोर में "Foo" मान के साथ लंबित ग्राहकरनाम ईवेंट होने पर परीक्षण करते हैं। (कार्यान्वयन के आधार पर आपके यूओ या आपकी इकाई घटना सूची में)