यूनिट परीक्षण डेटाबेस स्क्रिप्ट

अपने पसंदीदा C ++ पर यूनिट परीक्षणों का उपयोग करने की सुविधा को स्वीकार करते हुए, मैंने अपने अनुभव को TSQL में स्थानांतरित करने की कोशिश की, खासकर जब से नया नियोक्ता जमीन पर एक उपयोगी पहल प्यार करता है और इसके लिए बन्स वितरित करता है।

मैंने कई प्रसिद्ध रूपरेखाओं के माध्यम से देखा , मैं इस निष्कर्ष पर पहुंचा कि, एक नियम के रूप में, वे भारी हैं और अतिरिक्त सिंटैक्स लाते हैं जिन्हें अतिरिक्त रूप से अध्ययन करने की आवश्यकता है।

कुछ चौखटे खूबसूरती से काम करते हैं और प्रबंधक की नज़र को खुश करते हैं, जिन्हें उन्हें दिखाया जाता है, लेकिन कई सीमाएँ हैं जो मुझे पसंद नहीं थीं।

मैं शुद्ध कोषेर-हलाल-रूढ़िवादी TSQL पर सब कुछ लागू करना चाहता था।

समय-समय पर, स्क्रिप्ट की संरचना का सम्मान करने के लिए कई वर्षों तक मुख्य विकास से विचलित होकर, मैंने इसे आपके साथ साझा करने का निर्णय लिया (लेकिन फिर भी 3.5 एमबी स्क्रिप्ट का उत्पादन करने में कामयाब रहा)।

मेरी बुनियादी आवश्यकताएं सरल थीं - मुझे किसी भी इशारों और विशेष सॉफ़्टवेयर उपकरणों की आवश्यकता के बिना किसी भी फ़ाइल में किसी भी इकाई परीक्षण को करना होगा - केवल कट्टर: sqlcmd या MSSMS।

डेटाबेस में कोई परिवर्तन नहीं किया जाता है जिसमें परीक्षण किया जाता है - स्क्रिप्ट की शुरुआत में सब कुछ वापस लुढ़का हुआ है।

केवल एक सीमा निर्धारित की जाती है - परीक्षण को खाली डेटाबेस में काम करना चाहिए (प्रारंभिक डेटा हो सकता है), अन्यथा आप सभी विकल्पों को अलग करने से थक जाते हैं।

मुख्य कार्य तर्क का परीक्षण करना और तर्क की अखंडता को बनाए रखना है।

इसके लिए, मैंने परीक्षण की शुरुआत में निम्नलिखित शीर्षक रखे:

SET QUOTED_IDENTIFIER ON GO PRINT '-------------------------------- CLR Unit tests for Habr Logic ---------------------------------' IF 0 < ( SELECT count(*) FROM device) begin RAISERROR ('FAILED: database must be empty for this unit test', 16, -1 ) end GO 

मैं कोशिश करता हूं कि एक-दो स्क्रीन से ज्यादा यूनिट टेस्ट न बनाएं, हालांकि जटिल लॉजिक के मामले में यह आसान नहीं है।

एक विशिष्ट इकाई परीक्षण इस तरह दिखता है और इसके 3 मुख्य भाग हैं:

 BEGIN TRAN TestClr2 declare @test_name sysname = (select TOP 1 name from sys.dm_tran_active_transactions WHERE transaction_type = 1 ORDER BY transaction_begin_time DESC) + ' [fn_calculate_dev_status] record for device has wrong range' BEGIN TRY SET NOCOUNT ON; -- 1. prepare data for unit test insert into device (mli, oxygen, stamp ) values ('111', 5.55, getdate() ) -- 2. execute unit test -- SELECT dbo.fn_calculate_dev_status( 111, 0.1, 1.2) declare @result int = ( SELECT dbo.fn_calculate_dev_status( '111', 0.1, 1.2) ) END TRY BEGIN CATCH SELECT ERROR_NUMBER() AS ErrorNumber, ERROR_SEVERITY() AS ErrorSeverity, ERROR_STATE() AS ErrorState , @test_name AS ErrorProcedure, ERROR_LINE() AS ErrorLine, ERROR_MESSAGE() AS ErrorMessage END CATCH -- 3. result verification IF @result <> 0 RAISERROR ('FAILED: %s no data for device should be presented %d ', 16, -1, @test_name, @result ) ELSE print 'PASSED ' + @test_name ROLLBACK TRAN TestClr2 GO 

- 1. यूनिट टेस्ट के लिए डेटा तैयार करें

यहां हम डेटा के साथ आवश्यक तालिकाओं को भर सकते हैं और कुछ अस्थायी चर या तालिकाओं को तैयार कर सकते हैं ताकि परीक्षण अनुभाग में कोड को अव्यवस्थित न किया जा सके।

- 2. इकाई परीक्षण निष्पादित करें

यहां, एक नियम के रूप में, यह या तो एक फ़ंक्शन कॉल, या एक प्रक्रिया, या एक तालिका परिवर्तन, अगर हम ट्रिगर तर्क का परीक्षण करते हैं।

- 3. परिणाम सत्यापन

परीक्षण के इस भाग में, हम जाँचते हैं कि डेटाबेस ऑब्जेक्ट्स की स्थिति कैसे बदल गई है, या परीक्षण किए गए फ़ंक्शन-प्रक्रिया का परिणाम है।

यदि प्रक्रिया फ़ंक्शन एक रिकॉर्ड देता है, तो हम इसे अस्थायी तालिका में सम्मिलित करते हैं और पहले से ही इसका विश्लेषण करते हैं।

एकत्र और तैयार किए गए परिणामों की तुलना मानक के साथ की जाती है और यदि बाकी सभी विफल हो जाते हैं तो एक अपवाद फेंक दें।

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

प्रत्येक इकाई परीक्षण एक प्रक्रिया के रूप में जारी किया जाता है:

 CREATE OR REPLACE PROCEDURE UnitTest9_TRG_JOBLOGDETAIL AS v_message VARCHAR2(255) := 'UnitTest9_TRG_JOBLOGDETAIL: INSERT joblogdetail]- joblogdetail_result not Failed and joblogdetail_endtime is null '; v_maxdate date := '2014/01/01'; v_cnt NUMBER := 0; BEGIN savepoint my_savepoint; <b>-- 1. prepare data for unit test</b> insert into device ( dev_datecreated, dev_create_user, dev_ipaddress, dev_serialnumber , dev_productid, dev_manufacturer, dev_model, dev_id, dev_status, dev_functions) values (sysdate, 'Joe', '1.127.0.1', 'GSN-6238-N34', 'PRTF-452', 'Pinter Company', 'CM6003', 1, 1, 1 ); insert into joblog (JOBLOG_ID, joblog_starttime, joblog_progress) values (11, sysdate, 1); insert into joblog_template (JOBLOG_TEMPLATE_ID, joblog_id, joblog_templatename, joblog_templatetype) values (111, 11, N'joblog_template_test', 1); <b>-- 2. execute unit test</b> insert into joblogdetail ( JOBLOGDETAIL_ID, joblog_template_id, joblogdetail_function, joblogdetail_functiondetail, joblogdetail_result, joblogdetail_dev_id, joblogdetail_starttime, joblogdetail_endtime) values ( 1111, 111, 1, 1, 40, 1, v_maxdate, v_maxdate); <b>-- 3. result verification</b> SELECT count(dev_id) INTO v_cnt FROM device where dev_last_comm_time = v_maxdate; IF 1 <> v_cnt THEN DBMS_OUTPUT.PUT_LINE( 'FAILED: ' || v_message || ': Should not be update dev_last_comm_time: ' || TO_CHAR(v_maxdate)); ELSE DBMS_OUTPUT.PUT_LINE( 'PASSED: ' || v_message ); END IF; rollback to my_savepoint; END; / 

अंत में एक ही परीक्षण फ़ाइल में, आपको बनाए गए और निष्पादित परीक्षणों से एक डेटाबेस क्लीनअप करना होगा।

 commit; / set serveroutput on; SET FEEDBACK OFF; spool C:\dist\test.spl; exec UnitTest_empty_database; exec UnitTest3297_TRGBFR_UDEVICE(1); exec UnitTest5_TRG_BF_UDEVICE; exec UnitTest_3062a; ... spool off; / DROP PROCEDURE UnitTest_3062; DROP PROCEDURE UnitTest_BIRDIESEC_3344; DROP PROCEDURE UnitTest_empty_database; ... SET FEEDBACK ON; commit; 

बस इतना ही।

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

लगभग सभी डेटाबेस डेवलपर्स ने यह कहा और कहा - मुझे क्यों करना चाहिए, परीक्षकों को ऐसा करने देना चाहिए। यदि डेटाबेस में शब्द से तर्क बिल्कुल नहीं है, तो मैं उनसे सहमत हूं, लेकिन अगर इसमें बहुत कुछ है, तो वे स्वाभाविक रूप से तंत्रिकाओं, प्रतिष्ठा और धन को बचाते हैं।

एक उदाहरण है।

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

ऐसे प्रत्येक नोड में बहुत जटिल नियम होते हैं, उपयोगकर्ता या नियम या जनरेटर उपकरणों को असाइन करता है।

नतीजतन, यहां तक ​​कि चरणों में विस्तार से वर्णित निर्देश सभी को ध्वस्त करते हैं, यहां तक ​​कि उन लोगों ने भी जो इस तर्क की चर्चा और विकास में भाग लेते हैं।

विभिन्न डेटा सेट के साथ निर्देश के पचास से अधिक चरण - सब कुछ विस्तार से प्रलेखित है।

किसी भी परिवर्तन या तर्क के अलावा मैनुअल सत्यापन की एक घड़ी है कि कुछ भी नहीं टूट गया है।
डेथ रिफैक्टरिंग समान है।

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

किसी भी जावा डेवलपर ने मेरा सहारा लिया, गड़गड़ाहट और बिजली गिराना (अपने कुटिल हाथों के बारे में खुद को सोचना) आसानी से उपयुक्त परीक्षण चलाकर डाल दिया जाता है।

कुछ मिनट और हर कोई संतुष्ट है। मेरी अनुपस्थिति में कोई भी घातक कोड परिवर्तन मुझे मेल द्वारा सूचित किया जाएगा।

स्वाभाविक रूप से, एक आलसी व्यक्ति के रूप में, मैंने कंटीन्यूअस ऑटोमेशन के लिए सब कुछ स्वचालित करने का फैसला किया और बैचों और अजगर से दलिया लिखा।

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

मैं खिड़कियों पर सबकुछ नहीं करना चाहता था पावरशेल - हमारी स्किप्स अभी भी इधर-उधर चलती हैं।

मैं पायथन में सभी कॉल करना चाहता था, लेकिन यह पता चला कि कुछ sql (XML- पार्सिंग के अंदर cte) कंस्ट्रक्शन न केवल अजगर लाइब्रेरी में, बल्कि .NET में भी समर्थित हैं, इसलिए मैंने sqlcmd की स्क्रिप्टिंग की।

कोड यहाँ पोस्ट किया गया है ।

काम करने के उदाहरण को चलाने के लिए, बस 2 फ़ाइलों को संपादित करें: smtppart.py और config.ini - SMTP सर्वर नाम, पोर्ट और ईमेल जहां त्रुटि संदेश छोड़ दिया जाएगा।

स्क्रिप्ट पहले svn से नवीनतम अपडेट प्राप्त करने की कोशिश करते हैं (अपने खुद के - गिट, पर्फोर्स, ... के साथ बदलें)।

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

80 एमबी स्क्रिप्ट और 3.5 एमबी परीक्षण का डेटाबेस बनाना (योजना का मुख्य भाग कंपनी में शामिल होने से पहले ही हो चुका था, इसलिए मैंने केवल अपने हिस्से का परीक्षण किया) लगभग 15 मिनट में मेरी मशीन पर किया गया। मेरे पास अंतिम वचन से पहले सिर्फ एक कप कॉफी पीने का समय है।

यदि त्रुटियां थीं, तो त्रुटि के परिणाम ईमेल पर भेजे जाएंगे।

निर्भरता स्थापना फ़ाइल में वर्णित है: readme.txt

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



ऑटोरन.बैट फ़ाइल में सभी यूनिट परीक्षणों के लॉन्च को कॉर्पोरेट निर्माण से पहले या घर छोड़ने के 1-2 दिन बाद चलाने के लिए विंडोज टास्क शेड्यूलर में रखा जा सकता है - अगर शाम को कुछ टूट जाता है - तो आप टीवी के सामने जो हुआ उसे देख सकते हैं और जल्दी से ठीक कर सकते हैं।

मुझे पता है कि इकाई परीक्षण में सब कुछ सेट करना सबसे कठिन है, और फिर परीक्षण लिखना आसान और सुखद है, हालांकि यह कठिन और कठिन हो सकता है, लेकिन आवश्यक है। परीक्षण में सौभाग्य, मुझे आशा है कि मेरी सलाह किसी की मदद करेगी।

मुझे सलाह लेने में खुशी होगी अगर कहीं पर कुछ सुधार किया जा सकता है और कोड को कंघी किया जा सकता है, सख्ती से न्याय न करें।