TDD कैसे करें कि सही परिणाम वापस आए


12

मैं एक नई परियोजना शुरू कर रहा हूं, और डिजाइन को चलाने के लिए टीडीडी का उपयोग करने की बहुत कोशिश कर रहा हूं। मैं वर्षों से जोर दे रहा हूं, और आखिरकार इस परियोजना पर अतिरिक्त समय बिताने के लिए इसे इस्तेमाल करने की मंजूरी मिल गई, जबकि मैं इसे ठीक से करना सीखता हूं।

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

एक आवश्यकता यह है कि किसी दिए गए स्टोर के लिए, मैं उन सभी खरीद आदेशों को वापस करता हूं जिन्हें इस एप्लिकेशन के लिए वैध माना जाता है। एक पीओ को वैध माना जाता है अगर यह जहाज की तारीख स्टोर खोलने की तारीख से दी गई सीमा के साथ गिरती है (यह नए स्टोर के लिए है)।

अब, मैं इस तर्क को एप्लिकेशन कोड में नहीं डाल सकता, क्योंकि मैं एक दर्जन पीओ को वापस लाने वाला नहीं हूं, केवल उस दर्जन को प्राप्त करने के लिए जो इस स्टोर पर लागू हो सकता है जो ऊपर दिए गए अवरोध को देखते हुए लागू कर सकता है।

मैं सोच रहा था, मैं एक GetValidPOs की खरीद के लिए तिथि सीमा को पारित कर सकता हूं, और क्या यह उन मूल्यों का उपयोग करता है जो वैध पीओ को वापस करते हैं। लेकिन, क्या होगा यदि हम एक और आवश्यकता जोड़ते हैं जो एक वैध पीओ माना जाता है?

और मैं यह कैसे परीक्षण करूं और सत्यापित करूं कि यह काम कर रहा है? हम ORM का उपयोग नहीं कर रहे हैं, और ऐसा होने की संभावना नहीं है। और मैं अपने परीक्षण में DB को कॉल नहीं कर सकता।

मैं फँस गया हूँ।

मेरे अन्य विचार में, कुछ ऐसे मॉक हैं जो वैध डेटा लौटाते हैं, अन्य जो कुछ खराब डेटा लौटाते हैं, और स्थानीय रिपॉजिटरी ने एक अपवाद फेंक दिया है यदि बुरा डेटा होता है, और परीक्षण करें कि अपवाद फेंका जाता है यदि अमान्य डेटा GetValidPOs द्वारा वापस खरीद लिया जाता है (या) परीक्षण में प्रयुक्त मॉक)।

इसका कोई मतलब भी है क्या? या कोई बेहतर तरीका है?

अद्यतन: मैं यह प्रतीत होता है EF का उपयोग करने में सक्षम हूँ। अब मुझे केवल यह पता लगाना है कि इसका उपयोग कैसे करना है, और इसे परीक्षण योग्य बनाना है, जबकि अभी भी संग्रहीत प्रक्रियाओं पर भरोसा करने में सक्षम है, और कई डेटाबेस में डेटा बिखरे होने की कठिनाई है।


जिज्ञासा से बाहर, आप एक सादे SQL बयान के साथ सिर्फ वैध PO का चयन क्यों नहीं कर सकते? (यह सवाल या जवाब एक समाधान नहीं है।)
स्कारफ्रिज

जवाबों:


7

यह टीडीडी की आयु में संग्रहीत प्रक्रियाओं का एक प्रमुख नकारात्मक पहलू है। उनके पास अभी भी कुछ वास्तविक अपसाइड्स हैं, लेकिन किसी भी परीक्षण की परिभाषा के अनुसार जो एक संग्रहित खरीद का अभ्यास करता है, वह यूनिट टेस्ट नहीं है; यह एक एकीकरण परीक्षण है।

सामान्य समाधान, यह मानते हुए कि आर्किटेक्चर एक ORM का उपयोग करने के लिए बदल नहीं सकता है, इन परीक्षणों को यूनिट टेस्ट सूट में नहीं रखा जाना है; इसके बजाय, परीक्षणों को एक एकीकरण सूट में रखें। जब भी आप इसे सत्यापित करना चाहें, तब भी आप परीक्षण चला सकते हैं, लेकिन क्योंकि परीक्षण स्थापित करने में निहित लागत (उचित परीक्षण डेटा के साथ एक DB को प्रारंभ करना) अधिक है और यह आपके बिल्ड-बॉट के यूनिट-टेस्ट एजेंट के संसाधनों को नहीं छू सकता है तक पहुँच है, यह यूनिट टेस्ट सूट में नहीं होना चाहिए।

आप अभी भी यूनिट-टेस्ट कोड को डेटा की आवश्यकता कर सकते हैं, कुछ भी सार करके आप एक डीएओ क्लास में यूनिट-टेस्ट (ADO.NET कक्षाएं) नहीं कर सकते हैं जिसे आप तब मॉक कर सकते हैं। फिर आप यह सत्यापित कर सकते हैं कि अपेक्षित कॉल कोड का उपभोग करके किए गए हैं और वास्तविक दुनिया के व्यवहार को पुन: उत्पन्न करते हैं (जैसे कोई परिणाम नहीं मिल रहा है) विभिन्न उपयोग मामलों के परीक्षण की अनुमति देता है। हालाँकि, SqlCommand को संग्रहित खरीद को कॉल करने के लिए वास्तविक सेटिंग कमांड कमांड से कमांड क्रिएशन को अलग करके और कमांड एक्जीकटर को मॉक करके आप बहुत ही अंतिम काम कर सकते हैं। अगर यह बहुत सारी चिंताओं को अलग करने जैसा लगता है, तो यह हो सकता है; याद रखें, "ऐसी कोई समस्या नहीं है जिसे अप्रत्यक्ष की एक और परत द्वारा हल नहीं किया जा सकता है, सिवाय अप्रत्यक्ष की कई परतें होने के"। कुछ बिंदु पर आपको "पर्याप्त होना चाहिए; मैं सिर्फ इसको परख नहीं सकता, हम '

अन्य विकल्प:

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

  • ORM में अपग्रेड करने पर विचार करें। एक LinM प्रदाता के साथ एक ORM (वस्तुतः सभी आम उपयोग में हैं) आपको क्वेरी को Linq कथन के रूप में परिभाषित करने की अनुमति देगा; तब यह कथन एक नकली रिपॉजिटरी को दिया जा सकता है जिसमें इसे लागू करने के लिए परीक्षण डेटा का इन-मेमोरी संग्रह है। इस प्रकार आप डीबी को छूने के बिना क्वेरी सही है सत्यापित कर सकते हैं (आपको अभी भी क्वेरी को एकीकरण वातावरण में चलाना चाहिए, यह जांचने के लिए कि लाइनक प्रदाता क्वेरी को सही ढंग से पचा सकता है)।


2
-1 क्योंकि TDD! = इकाई परीक्षण। टीडीडी करते समय एकीकरण-स्तरीय परीक्षणों को शामिल करने के लिए बिल्कुल ठीक है।
स्टीवन ए लोव

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

1
मुझे वो सब समझ में आ गया, तुम दोनों को। मैंने कहां कहा कि यह एक एकीकरण परीक्षण होने का मतलब है कि आप इसे टीडीडी नहीं कर सकते हैं? मेरा कहना था कि एक संग्रहीत प्रक्रिया को अलगाव में नहीं देखा जा सकता है, जो कि आप अपने कोडबेस के जितना चाहें उतना कर सकते हैं। इसके बजाय परीक्षण एसपी को अधिक जटिल, लंबे समय तक चलने वाले एकीकरण परीक्षणों की आवश्यकता होती है; हालांकि वे मैन्युअल परीक्षण से बेहतर हैं, एक एकीकरण-भारी परीक्षण सूट को चलाने में घंटों लग सकते हैं और सीआई प्रयासों पर हानिकारक प्रभाव पड़ सकता है।
कीथ्स

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

अलगाव में संग्रहीत प्रक्रियाओं का परीक्षण किया जा सकता है। उन्हें और कैसे मान्य किया जाएगा? Transact SQL के लिए tSQLt ( tsqlt.org ) है
kevin cline

4

मेरी सलाह है कि फूट डालो और जीतो । समय के लिए डेटाबेस और दृढ़ता के बारे में भूल जाओ और अपने भंडार या डेटा एक्सेस ऑब्जेक्ट के नकली कार्यान्वयन का परीक्षण करने पर ध्यान केंद्रित करें।

अब, मैं इस तर्क को एप्लिकेशन कोड में नहीं डाल सकता, क्योंकि मैं एक दर्जन पीओ को वापस लाने वाला नहीं हूं, केवल उस दर्जन को प्राप्त करने के लिए जो इस स्टोर पर लागू हो सकता है जो ऊपर दिए गए अवरोध को देखते हुए लागू कर सकता है।

मैं खरीद आदेशों को वापस करने वाले भंडार का मजाक उड़ाऊंगा। बीस अजीब खरीद आदेश के साथ एक नकली बनाएं।

मैं सोच रहा था, मैं एक GetValidPOs की खरीद के लिए तिथि सीमा पारित कर सकता हूं, और क्या यह उन मूल्यों का उपयोग करता है जो वैध पीओ को वापस करते हैं। लेकिन, क्या होगा यदि हम एक और आवश्यकता जोड़ते हैं जो एक वैध पीओ माना जाता है?

GetValidPOs के लिए एक कॉल को स्टब करें ताकि यह डेटाबेस प्रक्रिया के बजाय आपके मॉक को कॉल करे।

और मैं यह कैसे परीक्षण करूं और सत्यापित करूं कि यह काम कर रहा है? हम ORM का उपयोग नहीं कर रहे हैं, और ऐसा होने की संभावना नहीं है। और मैं अपने परीक्षण में DB को कॉल नहीं कर सकता।

आपको यह सुनिश्चित करने के लिए एक इकाई-परीक्षण की आवश्यकता है कि सही डेटा एक नकली से वापस आ गया है।

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

मेरे अन्य विचार में, कुछ ऐसे मॉक हैं जो वैध डेटा लौटाते हैं, अन्य जो कुछ खराब डेटा लौटाते हैं, और स्थानीय रिपॉजिटरी ने एक अपवाद फेंक दिया है यदि बुरा डेटा होता है, और परीक्षण करें कि अपवाद फेंका जाता है यदि अमान्य डेटा GetValidPOs द्वारा वापस खरीद लिया जाता है (या) परीक्षण में प्रयुक्त मॉक)।

जैसा कि मैंने पहले ही कहा था, आपको एक ऐसे मॉक की आवश्यकता है जो कम से कम कुछ डेटा लौटाए जो आप क्वेरी कर सकते हैं।

जब आप डेटा क्वेरी करते हैं तो आप यह सुनिश्चित करना चाहते हैं कि आपका सिस्टम अपवादों को इनायत से संभाल सकता है। इसलिए आप व्यवहार का मजाक उड़ाते हैं ताकि यह कुछ परिदृश्यों में अपवादों को फेंक दे। फिर आप यह सुनिश्चित करने के लिए परीक्षण लिखते हैं कि आपका सिस्टम इन अपवादों को इनायत से संभाल सकता है।


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

0

जैसे जावा या जावास्क्रिप्ट का परीक्षण करने वाली इकाई का अर्थ है जावा के लिए जावा भाषा का उपयोग करके इकाई परीक्षण लिखना, और जावास्क्रिप्ट के साथ इकाई परीक्षण का परीक्षण करना, संग्रहीत कार्यविधियों को लिखने के लिए आपको ड्राइव करने के लिए स्वचालित परीक्षण लिखना, उस इकाई परीक्षण पुस्तकालय का अर्थ है जिसे आप संग्रहीत कर रहे हैं। प्रक्रियाओं।

एक और तरीका कहा, संग्रहीत प्रक्रियाओं का परीक्षण करने के लिए संग्रहीत प्रक्रियाओं का उपयोग करें क्योंकि:

  • जब से आप प्रक्रिया भाषा में विकसित कर रहे हैं, आपके पास प्रक्रिया भाषा में अपने परीक्षण लिखने का कौशल होना चाहिए
  • आपकी प्रक्रिया भाषा में परीक्षण लिखने से प्रक्रिया भाषा में आपके कौशल में वृद्धि होगी जो बदले में आपके उत्पाद विकास में मदद करेगी
  • आपके पास आपके DB द्वारा प्रदान किए जाने वाले सभी साधनों तक सीधी पहुंच होगी और आप उन साधनों का उपयोग कर सकते हैं जो आपकी इकाई परीक्षणों को यथासंभव सरल बनाए रख सकते हैं
  • यूनिट टेस्ट जो एक ही डीबी में संग्रहीत होते हैं, जो प्रक्रिया वे परीक्षण कर रहे हैं वे तेज होंगे (गति की तरह इकाई परीक्षण के निकटतम चीज) क्योंकि आप सिस्टम सीमाओं को पार नहीं कर रहे हैं

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

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.