इकाई परीक्षण नियमों

Question

मेरा प्रश्न वास्तव में आप में से कुछ के लिए बेवकूफ दिखाई दे सकते हैं, लेकिन मैं पूछना .. माफ करना ..

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

इसका काम करता है, लेकिन मेरा सवाल यह है कि ..

इकाई परीक्षण जो DALayer वर्ग मैं टेस्ट मैचों में डेटाबेस को प्रभावित करने के लिए है का परीक्षण करने के लिए! उदाहरण के लिए परीक्षण करने के लिए यदि डेटा 5 डेटाबेस को अच्छी तरह से पास किया गया है तो मुझे ऐसा करना होगा और परीक्षण के बाद डेटाबेस का क्षेत्र 5 होगा!

तो मैं जवाब के लिए पता सामान्य रूप से प्रणाली परीक्षण से प्रभावित नहीं है तो मैं कैसे आप परीक्षण कर सकते हैं बिना बिना तरीकों पर अमल समझ में नहीं आता ..

टीएक्स और मेरे गरीब अंग्रेजी बहाना ..

Answer 1

मैं आपके प्रश्न को कई उप प्रश्नों में विभाजित कर दूंगा क्योंकि उन्हें एक साथ जवाब देना मुश्किल है।

इकाई परीक्षण एक्स समाकलन परीक्षण

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

जब आप एकीकरण परीक्षण लिखते हैं तो आप यह देखने के लिए सभी परतों का परीक्षण कर रहे हैं कि एकीकरण और कॉन्फ़िगरेशन काम करता है या नहीं। आप आमतौर पर प्रत्येक निष्पादन पथ के लिए एकीकरण परीक्षण नहीं लिखते हैं क्योंकि सभी परतों में कई संयोजन होते हैं।

परीक्षण व्यापार कक्षाएं - इकाई परीक्षण

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

परीक्षण डेटा का उपयोग परत - एकीकरण परीक्षण

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

सादर, Ladislav

Answer 2

परिदृश्य के लिए आप डीबी इंटरैक्शन के संदर्भ में वर्णन करते हैं, मॉकिंग उपयोगी है। यदि आपके पास मौका है, तो Rhino Mocks

Answer 3

पर एक नज़र डालें, आप Inversion of Control का उपयोग एक मॉकिंग फ्रेमवर्क के साथ करते हैं, उदाहरण के लिए राइनो मोक्स के रूप में पहले से ही उल्लेख किया गया है

Answer 4

आप मजाक और परीक्षण में वास्तविक DB का उपयोग कर तो यह आम आदमी मामले में एकीकरण परीक्षण किया जाएगा का सहारा नहीं कर रहे हैं और यह एक इकाई परीक्षण नहीं रह गया है। मैंने एक ऐसे प्रोजेक्ट पर काम किया जहां एक समर्पित एसक्यूएल। एमडीएफ स्रोत नियंत्रण में था जो [सेटअप] के [सेटअप] भाग में [एनयूएनआईटी] का उपयोग करके डेटाबेस सर्वर से जुड़ा हुआ था, [टीयरडाउन] में अलग समेकित। यह हर बार किया गया था जब एनयूनीट परीक्षण किया गया था और आपके पास मौजूद SQL कोड के आधार पर और डेटा के आकार के आधार पर बहुत समय लग सकता है।

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

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