Database
 sql >> डेटाबेस >  >> RDS >> Database

टेस्ट-ड्रिवेन डाटाबेस डेवलपमेंट (टीडीडीडी) शुरू करने के लिए कूदें

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

पारंपरिक डेटाबेस विकास

विकास शैली में निम्नलिखित चरण होते हैं:

  1. आवश्यकताएं प्राप्त करें
  2. आवश्यकताओं के आधार पर डेटाबेस ऑब्जेक्ट बनाएं
  3. डेटाबेस ऑब्जेक्ट के लिए यूनिट परीक्षण चलाएं यह देखने के लिए कि क्या वे आवश्यकताओं को पूरा करते हैं
  4. नई आवश्यकताएं प्राप्त करें
  5. मौजूदा डेटाबेस ऑब्जेक्ट को संशोधित करें या नई आवश्यकताओं को पूरा करने के लिए नए जोड़ें
  6. यह जांचने के लिए यूनिट परीक्षण बनाएं और चलाएं कि क्या नई आवश्यकताएं तदनुसार काम करती हैं और पिछली आवश्यकताओं के साथ विरोध नहीं करती हैं

प्रक्रियाओं का पता लगाने और उनका वर्णन करने के लिए, आइए हम एक नमूना डेटाबेस सेट अप करके प्रारंभ करें SQLDevBlog :

 
-- Create sample database (SQLDevBlog)
  CREATE DATABASE SQLDevBlog

उस नमूना डेटाबेस में तालिकाएँ बनाने के लिए निम्न कोड का उपयोग करें:

USE SQLDevBlog;

-- (1) Create Author table in the sample database
CREATE TABLE Author (
  AuthorId INT PRIMARY KEY IDENTITY (1, 1)
 ,Name VARCHAR(40)
 ,RegistrationDate DATETIME2
 ,Notes VARCHAR(400)
)

-- (2) Create Article Category table in the sample database
CREATE TABLE Category (
  CategoryId INT PRIMARY KEY IDENTITY (1, 1)
 ,Name VARCHAR(50)
 ,Notes VARCHAR(400)
)

-- (3) Create Article table in the sample database
CREATE TABLE Article (
  ArticleId INT PRIMARY KEY IDENTITY (1, 1)
 ,CategoryId INT
 ,AuthorId INT
 ,Title VARCHAR(150)
 ,Published DATETIME2
 ,Notes VARCHAR(400)  
)

-- Adding foreign keys for author and article category
ALTER TABLE Article ADD CONSTRAINT FK_Category_CategoryId FOREIGN KEY (CategoryId) REFERENCES Category (CategoryId)
ALTER TABLE Article ADD CONSTRAINT FK_Author_AuthorId FOREIGN KEY (AuthorId) REFERENCES Author (AuthorId)

GO

हमारी नई बनाई गई तालिकाओं के साथ डेटाबेस आरेख की समीक्षा करें:

नोट :मैं यहां सभी कार्यों को करने के लिए SQL सर्वर के लिए dbForge Studio का उपयोग कर रहा हूं। इसके आउटपुट का स्वरूप SSMS (SQL Server Management Studio) से भिन्न हो सकता है, लेकिन परिणाम समान हैं।

इसके बाद, हम अपने SQLDevBlog . को पॉप्युलेट करेंगे अधिक यथार्थवादी परिदृश्य बनाने के लिए नमूना डेटाबेस:

-- (5) Populating Author table
INSERT INTO Author (Name, RegistrationDate, Notes)
  VALUES ('Sam', '2017-01-01', 'Database Analyst'),
  ('Asif', '2017-01-02', 'Database and Business Intelligence Developer'),
  ('Sadaf', '2018-01-01', 'Database Analyst Programmer')

-- (6) Populating Category table
INSERT INTO Category (Name, Notes)
  VALUES ('Development', 'Articles about database development'),
  ('Testing', 'Database testing related articles'),
  ('DLM', 'Database lifecycle management')

-- (7) Populating Article 
INSERT INTO Article (CategoryId, AuthorId, Title, Published, Notes)
  VALUES (1, 1, 'Fundamentals of SQL Database Development', '02-01-2018', ''),
  (1, 2, 'Advanced Database Development', '02-01-2018', ''),
  (2, 3, 'All About Database Testing', '03-01-2018', '');
GO

परिणामस्वरूप, हमारे पास निम्नलिखित पॉपुलेटेड टेबल हैं:

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

नई श्रेणी जोड़ने की आवश्यकता

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

संग्रहीत कार्यविधि बनाने के लिए, निम्न स्क्रिप्ट चलाएँ:

-- (8) This procedure meets a new requirement by adding a new category
CREATE PROCEDURE dbo.AddCategory @CategoryName VARCHAR(50),
@Notes VARCHAR(400)
AS
  INSERT INTO Category (Name, Notes)
    VALUES (@CategoryName, @Notes);
GO

परिणाम इस प्रकार है:

यह जांचने के लिए डेटाबेस यूनिट टेस्ट बनाएं कि क्या प्रक्रिया ठीक से काम करती है

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

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

पहला डेटाबेस यूनिट परीक्षण बनाने के लिए, SQLDevBlog पर राइट-क्लिक करें डेटाबेस> इकाई परीक्षण > नया परीक्षण जोड़ें

नया परीक्षण जोड़ें खिड़की खुलती है। सभी आवश्यक जानकारी भरें और परीक्षा जोड़ें . पर क्लिक करें ।

यूनिट टेस्ट इस प्रकार बनाएं और इसे सेव करें:

--  Comments here are associated with the test.
--  For test case examples, see: http://tsqlt.org/user-guide/tsqlt-tutorial/
CREATE PROCEDURE AddCategoryTests.[test to check if AddCategory procedure works]
AS
BEGIN
  --Assemble
  EXEC tSQLt.FakeTable @TableName = 'dbo.Category' -- create an empty dependency free Category table
                    

  
  CREATE TABLE AddCategoryTests.Expected ( -- create expected table 
  CategoryId INT 
 ,Name VARCHAR(50) NULL
 ,Notes VARCHAR(400) NULL
  ) 
                      
  INSERT INTO AddCategoryTests.Expected (CategoryId,Name, Notes) -- Insert data into expected table
  VALUES (null,'Database Dummy Category', 'This is just a dummy category for testing');
  
  --Act
  EXEC AddCategory @CategoryName = 'Database Dummy Category' 
                  ,@Notes = 'This is just a dummay category for testing'

   
  --Assert
  EXEC tSQLt.AssertEqualsTable @Expected = 'AddCategoryTests.Expected'
                              ,@Actual = 'dbo.Category'
                           

END;
GO

डेटाबेस क्लिक करें मेनू> इकाई परीक्षण > परीक्षा सूची देखें और नीचे दिखाए अनुसार इकाई परीक्षण चलाएँ:

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

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

परीक्षण संचालित डेटाबेस विकास (TDDD)

टेस्ट-संचालित डेटाबेस डेवलपमेंट (टीडीडीडी) यूनिट टेस्ट लिखने से शुरू होता है जो पहले विफल हो जाएगा। फिर, हम इसे पास करने के लिए संशोधित करेंगे, और फिर इसे परिशोधित करेंगे।

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

पारंपरिक डेटाबेस विकास और परीक्षण-संचालित डेटाबेस विकास के बीच अंतर को समझने के लिए, आइए हम SQLDevBlogTDD बनाएं। डेटाबेस। यह SQLDevBlog जैसा ही है ।

-- Create sample database (SQLDevBlogTDD)
  CREATE DATABASE SQLDevBlogTDD

फिर, नमूना डेटाबेस को तालिकाओं से भर दें:

USE SQLDevBlogTDD;

-- (1) Create Author table in the sample database
CREATE TABLE Author (
  AuthorId INT PRIMARY KEY IDENTITY (1, 1)
 ,Name VARCHAR(40)
 ,RegistrationDate DATETIME2
 ,Notes VARCHAR(400)
)

-- (2) Create Article Category table in the sample database
CREATE TABLE Category (
  CategoryId INT PRIMARY KEY IDENTITY (1, 1)
 ,Name VARCHAR(50)
 ,Notes VARCHAR(400)
)

-- (3) Create Article table in the sample database
CREATE TABLE Article (
  ArticleId INT PRIMARY KEY IDENTITY (1, 1)
 ,CategoryId INT
 ,AuthorId INT
 ,Title VARCHAR(150)
 ,Published DATETIME2
 ,Notes VARCHAR(400)  
)

-- Adding foreign keys for author and article category
ALTER TABLE Article ADD CONSTRAINT FK_Category_CategoryId FOREIGN KEY (CategoryId) REFERENCES Category (CategoryId)
ALTER TABLE Article ADD CONSTRAINT FK_Author_AuthorId FOREIGN KEY (AuthorId) REFERENCES Author (AuthorId)

GO

अधिक यथार्थवादी परिदृश्य बनाने के लिए हमें अपना नमूना डेटाबेस तैयार करना होगा:

-- Use SQLDevBlogTDD
-- (5) Populating Author table
INSERT INTO Author (Name, RegistrationDate, Notes)
  VALUES ('Sam', '2017-01-01', 'Database Analyst'),
  ('Asif', '2017-01-02', 'Database and Business Intelligence Developer'),
  ('Sadaf', '2018-01-01', 'Database Analyst Programmer')

-- (6) Populating Category table
INSERT INTO Category (Name, Notes)
  VALUES ('Development', 'Articles about database development'),
  ('Testing', 'Database testing related articles'),
  ('DLM', 'Database lifecycle management')

-- (7) Populating Article 
INSERT INTO Article (CategoryId, AuthorId, Title, Published, Notes)
  VALUES (1, 1, 'Fundamentals of SQL Database Development', '02-01-2018', ''),
  (1, 2, 'Advanced Database Development', '02-01-2018', ''),
  (2, 3, 'All About Database Testing', '03-01-2018', '');
GO

नई श्रेणी जोड़ने की आवश्यकता (TDDD)

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

इस प्रकार TDDD काम करता है:इकाई परीक्षण पहले विफल हो जाता है क्योंकि हम मानते हैं कि हम उस वस्तु की तलाश कर रहे हैं जो वर्तमान में मौजूद नहीं है, लेकिन यह जल्द ही होने वाली है।

वांछित वस्तु मौजूद है यह जांचने के लिए डेटाबेस यूनिट टेस्ट बनाएं और चलाएं

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

SQL सर्वर के लिए dbForge Studio में, डेटाबेस इकाई परीक्षण जो डिफ़ॉल्ट रूप से TDDD का समर्थन करता है, पहले विफल होने के लिए बनाया गया है। फिर, हम इसे थोड़ा बदलने जा रहे हैं। अगर आप tSQLt . का उपयोग कर रहे हैं डेटाबेस इकाई परीक्षण ढांचा सीधे, निम्नलिखित इकाई परीक्षण लिखें:

--  Comments here are associated with the test.
--  For test case examples, see: http://tsqlt.org/user-guide/tsqlt-tutorial/
CREATE PROCEDURE CategoryTests.[test to check if routine to add new category exists]
AS
BEGIN
  --Assemble
  --  This section is for code that sets up the environment. It often
  --  contains calls to methods such as tSQLt.FakeTable and tSQLt.SpyProcedure
  --  along with INSERTs of relevant data.
  --  For more information, see http://tsqlt.org/user-guide/isolating-dependencies/

  --Act
  --  Execute the code under tests like a stored procedure, function, or view
  --  and capture the results in variables or tables.

  --Assert
  --  Compare the expected and actual values, or call tSQLt.Fail in an IF statement.
  --  Available Asserts: tSQLt.AssertEquals, tSQLt.AssertEqualsString, tSQLt.AssertEqualsTable
  --  For a complete list, see: http://tsqlt.org/user-guide/assertions/
  EXEC tSQLt.AssertObjectExists @ObjectName = N'dbo.AddCategory'
                              

END;
GO

डेटाबेस इकाई परीक्षण चलाने के बाद, आप देख सकते हैं कि परीक्षण विफल रहता है:

डेटाबेस ऑब्जेक्ट बनाएं और यूनिट टेस्ट फिर से चलाएं

अगला चरण आवश्यक डेटाबेस ऑब्जेक्ट बनाना है। हमारे मामले में, यह एक संग्रहित प्रक्रिया है।

-- (8) This procedure meets the new requirement by adding a new category
CREATE PROCEDURE dbo.AddCategory @CategoryName VARCHAR(50),
@Notes VARCHAR(400)
AS  
-- Category Procedure Stub (template) in TDDD
GO

इकाई परीक्षण फिर से चलाएँ - इस बार यह सफल रहा:

लेकिन यदि संग्रहीत कार्यविधि मौजूद है, तो यूनिट परीक्षण जाँच को पास करना पर्याप्त नहीं है। हमें यह भी जांचना होगा कि संग्रहीत प्रक्रिया एक नई श्रेणी जोड़ती है या नहीं।

यह जांचने के लिए डेटाबेस यूनिट टेस्ट बनाएं कि रूटीन ठीक से काम करता है या नहीं

आइए नया डेटाबेस यूनिट टेस्ट बनाएं:

--  Comments here are associated with the test.
--  For test case examples, see: http://tsqlt.org/user-guide/tsqlt-tutorial/
CREATE PROCEDURE CategoryTests.[test to check routine adds new category]
AS
BEGIN
  --Assemble
  EXEC tSQLt.FakeTable @TableName = 'dbo.Category' -- create an empty dependency free Category table
                      

  
  CREATE TABLE CategoryTests.Expected ( -- create expected table 
  CategoryId INT 
 ,Name VARCHAR(50) NULL
 ,Notes VARCHAR(400) NULL
  ) 
                      
  INSERT INTO CategoryTests.Expected (CategoryId,Name, Notes) -- Insert data into expected table
  VALUES (null,'Database Dummy Category', 'This is just a dummy category for testing');
  
  --Act
  EXEC AddCategory @CategoryName = 'Database Dummy Category' 
                  ,@Notes = 'This is just a dummay category for testing'

  --SELECT * INTO CategoryTests.Actual FROM Category -- put category table data into an actual table
  
  --Assert
  EXEC tSQLt.AssertEqualsTable @Expected = 'CategoryTests.Expected'
                              ,@Actual = 'dbo.Category'
                           

END;
GO

जैसा कि आप देख सकते हैं, इकाई परीक्षण पहली बार विफल होता है और दूसरी बार सफल होता है:

रूटीन और रीरन यूनिट टेस्ट में कार्यक्षमता जोड़ें

आवश्यक कार्यक्षमता जोड़कर संग्रहीत कार्यविधि को संशोधित करें ताकि परीक्षण नीचे दिखाए अनुसार सफल हो सके:

-- (8) This procedure meets the new requirement by adding a new category
ALTER PROCEDURE dbo.AddCategory @CategoryName VARCHAR(50),
@Notes VARCHAR(400)
AS
  INSERT INTO Category (Name, Notes)
    VALUES (@CategoryName, @Notes);
GO

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

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

आइए देखें कि जब व्यापार रिपोर्टिंग आवश्यकता को पूरा करने की बात आती है तो TDDD कितना प्रभावी होता है।

TDDD के माध्यम से व्यवसाय रिपोर्टिंग आवश्यकता को पूरा करना

हम मानते हैं कि नई व्यावसायिक रिपोर्टिंग आवश्यकता प्राप्त करने से पहले डेटाबेस को पहले से ही आवश्यक वस्तुएं (जैसे टेबल) मिल गई हैं।

आइए एक नमूना डेटाबेस बनाएं जिसे SQLDevBlogReportTDD . कहा जाता है :

-- Create sample database (SQLDevBlogReportTDD)
CREATE DATABASE SQLDevBlogReportTDD;
GO

फिर निम्न कोड का उपयोग करके नमूना डेटाबेस के लिए टेबल बनाएं और पॉप्युलेट करें:

USE SQLDevBlogReportTDD;
-- (1) Create Author table in the sample database
CREATE TABLE Author (
  AuthorId INT PRIMARY KEY IDENTITY (1, 1)
 ,Name VARCHAR(40)
 ,RegistrationDate DATETIME2
 ,Notes VARCHAR(400)
)

-- (2) Create an Article Category table in the sample database
CREATE TABLE Category (
  CategoryId INT PRIMARY KEY IDENTITY (1, 1)
 ,Name VARCHAR(50)
 ,Notes VARCHAR(400)
)

-- (3) Create Article table in the sample database
CREATE TABLE Article (
  ArticleId INT PRIMARY KEY IDENTITY (1, 1)
 ,CategoryId INT
 ,AuthorId INT
 ,Title VARCHAR(150)
 ,Published DATETIME2
 ,Notes VARCHAR(400)  
)

-- Adding foreign keys for author and article category
ALTER TABLE Article ADD CONSTRAINT FK_Category_CategoryId FOREIGN KEY (CategoryId) REFERENCES Category (CategoryId)
ALTER TABLE Article ADD CONSTRAINT FK_Author_AuthorId FOREIGN KEY (AuthorId) REFERENCES Author (AuthorId)

GO

-- (4) Populating Author table
INSERT INTO Author (Name, RegistrationDate, Notes)
  VALUES ('Peter', '2017-01-01', 'Database Analyst'),
  ('Adil', '2017-01-02', 'Database and Business Intelligence Developer'),
  ('Sarah', '2018-01-01', 'Database Analyst Programmer'),
  ('Asim', '2018-01-01', 'Database Analyst')

-- (5) Populating Category table
INSERT INTO Category (Name, Notes)
  VALUES 
  ('Analysis', 'Database Analysis'),
  ('Development', 'Articles about database development'),
  ('Testing', 'Database testing related articles'),
  ('DLM', 'Database lifecycle management')
 

-- (6) Populating Article 
INSERT INTO Article (CategoryId, AuthorId, Title, Published, Notes)
  VALUES (1, 1, 'Replicating a problem in SQL', '02-01-2018', ''),
  (1, 2, 'Modern Database Development Tools', '02-01-2018', ''),
  (3, 3, 'Test Driven Database Development (TDDD)', '03-01-2018', ''),
  (3, 1, 'Database Unit Testing Fundamentals', '10-01-2018', ''),
  (3, 3, 'Unit Testing with tSQLt', '10-01-2018', '')
GO

सभी लेखकों, लेखों और लेखों की श्रेणियों की सूची देखने के लिए एक दृश्य बनाएं:

-- (7) Create a view to see a list of authors, articles, and categories
CREATE VIEW dbo.vwAuthors 
AS SELECT a.Name AS AuthorName,a1.Title AS ArticleTitle,c.Name AS CategoryName  FROM Author a INNER JOIN Article a1 ON a.AuthorId = a1.AuthorId INNER JOIN Category c ON a1.CategoryId = c.CategoryId
GO

परिणाम देखने के लिए बनाई गई तालिका का दृश्य चलाएँ:

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

व्यावसायिक आवश्यकता:प्रति लेखक रिपोर्ट में लेखों की कुल संख्या

एक नई व्यवसाय रिपोर्टिंग आवश्यकता पर विचार करें। प्रति लेखक लेखों की कुल संख्या देखने के लिए इसे एक डेटाबेस रिपोर्ट बताना होगा।

पहली बात एक डेटाबेस ऑब्जेक्ट को असाइन करना है जो व्यावसायिक आवश्यकताओं को पूरा कर सके। हमारे मामले में, यह ArticlesPerAuthorReport . है डेटाबेस ऑब्जेक्ट।

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

TDDD कार्यान्वयन योजना

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

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

वांछित वस्तु मौजूद है यह जांचने के लिए डेटाबेस यूनिट टेस्ट बनाएं

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

पहला डेटाबेस इकाई परीक्षण बनाने के लिए, SQLDevBlogReport . पर राइट-क्लिक करें डेटाबेस> इकाई परीक्षण > नया परीक्षण जोड़ें

वांछित वस्तु के अस्तित्व या अनुपस्थिति की जाँच करने वाले इकाई परीक्षण को बनाने के लिए निम्नलिखित कोड लिखें:

CREATE PROCEDURE ArticlesPerAuthorReport.[test to check ArticlesPerAuthorReport exists]
AS
BEGIN
  --Assemble
 
  --Act
  
  --Assert
   EXEC tSQLt.AssertObjectExists @ObjectName = N'ArticlesPerAuthorReport'
END;
GO

इकाई परीक्षण विफल होना चाहिए क्योंकि यह पहले बनाई गई वस्तु की जांच करता है। ऑब्जेक्ट स्वयं TDDD के अनुपालन के लिए बनाया गया है:

ऑब्जेक्ट स्टब बनाएं और यूनिट चलाएं

कुछ हार्ड-कोडेड अपेक्षित आउटपुट के साथ ऑब्जेक्ट स्टब बनाएं, क्योंकि हम केवल अपेक्षित परिणाम के साथ डेटाबेस ऑब्जेक्ट बनाना चाहते हैं। ArticlesPerAuthorReport बनाएं पहली बार में एक दृश्य स्टब (प्लेसहोल्डर) के रूप में वस्तु:

-- (8) Create ArticlesPerAuthorReport view stub
  CREATE VIEW ArticlesPerAuthorReport
    AS
    SELECT 'Adil' AS Author, 10 AS [Total Articles]
    UNION ALL
    SELECT 'Sam' AS Author, 5 AS [Total Articles]

इकाई परीक्षण चलाना सफल होना चाहिए:

स्टब बनाना TDDD के लिए किक-स्टार्टर का काम करता है। हम परीक्षा पास करने के लिए ऑब्जेक्ट बनाते हैं और ऑब्जेक्ट के वास्तविक कामकाज की परवाह नहीं करते हैं।

ऑब्जेक्ट आउटपुट सही डेटा है या नहीं यह जांचने के लिए यूनिट टेस्ट बनाएं और चलाएं

यह जांचने का समय है कि वांछित वस्तु ठीक से काम कर रही है या नहीं। वांछित वस्तु द्वारा डेटा आउटपुट की जांच करने के लिए एक और इकाई परीक्षण बनाएं (ArticlesPerAuthorReport ) आइए डेटाबेस में एक नया इकाई परीक्षण जोड़ें:

निम्नलिखित इकाई परीक्षण कोड जोड़ें:

CREATE PROCEDURE ArticlesPerAuthorReport.[test to check ArticlesPerAuthorReport outputs correct]
AS
BEGIN
  --Assemble
  --  Create mocked up tables (blank copies of original tables without constraints and data)
  EXEC tSQLt.FakeTable @TableName = N'Author'
                      ,@SchemaName = N'dbo'

  EXEC tSQLt.FakeTable @TableName = N'Article'
                      ,@SchemaName = N'dbo'                      

  EXEC tSQLt.FakeTable @TableName = N'Category'
                      ,@SchemaName = N'dbo'                      

  -- Add rows to the mocked up tables
  INSERT INTO Author (AuthorId,Name, RegistrationDate, Notes)
  VALUES (1,'Zak', DATEFROMPARTS(2017,01,01), 'Database Author'),
    (2,'Akeel',DATEFROMPARTS(2018,01,01),'Business Intelligence Author')
  
  INSERT INTO Category (CategoryID,Name, Notes)
  VALUES (1,'Database Development', '-'),
  (2,'Business Intelligene','-');

  INSERT INTO Article (ArticleId,CategoryId, AuthorId, Title, Published, Notes)
  VALUES (1,1, 1, 'Advanced Database Development', DATEFROMPARTS(2017,02,01),'10K Views'),
  (1,1, 1, 'Database Development with Cloud Technologies', DATEFROMPARTS(2017,02,01),'5K Views'),
  (1,1, 1, 'Developing Databases with Modern Tools', DATEFROMPARTS(2017,03,01),'20K Views'),
  (1,2, 2, 'Business Intelligence Fundamentals', DATEFROMPARTS(2017,02,01),'10K Views'),
  (1,2, 2, 'Tabular Models', DATEFROMPARTS(2017,02,01),'50K Views')

  -- Create an expected table
  CREATE TABLE ArticlesPerAuthorReport.Expected
  (Author VARCHAR(40),[Total Articles] int)  

  -- Add expected results into an expected table
  INSERT INTO ArticlesPerAuthorReport.Expected (Author, [Total Articles])
  VALUES ('Zak', 3), ('Akeel',2);


  --Act
  --  Run ArticlesPerAuthorReport object (view) and put results into an actual table
  SELECT * INTO ArticlesPerAuthorReport.Actual FROM ArticlesPerAuthorReport apar
  

  --Assert
  --  Compare the expected and actual tables
  EXEC TSQLT.AssertEqualsTable @Expected = N'ArticlesPerAuthorReport.Expected'
                              ,@Actual = N'ArticlesPerAuthorReport.Actual'
                              

END;
GO

TDDD का अनुपालन करने के लिए असफल होने के साथ-साथ यूनिट परीक्षण चलाएँ:

ArtsPerAuthorReport ऑब्जेक्ट में आवश्यक कार्यक्षमता जोड़ें

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

ArticlesPerAuthorReport . को संशोधित करें दूसरे यूनिट टेस्ट को पहले वाले की तरह ही पास होने देने के लिए देखें:

ALTER VIEW ArticlesPerAuthorReport
  AS
SELECT a.Name AS [Author],COUNT(a1.ArticleId) AS [Total Articles] FROM Author a 
    INNER JOIN Article a1 ON a.AuthorId = a1.AuthorId
    GROUP BY a.Name

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

ArticlesPerAuthorReport वस्तु तैयार है।

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

रिपोर्टिंग आवश्यकता को लागू करना (ArticlePerAuthorReport)

सबसे पहले, हम SQLDevBlogReportTDD . को रीसेट करने जा रहे हैं और इसमें और डेटा जोड़ें। या, आप पहली बार एक खाली डेटाबेस बना सकते हैं।

हमारे नमूना डेटाबेस में पर्याप्त डेटा जोड़ने के लिए, vwAuthors . से डेटा पुनर्प्राप्त करें सभी रिकॉर्ड देखने के लिए देखें:

इकाई परीक्षण चलाना

डेटाबेस इकाई परीक्षण चलाएँ जो हमने पहले बनाए थे:

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

articlePerAuthorsReport ऑब्जेक्ट के आधार पर डेटाबेस रिपोर्ट बनाएं

आप कई तरीकों से डेटाबेस रिपोर्ट बना सकते हैं (जैसे रिपोर्ट बिल्डर का उपयोग करना, विजुअल स्टूडियो डेटा टूल्स में रिपोर्ट सर्वर प्रोजेक्ट बनाना, या SQL सर्वर के लिए dbForge स्टूडियो का उपयोग करना)।

इस खंड में, हम रिपोर्ट बनाने के लिए SQL सर्वर के लिए dbForge Studio का उपयोग कर रहे हैं। आगे बढ़ने के लिए, नया . क्लिक करें फ़ाइल . से मेनू> डेटा रिपोर्ट :

मानक रिपोर्ट पर क्लिक करें :

साधारण तालिका\दृश्य चुनें डेटा प्रकार . के रूप में :

मूल वस्तु जोड़ें (ArticlesPerAuthorReport ), जो हमारे मामले में एक दृश्य है:

आवश्यक फ़ील्ड जोड़ें:

हमें इस समय किसी समूहीकरण की आवश्यकता नहीं है, इसलिए अगला . पर क्लिक करके आगे बढ़ें :

लेआउट चुनें और अभिविन्यास डेटा रिपोर्ट की:

अंत में, शीर्षक जोड़ें लेख प्रति लेखक रिपोर्ट और समाप्त करें . क्लिक करें :

इसके बाद, रिपोर्ट के स्वरूपण को आवश्यकता के अनुसार समायोजित करें:

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

रिपोर्ट को ArticlesPerAuthorReport . के रूप में सहेजें . डेटाबेस रिपोर्ट व्यावसायिक आवश्यकताओं के कारण बनाई गई है।

सेटअप प्रक्रिया का उपयोग

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

हम इकट्ठे . के अंतर्गत लिखे गए लगभग सभी परीक्षण कोड डाल सकते हैं (अनुभाग) कोड दोहराव से बचने के लिए सेटअप प्रक्रिया के तहत।

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

परीक्षण कोड दोहराव से बचने के लिए सेटअप प्रक्रिया बनाना

SQLDevBlogTDD . में संग्रहीत कार्यविधि बनाएं इस प्रकार है:

-- (12) Use of Setup Procedure to avoid repeating common test code
CREATE PROCEDURE ArticlesPerAuthorReport.Setup 
AS 
BEGIN
  --Assemble
  --  Create mocked up tables (blank copies of original tables without constraints and data)
  EXEC tSQLt.FakeTable @TableName = N'Author'
                      ,@SchemaName = N'dbo'

  EXEC tSQLt.FakeTable @TableName = N'Article'
                      ,@SchemaName = N'dbo'                      

  EXEC tSQLt.FakeTable @TableName = N'Category'
                      ,@SchemaName = N'dbo'                      

  -- Add rows to the mocked up tables
  INSERT INTO Author (AuthorId,Name, RegistrationDate, Notes)
  VALUES (1,'Zak', DATEFROMPARTS(2017,01,01), 'Database Author'),
    (2,'Akeel',DATEFROMPARTS(2018,01,01),'Business Intelligence Author')
  
  INSERT INTO Category (CategoryID,Name, Notes)
  VALUES (1,'Database Development', '-'),
  (2,'Business Intelligene','-');

  INSERT INTO Article (ArticleId,CategoryId, AuthorId, Title, Published, Notes)
  VALUES (1,1, 1, 'Advanced Database Development', DATEFROMPARTS(2017,02,01),'10K Views'),
  (1,1, 1, 'Database Development with Cloud Technologies', DATEFROMPARTS(2017,02,01),'5K Views'),
  (1,1, 1, 'Developing Databases with Modern Tools', DATEFROMPARTS(2017,03,01),'20K Views'),
  (1,2, 2, 'Business Intelligence Fundamentals', DATEFROMPARTS(2017,02,01),'10K Views'),
  (1,2, 2, 'Tabular Models', DATEFROMPARTS(2017,02,01),'50K Views')

  -- Create an expected table
  CREATE TABLE ArticlesPerAuthorReport.Expected
  (Author VARCHAR(40),[Total Articles] int)  

  -- Add expected results into an expected table
  INSERT INTO ArticlesPerAuthorReport.Expected (Author, [Total Articles])
  VALUES ('Zak', 3), ('Akeel',2)
END;
GO

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

-- (11) Create unit test check ArticlesPerAuthorReport outputs correct
ALTER PROCEDURE ArticlesPerAuthorReport.[test to check ArticlesPerAuthorReport outputs correct]
AS
BEGIN
  --Assemble (Test Code written in Setup Procedure)
  -- Create mocked up tables (blank copies of original tables without constraints and data)
  -- Add rows to the mocked up tables
  -- Create an expected table
  -- Add expected results into an expected table
  
  --Act
  --  Run ArticlesPerAuthorReport object (view) and put results into an actual table
  SELECT * INTO ArticlesPerAuthorReport.Actual FROM ArticlesPerAuthorReport apar
  

  --Assert
  --  Compare the expected and actual tables
  EXEC TSQLT.AssertEqualsTable @Expected = N'ArticlesPerAuthorReport.Expected'
                              ,@Actual = N'ArticlesPerAuthorReport.Actual'
                              
END;
GO

Running All Unit Tests to Check Setup Procedure Working

Run the unit tests and see the results:

The unit tests have run successfully despite the fact we are using a setup procedure to run some parts of the test code before these unit tests are running.

Use of Stored Procedures

Next, we’ll focus on creating stored procedures through test-driven database development (TDDD) to meet specific requirements that cannot be fulfilled by using a database view.

Let’s assume that business users want to know the Total number of articles per author for a specified year . The database view can’t meet it because it is not defined at the time of writing the script (exactly the year is going to be desired by the business users).

Thus, it requires a database object with parameter(s) capability and it is exactly the stored procedure.

Let us consider a new business requirement to create the report that shows the total number of articles per author for a specified year . We’ll use the sample database called SQLDevBlogReportTDD that we created earlier.

Run the ArticlesPerAuthorReport view to see the results:

Select the Database Object (AuthorsPerArticleByYearReport)

Name the potential database object as AuthorsPerArticleForYearReport ।

As we mentioned above, the database view can meet the reporting requirement despite the absence of the specified year . But this variable means that we need the stored procedure which will pass year as an argument to run the report and show the desired results.

Write and Run the Object Exists Unit Test

As we already know, we need to start with writing the basic unit test to check the existence or absence of the desired object.

To create the first database unit test, right-click the SQLDevBlogReport database> Unit Test > Add New Test

Write the following test code:

CREATE PROCEDURE ArticlesPerAuthorByYearReport.[test to check ArticlesPerAuthorByYearReport exists]

AS

BEGIN

--Assemble

--Act

--Assert

EXEC tSQLt.AssertObjectExists @ObjectName = N'ArticlesPerAuthorByYearReport'

,@Message = N''


END;

GO

Right-click on the database> click View Test List under Unit Test to see the Test List Manager :

Check the ArticlesPerAuthorByYearReport test class and click the run test icon:

This complies with TDDD – the unit test checking if object existence is written before the object is created. So, we expect the test to fail first.

Create Object Stub (dummy object)

We are going to create an object stub that mocks the object’s functionality. At this stage, we only need that object, the desired functionality is out of the question.

Create a stored procedure type object as the stub and call it ArticlesPerAuthorByYearReport by using the following code:

-- Create report object (stored procedure) stub

CREATE PROCEDURE dbo.ArticlesPerAuthorByYearReport

@Year INT

AS

SELECT 'Adil' AS Author, 10 AS [Total Articles], 0000 AS [Year]

UNION ALL

SELECT 'Sam' AS Author, 5 AS [Total Articles], 0000 AS [Year]

GO

After we created the object stub, the basic unit test that checks for the existence of the object will be successful:

Write and Run the Object Functionality Unit Test

To comply with TDDD, we need to write a unit test to check whether the desired object ArticlesPerAuthorByYearReport functions properly. Since the object was created as a stub (placeholder), this unit test is also going to fail first. The object has to function properly yet despite the fact it was created and passed the basic check of its existence.

Create a second unit test to check if the object outputs correct data by creating a setup procedure (which helps us to write shared test code within the same test class) that is followed by the unit test:

CREATE PROCEDURE ArticlesPerAuthorByYearReport. Setup

AS

BEGIN

--Assemble

-- Create mocked up tables (blank copies of original tables without constraints and data)

EXEC tSQLt.FakeTable @TableName = N'Author'

,@SchemaName = N'dbo'




EXEC tSQLt.FakeTable @TableName = N'Article'

,@SchemaName = N'dbo'




EXEC tSQLt.FakeTable @TableName = N'Category'

,@SchemaName = N'dbo'




-- Add rows to the mocked up tables

INSERT INTO Author (AuthorId,Name, RegistrationDate, Notes)

VALUES (1,'Zak', DATEFROMPARTS(2017,01,01), 'Database Author'),

(2,'Akeel',DATEFROMPARTS(2018,01,01),'Business Intelligence Author')

INSERT INTO Category (CategoryID,Name, Notes)

VALUES (1,'Database Development', '-'),

(2,'Business Intelligene','-');




INSERT INTO Article (ArticleId,CategoryId, AuthorId, Title, Published, Notes)

VALUES (1,1, 1, 'Advanced Database Development', DATEFROMPARTS(2017,02,01),'10K Views'),

(1,1, 1, 'Database Development with Cloud Technologies', DATEFROMPARTS(2017,02,01),'5K Views'),

(1,1, 1, 'Developing Databases with Modern Tools', DATEFROMPARTS(2017,03,01),'20K Views'),

(1,2, 2, 'Business Intelligence Fundamentals', DATEFROMPARTS(2016,02,01),'10K Views'),

(1,2, 2, 'Tabular Models', DATEFROMPARTS(2016,02,01),'50K Views')




-- Create an expected table

CREATE TABLE ArticlesPerAuthorByYearReport.Expected

(Author VARCHAR(40),[Total Articles] INT,[Year] INT)




-- Create an actual table

CREATE TABLE ArticlesPerAuthorByYearReport.Actual

(Author VARCHAR(40),[Total Articles] INT,[Year] INT)




-- Add expected results into an expected table for the year 2017

INSERT INTO ArticlesPerAuthorByYearReport.Expected (Author, [Total Articles],[Year])

VALUES ('Zak', 3,2017)




END;

GO

Write the unit test to check if the object functions properly:

-- Create unit test to check ArticlesPerAuthorByYearReport outputs correct data

CREATE PROCEDURE ArticlesPerAuthorByYearReport.[test to check ArticlesPerAuthorByYearReport outputs correct data]

AS

BEGIN

--Assemble (Test Code written in Setup Procedure)

-- Create mocked up tables (blank copies of original tables without constraints and data)

-- Add rows to the mocked up tables

-- Create an expected table

-- Create an actual table

-- Add expected results into an expected table

--Act

-- Call desired object (stored procedure) and put results into an actual table

INSERT INTO ArticlesPerAuthorByYearReport.Actual

EXEC dbo.ArticlesPerAuthorByYearReport @Year=2017




--Assert

-- Compare the expected and actual tables

EXEC TSQLT.AssertEqualsTable @Expected = N'ArticlesPerAuthorByYearReport.Expected'

,@Actual = N'ArticlesPerAuthorByYearReport.Actual'

END;

GO

Run the unit test. As demonstrated earlier, it will fail first since we have not added the desired functionality to the object yet:

Add Object Functionality and Rerun the Unit Test

Add the object functionality by modifying the stored procedure as follows:

-- Create report object (stored procedure) to show articles per author for a specified year

CREATE PROCEDURE dbo.ArticlesPerAuthorByYearReport

@Year INT

AS




SELECT

a.Name AS [Author],COUNT(a1.ArticleId) AS [Total Articles],YEAR(a.RegistrationDate) AS [Year]

FROM Author a

INNER JOIN Article a1

ON a.AuthorId = a1.AuthorId

WHERE YEAR(a.RegistrationDate) = @Year

GROUP BY a.Name,YEAR(a.RegistrationDate)

GO

नोट :If you are using a declarative database development tool like dbForge Studio for SQL Server, you’ll use the Create Procedure statement to modify the object. For tools like SSMS (SQL Server Management Studio), you must use ALTER Procedure ।

Rerunning the database unit test for checking the proper object functioning gives us the following results:

You have successfully unit tested the reporting procedure that is responsible for meeting the business requirement.

निष्कर्ष

Test-driven database development (TDDD) is a specific approach. To meet the business requirement(s), potential database object(s) must pass the unit test(s) and satisfy the following conditions under normal circumstances:

  • The database object must exist
  • The database object must function properly to meet the business requirement

First, the unit tests have to fail because they are created before the creation of the object/defining the object functionality. After adding the necessary objects and ensuring their functionality, the unit tests succeed.

This article examined the basics of test-driven database development and illustrated it with practical examples. We hope that the article was helpful to you. Feel free to share your opinions and maybe some lifehacks in the Comments section, and stay tuned for the next materials!


  1. Database
    2.   
  2. Mysql
    3.   
  3. Oracle
    4.   
  4. Sqlserver
    5.   
  5. PostgreSQL
    6.   
  6. Access
    7.   
  7. SQLite
    8.   
  8. MariaDB

  1. कार्यात्मक इकाइयाँ

  2. SQL में नंबर कैसे राउंड करें

  3. किसी अन्य कॉलम के फ़िल्टर के आधार पर कॉलम को कैसे अपडेट करें

  4. शुरुआती के लिए एसक्यूएल ट्यूटोरियल

  5. WP-CLI का उपयोग करके पोस्ट संशोधन कैसे हटाएं