डेटाबेस यूनिट परीक्षण में निर्भरता और डेटा को अलग करने की कला

सभी डेटाबेस डेवलपर कमोबेश डेटाबेस यूनिट परीक्षण लिखते हैं जो न केवल बग का जल्द पता लगाने में मदद करते हैं बल्कि डेटाबेस ऑब्जेक्ट्स के अप्रत्याशित व्यवहार के उत्पादन का मुद्दा बनने पर बहुत समय और प्रयास भी बचाते हैं।

आजकल, डीबीफोर्ज यूनिट टेस्ट सहित थर्ड-पार्टी यूनिट टेस्टिंग टूल्स के साथ टीएसक्यूएलटी जैसे कई डेटाबेस यूनिट टेस्टिंग फ्रेमवर्क हैं।

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

यह लेख कुछ मानक प्रथाओं की खोज करता है जो हमें डेटाबेस इकाई परीक्षण लिखने के तरीके को बेहतर बनाने में मदद कर सकते हैं।

सबसे पहले, आइए डेटाबेस इकाई परीक्षण की कुछ प्रमुख अवधारणाओं को देखें।

डेटाबेस इकाई परीक्षण क्या है

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

डेटाबेस इकाई परीक्षण यह सत्यापित करने के लिए लिखे जाते हैं कि कोड व्यावसायिक आवश्यकताओं को पूरा करता है या नहीं।

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

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

एएए सिद्धांत

यह इकाई परीक्षण के 3-चरणीय सिद्धांत के बारे में उल्लेखनीय है जो इकाई परीक्षण लिखने के लिए एक मानक अभ्यास है। एएए सिद्धांत इकाई परीक्षण का आधार है और इसमें निम्नलिखित चरण शामिल हैं:

व्यवस्थित करें/इकट्ठा करें
अधिनियम
जोर दें

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

अधिनियम अनुभाग तब होता है जब वास्तविक आउटपुट उत्पन्न करने के लिए डेटाबेस ऑब्जेक्ट (परीक्षण के तहत) को कॉल किया जाता है।

जोर स्टेप वास्तविक आउटपुट को अपेक्षित आउटपुट से मिलाने से संबंधित है और यह सत्यापित करता है कि परीक्षण या तो पास होता है या विफल होता है।

आइए इन विधियों को विशेष उदाहरणों पर देखें।

यदि हम यह सत्यापित करने के लिए एक इकाई परीक्षण बनाते हैं कि AddProduct संग्रहीत कार्यविधि एक नया उत्पाद जोड़ सकती है, हम उत्पाद . सेट करते हैं और अपेक्षित उत्पाद उत्पाद जोड़ने के बाद टेबल। इस मामले में, विधि व्यवस्था/इकट्ठा अनुभाग के अंतर्गत आती है।

AddProduct प्रक्रिया को कॉल करना और परिणाम को उत्पाद तालिका में डालना अधिनियम अनुभाग द्वारा कवर किया गया है।

यह देखने के लिए कि संग्रहीत कार्यविधि को सफलतापूर्वक निष्पादित किया गया है या विफल, Assert भाग केवल उत्पाद तालिका से अपेक्षित उत्पाद तालिका से मेल खाता है।

इकाई परीक्षण में निर्भरता को समझना

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

अब, आइए पहेली के एक अन्य महत्वपूर्ण भाग पर ध्यान दें - इकाई परीक्षण में निर्भरता।

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

निर्भरता को समझने का सबसे अच्छा तरीका एक इकाई परीक्षण का उदाहरण देखना है।

कर्मचारी नमूना डेटाबेस सेटअप

आगे बढ़ने के लिए, एक नमूना डेटाबेस बनाएं और इसे कर्मचारी नमूना कहें :

-- Create the Employees sample database to demonstrate unit testing

CREATE DATABASE EmployeesSample;
GO

अब, कर्मचारी बनाएं नमूना डेटाबेस में तालिका:

-- Create the Employee table in the sample database

USE EmployeesSample

CREATE TABLE Employee
  (EmployeeId INT PRIMARY KEY IDENTITY(1,1),
  NAME VARCHAR(40),
  StartDate DATETIME2,
  Title VARCHAR(50)
  );
GO

नमूना डेटा पॉप्युलेट करना

कुछ रिकॉर्ड जोड़कर तालिका को पॉप्युलेट करें:

-- Adding data to the Employee table
INSERT INTO Employee (NAME, StartDate, Title)
  VALUES 
  ('Sam','2018-01-01', 'Developer'),
  ('Asif','2017-12-12','Tester'),
  ('Andy','2016-10-01','Senior Developer'),
  ('Peter','2017-11-01','Infrastructure Engineer'),
  ('Sadaf','2015-01-01','Business Analyst');
GO

तालिका इस तरह दिखती है:

-- View the Employee table

  SELECT e.EmployeeId
        ,e.NAME
        ,e.StartDate
        ,e.Title FROM  Employee e;
GO

कृपया ध्यान दें कि मैं इस आलेख में SQL सर्वर के लिए dbForge Studio का उपयोग कर रहा हूं। इस प्रकार, यदि आप SSMS (SQL सर्वर प्रबंधन स्टूडियो) में समान कोड चलाते हैं, तो आउटपुट स्वरूप भिन्न हो सकता है। जब स्क्रिप्ट और उनके परिणामों की बात आती है तो कोई फर्क नहीं पड़ता।

नए कर्मचारी को जोड़ने की आवश्यकता

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

ऐसा करने के लिए, AddEmployee संग्रहीत कार्यविधि इस प्रकार बनाएँ:

-- Stored procedure to add a new employee 

CREATE PROCEDURE AddEmployee @Name VARCHAR(40),
@StartDate DATETIME2,
@Title VARCHAR(50)
AS
BEGIN
  SET NOCOUNT ON
    INSERT INTO Employee (NAME, StartDate, Title)
  VALUES (@Name, @StartDate, @Title);
END

आवश्यकता पूरी हुई है या नहीं यह सत्यापित करने के लिए यूनिट परीक्षण

हम यह सत्यापित करने के लिए एक डेटाबेस इकाई परीक्षण लिखने जा रहे हैं कि क्या AddEmployee संग्रहीत कार्यविधि कर्मचारी तालिका में एक नया रिकॉर्ड जोड़ने की आवश्यकता को पूरा करती है।

आइए हम परीक्षण ढांचे या तृतीय-पक्ष इकाई परीक्षण उपकरण के साथ एक इकाई परीक्षण लिखने के बजाय एक इकाई परीक्षण कोड का अनुकरण करके इकाई परीक्षण दर्शन को समझने पर ध्यान केंद्रित करें।

इकाई परीक्षण का अनुकरण और SQL में AAA सिद्धांत लागू करना

पहली चीज़ जो हमें करने की ज़रूरत है वह है SQL में AAA सिद्धांत का अनुकरण करना क्योंकि हम किसी इकाई परीक्षण ढांचे का उपयोग नहीं करने जा रहे हैं।

असेंबल सेक्शन तब लागू होता है जब वास्तविक और अपेक्षित टेबल सामान्य रूप से सेट की जाती हैं और अपेक्षित टेबल पॉप्युलेट हो जाती हैं। हम इस चरण में अपेक्षित तालिका को प्रारंभ करने के लिए SQL चर का उपयोग कर सकते हैं।

अधिनियम अनुभाग का उपयोग तब किया जाता है जब वास्तविक तालिका में डेटा सम्मिलित करने के लिए वास्तविक संग्रहीत कार्यविधि को कॉल किया जाता है।

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

दो तालिकाओं के बीच सामान्य (मिलान) पंक्तियों की गणना करना जो 1 होनी चाहिए (क्योंकि अपेक्षित तालिका में केवल एक रिकॉर्ड है जो वास्तविक तालिका से मेल खाना चाहिए)
अपेक्षित तालिका रिकॉर्ड से वास्तविक तालिका रिकॉर्ड को छोड़कर 0 के बराबर होना चाहिए (यदि अपेक्षित तालिका में रिकॉर्ड वास्तविक तालिका में भी मौजूद है, तो अपेक्षित तालिका से सभी वास्तविक तालिका रिकॉर्ड को छोड़कर 0) वापस आना चाहिए।>

SQL स्क्रिप्ट इस प्रकार है:

[विस्तार शीर्षक ="कोड"]

-- Simulating unit test to test the AddEmployee stored procedure

CREATE PROCEDURE TestAddEmployee
AS
BEGIN
  -- (1) Assemble

  -- Set up new employee data
  DECLARE @EmployeeId INT = 6
         ,@NAME VARCHAR(40) = 'Adil'
         ,@StartDate DATETIME2 = '2018-03-01'
         ,@Title VARCHAR(50) = 'Development Manager'


  -- Set up the expected table
  CREATE TABLE #EmployeeExpected (
    EmployeeId INT PRIMARY KEY IDENTITY (6, 1) 
    -- the expected table EmployeeId should begin with 6 
    -- since the actual table has already got 5 records and 
    -- the next EmployeeId in the actual table is 6
   ,NAME VARCHAR(40)
   ,StartDate DATETIME2
   ,Title VARCHAR(50)
  );

  -- Add the expected table data
  INSERT INTO #EmployeeExpected (NAME, StartDate, Title)
    VALUES (@NAME, @StartDate, @Title);

  -- (2) Act

  -- Call AddEmployee to add new employee data to the Employee table
  INSERT INTO Employee
  EXEC AddEmployee @NAME
                  ,@StartDate
                  ,@Title



  -- (3) Assert

  -- Match the actual table with the expected table
  DECLARE @ActualAndExpectedTableCommonRecords INT = 0 -- we assume that expected and actual table records have nothing in common

  SET @ActualAndExpectedTableCommonRecords = (SELECT
      COUNT(*)
    FROM (SELECT
        e.EmployeeId
       ,e.NAME
       ,e.StartDate
       ,e.Title
      FROM Employee e
      INTERSECT
      SELECT
        ee.EmployeeId
       ,ee.NAME
       ,ee.StartDate
       ,ee.Title
      FROM #EmployeeExpected ee) AS A)


  DECLARE @ExpectedTableExcluldingActualTable INT = 1 -- we assume that expected table has records which do not exist in the actual table

  SET @ExpectedTableExcluldingActualTable = (SELECT
      COUNT(*)
    FROM (SELECT
        ee.EmployeeId
       ,ee.NAME
       ,ee.StartDate
       ,ee.Title
      FROM #EmployeeExpected ee
      EXCEPT
      SELECT
        e.EmployeeId
       ,e.NAME
       ,e.StartDate
       ,e.Title
      FROM Employee e) AS A)


  IF @ActualAndExpectedTableCommonRecords = 1
    AND @ExpectedTableExcluldingActualTable = 0
    PRINT '*** Test Passed! ***'
  ELSE
    PRINT '*** Test Failed! ***'

END

[/विस्तार]

सिम्युलेटेड यूनिट टेस्ट चलाना

संग्रहीत कार्यविधि बनने के बाद, इसे सिम्युलेटेड यूनिट परीक्षण के साथ निष्पादित करें:

-- Running simulated unit test to check the AddEmployee stored procedure
EXEC TestAddEmployee

आउटपुट इस प्रकार है:

बधाई हो! डेटाबेस इकाई परीक्षण पास हुआ।

इकाई परीक्षण में निर्भरता के रूप में मुद्दों की पहचान करना

क्या हम यूनिट टेस्ट में कुछ गलत का पता लगा सकते हैं, इस तथ्य के बावजूद कि इसे सफलतापूर्वक लिखा और चलाया गया है?

यदि हम इकाई परीक्षण सेटअप (इकट्ठा भाग) को करीब से देखें, तो अपेक्षित तालिका में पहचान कॉलम के साथ एक अनावश्यक बंधन है:

एक इकाई परीक्षण लिखने से पहले हम वास्तविक (कर्मचारी) तालिका में पहले ही 5 रिकॉर्ड जोड़ चुके हैं। इस प्रकार, परीक्षण सेटअप पर, अपेक्षित तालिका के लिए पहचान कॉलम 6 से शुरू होता है। हालांकि, इसका मतलब यह है कि हम हमेशा उम्मीद करते हैं कि वास्तविक (कर्मचारी) तालिका में 5 रिकॉर्ड अपेक्षित तालिका (#EmployeeExpected) से मेल खाते हैं।

यह समझने के लिए कि यह इकाई परीक्षण को कैसे प्रभावित कर सकता है, आइए अब वास्तविक (कर्मचारी) तालिका पर एक नज़र डालें:

कर्मचारी तालिका में एक और रिकॉर्ड जोड़ें:

-- Adding a new record to the Employee table

INSERT INTO Employee (NAME, StartDate, Title)
  VALUES ('Mark', '2018-02-01', 'Developer');

कर्मचारी तालिका पर अभी एक नज़र डालें:

EmpoyeeId 6 (Adil) हटाएं ताकि यूनिट परीक्षण पहले से संग्रहीत रिकॉर्ड के बजाय EmployeeId 6 (आदिल) के अपने संस्करण के विरुद्ध चल सके।

-- Deleting the previously created EmployeeId: 6 (Adil) record from the Employee table

DELETE FROM Employee
  WHERE EmployeeId=6

नकली इकाई परीक्षण चलाएँ और परिणाम देखें:

-- Running simulated unit test to check the AddEmployee stored procedure
EXEC TestAddEmployee

इस बार टेस्ट फेल हो गया है। उत्तर कर्मचारी तालिका परिणाम सेट में निहित है जैसा कि नीचे दिखाया गया है:

जब हम एक नया रिकॉर्ड जोड़ने और पहले जोड़े गए कर्मचारी रिकॉर्ड को हटाने के बाद यूनिट टेस्ट को फिर से चलाते हैं, तो ऊपर बताए अनुसार यूनिट टेस्ट में कर्मचारी आईडी बाइंडिंग काम नहीं करती है।

परीक्षण में तीन प्रकार की निर्भरताएँ होती हैं:

डेटा निर्भरता
मुख्य बाधा निर्भरता
पहचान कॉलम निर्भरता

डेटा निर्भरता

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

इसका मतलब है कि आपका डेटाबेस यूनिट परीक्षण डेटाबेस में डेटा पर निर्भर नहीं होना चाहिए। उदाहरण के लिए, आपके यूनिट परीक्षण में डेटाबेस में पहले से मौजूद डेटा पर भरोसा करने के बजाय डेटाबेस ऑब्जेक्ट (टेबल) में डाला जाने वाला वास्तविक डेटा होना चाहिए जिसे हटाया या संशोधित किया जा सकता है।

हमारे मामले में, तथ्य यह है कि वास्तविक कर्मचारी तालिका में पहले से ही पांच रिकॉर्ड डाले जा चुके हैं, एक डेटा निर्भरता है जिसे रोका जाना चाहिए क्योंकि हमें इकाई परीक्षण के दर्शन का उल्लंघन नहीं करना चाहिए जो कहता है कि केवल कोड की इकाई का परीक्षण किया जाता है।

दूसरे शब्दों में, परीक्षण डेटा डेटाबेस में वास्तविक डेटा पर निर्भर नहीं होना चाहिए।

प्रमुख बाधा निर्भरता

एक अन्य निर्भरता एक प्रमुख बाधा निर्भरता है जिसका अर्थ है कि प्राथमिक कुंजी कॉलम कर्मचारी आईडी भी एक निर्भरता है। एक अच्छा इकाई परीक्षण लिखने के लिए इसे रोका जाना चाहिए। हालांकि, प्राथमिक कुंजी बाधा का परीक्षण करने के लिए एक अलग इकाई परीक्षण की आवश्यकता होती है।

उदाहरण के लिए, AddEmployee संग्रहीत कार्यविधि का परीक्षण करने के लिए, कर्मचारी तालिका प्राथमिक कुंजी को हटा दिया जाना चाहिए ताकि प्राथमिक कुंजी के उल्लंघन की चिंता के बिना किसी ऑब्जेक्ट का परीक्षण किया जा सके।

पहचान कॉलम निर्भरता

प्राथमिक कुंजी बाधा की तरह, पहचान कॉलम भी एक निर्भरता है। इस प्रकार, AddEmployee प्रक्रिया के लिए पहचान कॉलम ऑटो-इंक्रीमेंट लॉजिक के परीक्षण की कोई आवश्यकता नहीं है; इसे किसी भी कीमत पर टाला जाना चाहिए।

इकाई परीक्षण में निर्भरता को अलग करना

हम अस्थायी रूप से तालिका से बाधाओं को हटाकर सभी तीन निर्भरताओं को रोक सकते हैं और फिर इकाई परीक्षण के लिए डेटाबेस में डेटा पर निर्भर नहीं हैं। इस प्रकार मानक डेटाबेस इकाई परीक्षण लिखे जाते हैं।

इस मामले में, कोई यह पूछ सकता है कि कर्मचारी तालिका के लिए डेटा कहां से आया है। इसका उत्तर यह है कि तालिका इकाई परीक्षण में परिभाषित परीक्षण डेटा से भर जाती है।

इकाई परीक्षण संग्रहित प्रक्रिया को बदलना

आइए अब अपने यूनिट टेस्ट में निर्भरता को हटा दें:

[विस्तार शीर्षक ="कोड"]

-- Simulating dependency free unit test to test the AddEmployee stored procedure
ALTER PROCEDURE TestAddEmployee
AS
BEGIN
  -- (1) Assemble

  -- Set up new employee data
  DECLARE @NAME VARCHAR(40) = 'Adil'
         ,@StartDate DATETIME2 = '2018-03-01'
         ,@Title VARCHAR(50) = 'Development Manager'

  -- Set actual table
  DROP TABLE Employee -- drop table to remove dependencies

  CREATE TABLE Employee -- create a table without dependencies (PRIMARY KEY and IDENTITY(1,1))
  (
    EmployeeId INT DEFAULT(0)
   ,NAME VARCHAR(40)
   ,StartDate DATETIME2
   ,Title VARCHAR(50)
  )

  -- Set up the expected table without dependencies (PRIMARY KEY and IDENTITY(1,1)
  CREATE TABLE #EmployeeExpected (
    EmployeeId INT DEFAULT(0)
   ,NAME VARCHAR(40)
   ,StartDate DATETIME2
   ,Title VARCHAR(50)
  )

  -- Add the expected table data
  INSERT INTO #EmployeeExpected (NAME, StartDate, Title)
    VALUES (@NAME, @StartDate, @Title)

  -- (2) Act

  -- Call AddEmployee to add new employee data to the Employee table
  EXEC AddEmployee @NAME
                  ,@StartDate
                  ,@Title
 
  -- (3) Assert

  -- Match the actual table with the expected table
  DECLARE @ActualAndExpectedTableCommonRecords INT = 0 -- we assume that the expected and actual table records have nothing in common

  SET @ActualAndExpectedTableCommonRecords = (SELECT
      COUNT(*)
    FROM (SELECT
        e.EmployeeId
       ,e.NAME
       ,e.StartDate
       ,e.Title
      FROM Employee e
      INTERSECT
      SELECT
        ee.EmployeeId
       ,ee.NAME
       ,ee.StartDate
       ,ee.Title
      FROM #EmployeeExpected ee) AS A)


  DECLARE @ExpectedTableExcluldingActualTable INT = 1 -- we assume that the expected table has records which donot exist in actual table

  SET @ExpectedTableExcluldingActualTable = (SELECT
      COUNT(*)
    FROM (SELECT
        ee.EmployeeId
       ,ee.NAME
       ,ee.StartDate
       ,ee.Title
      FROM #EmployeeExpected ee
      EXCEPT
      SELECT
        e.EmployeeId
       ,e.NAME
       ,e.StartDate
       ,e.Title
      FROM Employee e) AS A)


  IF @ActualAndExpectedTableCommonRecords = 1
    AND @ExpectedTableExcluldingActualTable = 0
    PRINT '*** Test Passed! ***'
  ELSE
    PRINT '*** Test Failed! ***'

  -- View the actual and expected tables before comparison
    SELECT e.EmployeeId
          ,e.NAME
          ,e.StartDate
          ,e.Title FROM Employee e

      SELECT    ee.EmployeeId
               ,ee.NAME
               ,ee.StartDate
               ,ee.Title FROM #EmployeeExpected ee
  
  -- Reset the table (Put back constraints after the unit test)
  DROP TABLE Employee
  DROP TABLE #EmployeeExpected

  CREATE TABLE Employee (
    EmployeeId INT PRIMARY KEY IDENTITY (1, 1)
   ,NAME VARCHAR(40)
   ,StartDate DATETIME2
   ,Title VARCHAR(50)
  );

END

[/विस्तार]

डिपेंडेंसी-फ्री सिम्युलेटेड यूनिट टेस्ट चलाना

परिणाम देखने के लिए नकली इकाई परीक्षण चलाएँ:

-- Running the dependency-free simulated unit test to check the AddEmployee stored procedure

EXEC TestAddEmployee

AddEmployee संग्रहीत कार्यविधि की जाँच करने के लिए इकाई परीक्षण को फिर से चलाएँ:

-- Running the dependency-free simulated unit test to check the AddEmployee stored procedure

EXEC TestAddEmployee

बधाई हो! इकाई परीक्षण से निर्भरता सफलतापूर्वक हटा दी गई है।

अब, भले ही हम कर्मचारी तालिका में एक नया रिकॉर्ड या नए रिकॉर्ड का सेट जोड़ते हैं, यह हमारे यूनिट परीक्षण को प्रभावित नहीं करेगा क्योंकि हमने परीक्षण से डेटा और बाधा निर्भरता को सफलतापूर्वक हटा दिया है।

tSQLt का उपयोग करके डेटाबेस यूनिट टेस्ट बनाना

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

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

यदि आप SQL सर्वर के लिए dbForge Studio का उपयोग कर रहे हैं, तो आप AddEmployee संग्रहीत कार्यविधि पर राइट-क्लिक करके और फिर "यूनिट टेस्ट" => "नया परीक्षण जोड़ें..." पर क्लिक करके यूनिट परीक्षण बना सकते हैं जैसा कि नीचे दिखाया गया है:

एक नया परीक्षण जोड़ने के लिए, आवश्यक इकाई परीक्षण जानकारी भरें:

यूनिट टेस्ट लिखने के लिए, निम्न स्क्रिप्ट का उपयोग करें:

--  Comments here are associated with the test.
--  For test case examples, see: http://tsqlt.org/user-guide/tsqlt-tutorial/
CREATE PROCEDURE [BasicTests].[test if new employee can be added]
AS
BEGIN
  --Assemble
  DECLARE @NAME VARCHAR(40) = 'Adil'
         ,@StartDate DATETIME2 = '2018-03-01'
         ,@Title VARCHAR(50) = 'Development Manager'


  EXEC tSQLt.FakeTable "dbo.Employee" -- This will create a dependency-free copy of the Employee table
  
  CREATE TABLE BasicTests.Expected -- Create the expected table
  (
    EmployeeId INT 
    ,NAME VARCHAR(40)
   ,StartDate DATETIME2
   ,Title VARCHAR(50)
  )


  -- Add the expected table data
  INSERT INTO BasicTests.Expected (NAME, StartDate, Title)
    VALUES (@NAME, @StartDate, @Title)

  --Act
  EXEC AddEmployee @Name -- Insert data into the Employee table
                  ,@StartDate 
                  ,@Title 
  

  --Assert 
  EXEC tSQLt.AssertEqualsTable @Expected = N'BasicTests.Expected'
                              ,@Actual = N'dbo.Employee'
                              ,@Message = N'Actual table matched with expected table'
                              ,@FailMsg = N'Actual table does not match with expected table'

END;
GO

फिर, डेटाबेस इकाई परीक्षण चलाएँ:

बधाई हो! हमने सफलतापूर्वक डेटाबेस यूनिट परीक्षण बनाया और चलाया है जो निर्भरता से मुक्त है।

करने के लिए चीज़ें

इतना ही। आप इस लेख को पढ़ने के बाद डेटाबेस इकाई परीक्षणों से निर्भरता को अलग करने और डेटा और बाधा निर्भरता से मुक्त डेटाबेस इकाई परीक्षण बनाने के लिए तैयार हैं। परिणामस्वरूप, आप निम्न कार्य करके अपने कौशल में सुधार कर सकते हैं:

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

उपयोगी टूल:

dbForge यूनिट टेस्ट - SQL सर्वर प्रबंधन स्टूडियो में स्वचालित इकाई परीक्षण को लागू करने के लिए एक सहज और सुविधाजनक GUI।