इकाई फ्रेमवर्क एकीकरण परीक्षण

Question

के साथ लेनदेन का निपटान करने का डाउनसाइड मैं अपने टेबल डेटा को ईएफ के साथ एकीकरण परीक्षण करने के लिए एक त्वरित तरीका ढूंढ रहा हूं।

हर कोई अपनी परीक्षण विधि के आसपास एक लेनदेन लपेटता है और परीक्षण के बाद लेनदेन का निपटान करता है।

इस तरह डेटा को तालिका में कभी नहीं लिखा जाता है।

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

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

या दूसरे शब्दों में पूछा वहाँ दोषपूर्ण परिदृश्यों जो का उपयोग कर अपवाद के रूप में पॉप नहीं है प्रतिबद्धता के बिना लेनदेन()?

अद्यतन

public abstract class IntegrationTestsBase 
    { 
     protected TransactionScope TransactionScope; 

     public abstract void TestSetup(); 
     protected void InitTestSetupOnTable(string tableName) 
     { 
      TransactionScope = new TransactionScope(); 

      using (var context = new TGBContext()) 
      { 
       var cmdCommand = string.Format("DBCC CHECKIDENT ({0}, RESEED, 1)", tableName); 
       context.Database.ExecuteSqlCommand(cmdCommand); 
       context.SaveChanges(); 
      } 
     } 

     [TestCleanup] 
     public void TestCleanup() 
     { 
      TransactionScope.Dispose(); 
     } 
    } 

[TestClass] 
public class MyTests : IntegrationTestsBase 
{ 
     [TestInitialize] 
     public override void TestSetup() 
     { 
      base.InitTestSetupOnTable("MyTableName");   
     } 
} 

Answer 1

के रूप में डेटाबेस

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

क्या इस दृष्टिकोण का उपयोग करने के कोई डाउनसाइड्स हैं?

वास्तव में नहीं। मैं अपने दृष्टिकोण में इस दृष्टिकोण का व्यापक रूप से उपयोग करता हूं और इसमें बहुत अच्छी योग्यता है। ग्रीन टेस्ट आश्वासन का एक बहुत उच्च स्तर देते हैं। मैक किए गए संदर्भों और DbSet (हालांकि मैं कई अन्य चीजों के लिए यूनिट टेस्ट का उपयोग करता हूं) का उपयोग करके "वास्तविक" यूनिट परीक्षण से कभी भी सुरक्षित महसूस नहीं करूंगा।

लेकिन कुछ प्रतिबंध हैं जिनके बारे में आपको अवगत होना चाहिए।

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