FYI करें: यह लेख SQA डेज़ # 25 पर मेरी रिपोर्ट का एक विस्तारित संस्करण है।सहकर्मियों के साथ संवाद करने के मेरे अनुभव के आधार पर, मैं कह सकता हूं कि डेटाबेस में परीक्षण कोड एक सामान्य अभ्यास नहीं है। यह संभावित खतरा हो सकता है। डेटाबेस में तर्क उन्हीं लोगों द्वारा लिखा जाता है जो "नियमित" कोड लिखते हैं। नतीजतन, त्रुटियां भी वहां मौजूद हो सकती हैं, और वे उत्पाद, व्यवसाय और उपभोक्ताओं के लिए नकारात्मक परिणाम भी दे सकते हैं। इससे कोई फर्क नहीं पड़ता कि यह संग्रहित प्रक्रियाओं के बारे में है जो बैकएंड की मदद करता है, या ईटीएल के बारे में जो डेटा को भंडारण में परिवर्तित करते हैं - एक जोखिम है, और परीक्षण इसे काफी कम कर सकते हैं। मैं आपको बताना चाहता हूं कि tSQLt क्या है और यह SQL सर्वर में परीक्षण कोड में कैसे हमारी मदद करता है।
प्रसंग
विभिन्न नैदानिक अनुसंधान डेटा वाले SQL सर्वर पर एक बड़ा वेयरहाउस है। यह विभिन्न स्रोतों (मुख्य रूप से दस्तावेज़-उन्मुख डेटाबेस) से भरा हुआ है। सर्वर के अंदर, डेटा को बार-बार ETL का उपयोग करके परिवर्तित किया जाता है। भविष्य में, यह डेटा वेब अनुप्रयोगों द्वारा उपयोग के लिए छोटे डेटाबेस में अपलोड किया जा सकता है जो कुछ छोटी विशिष्ट समस्याओं को हल करता है। ग्राहक के कुछ ग्राहक अपनी आंतरिक जरूरतों के लिए एपीआई भी मांगते हैं। ऐसे एपीआई के कार्यान्वयन में, संग्रहीत प्रक्रियाओं और प्रश्नों का अक्सर उपयोग किया जाता है।
सामान्य तौर पर, कोड क्रम में DBMS की तरफ होता है।
यह सब क्यों जरूरी है
जैसा कि पहले से ही परिचय से समझा जाता है, डेटाबेस में कोड समान कोड है
बाकी की तरह अनुप्रयोग, और भी त्रुटियाँ हो सकती हैं।
मुझे लगता है कि बहुत से लोग इसकी खोज के समय बग की कीमत पर निर्भरता से अवगत हैं, जिसकी खोज आमतौर पर बैरी बोहेम को जिम्मेदार ठहराया जाता है। प्रारंभिक चरण में की गई एक त्रुटि और बाद के चरण में पता लगाया जाना कई चरणों (कोडिंग, यूनिट, एकीकरण, सिस्टम परीक्षण, आदि) के माध्यम से जाने की आवश्यकता के कारण अधिक महंगा हो सकता है, बार-बार दोनों त्रुटि को स्थानीय बनाने और सही कोड को वापस लाने के लिए। जिस चरण में समस्या की पहचान की गई थी। यह प्रभाव गोदाम मामले के लिए भी प्रासंगिक है। यदि कोई त्रुटि ईटीएल में होती है, और डेटा कई परिवर्तनों से गुजरता है, तो यदि डेटा में कोई त्रुटि पाई जाती है, तो आपके पास होगा:
- समस्या का स्थानीयकरण करने के लिए सभी रूपांतरण चरणों से गुजरें
- समस्या को ठीक करें।
- सही किए गए डेटा को फिर से प्राप्त करें (मैन्युअल सुधारों को बाहर नहीं किया गया है)।
- सत्यापित करें कि त्रुटि के कारण गलत डेटा कहीं और दिखाई नहीं दिया।
यह मत भूलो कि हम नरम खिलौने नहीं बेचते हैं। नैदानिक अनुसंधान जैसे क्षेत्र में एक गलती न केवल व्यापार के लिए, बल्कि लोगों के स्वास्थ्य को भी नुकसान पहुंचा सकती है।
कैसे करें टेस्ट?
चूंकि हम कोड परीक्षण के बारे में बात कर रहे हैं, हमारा मतलब इकाई और एकीकरण परीक्षण है। ये बातें बहुत पूर्वाभ्यास हैं और निरंतर प्रतिगमन को शामिल करती हैं। सख्ती से बोलना, कोई भी इस तरह के परीक्षण को मैन्युअल रूप से आयोजित करता है (ठीक है, शायद कुछ पूरी तरह से पतित मामलों के अपवाद के साथ)।
एक अच्छा बोनस: कोड का दस्तावेजीकरण करते समय परीक्षण एक सहायक सामग्री हो सकती है। वैसे, ग्राहक की आवश्यकताएं इस तरह दिख सकती हैं (क्लिक करने योग्य):
एक्सेल, आवश्यकताओं के साथ दो कॉलम + अन्य कॉलम + स्लेटेड मार्कअप में सहायक जानकारी बिखरे हुए, जो मदद करने से अधिक भ्रामक है। यदि आवश्यक हो, तो मूल इच्छाओं को पुनर्स्थापित करना मुश्किल हो सकता है। परीक्षण कार्यान्वयन की बारीकियों को पकड़ने में और अधिक सटीक रूप से मदद कर सकते हैं (बेशक, आपको उन्हें प्रलेखन के समकक्ष नहीं मानना चाहिए)।
दुर्भाग्य से, कोड की जटिलता के साथ, परीक्षणों की जटिलता बढ़ती है, और इस प्रभाव को समतल किया जा सकता है।
टेस्ट सहज वालरस के खिलाफ सुरक्षा की एक अतिरिक्त परत के रूप में काम कर सकते हैं। औपचारिकता के कारण सीआई में स्व-परीक्षण इस समस्या से निपटने में मदद करते हैं।
यदि हमारी पसंद स्वचालन के रास्ते पर गिर गई, तो हमें इसके कार्यान्वयन के लिए उपकरणों पर निर्णय लेने की आवश्यकता है।
कैसे करें टेस्ट?
डेटाबेस में कोड का परीक्षण करने के मामले में, मैं दो दृष्टिकोणों को अलग करता हूं: SQL- संचालित, यानी, DBMS में सीधे कार्य करना, और गैर-SQL-संचालित। मैं निम्नलिखित बारीकियों को उजागर करने में सक्षम था:
SQL सर्वर में, हमारे पास कुछ विकल्प हैं:
"अच्छे-बुरे" के मूल्यांकन व्यक्तिपरक हैं, क्षमा करें, इसके बिना, कहीं नहीं।
व्याख्या: "पहली उपस्थिति" उस ढांचे के जीवन पथ में सबसे शुरुआती तारीख है जिसे मैंने पाया है, यानी, जो जल्द से जल्द जारी या प्रतिबद्ध है।
आप देख सकते हैं कि SQL- संचालित विकल्पों को कुछ समय के लिए छोड़ दिया गया है, और tSQLt एकमात्र समर्थित विकल्प है। कार्यात्मक रूप से, tSQLt भी जीतता है। केवल एक चीज यह है कि जोर देने के मामले में, TSTT ttt की तुलना में थोड़ा समृद्ध विकल्प है, जो हालांकि, इसके विपक्ष को पछाड़ने की संभावना नहीं है।
TSQLt प्रलेखन में बारीकियां हैं, लेकिन मैं इस बारे में बाद में बात करूंगा।
गैर-SQL-संचालित दुनिया में, चीजें इतनी सीधी नहीं हैं। अल्टरनेटिव, अल सुपरिट नहीं सुपर एक्टिव, विकसित किए जा रहे हैं। DbFit FitNesse फ्रेमवर्क पर आधारित एक दिलचस्प उपकरण है। वह विकि मार्कअप पर लेखन परीक्षण प्रदान करता है। डेटाबेस के लिए परीक्षण लिखते समय स्लैकर भी एक जिज्ञासु चीज है - BDD दृष्टिकोण।
मैं गैर-एसक्यूएल-संचालित में अभिकथनों पर चर्चा करूंगा। बाह्य रूप से, उनमें से कुछ कम हैं, और कोई यह कह सकता है कि वे इस वजह से बदतर हैं। लेकिन यहां यह विचार करने योग्य है कि वे मूल रूप से tSQLt से अलग हैं। सब कुछ इतना सरल नहीं है।
अंतिम पंक्ति "NUnit, आदि" है - यह एक अनुस्मारक है। रोजमर्रा के काम में परिचित कई यूनिट-टेस्टिंग फ्रेमवर्क का उपयोग सहायक पुस्तकालयों का उपयोग करके सहायक डेटाबेस पर किया जा सकता है। तालिका में बहुत अधिक एन / ए है, क्योंकि यह रेखा, वास्तव में, कई उपकरण शामिल हैं। जोर स्तंभ में "बारीकियों" एक ही बिंदु से आते हैं - विभिन्न उपकरणों में, उनका सेट अलग-अलग हो सकता है, और डेटाबेस के लिए प्रयोज्यता का प्रश्न खुला है।
एक और दिलचस्प मीट्रिक के रूप में हम
Google रुझानों पर विचार कर सकते हैं।
बारीकियों:
- मैंने स्लैकर को शामिल नहीं किया, क्योंकि इस नाम का अर्थ बहुत सारी चीजें हो सकती हैं (और "स्लैकर ढांचे" जैसे अनुरोध चार्ट पर विशेष रूप से दिखाई नहीं देते हैं)।
- जिज्ञासा के लिए, TST प्रवृत्ति में इजाफा हुआ, लेकिन यह भी मामलों की स्थिति को ज्यादा प्रतिबिंबित नहीं करता है, क्योंकि यह एक संक्षिप्त नाम है जिसका मतलब है कि बहुत सारी चीजें।
- मैंने NUnit और इसके एनालॉग्स को शामिल नहीं किया है, क्योंकि ये मूल रूप से स्वयं अनुप्रयोगों के कोड के परीक्षण के लिए रूपरेखा थे, और उनके रुझान हमारे संदर्भ के संकेत नहीं हैं।
सामान्य तौर पर, हम कह सकते हैं कि एनालॉग्स की पृष्ठभूमि के खिलाफ tSQLt अनुकूल रूप से दिखता है।
TSQLt क्या है?
tSQLt, जैसा कि आप अनुमान लगा सकते हैं, एक SQL- संचालित इकाई परीक्षण रूपरेखा है।
→
आधिकारिक साइट2005 SP2 के बाद से SQL सर्वर समर्थन की घोषणा की गई है। मैं अब तक अतीत में कभी नहीं देख पाया, लेकिन हमारे पास देव सर्वर पर 2012 है, मेरे पास स्थानीय रूप से 2017 है - कोई समस्या नहीं थी।
ओपन सोर्स, Apache 2.0 लाइसेंस,
GitHub पर उपलब्ध है । आप कांटा, तस्करी, वाणिज्यिक परियोजनाओं में मुफ्त में उपयोग कर सकते हैं और, सबसे महत्वपूर्ण बात, सीएलआर में बुकमार्क से डरो नहीं।
काम यांत्रिकी
परीक्षण के मामले संग्रहीत प्रक्रिया हैं। उन्हें टेस्ट कक्षाओं (xUnit के संदर्भ में टेस्ट सूट) में जोड़ा जाता है।
परीक्षण कक्षाएं नियमित डेटाबेस स्कीमा से अधिक कुछ नहीं हैं। वे फ्रेमवर्क तालिकाओं में पंजीकरण द्वारा अन्य योजनाओं से भिन्न हैं। आप एक प्रक्रिया - tSQLt.NewTestClass पर कॉल करके इस तरह के पंजीकरण कर सकते हैं।
परीक्षण वर्ग के अंदर, एक सेटअप प्रक्रिया को परिभाषित करना भी संभव है जो प्रत्येक व्यक्तिगत परीक्षण मामले को निष्पादित करने से पहले चलाया जाएगा।
परीक्षण मामले के पूरा होने पर सिस्टम को पुनर्स्थापित करने के लिए एक अशांति प्रक्रिया की आवश्यकता नहीं है। सेटअप प्रक्रिया के साथ प्रत्येक परीक्षण मामले को एक अलग लेन-देन में किया जाता है, जिसे परिणाम एकत्र करने के बाद वापस रोल किया जाता है। यह बहुत सुविधाजनक है, लेकिन इसके कुछ नकारात्मक प्रभाव हैं, जिनकी मैं नीचे चर्चा करूंगा।
ढांचा आपको एक बार में व्यक्तिगत परीक्षण मामलों, संपूर्ण परीक्षण कक्षाओं या सभी पंजीकृत परीक्षण कक्षाओं को चलाने की अनुमति देता है।
उदाहरण के द्वारा सुविधाएँ
पहले से ही सरल आधिकारिक गाइड को रिटेल करने की इच्छा नहीं होने पर, मैं उदाहरणों का उपयोग करके फ्रेमवर्क की संभावनाओं के बारे में बात करूंगा।
अस्वीकरण:- उदाहरण सरल हैं;
- मूल में, सभी परीक्षण कोड मेरे द्वारा नहीं लिखे गए थे, बल्कि यह सामूहिक रचनात्मकता का फल है;
- उदाहरण 2 का आविष्कार tSQLt की क्षमताओं को पूरी तरह प्रदर्शित करने के लिए किया गया था।
उदाहरण 1: CsvSql
ग्राहक के किसी एक ग्राहक के अनुरोध पर, निम्नलिखित को लागू किया गया था। Nvarchar (MAX) फ़ील्ड में डेटाबेस SQL क्वेरी को संग्रहीत करता है। इन प्रश्नों को देखने के लिए, एक न्यूनतम सीमा को बोल्ट किया गया है। इन अनुरोधों द्वारा लौटाए गए परिणाम सेट्स का उपयोग बैकएंड द्वारा एपीआई कॉल के माध्यम से सीएसवी फ़ाइल बनाने के लिए किया जाता है।
परिणाम सेट काफी भारी होते हैं और इनमें कई कॉलम होते हैं। ऐसे परिणाम सेट का एक सशर्त उदाहरण:
यह परिणाम सेट कुछ नैदानिक परीक्षण डेटा है। आइए क्लिनिकनम कैसे माना जाता है, इस पर एक करीब से नज़र डालें - अध्ययन में शामिल क्लीनिकों की संख्या। हमारे पास दो टेबल हैं: [परीक्षण] और [क्लिनिक]:
एफके है: [क्लिनिक]। [परीक्षण] -> [परीक्षण] [परीक्षण]। जाहिर है, क्लीनिकों की संख्या की गणना करने के लिए, हमें बस सामान्य 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';
फ़ेकटेबल एक साधारण बात करता है - पुरानी तालिकाओं का नाम बदल देता है और उनकी जगह नए बनाता है। समान नाम, समान कॉलम, लेकिन बिना बाधा और ट्रिगर'ओव के।
हमें इसकी आवश्यकता क्यों है:
- परीक्षण डेटाबेस में कुछ डेटा हो सकते हैं जो परीक्षणों में हस्तक्षेप कर सकते हैं। फेकटेबल के लिए धन्यवाद, हम उन पर निर्भर नहीं हैं।
- परीक्षण के लिए, एक नियम के रूप में, आपको केवल कुछ कॉलम भरने होंगे। तालिका में उनमें से कई हो सकते हैं, और उनमें से कुछ में बाधाएं होंगी। इस तरह, हम परीक्षण डेटा की आगे की स्थापना को सरल करते हैं - हम केवल उन लोगों को सम्मिलित करेंगे जो वास्तव में परीक्षण के मामले के लिए आवश्यक हैं।
- परीक्षण डेटा सम्मिलित करते समय हम निश्चित रूप से किसी भी ट्रिगर को प्रभावित नहीं करेंगे और हमें अवांछित पोस्ट-इफेक्ट्स के बारे में चिंता करने की ज़रूरत नहीं है।
अगला, हमें आवश्यक परीक्षण डेटा डालें:
INSERT INTO dbo.Trial ([ID], [Name]) VALUES (1, 'Valerian'); INSERT INTO dbo.Clinic ([ID], [TrialID], [Name]) VALUES (1, 1, 'Clinic1'), (2, 1, 'Clinic2');
हम डेटाबेस से अपनी क्वेरी प्राप्त करते हैं, वास्तविक तालिका बनाते हैं और इसे हमारी क्वेरी से निर्धारित परिणाम से भरते हैं:
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 के माध्यम से स्वचालित रूप से भर जाता है और किसी बिंदु पर एक अतिरिक्त स्तंभ अचानक सामने आता है, तो इस तरह के एक परीक्षण का मामला इस क्षण को नहीं पकड़ेगा। ऐसी स्थितियों को संभालने के लिए, आपको अतिरिक्त जांच करने की आवश्यकता है।
बहन प्रक्रियाओं AssertEqualsTable
यह उल्लेखनीय है कि tSQLt में AssertEqualsTable के समान दो प्रक्रियाएँ हैं। ये AssertEqualsTableSchema और AssertResultSetsHaveSameMetaData हैं। पहले AssertEqualsTable के रूप में ही करता है, लेकिन तालिका मेटाडेटा पर। दूसरा एक समान तुलना करता है, लेकिन परिणाम सेट के मेटाडेटा पर।
उदाहरण 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)
अपवाद पकड़ा गया। टेस्ट पास।
बहन प्रक्रियाओं
TSQLt डेवलपर्स हमें ट्रिगर्स के परीक्षण के लिए एक समान दृष्टिकोण प्रदान करते हैं। आप नकली तालिका पर ट्रिगर वापस करने के लिए ApplyTrigger प्रक्रिया का उपयोग कर सकते हैं। इसके अलावा, सब कुछ ऊपर दिए गए उदाहरण में है - हम ट्रिगर को ट्रिगर करते हैं, परिणाम की जांच करते हैं।
ExpectNoException - ExpectException का antonym
ऐसे मामलों के लिए जहां अपवाद निश्चित रूप से नहीं होना चाहिए, एक ExpectNoException प्रक्रिया है। यह एक ExpectException की तरह ही काम करता है, सिवाय इसके कि यदि कोई अपवाद होता है तो परीक्षण विफल माना जाता है।
उदाहरण 3: सेमाफोर
स्थिति इस प्रकार है। कई संग्रहीत कार्यविधियाँ और विंडोज़ सेवाएँ हैं। उनके निष्पादन की शुरुआत विभिन्न बाहरी घटनाओं के कारण हो सकती है। इस मामले में, उनके निष्पादन का अनुमत आदेश निर्धारित है। डेटाबेस टेबल तक पहुंच को अलग करने के लिए एक सेमाफोर का उपयोग किया जाता है। यह संग्रहीत प्रक्रियाओं का एक समूह है।
उदाहरण के लिए, इन प्रक्रियाओं में से एक पर विचार करें। हमारे पास दो टेबल हैं:
तालिका [प्रक्रिया] में निष्पादन के लिए अनुमत प्रक्रियाओं की एक सूची शामिल है, [प्रोकैस्टस] - इन प्रक्रियाओं की स्थिति की सूची।
हमारी प्रक्रिया क्या करती है? जब बुलाया जाता है, तो चेक की एक श्रृंखला पहले होती है:
- प्रक्रिया पैरामीटर में पारित करने के लिए शुरू करने की प्रक्रिया का नाम, [प्रक्रिया] तालिका के [नाम] क्षेत्र में देखा गया है।
- यदि प्रक्रिया नाम पाया गया था, तो यह जाँच की जाती है कि क्या वर्तमान में इसे शुरू करना संभव है - [प्रक्रिया] तालिका का [IsRunable] ध्वज।
- यदि यह पता चला कि यह प्रक्रिया निष्पादन के लिए स्वीकार्य है, तो यह सुनिश्चित किया जाना चाहिए कि यह पहले से ही चल नहीं रहा है। तालिका में [ProcStatus], स्थिति के साथ इस प्रक्रिया के बारे में रिकॉर्ड की अनुपस्थिति = 'InProg' की जाँच की जाती है।
यदि सब कुछ ठीक है, तो इस प्रक्रिया के बारे में एक नया रिकॉर्ड 'InProg' के साथ ProcStatus (यह एक लॉन्च माना जाता है) में जोड़ा जाता है, इस रिकॉर्ड की ID ProcStatusId पैरामीटर के साथ वापस आ जाती है। यदि कोई सत्यापन विफल हो जाता है, तो हम निम्नलिखित की अपेक्षा करते हैं:
- एक पत्र सिस्टम प्रशासक को भेजा जाता है।
- रिटर्न ProcStatusId = -1।
- [ProcStatus] में एक नई प्रविष्टि नहीं जोड़ी गई है।
जब मामला स्वीकार्य लोगों की सूची में नहीं है, तो मामले का परीक्षण करने के लिए एक परीक्षण मामला लिखें।
सुविधा के लिए, तुरंत FakeTable लागू करें। यहां यह मौलिक रूप से महत्वपूर्ण नहीं है, लेकिन यह उपयोगी हो सकता है:
- हमें किसी भी डेटा से छुटकारा पाने की गारंटी है जो परीक्षण मामले के सही निष्पादन में हस्तक्षेप कर सकता है।
- हम ProcStatus में लापता प्रविष्टियों के सत्यापन को और सरल करेंगे।
EXEC tSQLt.FakeTable 'dbo.Process'; EXEC tSQLt.FakeTable 'dbo.ProcStatus';
संदेश भेजने के लिए, हमारे प्रोग्रामर द्वारा लिखित [SendEmail] प्रक्रिया का उपयोग किया जाता है। व्यवस्थापकों को एक पत्र भेजने की जाँच करने के लिए, हमें उसकी कॉल को पकड़ने की आवश्यकता है। इस स्थिति के लिए, tSQLt हमें SpyProcedure का उपयोग करने की पेशकश करता है।
EXEC tSQLt.SpyProcedure 'dbo.SendEmail'
SpyProcedure निम्नलिखित करता है:
- प्रपत्र की तालिका [dbo] बनाता है। [SendEmail_SpyProcedureLog]।
- फ़ेकटेबल की तरह, यह मूल प्रक्रिया को अपने नाम के साथ, समान नाम के साथ बदलता है, लेकिन लॉगिंग लॉजिक के साथ। यदि वांछित है, तो आप अपने स्वयं के किसी भी तर्क को जोड़ सकते हैं।
जैसा कि आप अनुमान लगा सकते हैं, तालिका में लॉगिंग होती है [dbo]। [SendEmail_SpyProcedureLog]। इस तालिका में कॉलम [_ID_] है - प्रक्रिया कॉल का क्रम संख्या। बाद के कॉलम प्रक्रिया में दिए गए मापदंडों के नाम को सहन करते हैं, और कॉल में पारित किए गए मान उनमें एकत्र किए जाते हैं। यदि आवश्यक हो, तो उन्हें भी जांचा जा सकता है।
अंतिम चीज़ जो हमें अर्धकुंभ को कॉल करने से पहले करने की आवश्यकता है और जाँच एक चर बनाने के लिए है जिसमें हम रिकॉर्ड आईडी को [ProcStatus] तालिका से डालेंगे (अधिक सटीक, -1, क्योंकि रिकॉर्ड जोड़ा नहीं जाएगा)।
DECLARE @ProcStatusId BIGINT;
सेमाफोर को बुलाओ:
EXEC dbo.[Semaphore_JobStarter] 'SomeProcess', @ProcStatusId OUTPUT;
यही है, अब हमारे पास सत्यापन के लिए सभी आवश्यक डेटा हैं। चलो शिपमेंट की जांच करके शुरू करते हैं।
पत्र:
IF NOT EXISTS ( SELECT * FROM dbo.SendEmail_SpyProcedureLog) EXEC tSQLt.Fail 'SendEmail has not been run.';
इस मामले में, हमने भेजने के दौरान प्रेषित मापदंडों की जांच नहीं करने का फैसला किया, लेकिन केवल स्वयं तथ्य की जांच करें। मैं आपका ध्यान tSQLt.Fail प्रक्रिया की ओर आकर्षित करता हूं। यह आपको परीक्षण के मामले को "आधिकारिक" रूप से विफल करने की अनुमति देता है। यदि आपको कुछ विशिष्ट निर्माण करने की आवश्यकता है, तो tSQLt.Fail आपको ऐसा करने की अनुमति देगा।
अगला, प्रविष्टियों की अनुपस्थिति की जांच [dbo] में करें। [ProcStatus]:
EXEC tSQLt.AssertEmptyTable 'dbo.ProcStatus';
यह वह जगह है जहाँ हमने शुरुआत में जो FakeTable लागू किया था, उसने हमारी मदद की। उसके लिए धन्यवाद, हम खालीपन की उम्मीद कर सकते हैं। इसके बिना, सटीक सत्यापन के लिए, हमें अच्छे तरीके से, अर्धकुंभ से पहले और बाद के रिकॉर्ड की संख्या की तुलना करनी चाहिए।
समानता ProcStatusId = -1 हम आसानी से परख के साथ जाँच कर सकते हैं:
EXEC tSQLt.AssertEquals -1, @ProcStatusId, 'Wrong ProcStatusId.';
अभिकथन न्यूनतम है - यह केवल दो मूल्यों की तुलना करता है, अलौकिक कुछ भी नहीं।
AsibEquals सिबलिंग प्रक्रियाएँ
मूल्यों की तुलना करने के लिए, हमें कई प्रक्रियाएँ प्रदान की जाती हैं:
- AssertEquals
- AssertNotEquals
- AssertEqualsString
- AssertLike
मुझे लगता है कि उनके नाम अपने लिए बोलते हैं। ध्यान देने योग्य एकमात्र चीज एक अलग AssertEqualsString प्रक्रिया का अस्तित्व है। बात यह है कि AssertEquals / AssertNotEquals / AssertLike SQL_VARIANT के साथ काम करता है, और NVARCHAR (MAX) इस पर लागू नहीं होता है, और इसलिए tSQLt डेवलपर्स को NVARCHAR (MAX) के परीक्षण के लिए एक अलग प्रक्रिया आवंटित करनी पड़ी।
नकली कार्य
कुछ खिंचाव के साथ FakeFunction को SpyProcedure के समान एक प्रक्रिया कहा जा सकता है। यह नकली आपको किसी भी फ़ंक्शन को आवश्यक सरल के साथ बदलने की अनुमति देता है। चूंकि एसक्यूएल सर्वर में फ़ंक्शन टूथपेस्ट के साथ एक ट्यूब के सिद्धांत पर काम करते हैं - वे "केवल तकनीकी छेद" के माध्यम से परिणाम देते हैं, फिर, दुर्भाग्य से, कोई लॉगिंग कार्यक्षमता प्रदान नहीं की जाती है। केवल तर्क के लिए एक प्रतिस्थापन।
नुकसान
यह ध्यान देने योग्य है कि tSQLt के साथ काम करते समय आपको कुछ नुकसान हो सकते हैं। इस मामले में, नुकसान से मेरा मतलब है कि कुछ समस्याग्रस्त मुद्दे जो SQL सर्वर और / या की सीमाओं के कारण पैदा हुए थे, जिन्हें फ्रेमवर्क के डेवलपर्स द्वारा हल नहीं किया जा सकता है।
लेन-देन का रद्दीकरण / भ्रष्टाचार
हमारी टीम ने पहली और सबसे महत्वपूर्ण समस्या लेन-देन को रद्द करने की थी। SQL सर्वर को पता नहीं है कि नेस्टेड लेनदेन को अलग से कैसे रोल किया जाए - केवल सब कुछ एक पूरे के रूप में, सबसे बाहरी के ठीक नीचे। इस तथ्य को देखते हुए कि tSQLt प्रत्येक परीक्षण मामले को एक अलग लेनदेन में लपेटता है, यह एक समस्या बन जाती है। आखिरकार, परीक्षण प्रक्रिया के अंदर एक लेन-देन रोलबैक परीक्षण निष्पादन को तोड़ सकता है, जिससे गैर-वर्णनात्मक निष्पादन त्रुटि हो सकती है।
इस समस्या को दरकिनार करने के लिए, हम savepoints का उपयोग करते हैं। विचार सरल है। परीक्षण प्रक्रिया में लेनदेन शुरू करने से पहले, हम यह देखने के लिए जांच करते हैं कि क्या हम पहले ही लेनदेन के अंदर हैं। अगर यह पता चला कि हाँ, हम हैं, तो, यह मानते हुए कि यह एक tSQLt लेनदेन है, शुरू करने के बजाय savepoint डालें। फिर, यदि आवश्यक हो, तो हम इस सहेजने के लिए वापस रोल करेंगे, और लेनदेन की शुरुआत में नहीं। घोंसला ऐसा नहीं है।
लेन-देन भ्रष्टाचार से समस्या जटिल है। अगर अचानक कुछ गलत हो गया और अपवाद काम कर गया, तो लेनदेन एक प्रलय बन सकता है। ऐसा लेन-देन न केवल प्रतिबद्ध हो सकता है, बल्कि बचत करने के लिए भी लुढ़का हुआ है, केवल पूरी चीज को वापस ले लिया है।
उपरोक्त सभी को देखते हुए, आपको निम्नलिखित डिज़ाइन लागू करना होगा:
DECLARE @isNestedTransaction BIT = CASE WHEN @@trancount > 0 THEN 'true' ELSE 'false' END; BEGIN TRY IF @isNestedTransaction = 'false' BEGIN TRANSACTION ELSE SAVE TRANSACTION SavepointName;
भागों में कोड पर विचार करें। पहले हमें यह निर्धारित करने की आवश्यकता है कि क्या हम लेनदेन के अंदर हैं:
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;
अगर हमने कुछ उपयोगी, प्रतिबद्ध किया है, तो यह प्रक्रिया की "वास्तविक" शुरुआत है।
बेशक, अगर यह परीक्षण के मामले से एक लॉन्च है, तो हमें कुछ भी करने की आवश्यकता नहीं है। निष्पादन के अंत में, tSQLt बस सभी परिवर्तनों को वापस रोल करेगा। अगर अचानक कुछ गलत हुआ और हम CATCH ब्लॉक में आ गए, तो पहली बात यह पता लगाना है कि क्या हमारा लेनदेन भी हो सकता है।
BEGIN CATCH DECLARE @isCommitable BIT = CASE WHEN XACT_STATE() = 1 THEN 'true' ELSE 'false' END;
हम केवल तभी वापस बचाने के लिए रोल कर सकते हैं
- सराहनीय लेनदेन
- एक टेस्ट रन होता है, अर्थात savepoint मौजूद है।
अन्य मामलों में, हमें संपूर्ण लेनदेन वापस करने की आवश्यकता है।
IF @isCommitable = 'true' AND @isNestedTransaction = 'true' ROLLBACK TRANSACTION SavepointName; ELSE ROLLBACK; THROW; END CATCH;
हां, दुर्भाग्य से, अगर एक परीक्षण रन के दौरान हमें एक व्यवहार्य लेनदेन मिला, तो हमें अभी भी परीक्षण मामले के निष्पादन में त्रुटि मिलती है।
नकली कुंजी और विदेशी कुंजी के साथ समस्या
परिचित तालिकाओं पर विचार करें [परीक्षण] और [क्लिनिक]:
हमें याद है [परीक्षण] एफ.के. इसके कारण क्या समस्याएं हो सकती हैं? पहले दिए गए उदाहरणों में, हमने एक ही बार में दोनों तालिकाओं में फ़ेकटेबल लागू किया। यदि हम इसे केवल [परीक्षण] पर लागू करते हैं, तो हमें निम्न स्थिति मिलती है:
इस तरह से [क्लिनिक] में एक प्रविष्टि सम्मिलित करने का प्रयास विफल हो सकता है (भले ही हमने [परीक्षण] तालिका के नकली संस्करण में सभी आवश्यक डेटा तैयार किए हों।
[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] प्रक्रिया को कॉल ट्रैक किया। इस मामले में, एक अलग प्रक्रिया लिखना सीधे संदेश भेजने से पहले कुछ अतिरिक्त जानकारी एकत्र करने और संसाधित करने की आवश्यकता के कारण है। सामान्य तौर पर, किसी को इस तथ्य के लिए मानसिक रूप से तैयार होना चाहिए कि किसी को परीक्षण के उद्देश्य से पूरी तरह से कुछ सिस्टम प्रक्रियाओं के लिए इंटरलेयर प्रक्रियाएं लिखनी पड़ सकती हैं।
गौरव
त्वरित स्थापना
स्थापना 2 चरणों में होती है और लगभग 2 मिनट लगते हैं। आपको केवल सर्वर पर सीएलआर को सक्रिय करने की आवश्यकता है, यदि पहले से नहीं किया गया है, और एक स्क्रिप्ट पर अमल करें। सब कुछ, आप पहले टेस्ट क्लास को जोड़ सकते हैं और टेस्ट केस लिख सकते हैं।
त्वरित विकास
tSQLt टूल सीखना आसान है। मुझे इसमें महारत हासिल करने में थोड़ा दिन लगा। मैंने अपने उन सहयोगियों से पूछा, जिन्होंने ढांचे के साथ काम किया है, और यह पता चला है कि हर कोई लगभग एक दिन बिताएगा।
सीआई में तेजी से कार्यान्वयन
हमारी परियोजना पर CI में एकीकरण स्थापित करने में लगभग 2 घंटे का समय लगा। समय, ज़ाहिर है, अलग-अलग हो सकता है, लेकिन सामान्य तौर पर यह कोई समस्या नहीं है, और एकीकरण बहुत तेज़ी से किया जा सकता है।
साधनों की विस्तृत श्रृंखला
यह एक व्यक्तिपरक आकलन है, लेकिन, मेरी राय में, tSQLt द्वारा प्रदान की गई कार्यक्षमता काफी समृद्ध है और अभ्यास में जरूरतों के शेर के हिस्से को कवर करती है। दुर्लभ मामलों के लिए जब पर्याप्त बिल्ट-इन फ़ेक और दावे नहीं होते हैं, तो ज़ाहिर है, tSQLt.Fail।
सुविधाजनक प्रलेखन
आधिकारिक दस्तावेज सुविधाजनक और सुसंगत है। इसकी मदद से, आप आसानी से थोड़े समय में 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. -----------------------------------------------------------------------------
आप डेटाबेस (क्लिक करने योग्य) से भी निकाल सकते हैं ...
... या 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>
बाद वाला विकल्प आपको आसानी से सीआई में परीक्षणों को एकीकृत करने की अनुमति देता है। विशेष रूप से, एटलसियन बांस के तहत हमारे लिए सब कुछ काम करता है।
Redgate समर्थन करते हैं
प्लस में RedGate जैसे DBA टूल के इतने बड़े प्रदाता के लिए समर्थन शामिल है। SQL टेस्ट - SQL सर्वर प्रबंधन स्टूडियो के लिए उनका प्लगइन - बॉक्स के ठीक बाहर tSQLt के साथ काम करता है। इसके अलावा, RedGate देव वातावरण के साथ tSQLt मुख्य डेवलपर को सहायता प्रदान करता है, जैसा कि
Google समूह के दावों में डेवलपर स्वयं करता है।
कमियों
कोई अस्थायी तालिका नहीं है
tSQLt नकली अस्थायी तालिकाओं की अनुमति नहीं देता है। यदि आवश्यक हो, तो आप
अनौपचारिक ऐड-ऑन का उपयोग कर सकते हैं। दुर्भाग्य से, यह ऐड-ऑन केवल SQL सर्वर 2016+ द्वारा समर्थित है।
बाहरी डेटाबेस तक कोई पहुँच नहीं
यह केवल ढांचे को संग्रहीत करने के लिए एक अलग आधार रखने के लिए काम नहीं करेगा। tSQLt को उसी डेटाबेस में परीक्षण करने के लिए डिज़ाइन किया गया है जो इसके साथ निहित है। नकली, अफसोस, काम नहीं करेगा।
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
प्रलेखन कीड़े
इस तथ्य के बावजूद कि मैंने प्रलेखन की स्थिरता और उपलब्धता के बारे में ऊपर लिखा है, इसमें समस्याएं भी हैं। इसमें कुछ पुराने क्षण हैं।
उदाहरण 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 = ''; 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 तक tSQLt के विकास में एक लंबा ब्रेक है। हां, दुर्भाग्य से, इस उपकरण को आंशिक रूप से छोड़ दिया गया है। 2019 में,
GitHub द्वारा थोड़ा-थोड़ा करके, विकास अभी भी आगे बढ़ा। हालांकि आधिकारिक Google समूह के
पास एक धागा है जिसमें tastt के मुख्य डेवलपर सेबस्टियन से सीधे विकास के भाग्य के बारे में पूछा गया था। 2 मार्च, 2019 को आखिरी सवाल पूछा गया था, जवाब अभी तक नहीं मिला है।
SQL सर्वर 2017 के साथ समस्या
यदि आप SQL Server 2017 का उपयोग कर रहे हैं, तो आपके लिए, संभवतः tSQLt को स्थापित करने के लिए कुछ अतिरिक्त हेरफेर की आवश्यकता होगी।
बात यह है कि 2012 के बाद पहली बार, SQL सर्वर ने सुरक्षा परिवर्तन किए। सर्वर स्तर पर, "CLR सख्त सुरक्षा" ध्वज जोड़ा गया था, जो अहस्ताक्षरित असेंबली (यहां तक कि सुरक्षित) के निर्माण पर रोक लगाता है। समस्या का विस्तृत वर्णन एक अलग लेख (और, सौभाग्य से, सब कुछ पहले से ही अच्छी तरह से वर्णित है और श्रृंखला में बाद के लेख) के योग्य है। बस इसके लिए मानसिक रूप से तैयार रहें।बेशक, इस कमी को "नुकसान" के लिए जिम्मेदार ठहराया जा सकता है, जिसका समाधान tSQLt डेवलपर्स पर निर्भर नहीं करता है, लेकिन फ्रेमवर्क स्तर पर इस समस्या को हल करना संभव है, भले ही थोड़ा समय लेने वाला हो। GitHub में पहले से ही एक मुद्दा है , हालांकि, इसकी अनुमति के साथ अक्टूबर 2017 से इसे खींच लिया गया है (पिछले उपखंड देखें)।अन्य DBMS के लिए विकल्प (±)
यह अन्य DBMS के लिए विकल्पों का उल्लेख करने योग्य भी है। tSQLt अपनी तरह का एकमात्र उपकरण नहीं है। हालाँकि, कार्यान्वयन की ख़ासियत (CLR, और T-SQL अन्य SQL बोलियों से काफी अलग है) के कारण, आप इसे अन्य DBMS में उपयोग नहीं कर सकते, फिर भी आप समान उपकरण पा सकते हैं। मैं ध्यान देता हूं कि ये विकल्प tSQLt से काफी भिन्न हैं, इसलिए हम मुख्य रूप से SQL- संचालित दृष्टिकोण के बारे में बात कर रहे हैं।तो, PostgreSQL के तहत एक काफी विकसित और सक्रिय रूप से विकसित ptTAP है । इसमें मूल PL / pgSQL में परीक्षण लिखना और परिणामों को TAP प्रारूप में शामिल करना शामिल है। MySQL के तहत, एक समान है, यद्यपि कुछ कम कार्यात्मक उपकरण - MyTAP । यदि आप ओरेकल के साथ काम करने के लिए भाग्यशाली हैं, तो आपके पास utPLSQL का उपयोग करने का अवसर है- एक बहुत शक्तिशाली और सक्रिय रूप से (मैं भी कहूंगा, एक से अधिक) एक विकासशील उपकरण।निष्कर्ष
शायद, उपरोक्त सभी जानकारी के साथ, मैं दो मुख्य विचारों को व्यक्त करना चाहता था।पहले एक डेटाबेस में परीक्षण कोड की उपयोगिता है। चाहे आप SQL सर्वर, Oracle या MySQL के तहत बैठे हों, इससे कोई फर्क नहीं पड़ता। यदि आपके पास डेटाबेस में एक निश्चित मात्रा में अप्रयुक्त तर्क संग्रहीत है, तो आप अतिरिक्त जोखिम उठाते हैं। डेटाबेस कोड में कीड़े सक्षम हैं, कोड के बाकी हिस्सों में कीड़े की तरह, उत्पाद को नुकसान पहुंचाता है और, परिणामस्वरूप, उस कंपनी को जो इसे आपूर्ति करता है।दूसरा विचार एक उपकरण चुन रहा है। यदि आप, मेरी तरह, SQL सर्वर के साथ काम करते हैं, तो tSQLt है, यदि 100% विजेता नहीं है, तो यह निश्चित रूप से आपके ध्यान देने योग्य है। हाल ही में सुस्त विकास के बावजूद, यह अभी भी एक प्रासंगिक उपकरण है जो परीक्षण की सुविधा प्रदान करता है।सूत्रों ने मेरी मदद की (अधूरी सूची)