टेस्ट और डेटाबेस। परीक्षण द्वारा किए गए परिवर्तनों को वापस कैसे करें?

कार्य विवरण

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

निर्णय की समीक्षा

इसे कैसे लागू किया जा सकता है? कई विकल्प दिमाग में आते हैं:

• डेटाबेस को पूरी तरह से साफ़ करें और प्रत्येक बार कोड या स्क्रिप्ट से मूल सेट का डेटा डालें;
• नई संस्थाओं को हटाने के लिए एक सफाई स्क्रिप्ट। लेकिन आपको मूल सेट के सार को किसी तरह से बदलने की आवश्यकता है। परीक्षणों के मूल सेट की संस्थाओं को बदलने का भी खतरा है;
• परीक्षण से पहले डेटाबेस को बैकअप में रोल करें;
• बैकअप के बजाय समान लेकिन स्नैपशॉट।

(आप क्या अन्य विकल्प सुझाते हैं?)

निर्णय लेना

"सफाई स्क्रिप्ट" के आधार पर इसी तरह के समाधान के साथ कुछ समय तक काम करने के बाद, कुछ नया करने की कोशिश करने का निर्णय लिया गया। यह नया विकल्प "बैकअप" के साथ था।
मैं ध्यान देता हूं कि मुझे स्नैपशॉट अधिक पसंद हैं, लेकिन वे एमएस सकेल एक्सप्रेस में नहीं हैं, और मैं इसके साथ काम करता हूं।
संपूर्ण दृष्टिकोण .Net प्लेटफ़ॉर्म और MS Sql सर्वर के लिए विकसित किया गया था।

कार्यान्वयन

पहले परीक्षणों में निम्नलिखित समस्याएं सामने आईं:

• आधार रोजगार की समस्या। RESTORE टीम को चलाने के लिए, आपको डेटाबेस तक विशेष पहुंच की आवश्यकता होती है। यदि इस डेटाबेस में अन्य सक्रिय कनेक्शन हैं, तो निष्पादन विफल हो जाता है।
  
  • कभी-कभी परीक्षण कनेक्शन को बंद नहीं करते हैं; तदनुसार, इसे बंद करना और निगरानी करना आवश्यक है। या - रोलबैक से पहले जबरन लटके हुए ऐड को ऑन करने के लिए।
  • .Net में एक कनेक्शनपूल है। यह प्रदर्शन में सुधार करने के लिए बंद होने के बाद भी कनेक्शन रखता है। समाधान SqlConnection.ClearAllPools () है;
  • बचा हुआ कोई व्यक्ति सिर्फ डेटाबेस से जुड़ सकता है। उदाहरण के लिए, प्रबंध स्टूडियो के माध्यम से और परीक्षणों की विधानसभा को बर्बाद कर दिया। समाधान यह है कि इन आंकड़ों को टेस्ट बेस से उनके कनेक्शन बंद करके फेंक दिया जाए।
• पुनर्प्राप्ति टीम को पुनर्प्राप्ति के लिए स्रोत को स्वीकार करना होगा। यह आमतौर पर MS Sql सर्वर पर फ़ाइल का नाम है। बेशक, मैं डीबीएमएस में ही इस विवरण को छिपाना चाहूंगा। लेकिन यह काम नहीं करता है। समाधान स्नैपशॉट हो सकता है (तब केवल स्नैपशॉट डेटाबेस का नाम कोड / स्क्रिप्ट में अंकित किया जाना चाहिए, जो स्वीकार्य है)। लेकिन वे एक्सप्रेस में नहीं हैं।
• बैकअप का उपयोग करने की गति। चूंकि रोलबैक प्रत्येक परीक्षण से पहले आदर्श रूप से होता है, इसलिए इसकी गति बहुत महत्वपूर्ण है। 11 एमबी का मेरा छोटा आधार 0.216 सेकंड में बहाल किया गया था, जो स्वीकार्य है। आधार के आकार के आधार पर इस पैरामीटर की वृद्धि विशेषताओं का ठीक से अध्ययन नहीं किया गया है।
  
  • मेरे अनुभव में, मूल सेट का आकार जोरदार रूप से बढ़ने के लिए इच्छुक नहीं है क्योंकि परियोजना विकसित होती है;
  • एक मूल सेट को संकलित करते समय, आपको मेगाबाइट में, इसके आकार को कम करने के बारे में सोचना चाहिए।

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

उपयोगकर्ता डिस्कनेक्ट स्क्रिप्ट:

DECLARE @twho TABLE( SPID int , ecid int , [STATUS] NVARCHAR(64) , [Loginame] NVARCHAR(64) , [HostName] NVARCHAR(64) , [Blk] int , [DBName] NVARCHAR(64) , cmd NVARCHAR(64), request_id INT) INSERT INTO @twho EXEC SP_WHO DECLARE spid_cursor CURSOR FOR SELECT SPID FROM @twho WHERE DBName = @dbname OPEN spid_cursor DECLARE @SpidToClose INT FETCH NEXT FROM spid_cursor INTO @SpidToClose WHILE @@FETCH_STATUS = 0 BEGIN IF @@SPID <> @SpidToClose BEGIN -- kill     . declare @str varchar(32) set @str='KILL ' + cast(@SpidToClose as varchar(16)) exec(@str) END FETCH NEXT FROM spid_cursor INTO @SpidToClose END CLOSE spid_cursor; DEALLOCATE spid_cursor; 

डेटाबेस को वापस लाने के लिए स्क्रिप्ट:

 USE master RESTORE DATABASE [FSID_test] FROM DISK = N'c:\BackupPathHere\BackupNameHere.bak' WITH FILE = 2 

SetUp परीक्षण से कॉल करने के लिए कोड

 public static void RevertDb() { //      -     .     var sb = new SqlConnectionStringBuilder(Utilities.ConnectionDb) { ConnectTimeout = 2, ApplicationName = "FSID Tests, clearing" }; using (var con = new SqlConnection(sb.ToString())) { con.Open(); using (var cmd = con.CreateCommand()) { cmd.CommandText = Utilities.CommandKillAllConectionsToDb; cmd.Parameters.AddWithValue("@ dbname", sb.InitialCatalog); //       var result = cmd.ExecuteScalar(); } } //      -     , .     .  . SqlConnection.ClearAllPools(); using (var con = new SqlConnection(sb.ToString())) { con.Open(); using (var cmd = con.CreateCommand()) { cmd.CommandText = Utilities.CommandRevertTestDb; cmd.ExecuteScalar(); } } } 

अब सब कुछ बहुत आसान लग रहा है, लेकिन इस प्रक्रिया में मुझे कई छोटी-मोटी समस्याओं को हल करना पड़ा जो मैंने पहले सामना की थी:

• कनेक्शनपूल पास में अद्भुत है। मैंने लंबे समय तक खोज की, किस तरह का संक्रमण कनेक्शन रखता है।
• KILL परम - यह पता चला है कि KILL को एक पैरामीटर के साथ नहीं बुलाया जा सकता है। EXEC के माध्यम से एक बाईपास है
• SP से चयन करें () - संग्रहीत कार्यविधियों के परिणामों की क्वेरी करना नहीं जानता था। मुझे पढ़ना था और मैं समाधान की तरह नहीं था।

इसलिए, व्यवहार में यह सब करने की कोशिश करते हुए, हम सुरक्षित रूप से कह सकते हैं कि दृष्टिकोण व्यवहार्य और सुविधाजनक है। विशेषताएं:

• परीक्षणों द्वारा कोड में झूलने वाले कनेक्शनों का पता लगाना। (यदि आप उन्हें बल से साफ नहीं करते हैं या सफाई में अधिक जटिल तर्क जोड़ते हैं)
• मूल सेट स्पष्ट है और परीक्षणों से परिवर्तन के अधीन नहीं है। आवश्यक होने पर बदलना आसान है।
• निरंतर एकीकरण सर्वर पर निर्माण के दौरान DB परीक्षणों का उपयोग करने के प्रयासों का उन्मूलन।

युपीडी:
टिप्पणियों में दो बातें सुझाई गई हैं:

• प्रत्येक परीक्षण रन के लिए एक नया डेटाबेस बनाएं - बाएं उपयोगकर्ताओं को डिस्कनेक्ट करने की आवश्यकता से बचें।
• वापस लेन-देन करने के लिए उपयोग करें, बैकअप नहीं

ये दृष्टिकोण, जैसे मेरे द्वारा प्रस्तावित, उनकी कमियों के बिना नहीं हैं (बनाया गया डेटाबेस हटा दिया जाना चाहिए, लेन-देन हमेशा तेजी से वापस नहीं होता है और संग्रहीत प्रक्रियाओं पर प्रतिबंध लगाता है), लेकिन यह उनके बारे में गंभीरता से विचार करने योग्य है।