2010-07-09 10 views
19

मैं हाल ही में यूनिट परीक्षण के बारे में बहुत कुछ सुन रहा हूं।यूनिट टेस्ट सीआरयूडी अनुप्रयोग कब/कैसे करें?

जो मैं समझने की कोशिश कर रहा हूं वह है कि एक व्यक्ति को एक क्रूड बिजनेस ऐप का परीक्षण करने के बारे में कैसे जाना चाहिए? (मूल रूप से एक ऐप जो डेटाबेस को डेटा में डेटा लिखता/पढ़ता है)।

क्या यूनिट परीक्षण उस स्केनेरियो में भी इसके लायक है या क्या आप आमतौर पर अधिक जटिल चीजों का परीक्षण करते हैं? एक भी विधि, कोई और अधिक -

धन्यवाद

+0

डाटा मॉडल में मैपिंग में कीड़े के बहुत सारे, संग्रहीत प्रक्रिया तर्क, गलतियाँ, गलत डेटा पकड़ा कर सकते हैं मैं इकाई परीक्षण डेटाबेस पढ़ना/लिखना नहीं चाहिए। मुझे व्यापार तर्क कोड का परीक्षण करना चाहिए। – foreyez

+1

संभवतः तोड़ने वाली हर चीज का परीक्षण करें। यह आम संवेदना है। –

उत्तर

12

इकाई परीक्षण कोड की असतत इकाइयों का परीक्षण के बारे में है।

जिस क्षण आप सीआरयूडी में जाते हैं, आप परीक्षण नेटवर्क, आईओ, डेटाबेस और अन्य चीजों के बारे में बात कर रहे हैं - यह यूनिट परीक्षण के बाहर है। इस मामले में, इसे एकीकरण परीक्षण कहा जाता है (आप परीक्षण कर रहे हैं कि आपका कोड अन्य कोड/सिस्टम के साथ कैसे एकीकृत करता है)।

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

+2

यूनिट टेस्ट विभिन्न एसयूटी (परीक्षण के तहत सिस्टम) का परीक्षण कर सकता है: कक्षाओं के दो तरीकों या यहां तक ​​कि समूह। यूनिट परीक्षणों के बीच अंतर बहुत अस्पष्ट है और दोनों इकाई या एकीकरण परीक्षण के आकार के आकार और विशेषताओं की कोई स्पष्ट परिभाषा नहीं है। –

+0

@Yauheni शिवुखा - विकिपीडिया से: एक इकाई एक आवेदन का सबसे छोटा परीक्षण योग्य हिस्सा है। http://en.wikipedia.org/wiki/Unit_testing – Oded

+0

@ जोड़ा गया - विकिपीडिया यह नहीं कहता कि सबसे छोटा टेस्टेबल हिस्सा विधि है। यह संदर्भ पर निर्भर करता है। यदि परीक्षण क्रम में कुल सत्यापित करता है, तो उसे ऑर्डर लाइन भरनी चाहिए। वैसे: http://stackoverflow.com/questions/10752/what-is-the-difference-between-integration-and-unit-tests –

1

यूनिट परीक्षण कार्यक्षमता के छोटे सरल बिट्स का परीक्षण करने के बारे में है। आम तौर पर आप इकाई को अपने आवेदन की डेटा परत का परीक्षण करेंगे जो सभी सीआरयूडी कार्यक्षमता को संभालेगा। एक बनाएँ और इस प्रकार दिखाई देंगे पुन: प्राप्त करने के लिए एक परीक्षण:

PrimaryKey = InsertObject(TestObject) 

    if PrimaryKey = 0 then 

    AssertTestFailed("Primary Key Not Returned.") 

    end if 


    NewInstanceOfObject = GetObject(PrimaryKey) 

    If NewInstanceOfObject <> TestObject then 
     AssertTestFailed("Record not located.") 
else 
     AssertTestPassed("This Code is awesome UnitTest Passed.") 
    end if 
8

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

3

क्रूडी ऐप्स शायद ही कभी क्रूर रहें। वे अंततः एक व्यापार वस्तु परत शामिल करने के लिए बढ़ते हैं।

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

3

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

अंगूठे का मेरा नियम यह है कि मैं उन चीजों के लिए स्वचालित परीक्षण तैयार करता हूं जिन्हें मैं वास्तव में reguarlity के साथ तोड़ने की उम्मीद करता हूं, या जिन चीज़ों को मैं तत्काल नोटिस नहीं करूँगा उन्हें तोड़ दिया जाता है। और सबसे अधिक, मैं चाहता हूं कि यह उन चीजों का परीक्षण करे जो मैं पूरी तरह से पुनः परीक्षण नहीं कर सकता/सकती हूं।

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

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

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

+1

परीक्षण-प्रथम इकाई परीक्षण के बारे में नहीं है। यह टीडीडी (या कुछ के लिए बीडीडी) नामक एक डिजाइन पद्धति के बारे में है। – Oded

2

Test everything that could possibly break

बेशक आप खासकर यदि आप डेटा उन्मुख आवेदन अपने CRUD संचालन परीक्षण की आवश्यकता के

। और मेरे expirience से परीक्षण इस तरह, बहुत उपयोगी परीक्षण कर रहे हैं, क्योंकि वे तो मैं क्या इन प्रतिक्रियाओं से समझने रहा हूँ से आदि

संबंधित मुद्दे