FYI करें: यह लेख SQA डेज़ # 25 में मेरी बात का एक विस्तारित संस्करण है।

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

प्रसंग

SQL सर्वर का उपयोग करके और विभिन्न नैदानिक ​​परीक्षण डेटा युक्त एक बड़ा गोदाम है। यह विभिन्न स्रोतों (मुख्य रूप से दस्तावेज़-उन्मुख डेटाबेस) से भरा हुआ है। बहुत से ईटीएल कई अवसरों पर गोदाम के भीतर डेटा बदल देते हैं। इस डेटा को छोटे विशिष्ट कार्यों पर उन्मुख वेब ऐप्स द्वारा उपयोग करने के लिए छोटे DB में लोड किया जा सकता है। ग्राहक के कुछ ग्राहकों ने अपनी आवश्यकताओं के लिए एपीआई को लागू करने के लिए कहा। ऐसे एपीआई अक्सर संग्रहीत प्रक्रियाओं और विभिन्न प्रश्नों का उपयोग करते हैं।


सामान्य तौर पर, DBMS की तरफ बहुत अधिक मात्रा में कोड होता है।

हमें इसकी आवश्यकता क्यों है?

जैसा कि आप परिचय से देख सकते हैं, DB कोड एप्लिकेशन कोड का हिस्सा है और इसमें बग भी हो सकते हैं।

मुझे लगता है कि हम में से बहुत से बोहेम कर्व से परिचित हैं: कीड़े हमेशा प्रक्रिया में बाद में ठीक करने के लिए अधिक महंगे होते हैं। एक त्रुटि जो पहले के विकास के चरण में बनाई गई थी और बाद में एक पर स्थानीय हो सकती है, और अधिक खर्च हो सकती है। यह बहुत सारे अंतरिम चरणों (कोडिंग, यूनिट-टेस्टिंग, इंटीग्रेशन टेस्टिंग, सिस्टम टेस्टिंग आदि) से गुजरने की आवश्यकता के कारण है: दो बार डिबगिंग के लिए और कोड को उस चरण में वापस करने के लिए जहां यह पाया गया था। यह प्रभाव वेयरहाउस केस के लिए भी सही है। यदि ETL प्रक्रिया में कोई त्रुटि है और डेटा को कई बार संशोधित किया जाता है, तो हमें यह करना होगा:

1. समस्या के स्रोत पर सभी डेटा परिवर्तन चरणों से गुजरें
2. समस्या को ठीक करें
3. फिर से उचित डेटा प्राप्त करें (अतिरिक्त मैनुअल संपादन की आवश्यकता हो सकती है)
4. सुनिश्चित करें कि बग के कारण कोई अन्य टूटा हुआ डेटा नहीं है।

यह मत भूलो कि हम नरम खिलौने नहीं बेचते हैं। नैदानिक ​​परीक्षणों के रूप में ऐसे क्षेत्र में एक गलती न केवल व्यापार बल्कि मानव स्वास्थ्य को भी नुकसान पहुंचा सकती है।

कैसे करें टेस्ट?

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

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


XLS फ़ाइल, आवश्यकताओं के साथ 2 कॉलम + अन्य कॉलमों में अतिरिक्त जानकारी खंडित + भ्रमित मार्कअप। यदि आवश्यक हो तो प्रारंभिक इच्छाओं को बहाल करना मुश्किल हो सकता है। टेस्ट कार्यान्वयन बारीकियों को रिकॉर्ड करने में मदद कर सकते हैं। बेशक, उन्हें प्रलेखन के प्रतिस्थापन के रूप में नहीं माना जाना चाहिए।

दुर्भाग्य से, कोड जटिलता वृद्धि के साथ परीक्षण जटिलता बढ़ जाती है, इसलिए, इस प्रभाव को खत्म किया जा सकता है।

टेस्ट स्वतःस्फूर्त विलय के खिलाफ एक अतिरिक्त सुरक्षा परत हो सकते हैं। सीआई ऑटो परीक्षण उनकी औपचारिकता के कारण इस समस्या में मदद करते हैं।

इसलिए, यदि हमने स्वचालन का उपयोग करने का निर्णय लिया है, तो हमें इसके लिए एक उपकरण चुनने की आवश्यकता है।

परीक्षण के लिए क्या उपयोग करना है?

DB कोड परीक्षण के मामले में, मुझे 2 दृष्टिकोण दिखाई देते हैं: SQL- संचालित (जब एक उपकरण सीधे DBMS में काम कर रहा है) और गैर-SQL- संचालित। यहाँ मुख्य अंतर मुझे मिले:
SQL सर्वर के मामले में, हमारे पास कई विकल्प हैं:
स्केल "उत्कृष्ट - फेलिंग" व्यक्तिपरक है, क्षमा करें, इसके चारों ओर एक रास्ता खोजना मुश्किल है।

"पहली उपस्थिति" - फ्रेमवर्क उपस्थिति की सबसे शुरुआती तारीख जो मुझे मिल सकती है - जल्द से जल्द रिलीज या प्रतिबद्ध।

जैसा कि आप देख सकते हैं, SQL- संचालित विकल्पों को काफी समय पहले छोड़ दिया गया था, और tSQLt केवल वर्तमान में समर्थित उत्पाद है। इसके अलावा, tSQLt कार्यात्मक रूप से जीतता है। केवल एक ही चीज़ है, TST tSQLt की तुलना में कुछ अधिक समृद्ध है; हालाँकि, मुझे संदेह है कि यह सभी विपक्षों को पछाड़ सकता है।

TSQLt प्रलेखन में कुछ बारीकियाँ हैं, मैं बाद में उनका वर्णन करूँगा।

गैर-SQL-संचालित दुनिया में, चीजें इतनी स्पष्ट नहीं हैं। विकल्प विकसित हो रहे हैं, हालांकि अति-सक्रिय नहीं हैं। DbFit FitNesse फ्रेमवर्क पर आधारित एक बहुत ही रोचक उपकरण है। यह परीक्षण लिखने के लिए विकि मार्कअप का उपयोग करता है। स्लैकर एक दिलचस्प भी है: BDD दृष्टिकोण को DB कोड परीक्षण के लिए सुझाया गया है।

मुझे गैर-एसक्यूएल-संचालित समाधानों में अभिकथन के बारे में कहना चाहिए। पहली नजर में, दावे की मात्रा कम है, और हम सोच सकते हैं कि ऐसे उपकरण बदतर हैं। लेकिन हमें यह ध्यान रखना चाहिए कि वे मूल रूप से tSQLt से अलग हैं, इसलिए, इस तरह की सतही झलक गलत है।

नवीनतम पंक्ति - "NUnit, आदि" - एक अनुस्मारक की तरह है। अतिरिक्त पुस्तकालयों की सहायता से बहुत सी सामान्य इकाई-परीक्षण रूपरेखाएँ DB कोड पर लागू की जा सकती हैं। इस पंक्ति में बहुत सारे N / A हैं क्योंकि इस पंक्ति में, वास्तव में कई उपकरण शामिल हैं। यह "जोर" कॉलम में "बारीकियों" का स्रोत है - विभिन्न उपकरण अलग-अलग सेट प्रदान कर सकते हैं और इस बात की कोई गारंटी नहीं है कि सभी दावे डीबी पर लागू किए जा सकते हैं।

एक और दिलचस्प मीट्रिक के रूप में, हम Google रुझानों पर विचार कर सकते हैं।


बारीकियों:

1. मैंने स्लैकर को शामिल नहीं करने का फैसला किया क्योंकि इस नाम का मतलब अलग-अलग चीजें हो सकती हैं (और "स्लैकर फ्रेमवर्क" जैसे प्रश्न मुश्किल से ग्राफ पर देखे जाते हैं)।
2. जिज्ञासा से बाहर (और क्योंकि एक स्लॉट खाली रहा), मैंने टीएसटी प्रवृत्ति को जोड़ा है। लेकिन यह शायद ही हमें असली तस्वीर दिखाता है क्योंकि यह संक्षिप्त नाम है जिसका मतलब अलग-अलग चीजें भी हो सकती हैं।
3. मैंने NUnit और इसके एनालॉग्स को शामिल नहीं किया है। ये उपकरण "सामान्य" कोड परीक्षण के लिए रूपरेखा हैं, इसलिए उनके रुझान हमारे संदर्भ के लिए वर्णनात्मक नहीं हैं।

जैसा कि आप देख सकते हैं, tSQLt सूची में सबसे अधिक खोज योग्य उपकरण है। एक और (कम) लोकप्रिय उपकरण DbFit है। अन्य उपकरणों की सीमित लोकप्रियता है।

द्वारा और बड़े, हम देख सकते हैं कि पृष्ठभूमि के खिलाफ tSQLt चमक रहा है।

TSQLt क्या है?

यह अनुमान लगाना आसान है कि tSQLt एक SQL- संचालित इकाई-परीक्षण ढाँचा है। आधिकारिक साइट https://tsqlt.org है ।

यह वादा किया गया है कि tSQLt 2005 SP2 से शुरू होने वाले SQL सर्वर का समर्थन करता है। मैंने इस तरह के शुरुआती संशोधनों की जाँच नहीं की है, लेकिन मुझे हमारे देव-सर्वर और २०१ rev की स्थानीय मशीन पर २०१२ की कोई समस्या नहीं दिख रही है।

ओपन सोर्स, Apache 2.0 लाइसेंस, GitHub पर उपलब्ध है । हमेशा की तरह, हम वाणिज्यिक परियोजनाओं में मुफ्त में कांटा, योगदान, उपयोग कर सकते हैं और, क्या अधिक महत्वपूर्ण है, सीएलआर में स्पायवेयर से डरने की ज़रूरत नहीं है।

यांत्रिकी

परीक्षण के मामले संग्रहीत प्रक्रिया हैं। उन्हें परीक्षण कक्षाओं (एक्सयूनिट शब्दावली में टेस्ट सूट) में जोड़ा जा सकता है।

परीक्षण कक्षाएं और कुछ नहीं बल्कि डीबी स्कीमा हैं। tSQLt को उन्हें NewTestClass प्रक्रिया के साथ पंजीकृत करना होगा जो एक विशेष तालिका में परीक्षण कक्षाएं जोड़ता है।

एक SetUp प्रक्रिया निर्धारित करना संभव है। प्रत्येक अलग-अलग परीक्षण केस चलने से पहले ऐसी प्रक्रिया चलेगी।

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

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

सुविधाएँ और उदाहरण

आधिकारिक गाइड को दोहराने के लिए अनिच्छुक, मैं उदाहरणों पर tSQLt विशेषताओं को दिखाऊंगा।

अस्वीकरण:

• उदाहरण सरल हैं
• मूल कोड पूरी तरह से मेरा नहीं है - बल्कि सामूहिक रचना है
• उदाहरण 2 पूरी तरह से सुविधाओं को प्रदर्शित करने के लिए मेरे द्वारा काल्पनिक है।

उदाहरण # 1: CsvSql

ग्राहक के किसी एक ग्राहक के अनुरोध पर निम्नलिखित लागू किया गया था। Nvarchar (MAX) फ़ील्ड में SQL-क्वेरीज़ संग्रहीत हैं। उन्हें देखने के लिए न्यूनतम UI बनाया गया है। इन प्रश्नों द्वारा उत्पन्न परिणाम सेट का उपयोग CSV- फ़ाइलों के रूप में आगे की रचना के लिए बैकएंड में किया जाता है। CSV- फ़ाइलों को एपीआई कॉल द्वारा अनुरोध किया जा सकता है।


परिणाम सेट बड़े होते हैं और बड़ी संख्या में कॉलम होते हैं। ऐसे परिणाम सेट का एक काल्पनिक उदाहरण:


यह परिणाम सेट नैदानिक ​​परीक्षण डेटा का प्रतिनिधित्व करता है। आइए [क्लीनिकनम] गणना पर करीब से नज़र डालें। हमारे पास 2 टेबल हैं: [परीक्षण] और [क्लिनिक]।


एक FK है: [क्लिनिक]। [परीक्षण] -> [परीक्षण] [परीक्षण]। जाहिर है, यह कई क्लीनिकों को प्राप्त करने के लिए COUNT (*) का उपयोग करने के लिए पर्याप्त है:

SELECT COUNT(*), ...  FROM dbo.Trial  LEFT JOIN dbo.Clinic    ON Trial.ID = Clinic.TrialID  WHERE Trial.Name = @trialName  GROUP BY ... 

हम ऐसी क्वेरी का परीक्षण कैसे कर सकते हैं? सबसे पहले, स्टब फ़ेकटेबल का उपयोग करें, जो हमारे आगे के काम को बहुत आसान बना देगा।

 EXEC tSQLt.FakeTable 'dbo.Trial'; EXEC tSQLt.FakeTable 'dbo.Clinic'; 

फ़ेकटेबल एक साधारण बात करता है - पुरानी तालिकाओं का नाम बदलकर एक ही नाम के साथ नए बनाता है। समान नाम, समान कॉलम, लेकिन बाधाओं और ट्रिगर के बिना।

हमें इसकी आवश्यकता है क्योंकि:

1. टेस्ट डीबी में कुछ डेटा शामिल हो सकते हैं जो परीक्षण के उचित भाग को रोक सकते हैं। FakeTable हमें उन पर निर्भर नहीं करने की अनुमति देता है।
2. आमतौर पर, हमें परीक्षण प्रयोजनों के लिए केवल कुछ कॉलम भरने की आवश्यकता होती है। तालिका में उनमें से बहुत कुछ हो सकता है, जिसमें अक्सर बाधाएं और ट्रिगर होते हैं। हम बाद में डेटा सम्मिलित करना आसान बनाते हैं - हम केवल परीक्षण जानकारी के लिए आवश्यक सम्मिलित करेंगे, परीक्षण को यथासंभव न्यूनतम रखते हुए।
3. कोई अवांछित ट्रिगर रन नहीं होगा, इसलिए, हमें पोस्ट-प्रभाव के बारे में चिंता करने की आवश्यकता नहीं है।

फिर हम आवश्यक परीक्षण डेटा सम्मिलित करते हैं:

 INSERT INTO dbo.Trial ([ID], [Name]) VALUES (1,   'Valerian'); INSERT INTO dbo.Clinic ([ID], [TrialID], [Name]) VALUES (1,   1,        'Clinic1'), (2,   1,        'Clinic2'); 

हम DB से क्वेरी प्राप्त करते हैं, [वास्तविक] तालिका बनाते हैं और परिणाम के साथ इसे भरते हैं
क्वेरी से सेट करें।

 DECLARE @sqlStatement NVARCHAR(MAX) = (SELECT… CREATE TABLE actual ([TrialID], ...); INSERT INTO actual EXEC sp_executesql @sqlStatement, ... 

अब, हम [अपेक्षित] - हमारे अपेक्षित मूल्यों को भरते हैं:

 CREATE TABLE expected (   ClinicsNum INT ); INSERT INTO expected SELECT 2 

मैं आपका ध्यान आकर्षित करना चाहता हूं कि हमारे पास [अपेक्षित] तालिका में केवल एक कॉलम है, हालांकि हमारे पास [वास्तविक] कॉलम में पूरा सेट है।


यह AssertEqualsTable प्रक्रिया की एक उपयोगी विशेषता के कारण है जिसे हम मान सत्यापन के लिए उपयोग करेंगे।

 EXEC tSQLt.AssertEqualsTable   'expected',   'actual',   'incorrect number of clinics'; 

यह केवल उन स्तंभों की तुलना करता है जो दोनों तालिकाओं में प्रस्तुत किए जाते हैं। यह हमारे मामले में बहुत सुविधाजनक है क्योंकि परीक्षण के तहत क्वेरी बहुत सारे कॉलम लौटाती है, प्रत्येक बहुत जटिल तर्क के साथ जुड़ा हुआ है। हम परीक्षण मामलों को बढ़ाना नहीं चाहते हैं, इसलिए यह सुविधा वास्तव में मदद करती है। बेशक, यह सुविधा एक दोधारी तलवार है। यदि [वास्तविक] SELECT TOP 0 के माध्यम से भरा हुआ है और एक बिंदु पर एक अप्रत्याशित कॉलम दिखाई देता है, तो ऐसा परीक्षण मामला इसे पकड़ नहीं पाएगा। इसे कवर करने के लिए आपको अतिरिक्त चेक लिखना होगा।

AservEqualsTable जुड़वां प्रक्रियाओं

यह उल्लेखनीय है कि tSQLt में AssertEqualsTable जैसी 2 प्रक्रियाएँ हैं। वे AssertEqualsTableSchema और AssertResultSetsHaveSameMetaData हैं। पहले एक AssertEqualsTable के रूप में ही करता है, लेकिन तालिकाओं मेटाडेटा पर। दूसरा एक ही करता है, लेकिन परिणाम मेटाडेटा पर सेट होता है।

उदाहरण # 2: बाधाओं

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

पिछले उदाहरण से स्थिति पर विचार करें। 2 टेबल - [परीक्षण] और [क्लिनिक]; [परीक्षण] FK:


आइए इसे जांचने के लिए एक टेस्ट केस लिखने की कोशिश करें। पहले की तरह, पिछले मामले में, हम तालिकाओं को नकली करते हैं:

 EXEC tSQLt.FakeTable '[dbo].[Trial]' EXEC tSQLt.FakeTable '[dbo].[Clinic]' 

उद्देश्य एक ही है - अनावश्यक सीमाओं से छुटकारा पाना। हम अनुचित प्रयास के बिना पृथक चेक चाहते हैं।

अगला, हम उस बाधा को वापस करते हैं जिसे हम ApplyConstraint का उपयोग करके परीक्षण करना चाहते हैं:

 EXEC tSQLt.ApplyConstraint   '[dbo].[Clinic]',   'Trial_FK'; 

अब हमारे पास चेक के लिए एक कॉन्फ़िगरेशन है। चेक ही यह है कि डेटा डालने की कोशिश करने से अपवाद होगा। टेस्ट केस पास होने के लिए हमें इस अपवाद को पकड़ने की जरूरत है। अपवाद हैंडलर ExpectException मदद कर सकता है।

 EXEC tSQLt.ExpectException   @ExpectedMessage = 'The INSERT statement conflicted...',   @ExpectedSeverity = 16,   @ExpectedState = 0; 

हम हैंडलर सेटिंग के बाद नॉन-इंसर्टेबल डालने की कोशिश कर सकते हैं।

 INSERT INTO [dbo].[Clinic] ([TrialID])   VALUES (1) 

अपवाद पकड़ा गया था। टेस्ट पास।

ApplyConstraint जुड़वां प्रक्रियाओं

TSQLt लेखकों द्वारा प्रस्तावित परीक्षण ट्रिगर्स का तरीका परीक्षण बाधाओं के समान है। हम मेज पर ट्रिगर लौटने के लिए ApplyTrigger प्रक्रिया का उपयोग कर सकते हैं। उसके बाद, सब कुछ ऊपर के उदाहरण के रूप में चला जाता है - ट्रिगर शुरू करें, परिणाम की जांच करें।

ExpectNoException - ExpectException's antonym

अपवाद नहीं होने पर मामलों के लिए एक ExpectNoException प्रक्रिया है। यह उसी तरह से काम करता है जैसे कि एक्सपेक्टेशन अपवाद काम करता है सिवाय इसके कि अपवाद होने की स्थिति में परीक्षण विफल हो जाए।

उदाहरण # 3: सेमाफोर

कुछ संग्रहीत कार्यविधियाँ और विंडोज़ सेवाएँ हैं। उनके निष्पादन की शुरुआत विभिन्न बाहरी घटनाओं के कारण हो सकती है। हालांकि, उनके निष्पादन का क्रम तय है। तो, यह डीबी की तरफ एक्सेस कंट्रोल को लागू करने के लिए आवश्यक है - यानी एक सेमीफोर। हमारे मामले में, सेमाफोर एक साथ काम करने वाली संग्रहीत प्रक्रियाओं का एक समूह है।

आइए एक प्रक्रिया को अर्धवृत्त के भीतर देखें। हमारे पास 2 टेबल हैं - [प्रक्रिया] और [प्रोकैस्टस]:


[प्रक्रिया] तालिका में निष्पादन के लिए अनुमत प्रक्रियाओं की सूची है। [ProcStatus], जाहिर है, पिछली तालिका से प्रक्रिया की स्थिति की सूची शामिल है।

तो, हमारी प्रक्रिया क्या करती है? सबसे पहले, यह निम्नलिखित जाँच करता है:

1. हमने प्रक्रिया के इनपुट मापदंडों में से एक के रूप में एक प्रक्रिया नाम पारित किया है। यह नाम [प्रक्रिया] तालिका के [नाम] क्षेत्र में खोजा गया है।
2. यदि प्रक्रिया का नाम मिल गया है, तो यह [प्रक्रिया] तालिका के [IsRunable] झंडे की जाँच करता है।
3. यदि झंडा चालू है, तो हम मानते हैं कि प्रक्रिया चल सकती है। अंतिम जांच [ProcStatus] तालिका में होती है। हमें यह सुनिश्चित करने की आवश्यकता है कि प्रक्रिया वर्तमान में नहीं चल रही है, जिसका अर्थ है कि [प्रोकैस्टस] तालिका में "इनप्रोग" स्थिति के साथ प्रक्रिया के बारे में रिकॉर्ड की अनुपस्थिति।

यदि सब कुछ ठीक है और सभी चेक पास हो गए हैं, तो हम अपनी प्रक्रिया के बारे में एक नया रिकॉर्ड जोड़ते हैं [ProcStatus] तालिका में स्थिति "InProg" के साथ। इस नए रिकॉर्ड की आईडी ProcStatusId आउटपुट पैरामीटर के साथ वापस आ गई है।

अगर कुछ गलत हुआ है, तो हम निम्नलिखित की उम्मीद करते हैं:

1. एक सिस्टम प्रशासक को एक ईमेल भेजा जाता है।
2. ProcStatusId = -1 लौटाया गया है।
3. कोई नया [ProcStatus] रिकॉर्ड नहीं जोड़ा गया।

चलो [प्रक्रिया] तालिका में प्रक्रिया की अनुपस्थिति के मामले की जांच के लिए एक परीक्षण मामला बनाएं।

हम फ़ेकटेबल का फिर से उपयोग करते हैं। यह यहाँ बहुत महत्वपूर्ण नहीं है, लेकिन यह सुविधाजनक हो सकता है क्योंकि:

1. यह गारंटी है कि कोई डेटा नहीं होगा जो परीक्षण मामले के निष्पादन को बाधित कर सकता है।
2. नए [ProcStatus] रिकॉर्ड अनुपस्थिति की आगे की जांच को सरल बनाया जाएगा।

 EXEC tSQLt.FakeTable 'dbo.Process'; EXEC tSQLt.FakeTable 'dbo.ProcStatus'; 

एक [SendEmail] प्रक्रिया है जिसका नाम स्वयं के लिए बोलता है। हमें इसकी कॉल को पकड़ने की जरूरत है। tSQLt उसके लिए SpyProcedure मॉक का उपयोग करने का सुझाव देता है।

 EXEC tSQLt.SpyProcedure 'dbo.SendEmail' 

SpyProcedure निम्नलिखित करता है:

1. एक नाम के साथ एक तालिका बनाता है जो [dbo] जैसा दिखता है। [प्रक्रिया .Name_SpyProcedureLog]
2. फ़ेकटेबल की तरह, मूल प्रक्रिया को एक स्वचालित रूप से जनरेट किए गए एक ही नाम के साथ, लेकिन अंदर लॉजिक लॉजिक के साथ बदल देता है। यदि आवश्यक हो तो आप अपने स्वयं के तर्क भी उत्पन्न प्रक्रिया में जोड़ सकते हैं।

यह अनुमान लगाना मुश्किल नहीं है कि लॉग [dbo] में दर्ज किए गए हैं। [SendEmail_SpyProcedureLog] तालिका। इस तालिका में एक [_ID_] कॉलम है जो कॉल के अनुक्रम संख्या के लिए है। बाद के स्तंभों को प्रक्रिया में पारित किए गए मापदंडों के नाम पर रखा गया है और उन्हें इकट्ठा करने के लिए उपयोग किया जाता है, इसलिए, मापदंडों के मूल्यों को भी सत्यापित किया जा सकता है।


आखिरी चीज़ जो हमें करने की ज़रूरत है, उससे पहले सेमीफोर कॉल को [ProcStatusId] मान को संग्रहीत करने के लिए एक वैरिएबल बनाना होगा (अधिक सटीक होना चाहिए, -1, जैसा कि रिकॉर्ड नहीं जोड़ा जाएगा)।

 DECLARE @ProcStatusId BIGINT; 

हम सेमाफोर कहते हैं:

 EXEC dbo.[Semaphore_JobStarter]   'SomeProcess',   @ProcStatusId OUTPUT; -- here we get -1 

अब हमारे पास चेक के लिए आवश्यक सभी डेटा हैं। चलो जाँच से शुरू करते हैं
यह संदेश भेजा गया है।

 IF NOT EXISTS (   SELECT *   FROM dbo.SendEmail_SpyProcedureLog) EXEC tSQLt.Fail 'SendEmail has not been run.'; 

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

अब हम AssertEmptyTable प्रक्रिया के साथ [ProcStatus] तालिका में रिकॉर्ड की अनुपस्थिति की जांच करते हैं।

 EXEC tSQLt.AssertEmptyTable 'dbo.ProcStatus'; 

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

हम आसानी से ProcStatusId = -1 समानता की जांच कर सकते हैं।

 EXEC tSQLt.AssertEquals   -1,       @ProcStatusId,       'Wrong ProcStatusId.'; 

अभिकथन न्यूनतम है। यह सिर्फ 2 मूल्यों की तुलना करता है, असाधारण कुछ भी नहीं।

AservEquals जुड़वां प्रक्रियाओं

हमारे पास मूल्यों की तुलना के लिए निम्नलिखित प्रक्रियाएँ हैं:

• AssertEquals
• AssertNotEquals
• AssertEqualsString
• AssertLike

नाम स्व-व्याख्यात्मक हैं, मुझे लगता है। केवल एक ही प्रक्रिया जिस पर मैं जोर देना चाहता हूं वह है एसेटर्क्वाल्सस्ट्रिंग। यह स्ट्रिंग मान सत्यापन के लिए समर्पित प्रक्रिया है। हमें दिए गए सार्वभौमिक सिद्धांतों पर विचार करते हुए एक और प्रक्रिया की आवश्यकता क्यों है? बात यह है, AssertEquals / AssertNotEquals / AssertLike SQL_VARIANT प्रकार के साथ काम करते हैं। NVARCHAR (MAX) SQL_VARIANT में शामिल नहीं है, इसलिए tSQLt डेवलपर्स को एक अतिरिक्त प्रक्रिया करनी पड़ी।

नकली कार्य

एक धक्का पर, हम FakeFunction को SpyProcedure के समान एक प्रक्रिया कह सकते हैं। यह नकली किसी भी फ़ंक्शन को सरल के साथ बदलने की अनुमति देता है। चूंकि SQL सर्वर फ़ंक्शन टूथपेस्ट ट्यूब की तरह काम करता है (परिणाम केवल "छेद" के माध्यम से वापस आ जाता है), यह लॉगिंग कार्यक्षमता को लागू करने के लिए तकनीकी रूप से असंभव है। आंतरिक तर्क प्रतिस्थापन एकमात्र उपलब्ध तरीका है।

नुकसान

मैं आपको कुछ नुकसानों के बारे में बताना चाहता हूं जिनका आप tSQLt उपयोग के दौरान सामना कर सकते हैं। इस मामले में "नुकसान" का मतलब है कि कुछ मुद्दे जो SQL सर्वर प्रतिबंध और / या जो फ्रेमवर्क डेवलपर्स द्वारा हल किया जाना असंभव है।

लेन-देन रोलबैक और डूमिंग

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

वर्कअराउंड के रूप में, हम सेवपॉइंट का उपयोग करते हैं। विचार सरल है। शुरुआत में, हम जांचते हैं कि हम लेनदेन के अंदर हैं या नहीं। यदि हाँ, तो हमें लगता है कि यह एक tSQLt लेनदेन है और एक सेव पॉइंट है, इसलिए यदि आवश्यक हो तो हम इसे वापस रोल करेंगे। यदि नहीं, तो हम एक नया लेनदेन शुरू करते हैं। वास्तव में, हम घोंसले के शिकार की अनुमति नहीं देते हैं।


समस्या लेनदेन डूइंग द्वारा जटिल है - यह एक अपवाद फेंक दिए जाने पर हो सकता है। डूम किए गए लेन-देन के साथ-साथ एक सेव पॉइंट पर वापस ले जाने के लिए प्रतिबद्ध नहीं किया जा सकता है, इसलिए हमें इसे फिर से सबसे बाहरी ट्रांजैक्शन पर वापस रोल करना होगा।

ऊपर वर्णित बिंदुओं को ध्यान में रखते हुए, हमें निम्नलिखित संरचना का उपयोग करना चाहिए:

 DECLARE @isNestedTransaction BIT =   CASE WHEN @@trancount > 0       THEN 'true'       ELSE 'false' END; BEGIN TRY   IF @isNestedTransaction = 'false'       BEGIN TRANSACTION   ELSE       SAVE TRANSACTION SavepointName;       -- something useful   IF @isNestedTransaction = 'false'   COMMIT TRANSACTION; END TRY BEGIN CATCH   DECLARE @isCommitable BIT =       CASE WHEN XACT_STATE() = 1           THEN 'true'           ELSE 'false'   END;   IF @isCommitable = 'true' AND @isNestedTransaction = 'true'       ROLLBACK TRANSACTION SavepointName;   ELSE       ROLLBACK;   THROW; END CATCH; 

आइए कोड टुकड़ा की समीक्षा करें। सबसे पहले, हमें यह निर्धारित करने की आवश्यकता है कि क्या हम लेनदेन के अंदर हैं या नहीं।

 DECLARE @isNestedTransaction BIT =   CASE WHEN @@trancount > 0       THEN 'true'       ELSE 'false' END; 

@IsNestedTransaction ध्वज को प्राप्त करने के बाद, हम TRY- ब्लॉक को शुरू कर सकते हैं और एक बचत बिंदु सेट कर सकते हैं या स्थिति के आधार पर लेनदेन शुरू कर सकते हैं।

 BEGIN TRY   IF @isNestedTransaction = 'false'       BEGIN TRANSACTION   ELSE       SAVE TRANSACTION SavepointName;       -- something useful 

कुछ उपयोगी करने के बाद, हम परिणाम देते हैं यदि यह एक "वास्तविक" प्रक्रिया है।

        -- something useful   IF @isNestedTransaction = 'false'   COMMIT TRANSACTION; END TRY 

बेशक, अगर यह एक परीक्षण मामला है, तो हमें कुछ भी करने की आवश्यकता नहीं है। tSQLt अंत में परिवर्तनों को स्वचालित रूप से वापस करेगा।

यदि कुछ गड़बड़ हो गई है और हम CATCH ब्लॉक में पहुंच गए हैं, तो हमें यह निर्धारित करने की आवश्यकता है कि लेनदेन सराहनीय है या नहीं।

 BEGIN CATCH   DECLARE @isCommitable BIT =       CASE WHEN XACT_STATE() = 1           THEN 'true'           ELSE 'false'   END; 

हम केवल तभी वापस सहेज सकते हैं जब:

1. लेनदेन सराहनीय है
2. यह एक परीक्षण रन है, इसलिए, savepoint मौजूद है।

अन्य सभी मामलों में हमें पूरे लेनदेन को वापस करना होगा।

    IF @isCommitable = 'true' AND @isNestedTransaction = 'true'       ROLLBACK TRANSACTION SavepointName;   ELSE       ROLLBACK;   THROW; END CATCH; 

हां, दुर्भाग्यवश, यदि हम परीक्षण चलाने के दौरान बिना लेन-देन की स्थिति में पहुंच गए हैं, तो भी हमें निष्पादन त्रुटि मिलती है।

Faketable और विदेशी कुंजी मुद्दा

आइए परिचित [परीक्षण] और [क्लिनिक] तालिकाओं की समीक्षा करें


हम [परीक्षण] एफके के बारे में याद करते हैं। इसका क्या कारण हो सकता है? ऊपर दिए गए उदाहरणों में हमने दोनों तालिकाओं पर फेकटेबल लागू किया। यदि हम इसका उपयोग केवल उन्हीं में से एक पर करते हैं, तो हम निम्नलिखित सेटअप तक पहुँचेंगे:


इसलिए, [क्लिनिक] में एक रिकॉर्ड सम्मिलित करने का प्रयास विफल हो सकता है, भले ही हमने [परीक्षण] के नकली-संस्करण में डेटा तैयार किया हो।

 [dbo].[Test_FK_Problem] failed: (Error) The INSERT statement conflicted with the FOREIGN KEY constraint "Trial_Fk". The conflict occurred in database "HabrDemo", table "dbo.tSQLt_tempobject_ba8f36353f7a44f6a9176a7d1db02493", column 'TrialID'.[16,0]{Test_FK_Problem,14} 

निष्कर्ष: नकली सभी या कोई भी नहीं। कोई नहीं के मामले में, जाहिर है, आपको सभी आवश्यक परीक्षण डेटा के साथ एक डीबी तैयार करना चाहिए।

सिस्टम प्रक्रियाओं पर SpyProcedure

दुर्भाग्य से, हम सिस्टम प्रक्रियाओं की जासूसी नहीं कर सकते:

 [HabrDemo].[test_test] failed: (Error) Cannot use SpyProcedure on sys.sp_help because the procedure does not exist[16,10] {tSQLt.Private_ValidateProcedureCanBeUsedWithSpyProcedure,7} 

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

पेशेवरों

त्वरित स्थापना

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

त्वरित शिक्षा

tSQLt सीखना आसान है। यह मेरे लिए एक कार्यदिवस से थोड़ा अधिक था। मैंने सहयोगियों से पूछा और यह दूसरों के लिए भी लगभग 1 कार्यदिवस लेता है। मुझे संदेह है कि इसमें और अधिक समय लग सकता है।

त्वरित सीआई एकीकरण

हमारी परियोजना पर CI एकीकरण को सेटअप करने में लगभग 2 घंटे का समय लगा। समय अलग-अलग हो सकता है, लेकिन यह सामान्य रूप से कोई समस्या नहीं है, और यह जल्दी से किया जा सकता है।

उपकरणों का एक व्यापक सेट

यह व्यक्तिपरक है, लेकिन मेरे विचार में tSQLt कार्यक्षमता समृद्ध है और शेर की जरूरतों का हिस्सा इसके द्वारा कवर किया जा सकता है। यदि यह पर्याप्त नहीं है, तो आप दुर्लभ और परिष्कृत मामलों के लिए हमेशा फेल प्रक्रिया का उपयोग कर सकते हैं।

सुविधाजनक प्रलेखन

आधिकारिक गाइड सुविधाजनक और सुसंगत हैं। भले ही यह आपका पहला यूनिट टेस्टिंग टूल हो, आप छोटी अवधि में आसानी से tSQLt के उपयोग को समझ सकते हैं।

साफ उत्पादन

परीक्षण आउटपुट को एक उदाहरण पाठ प्रारूप में लिया जा सकता है:

 [tSQLtDemo].[test_error_messages] failed: (Failure) Expected an error to be raised. [tSQLtDemo].[test_tables_comparison] failed: (Failure) useful and descriptive error message Unexpected/missing resultset rows! |_m_|Column1|Column2| +---+-------+-------+ |< |2 |Value2 | |= |1 |Value1 | |= |3 |Value3 | |> |2 |Value3 | +----------------------+ |Test Execution Summary| +----------------------+ |No|Test Case Name |Dur(ms)|Result | +--+------------------------------------+-------+-------+ |1 |[tSQLtDemo].[test_constraint] | 83|Success| |2 |[tSQLtDemo].[test_trial_view] | 83|Success| |3 |[tSQLtDemo].[test_error_messages] | 127|Failure| |4 |[tSQLtDemo].[test_tables_comparison]| 147|Failure| ----------------------------------------------------------------------------- Msg 50000, Level 16, State 10, Line 1 Test Case Summary: 4 test case(s) executed, 2 succeeded, 2 failed, 0 errored. ----------------------------------------------------------------------------- 

यह भी DB (क्लिक करने योग्य) से प्राप्त किया जा सकता है ...


... या XML के रूप में भी।

 <?xml version="1.0" encoding="UTF-8"?> <testsuites> <testsuite id="1" name="tSQLtDemo" tests="3" errors="0" failures="1" timestamp="2019-06-22T16:46:06" time="0.433" hostname="BLAHBLAHBLAH\SQL2017" package="tSQLt"> <properties /> <testcase classname="tSQLtDemo" name="test_constraint" time="0.097" /> <testcase classname="tSQLtDemo" name="test_error_messages" time="0.153"> <failure message="Expected an error to be raised." type="tSQLt.Fail" /> </testcase> <testcase classname="tSQLtDemo" name="test_trial_view" time="0.156" /> <system-out /> <system-err /> </testsuite> </testsuites> 

अंतिम प्रारूप बिना किसी समस्या के CI एकीकरण की अनुमति देता है। विशेष रूप से, हम एटलसियन बांस के साथ मिलकर tSQLt का उपयोग करते हैं।

रेडगेट का समर्थन

पेशेवरों में से एक के रूप में, मैं डीबीए उपकरण प्रदाताओं में से एक के समर्थन का नाम दे सकता हूं - रेडगेट। एसक्यूएल टेस्ट नाम का उनका SQL सर्वर मैनेजमेंट स्टूडियो प्लगइन शुरू से tSQLt के साथ काम करता है। इसके अलावा, RedGate Google समूहों में उनके शब्दों के अनुसार, tSQLt के मुख्य डेवलपर को देव-पर्यावरण के साथ मदद करता है।

विपक्ष

कोई अस्थायी टेबल फ़ेकिंग नहीं

tSQLt फ़ेकिंग अस्थायी तालिकाओं की अनुमति नहीं देता है। विचार, आवश्यकता के मामले में, आप एक अनौपचारिक एडऑन का उपयोग कर सकते हैं। दुर्भाग्य से, यह addon SQL Server 2016+ के साथ ही काम करता है।

बाहरी DBs के साथ काम करें

tSQLt को उसी DB में कोड के साथ काम करने के लिए डिज़ाइन किया गया है जिसमें फ्रेमवर्क स्थापित है। इस प्रकार, बाहरी डीबी के साथ इसका उपयोग करना असंभव हो सकता है। कम से कम, नकली काम नहीं करेगा।

 CREATE PROCEDURE [tSQLtDemo].[test_outer_db] AS BEGIN   SELECT TOP 10 * FROM [AdventureWorks2017].[Person].[Password]   EXEC tSQLt.FakeTable '[AdventureWorks2017].[Person].[Password]'   SELECT TOP 10 * FROM [AdventureWorks2017].[Person].[Password] END 

यह मुखर कार्य की तरह दिखता है, लेकिन उनकी कार्यशीलता की गारंटी नहीं है, निश्चित रूप से।

 CREATE PROCEDURE [tSQLtDemo].[test_outer_db_assertions] AS BEGIN   SELECT TOP 1 *   INTO #Actual   FROM [AdventureWorks2017].[Person].[Password]   SELECT *   INTO #Expected   FROM (          SELECT 'bE3XiWw=' AS [PasswordSalt]   ) expectedresult;   EXEC tSQLt.AssertEqualsTable '#Expected', '#Actual', 'The salt is not salty'; END 

प्रलेखन कीड़े

इसके बावजूद कि मैंने ऊपर उल्लेख किया है कि गाइड सुविधाजनक और सुसंगत हैं, प्रलेखन में कुछ मुद्दे हैं। इसमें पुराने हिस्से होते हैं।

उदाहरण 1. "क्विक स्टार्ट गाइड" से सोर्सफॉर्ग से फ्रेमवर्क डाउनलोड करने का सुझाव मिलता है।
वे 2015 में SourceForge से चले गए।

उदाहरण 2. ApplyConstraint गाइड अपवाद अपवाद उदाहरण के अंदर विफल प्रक्रिया के साथ भारी डिजाइन का उपयोग करता है। यह ExpectException का उपयोग करके सरल और स्पष्ट कोड से बदला जा सकता है।

 CREATE PROCEDURE ConstraintTests.[test ReferencingTable_ReferencedTable_FK prevents insert of orphaned rows] AS BEGIN EXEC tSQLt.FakeTable 'dbo.ReferencedTable'; EXEC tSQLt.FakeTable 'dbo.ReferencingTable'; EXEC tSQLt.ApplyConstraint 'dbo.ReferencingTable','ReferencingTable_ReferencedTable_FK'; DECLARE @ErrorMessage NVARCHAR(MAX); SET @ErrorMessage = ''; /* [NB] Why don't we use ExceptException below? */ BEGIN TRY INSERT INTO dbo.ReferencingTable ( id, ReferencedTableId ) VALUES ( 1, 11 ) ; END TRY BEGIN CATCH SET @ErrorMessage = ERROR_MESSAGE(); END CATCH IF @ErrorMessage NOT LIKE '%ReferencingTable_ReferencedTable_FK%' BEGIN EXEC tSQLt.Fail 'Expected error message containing ''ReferencingTable_ReferencedTable_FK'' but got: ''',@ErrorMessage,'''!'; END END GO 

और यह उम्मीद है, क्योंकि ...

आंशिक परित्याग

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

SQL सर्वर 2017 समस्या

यदि आप SQL Server 2017 का उपयोग कर रहे हैं तो tSQLt स्थापना के लिए कुछ अतिरिक्त क्रियाओं की आवश्यकता हो सकती है। Microsoft ने इस रिलीज़ के बाद 2012 में पहला सुरक्षा परिवर्तन लागू किया। "सीएलआर सख्त सुरक्षा" सर्वर-स्तरीय ध्वज को जोड़ा गया है। यह ध्वज अहस्ताक्षरित असेंबली का निर्माण रोक देता है (यहां तक ​​कि सेफ)। विस्तृत विवरण एक अलग लेख के हकदार हैं (और, सौभाग्य से, हमारे पास पहले से ही एक अच्छा है; अनुक्रम में लेखों का पालन भी देखें। बस इसके लिए मानसिक रूप से तैयार रहें।

बेशक, मैं इस मुद्दे को "नुकसान" के लिए जिम्मेदार ठहरा सकता हूं, लेकिन इस मुद्दे को tSQLt डेवलपर्स द्वारा हल किया जा सकता है। GitHub का मुद्दा पहले ही उठ चुका है । फिर भी, अक्टूबर 2017 से इसे हल नहीं किया गया है।

अन्य DBMS के लिए विकल्प (±)

tSQLt एक तरह का नहीं है। यद्यपि आप CLR और T-SQL बारीकियों के कारण अन्य DBMS में इसका उपयोग नहीं कर सकते हैं, फिर भी आप कुछ समान पा सकते हैं। यह ध्यान देने योग्य है कि ये विकल्प tSQLt के बहुत करीब नहीं हैं, इसलिए मेरा मतलब है कि SQL- संचालित दृष्टिकोण।

उदाहरण के लिए, PostgreSQL उपयोगकर्ता pgTAP की कोशिश कर सकते हैं। यह परीक्षणों और टैप आउटपुट प्रारूप के लिए मूल PL / pgSQL का उपयोग करके एक अच्छी तरह से विकसित और सक्रिय रूप से विकासशील टूल है। इसी तरह का टूल MyTap आपको MySQL के तहत परीक्षणों में मदद कर सकता है। यह ढांचा pgTAP की तुलना में थोड़ा कम कार्यात्मक है लेकिन फिर भी उपयोगी हो सकता है। और यह सक्रिय विकास में भी है। यदि आप एक Oracle उपयोगकर्ता हैं, तो आपके पास बहुत शक्तिशाली उपकरण utPLSQL का उपयोग करने का अवसर है। यह बहुत सक्रिय रूप से विकसित हो रहा है और बड़ी संख्या में सुविधाएँ प्रदान करता है।

निष्कर्ष

मैं 2 विचारों को व्यक्त करना चाहता था:

पहला: DB कोड परीक्षण की उपयोगिता। यदि आप SQL सर्वर, Oracle, MySQL, या कुछ और का उपयोग कर रहे हैं तो यह महत्वपूर्ण नहीं है। यदि आपके DB में अप्रयुक्त तर्क हैं, तो आप जोखिम उठा रहे हैं। अन्य सभी कोडों में अन्य सभी बगों के रूप में, DB कोड बग्स उत्पाद और इसे प्रदान करने वाली कंपनी को नुकसान पहुंचा सकते हैं।

दूसरा: उपकरण विकल्प। जो SQL सर्वर के साथ काम करते हैं, tSQLt, भले ही यह 100% विजेता न हो, निश्चित रूप से ध्यान देने योग्य है। धीमी गति से विकास और कुछ मुद्दों के बावजूद, यह अभी भी एक व्यावहारिक ढांचा है जो आपके काम को बहुत आसान बना सकता है।