कार्यों को पढ़ने / लिखने के लिए मैं TDD कैसे लागू करूँ?

Question

यह चिकन और अंडे की समस्या की तरह लगता है।

आप कुछ डेटा स्टोर के लिए एक लिखने के कार्य को लिख सकते हैं, लेकिन कभी नहीं जानते कि आपने इसे बिना पढ़े फ़ंक्शन के बिना ठीक से सहेजा है।

आप किसी डेटा स्टोर से पढ़े गए फंक्शन को पढ़ सकते हैं, लेकिन आप उस डेटा स्टोर में सामान कैसे रख सकते हैं, पढ़ने के लिए, बिना टेस्ट किए हुए फंक्शन में?

संपादित करें:

मैं उपयोग करने के लिए वस्तुओं को बचाने और लोड करने के लिए SQL डेटाबेस के साथ लेनदेन कर रहा हूं और बना रहा हूं। डीबी द्वारा प्रदान किए जाने वाले एक्सेस फ़ंक्शंस के परीक्षण का कोई मतलब नहीं है, लेकिन मैं ऑब्जेक्ट्स को क्रमांकित / डीस्सराइज़ करने के लिए ऐसे डीबी फ़ंक्शन को लपेटता हूं। मैं यह सुनिश्चित करना चाहता हूं कि मैं DB से सही तरीके से और सही सामान लिख रहा हूं और पढ़ रहा हूं।

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

Comments

क्या आप अपना स्वयं का डेटा स्टोर लिख रहे हैं, या किसी मौजूदा का उपयोग कर रहे हैं? यदि आप किसी मौजूदा का उपयोग कर रहे हैं, तो मान लें कि यह पहले से ही काम कर रहा है। यदि आप अपना स्वयं का लिख ​​रहे हैं, तो यह उसी तरह से काम करता है जैसे कि TDD का उपयोग करके किसी अन्य सॉफ़्टवेयर को लिखना।

— रॉबर्ट हार्वे

किसी अनुप्रयोग के CRUD परत पर यूनिट टेस्ट बनाने

— जोंशरशेप

निकटता से संबंधित होने के दौरान, मुझे नहीं लगता कि यह उस विशेष प्रश्न की नकल है। डूप लक्ष्य लक्ष्य / हटाने के बारे में बात कर रहा है, यह एक पढ़ा / लिखा है। अंतर एक पढ़ने / लिखने की निर्भरता की संभावना है जो पढ़ने / लिखी जाने वाली वस्तुओं की सामग्री पर निर्भर करता है, जबकि एक सरल ऐड / डिलीट टेस्ट संभवतः बहुत सरल होगा: क्या वस्तु मौजूद है या नहीं।

आप पढ़े गए फ़ंक्शन का परीक्षण करने के लिए डेटा के साथ एक डेटाबेस चरणबद्ध कर सकते हैं और कोई लेखन कार्य नहीं कर सकते हैं।

— जेफ ओ

Answer 1

पढ़ें समारोह के साथ शुरू करो।

• परीक्षण सेटअप में : डेटाबेस बनाएँ और परीक्षण डेटा जोड़ें। या तो माइग्रेशन स्क्रिप्ट के माध्यम से या बैकअप से। चूंकि यह आपका कोड नहीं है, इसलिए उसे TDD में परीक्षण की आवश्यकता नहीं है

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

अब आपके पास पूरी तरह से परीक्षण किया गया फ़ंक्शन है, तो आप लिखें फ़ंक्शन पर जा सकते हैं, जो अपने परिणामों को सत्यापित करने के लिए मौजूदा रीड का उपयोग कर सकता है

Comments

मुझे लगता है कि आप चीजों को गति देने के लिए मेमोरी में DB बना सकते हैं, लेकिन यह बहुत जटिल हो सकता है। यूनिट परीक्षणों के बजाय मोक्स का उपयोग क्यों नहीं किया जाता है?

— 383838।।

यहाँ शैतान का थोड़ा सा वकील है, लेकिन आप कैसे परीक्षण करते हैं कि डेटाबेस सही तरीके से बनाया गया था? जैसा कि ओपी ने कहा, चिकन और अंडा।

— user949300

@ ईवान - मैं पूरी तरह से सहमत हूं कि आपको उनके डीबी कोड का परीक्षण नहीं करना चाहिए। लेकिन आपको कैसे पता चलेगा कि आपका DB सेटअप कोड कहीं INSERT को नहीं भूल गया है या किसी कॉलम में गलत मूल्य नहीं डाल रहा है?

— user949300

एक शुद्ध टीडीडी से परीक्षण की आवश्यकता है। इसलिए यह तार्किक रूप से गलत नहीं हो सकता। obvs असली दुनिया में आप इसे आँख मारना होगा

— Ewan

क्विस कस्टोडिएट ipsos कस्टोड? या, "परीक्षण कौन करता है?" :-) मैं आपसे सहमत हूं कि एक प्योरिस्ट TDD वर्ल्ड में यह बहुत ही थकाऊ और बग-प्रोन होगा। (अगर यह 8 JOINS के साथ एक जटिल मल्टीपल टेबल स्ट्रक्चर था) इसे करने का तरीका। Upvoted।

— user949300

Answer 2

मैं अक्सर सिर्फ एक लिखा पढ़ता हूं। उदा। (स्यूडोकोड)

Foo foo1 = setup some object to write
File tempfile = create a tempfile, possibly in memory 
writeFoo(foo1, tempfile) 
Foo foo2 = readFoo(tempfile) 
assertEquals(foo1, foo2); 
clean-up goes here

बाद में जोड़ा गया

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

अब, यदि आपको कुछ आधिकारिक युक्ति का सख्ती से पालन करना चाहिए, तो मैं सहमत हूं कि ठीक विवरण की जाँच करना उचित है।

Comments

क्योंकि यह 90% वास्तव में सेंसुकोड है? निश्चित नहीं। शायद पाठ को हाइलाइट करें और कोड कम शोर करें?

— रबरडक

हां @ इवान। जाइलॉट इस पर भड़क जाएगा, हालांकि व्यावहारिक प्रोग्रामर "काफी अच्छा" कहेगा और आगे बढ़ेगा।

— रबरडक

मैं थोड़े सवाल के रूप में पढ़ा .. "मुझे लगता है कि मैं एक zealot की तरह TDD का पालन करें ..."

— Ewan

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

— इवान

आप परीक्षण कर रहे हैं, '' मुझे जो लिखना है, उसे पढ़ना चाहिए, लेकिन 'db से डेटा वापस पढ़ना चाहिए' और 'db को डेटा लिखना चाहिए' लिखना है

— Ewan

Answer 3

मत करो। यूनिट टेस्ट I / O न करें। यह समय की बर्बादी है।

इकाई परीक्षण तर्क। यदि आपके पास I / O कोड में परीक्षण करने के लिए बहुत सारे तर्क हैं, तो आपको I / O के तर्क को अलग करने के लिए अपने कोड को फिर से लिखना चाहिए कि I / O और I / O के वास्तविक व्यवसाय से आप क्या करते हैं (जो परीक्षण करने के लिए नामुमकिन है)।

थोड़ा विस्तार करने के लिए, यदि आप एक HTTP सर्वर का परीक्षण करना चाहते हैं, तो आपको दो प्रकार के परीक्षणों के माध्यम से ऐसा करना चाहिए: एकीकरण परीक्षण और इकाई परीक्षण। यूनिट परीक्षणों को I / O के साथ बिल्कुल भी बातचीत नहीं करनी चाहिए। यह धीमा है और बहुत सी त्रुटि स्थितियों का परिचय देता है जिनका आपके कोड की शुद्धता से कोई लेना-देना नहीं है। इकाई परीक्षण आपके नेटवर्क की स्थिति के अधीन नहीं होना चाहिए!

आपका कोड अलग होना चाहिए:

• यह निर्धारित करने का तर्क कि किस सूचना को भेजना है
• यह निर्धारित करने का तर्क कि किसी विशेष सूचना को भेजने के लिए कौन सी बाइट्स भेजनी है (मैं कच्चे बाइट्स में प्रतिक्रिया कैसे दर्ज करता हूं), और
• वास्तव में उन बाइट्स को एक सॉकेट में लिखने का तंत्र।

पहले दो में तर्क और निर्णय शामिल हैं और यूनिट परीक्षणों की आवश्यकता है। अंतिम में कई निर्णय लेना शामिल नहीं होता है और किसी भी निर्णय का एकीकरण परीक्षण का उपयोग करके शानदार तरीके से परीक्षण किया जा सकता है।

यह सामान्य रूप से केवल अच्छा डिज़ाइन है, वास्तव में, लेकिन इसका एक कारण यह है कि यह परीक्षण करना आसान बनाता है।

---

यहाँ कुछ उदाहरण हैं:

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

Answer 4

मुझे नहीं पता कि यह एक मानक अभ्यास है या नहीं लेकिन यह मेरे लिए ठीक काम करता है।

मेरे गैर-डेटाबेस रीड राइट विधि कार्यान्वयन में मैं अपने स्वयं के विशिष्ट toString()और fromString()कार्यान्वयन विवरण के रूप में विधियों का उपयोग करता हूं ।

इन्हें आसानी से अलगाव में परखा जा सकता है:

 assertEquals("<xml><car type='porsche'>....", new Car("porsche").toString());

वास्तविक पढ़ने लिखने के तरीकों के लिए मेरे पास एक एकीकरण परीक्षण है जो एक परीक्षण में शारीरिक रूप से पढ़ा और लिखा गया है

वैसे: क्या एक परीक्षा में कुछ गलत है जो एक साथ पढ़ने / लिखने का परीक्षण करता है?

Comments

यह अच्छा या "शुद्ध" नहीं लग सकता है, लेकिन यह व्यावहारिक समाधान है।

— रबरडक

मुझे भी एक साथ पढ़ने और लिखने के परीक्षण का विचार पसंद है। आपका toString () एक अच्छा व्यावहारिक समझौता है।

— user949300

Answer 5

ज्ञात डेटा को ज्ञात तरीके से स्वरूपित किया जाना चाहिए। इसे लागू करने का सबसे आसान तरीका एक निरंतर स्ट्रिंग का उपयोग करना और परिणाम की तुलना करना है, जैसा कि @ k3b वर्णित है।

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

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

Answer 6

निर्भरता इंजेक्शन और मॉकिंग का उपयोग करें।

आप अपने SQL ड्राइवर का परीक्षण नहीं करना चाहते हैं और यदि आपका SQL डेटाबेस ऑनलाइन है और ठीक से सेट है तो आप परीक्षण नहीं करना चाहते हैं। यह एकीकरण-या प्रणाली-परीक्षण का हिस्सा होगा। आप परीक्षण करना चाहते हैं कि क्या आपका कोड एसक्यूएल स्टेटमेंट भेजता है जिसे इसे भेजना है और यदि यह प्रतिक्रियाओं की व्याख्या करता है तो इसे माना जाता है।

इसलिए जब आपके पास कोई ऐसा तरीका / वर्ग हो जो किसी डेटाबेस के साथ कुछ करने वाला हो, तो उसके पास उस डेटाबेस कनेक्शन को खुद से न रखें। इसे बदलें ताकि जो ऑब्जेक्ट डेटाबेस कनेक्शन का प्रतिनिधित्व करता है उसे पास किया जाए।

अपने उत्पादन कोड में, वास्तविक डेटाबेस ऑब्जेक्ट पास करें।

अपने यूनिट परीक्षणों में, एक नकली वस्तु को पास करें जो सिर्फ एक वास्तविक डेटाबेस की तरह व्यवहार करता है वास्तव में डेटाबेस सर्वर से संपर्क नहीं करता है। बस यह जाँच लें कि क्या यह एसक्यूएल स्टेटमेंट प्राप्त करता है जिसे इसे प्राप्त करना चाहिए और फिर हार्डकोड किए गए प्रतिक्रियाओं के साथ प्रतिक्रिया करता है।

इस तरह आप एक वास्तविक डेटाबेस की आवश्यकता के बिना भी अपने डेटाबेस अमूर्त परत का परीक्षण कर सकते हैं।

Comments

डेविल्स एडवोकेट: आप कैसे जानते हैं कि यह "प्राप्त करने वाला" कौन सा एसक्यूएल कथन है? क्या होगा यदि DB ड्राइवर कोड में दिखाई देने वाले आदेश से अनुकूलन करता है?

— 199 में user949300

@ user949300 डेटाबेस मॉक ऑब्जेक्ट आमतौर पर डेटाबेस ड्राइवर को बदलता है।

— फिलिप

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

— इवान

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

— फिलिप

हाँ। IM कह रहा है कि कोई बिंदु इकाई परीक्षण डीबी भंडार नहीं है। एकीकरण परीक्षण केवल एक चीज है जो करने योग्य है

— इवान

Answer 7

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

NHibernate दृढ़ता विशिष्टता परीक्षण प्रदान करता है । इसे तेज इकाई परीक्षणों के लिए इन-मेमोरी स्टोर के खिलाफ काम करने के लिए कॉन्फ़िगर किया जा सकता है।

यदि आप कार्य पैटर्न के रिपॉजिटरी और यूनिट के सबसे सरल संस्करण का पालन करते हैं, और अपने सभी मैपिंग का परीक्षण करते हैं, तो आप बहुत काम की चीजों पर भरोसा कर सकते हैं।