Nghệ thuật tách biệt sự phụ thuộc và dữ liệu trong kiểm thử đơn vị cơ sở dữ liệu

Tất cả các nhà phát triển cơ sở dữ liệu ít nhiều đều viết các bài kiểm tra đơn vị cơ sở dữ liệu không chỉ giúp phát hiện lỗi sớm mà còn tiết kiệm rất nhiều thời gian và nỗ lực khi hành vi không mong muốn của các đối tượng cơ sở dữ liệu trở thành vấn đề sản xuất.

Ngày nay, có một số khuôn khổ kiểm tra đơn vị cơ sở dữ liệu như tSQLt cùng với các công cụ kiểm tra đơn vị của bên thứ ba bao gồm cả dbForge Unit Test.

Một mặt, lợi ích của việc sử dụng các công cụ kiểm tra của bên thứ ba là nhóm phát triển có thể tạo và chạy các bài kiểm tra đơn vị ngay lập tức với các tính năng được bổ sung. Ngoài ra, việc sử dụng khung kiểm thử trực tiếp cho phép bạn kiểm soát nhiều hơn các bài kiểm tra đơn vị. Do đó, bạn có thể thêm nhiều chức năng hơn vào chính khung kiểm thử đơn vị. Tuy nhiên, trong trường hợp này, nhóm của bạn phải có thời gian và trình độ chuyên môn nhất định để thực hiện việc này.

Bài viết này khám phá một số phương pháp thực hành tiêu chuẩn có thể giúp chúng tôi cải thiện cách chúng tôi viết các bài kiểm tra đơn vị cơ sở dữ liệu.

Trước tiên, chúng ta hãy xem qua một số khái niệm chính về kiểm thử đơn vị cơ sở dữ liệu.

Kiểm thử đơn vị cơ sở dữ liệu là gì

Theo Dave Green, các bài kiểm tra đơn vị cơ sở dữ liệu đảm bảo rằng các đơn vị nhỏ của cơ sở dữ liệu, chẳng hạn như bảng, dạng xem, thủ tục được lưu trữ, v.v., đang hoạt động như mong đợi.

Các bài kiểm tra đơn vị cơ sở dữ liệu được viết để xác minh xem mã có đáp ứng các yêu cầu kinh doanh hay không.

Ví dụ:nếu bạn nhận được yêu cầu như “Thủ thư (người dùng cuối) có thể thêm sách mới vào thư viện (Hệ thống thông tin quản lý)”, bạn cần nghĩ đến việc áp dụng các bài kiểm tra đơn vị cho quy trình được lưu trữ để kiểm tra xem nó có thể thêm một cuốn sách mới vào Sách bảng.

Đôi khi, một loạt các bài kiểm tra đơn vị đảm bảo rằng mã đáp ứng các yêu cầu. Do đó, hầu hết các khuôn khổ kiểm thử đơn vị bao gồm tSQLt cho phép nhóm các bài kiểm tra đơn vị liên quan thành một lớp kiểm tra duy nhất thay vì chạy các bài kiểm tra riêng lẻ.

Nguyên tắc AAA

Điều đáng nói là nguyên tắc 3 bước của bài kiểm tra đơn vị là một thực hành tiêu chuẩn để viết bài kiểm tra đơn vị. Nguyên tắc AAA là cơ sở để kiểm tra đơn vị và bao gồm các bước sau:

Sắp xếp / Lắp ráp
Hành động
Khẳng định

Sắp xếp là bước đầu tiên trong việc viết các bài kiểm tra đơn vị cơ sở dữ liệu. Nó hướng dẫn cách cấu hình một đối tượng cơ sở dữ liệu để thử nghiệm và thiết lập các kết quả mong đợi.

Hành động là khi một đối tượng cơ sở dữ liệu (đang thử nghiệm) được gọi để tạo ra đầu ra thực tế.

Khẳng định bước giải quyết việc khớp kết quả đầu ra thực tế với kết quả mong đợi và xác minh xem bài kiểm tra đạt hay không đạt.

Hãy khám phá các phương pháp này trên các ví dụ cụ thể.

Nếu chúng tôi tạo thử nghiệm đơn vị để xác minh rằng Sản phẩm bổ sung quy trình được lưu trữ có thể thêm sản phẩm mới, chúng tôi thiết lập Sản phẩm và Sản phẩm mong đợi bảng sau khi sản phẩm được thêm vào. Trong trường hợp này, phương pháp nằm trong phần Sắp xếp / Lắp ráp.

Việc gọi thủ tục AddProduct và đưa kết quả vào bảng Sản phẩm nằm trong phần Hành động.

Phần Assert chỉ đơn giản là khớp bảng Sản phẩm với bảng Sản phẩm mong đợi để xem liệu thủ tục được lưu trữ đã được thực thi thành công hay thất bại.

Hiểu sự phụ thuộc trong Kiểm thử đơn vị

Cho đến nay, chúng ta đã thảo luận về những điều cơ bản về kiểm thử đơn vị cơ sở dữ liệu và tầm quan trọng của nguyên tắc AAA (Assemble, Act và Assert) khi tạo kiểm thử đơn vị tiêu chuẩn.

Bây giờ, chúng ta hãy tập trung vào một phần quan trọng khác của câu đố - sự phụ thuộc trong kiểm thử đơn vị.

Ngoài việc tuân theo nguyên tắc AAA và chỉ tập trung vào một đối tượng cơ sở dữ liệu cụ thể (đang thử nghiệm), chúng ta cũng cần biết các yếu tố phụ thuộc có thể ảnh hưởng đến các thử nghiệm đơn vị.

Cách tốt nhất để hiểu sự phụ thuộc là xem một ví dụ về kiểm thử đơn vị.

EmploySample Database Setup

Để tiếp tục, hãy tạo một cơ sở dữ liệu mẫu và gọi nó là Nhân viên mẫu :

- Tạo cơ sở dữ liệu mẫu Nhân viên để chứng minh thử nghiệm đơn vị

Bây giờ, hãy tạo Nhân viên bảng trong cơ sở dữ liệu mẫu:

 - Tạo bảng Nhân viên trong cơ sở dữ liệu mẫu vì BẢNG NHÂN VIÊN NHÂN VIÊN (EmployeeId INT PRIMARY KEY IDENTITY (1,1), NAME VARCHAR (40), StartDate DATETIME2, Title VARCHAR (50)); ĐI

Đang điền dữ liệu mẫu

Điền vào bảng bằng cách thêm một vài bản ghi:

 - Thêm dữ liệu vào bảng Nhân viên CHÈN VÀO NHÂN VIÊN (TÊN, Ngày bắt đầu, Chức danh) GIÁ TRỊ ('Sam', '2018-01-01', 'Nhà phát triển'), ('Asif', '2017-12-12 ',' Người kiểm tra '), (' Andy ',' 2016-10-01 ',' Nhà phát triển cấp cao '), (' Peter ',' 2017-11-01 ',' Kỹ sư cơ sở hạ tầng '), (' Sadaf ', '2015-01-01', 'Nhà phân tích kinh doanh'); ĐI

Bảng trông như sau:

 - Xem bảng Nhân viên CHỌN e.EaffeeId, e.NAME, e.StartDate, e.Title FROM Employee e; GO

Xin lưu ý rằng tôi đang sử dụng dbForge Studio cho SQL Server trong bài viết này. Do đó, giao diện đầu ra có thể khác nếu bạn chạy cùng một mã trong SSMS (SQL Server Management Studio). Không có sự khác biệt khi nói đến tập lệnh và kết quả của chúng.

Yêu cầu thêm nhân viên mới

Bây giờ, nếu nhận được yêu cầu thêm nhân viên mới, thì cách tốt nhất để đáp ứng yêu cầu này là tạo một quy trình được lưu trữ để có thể thêm thành công nhân viên mới vào bảng.

Để thực hiện việc này, hãy tạo thủ tục được lưu trữ AddEaffee như sau:

 - Quy trình được lưu trữ để thêm nhân viên mới TẠO THỦ TỤC Thêm nhân viên @Name VARCHAR (40), @ StartDate DATETIME2, @ Title VARCHAR (50) ASBEGIN ĐẶT TÀI KHOẢN TRÊN CHÈN VÀO NHÂN VIÊN (TÊN, Ngày bắt đầu, Chức danh) GIÁ TRỊ (@ Tên , @StartDate, @Title); HẾT

Kiểm tra đơn vị để xác minh xem yêu cầu có được đáp ứng hay không

Chúng tôi sẽ viết một bài kiểm tra đơn vị cơ sở dữ liệu để xác minh xem thủ tục được lưu trữ AddEaffee có đáp ứng yêu cầu thêm bản ghi mới vào bảng Nhân viên hay không.

Chúng ta hãy tập trung vào việc hiểu triết lý kiểm thử đơn vị bằng cách mô phỏng mã kiểm thử đơn vị thay vì viết kiểm thử đơn vị với khung kiểm tra hoặc công cụ kiểm tra đơn vị của bên thứ ba.

Mô phỏng kiểm tra đơn vị và áp dụng nguyên tắc AAA trong SQL

Điều đầu tiên chúng ta cần làm là bắt chước nguyên tắc AAA trong SQL vì chúng ta sẽ không sử dụng bất kỳ khung kiểm thử đơn vị nào.

Phần Lắp ráp được áp dụng khi các bảng thực tế và dự kiến thường được thiết lập cùng với bảng dự kiến được phổ biến. Chúng ta có thể sử dụng các biến SQL để khởi tạo bảng dự kiến trong bước này.

Phần Hành động được sử dụng khi thủ tục được lưu trữ thực tế được gọi để chèn dữ liệu vào bảng thực tế.

Phần Assert là khi bảng mong đợi khớp với bảng thực tế. Việc mô phỏng phần Assert hơi khó một chút và có thể đạt được bằng các bước sau:

Đếm các hàng chung (khớp) giữa hai bảng phải là 1 (vì bảng dự kiến chỉ có một bản ghi khớp với bảng thực tế)
Việc loại trừ các bản ghi bảng thực tế khỏi các bản ghi bảng dự kiến sẽ bằng 0 (nếu bản ghi trong bảng mong đợi cũng tồn tại trong bảng thực tế, thì việc loại trừ tất cả các bản ghi bảng thực tế khỏi bảng dự kiến sẽ trả về 0)

Tập lệnh SQL như sau:

[expand title =”Code”]

 - Mô phỏng kiểm tra đơn vị để kiểm tra quy trình được lưu trữ AddEaffee ='2018-03-01', @ Title VARCHAR (50) ='Development Manager' - Thiết lập bảng dự kiến TẠO BẢNG #E EmployeeEained (EmployeeId INT PRIMARY KEY IDENTITY (6, 1) - bảng dự kiến EmployeeId sẽ bắt đầu với 6 - vì bảng thực tế đã có 5 bản ghi và - EmployeeId tiếp theo trong bảng thực tế là 6, NAME VARCHAR (40), StartDate DATETIME2, Title VARCHAR (50)); - Thêm dữ liệu bảng dự kiến CHÈN VÀO #E JobeeEosystem (NAME, StartDate, Title) VALUES (@NAME, @StartDate, @Title); - (2) Hành động - Gọi AddE Jobee để thêm dữ liệu nhân viên mới vào bảng Nhân viên CHÈN VÀO NHÂN VIÊN EXEC AddE Jobee @NAME, @ StartDate, @ Title - (3) Khẳng định - Khớp bảng thực tế với bảng mong đợi DECLARE @ ActualAndEosystemTableCommonRecords INT =0 - chúng tôi giả định rằng các bản ghi bảng dự kiến và thực tế không có điểm chung nào SET @ActualAndEpectTableCommonRecords =(SELECT COUNT (*) FROM (SELECT e.EaffeeId, e.NAME, e.StartDate, e.Title FROM Employee e INTERSECT) CHỌN ee.EpriseeId, ee.NAME, ee.StartDate, ee.Title FROM #EosystemeeE dự kiến ee) AS A) DECLARE @EosystemTableExcluldingActualTable INT =1 - chúng tôi giả định rằng bảng mong đợi có các bản ghi không tồn tại trong bảng thực tế SET @E BloggerTableExcluldingActualTable =(CHỌN ĐẾM (*) TỪ (CHỌN ee.EFasteeId, ee.NAME, ee.StartDate, ee.Title FROM #EustingeeEmplete e. NGOẠI TRỪ CHỌN e. *** 'ELSE PRINT' *** Kiểm tra Không thành công! *** 'HẾT

[/ mở rộng]

Chạy Kiểm tra Đơn vị Mô phỏng

Sau khi thủ tục đã lưu trữ được tạo, hãy thực thi nó với kiểm tra đơn vị được mô phỏng:

 - Chạy thử nghiệm đơn vị được mô phỏng để kiểm tra thủ tục được lưu trữ của AddEaffee .EXEC TestAddErantyee

Kết quả như sau:

Xin chúc mừng! Đã vượt qua bài kiểm tra đơn vị cơ sở dữ liệu.

Xác định các vấn đề ở dạng Phụ thuộc trong Bài kiểm tra đơn vị

Chúng tôi có thể phát hiện bất kỳ điều gì sai trong bài kiểm tra đơn vị mà chúng tôi đã tạo mặc dù thực tế là nó đã được viết và chạy thành công không?

Nếu chúng ta xem xét kỹ thiết lập đơn vị kiểm tra (phần Lắp ráp), bảng dự kiến có ràng buộc không cần thiết với cột nhận dạng:

Trước khi viết bài kiểm tra đơn vị, chúng tôi đã thêm 5 bản ghi vào bảng (Nhân viên) thực tế. Do đó, ở thiết lập thử nghiệm, cột nhận dạng cho bảng mong đợi bắt đầu bằng 6. Tuy nhiên, điều này có nghĩa là chúng tôi luôn mong đợi 5 bản ghi có trong bảng (Nhân viên) thực tế để khớp với bảng mong đợi (# Nhân viên dự kiến).

Để hiểu điều này có thể ảnh hưởng như thế nào đến bài kiểm tra đơn vị, chúng ta hãy xem bảng (Nhân viên) thực tế ngay bây giờ:

Thêm một bản ghi khác vào bảng Nhân viên:

 - Thêm bản ghi mới vào bảng Nhân viên CHÈN VÀO GIÁ TRỊ Nhân viên (TÊN, Ngày bắt đầu, Chức danh) ('Đánh dấu', '2018-02-01', 'Nhà phát triển');

Hãy xem bảng Nhân viên ngay bây giờ:

Xóa EmpoyeeId 6 (Adil) để bài kiểm tra đơn vị có thể chạy dựa trên phiên bản EmployeeId 6 (Adil) của chính nó thay vì bản ghi đã lưu trữ trước đó.

 - Xóa bản ghi EmployeeId:6 (Adil) đã tạo trước đó khỏi bảng EmployeeDELETE FROM Employee WHERE EmployeeId =6

Chạy kiểm tra đơn vị được mô phỏng và xem kết quả:

 - Chạy thử nghiệm đơn vị được mô phỏng để kiểm tra thủ tục được lưu trữ của AddEaffee .EXEC TestAddErantyee

Lần này thử nghiệm đã thất bại. Câu trả lời nằm ở bảng kết quả Nhân viên tập hợp như hình dưới đây:

Ràng buộc Id nhân viên trong bài kiểm tra đơn vị như đã đề cập ở trên không hoạt động khi chúng tôi chạy lại bài kiểm tra đơn vị sau khi thêm bản ghi mới và xóa bản ghi nhân viên đã thêm trước đó.

Có ba loại phụ thuộc trong bài kiểm tra:

Sự phụ thuộc vào dữ liệu
Sự phụ thuộc Ràng buộc Chính
Sự phụ thuộc vào cột nhận dạng

Sự phụ thuộc vào dữ liệu

Trước hết, bài kiểm tra đơn vị này phụ thuộc vào dữ liệu trong cơ sở dữ liệu. Theo Dave Green, khi nói đến cơ sở dữ liệu kiểm thử đơn vị, bản thân dữ liệu là một phần phụ thuộc.

Điều này có nghĩa là kiểm tra đơn vị cơ sở dữ liệu của bạn không nên dựa vào dữ liệu trong cơ sở dữ liệu. Ví dụ:bài kiểm tra đơn vị của bạn phải chứa dữ liệu thực tế sẽ được chèn vào đối tượng cơ sở dữ liệu (bảng) thay vì dựa vào dữ liệu đã có trong cơ sở dữ liệu có thể bị xóa hoặc sửa đổi.

Trong trường hợp của chúng tôi, thực tế là năm bản ghi đã được chèn vào bảng Nhân viên thực tế là một phụ thuộc dữ liệu cần phải được ngăn chặn vì chúng tôi không nên vi phạm triết lý của kiểm thử đơn vị nói rằng chỉ đơn vị của mã được kiểm tra.

Nói cách khác, dữ liệu thử nghiệm không được dựa trên dữ liệu thực tế trong cơ sở dữ liệu.

Sự phụ thuộc ràng buộc chính

Một phụ thuộc khác là phụ thuộc ràng buộc khóa có nghĩa là cột khóa chính EmployeeId cũng là một phụ thuộc. Nó phải được ngăn chặn để viết một bài kiểm tra đơn vị tốt. Tuy nhiên, yêu cầu kiểm tra đơn vị riêng biệt để kiểm tra ràng buộc khóa chính.

Ví dụ:để kiểm tra thủ tục được lưu trữ của AddEaffee, khóa chính của bảng Employee phải được xóa để một đối tượng có thể được kiểm tra mà không phải lo lắng về việc vi phạm khóa chính.

Sự phụ thuộc của cột nhận dạng

Cũng giống như ràng buộc khóa chính, cột nhận dạng cũng là một phụ thuộc. Do đó, không cần phải kiểm tra logic tự động tăng dần cột nhận dạng cho thủ tục AddE Jobee; nó phải được tránh bằng bất cứ giá nào.

Tách biệt sự phụ thuộc trong Kiểm thử đơn vị

Chúng ta có thể ngăn chặn cả ba sự phụ thuộc bằng cách tạm thời loại bỏ các ràng buộc khỏi bảng và sau đó không phụ thuộc vào dữ liệu trong cơ sở dữ liệu để kiểm tra đơn vị. Đây là cách viết các bài kiểm tra đơn vị cơ sở dữ liệu tiêu chuẩn.

Trong trường hợp này, người ta có thể hỏi dữ liệu cho bảng Nhân viên đến từ đâu. Câu trả lời là bảng được điền với dữ liệu thử nghiệm được xác định trong thử nghiệm đơn vị.

Quy trình lưu trữ kiểm tra đơn vị thay đổi

Bây giờ, hãy để chúng tôi xóa các phần phụ thuộc trong bài kiểm tra đơn vị của chúng tôi:

[expand title =”Code”]

 - Mô phỏng kiểm tra đơn vị phụ thuộc không phụ thuộc để kiểm tra thủ tục được lưu trữ AddEaffee 03-01 ', @ Title VARCHAR (50) =' Development Manager '- Đặt bảng thực tế DROP TABLE Nhân viên - thả bảng để loại bỏ phần phụ thuộc TẠO BẢNG Nhân viên - tạo bảng không có phần phụ thuộc (PRIMARY KEY và IDENTITY (1,1 )) (EmployeeId INT DEFAULT (0), NAME VARCHAR (40), StartDate DATETIME2, Title VARCHAR (50)) - Thiết lập bảng mong đợi mà không có phụ thuộc (PRIMARY KEY và IDENTITY (1,1) TẠO TÊN INT DEFAULT (0), NAME VARCHAR (40), StartDate DATETIME2, Title VARCHAR (50)) - Thêm dữ liệu bảng dự kiến CHÈN VÀO #E JobeeEosystem (NAME, StartDate, Title) VALUES (@NAME, @StartDate, @Title) - (2) Hành động - Gọi AddE Jobee để thêm dữ liệu nhân viên mới vào bảng Nhân viên EXEC A ddE Jobee @NAME, @ StartDate, @ Title - (3) Khẳng định - Khớp bảng thực tế với bảng dự kiến DECLARE @ActualAndEosystemTableCommonRecords INT =0 - chúng tôi giả định rằng các bản ghi bảng dự kiến và thực tế không có điểm chung SET @ActualAndEosystemTableCommonRecords =(CHỌN ĐẾM (*) TỪ (CHỌN e.EmpleteeeId, e.NAME, e.StartDate, e.Title FROM Employee e INTERSECT SELECT ee.ErantyeeId, ee.NAME, ee.StartDate, ee.Title FROM #ErantyeeE dự kiến ee) AS A) DECLARE @EosystemTableExcluldingActualTable INT =1 - chúng tôi giả định rằng bảng mong đợi có các bản ghi không tồn tại trong bảng thực SET @EosystemTableExcluldingActualTable =(CHỌN COUNT (*) TỪ (CHỌN ee.EmpleteeeId, ee.NAME, ee.StartDate, ee . Tiêu đề TỪ #EpriseeEpris ee NGOẠI TRỪ CHỌN e.EFasteeId, e.NAME, e.StartDate, e.Title FROM Nhân viên e) NHƯ A) NẾU @ActualAndEosystemTableCommonRecords =1 VÀ @EosystemTableExcluldingActualTable =0 PRINT '*** Kiểm tra Đã vượt qua! *** 'ELSE PRINT' *** Kiểm tra Không thành công! *** '- Xem các bảng thực tế và dự kiến trước khi so sánh. #EpriseeEpris ee - Đặt lại bảng (Đặt lại các ràng buộc sau khi kiểm tra đơn vị) BẢNG DROP TABLE Nhân viên DROP TABLE #E JobeeE Dự kiến Tạo BẢNG Nhân viên (EmployeeId INT PRIMARY KEY IDENTITY (1, 1), NAME VARCHAR (40), StartDate DATETIME2, Title VARCHAR (50)); HẾT

[/ mở rộng]

Chạy thử nghiệm đơn vị được mô phỏng không phụ thuộc

Chạy kiểm tra đơn vị được mô phỏng để xem kết quả:

 - Chạy thử nghiệm đơn vị được mô phỏng không phụ thuộc để kiểm tra thủ tục được lưu trữ của AddEaffeeEXEC TestAddErantyee

Chạy lại bài kiểm tra đơn vị để kiểm tra quy trình được lưu trữ AddEaffee:

 - Chạy thử nghiệm đơn vị được mô phỏng không phụ thuộc để kiểm tra thủ tục được lưu trữ của AddEaffeeEXEC TestAddErantyee

Xin chúc mừng! Các phần phụ thuộc từ thử nghiệm đơn vị đã được xóa thành công.

Bây giờ, ngay cả khi chúng tôi thêm bản ghi mới hoặc tập hợp các bản ghi mới vào bảng Nhân viên, nó sẽ không ảnh hưởng đến bài kiểm tra đơn vị của chúng tôi vì chúng tôi đã xóa thành công dữ liệu và ràng buộc phụ thuộc khỏi kiểm tra.

Tạo Kiểm tra Đơn vị Cơ sở dữ liệu Sử dụng tSQLt

Bước tiếp theo là tạo một bài kiểm tra đơn vị cơ sở dữ liệu thực dựa trên bài kiểm tra đơn vị được mô phỏng.

Nếu bạn đang sử dụng SSMS (SQL Server Management Studio), bạn sẽ phải cài đặt khuôn khổ tSQLt, tạo một lớp thử nghiệm và bật CLR trước khi viết và chạy thử nghiệm đơn vị.

Nếu bạn đang sử dụng dbForge Studio cho SQL Server, bạn có thể tạo bài kiểm tra đơn vị bằng cách nhấp chuột phải vào thủ tục được lưu trữ AddEaffee và sau đó nhấp vào “Kiểm tra đơn vị” => “Thêm bài kiểm tra mới…” như hình dưới đây:

Để thêm thử nghiệm mới, hãy điền vào thông tin đơn vị thử nghiệm được yêu cầu:

Để viết bài kiểm tra đơn vị, hãy sử dụng tập lệnh sau:

 - Các nhận xét ở đây được liên kết với bài kiểm tra. - Để biết các ví dụ về trường hợp kiểm tra, hãy xem:http://tsqlt.org/user-guide/tsqlt-tutorial/CREATE PROCEDURE [BasicTests]. [kiểm tra xem nhân viên mới có thể được thêm vào] ASBEGIN --Assemble DECLARE @NAME VARCHAR (40) ='Adil', @ StartDate DATETIME2 ='2018-03-01', @ Title VARCHAR (50) ='Giám đốc phát triển' EXEC tSQLt.FakeTable "dbo.Eprisee "- Thao tác này sẽ tạo bản sao không phụ thuộc của bảng Nhân viên. TẠO BẢNG BasicTests.E Dự kiến - Tạo bảng dự kiến (Nhân viên INT, TÊN VARCHAR (40), Ngày bắt đầu DATETIME2, Tiêu đề VARCHAR (50)) - Thêm dự kiến dữ liệu bảng CHÈN VÀO BasicTests.E Dự kiến (TÊN, Ngày bắt đầu, Tiêu đề) GIÁ TRỊ (@NAME, @StartDate, @Title) --Act EXEC AddErantyee @Name - Chèn dữ liệu vào bảng Nhân viên, @ StartDate, @ Title --Assert EXEC tSQLt. , @ Message =N'Bảng thực tế khớp với bảng mong đợi ', @ FailMsg =N'Bảng thực tế không khớp với bảng dự kiến'END; ĐI

Sau đó, chạy kiểm tra đơn vị cơ sở dữ liệu:

Xin chúc mừng! Chúng tôi đã tạo và chạy thành công kiểm tra đơn vị cơ sở dữ liệu mà không có phụ thuộc.

Việc cần làm

Đó là nó. Bạn đã sẵn sàng để tách các phần phụ thuộc khỏi các bài kiểm tra đơn vị cơ sở dữ liệu và tạo bài kiểm tra đơn vị cơ sở dữ liệu miễn phí khỏi dữ liệu và các phụ thuộc ràng buộc sau khi xem qua bài viết này. Do đó, bạn có thể cải thiện kỹ năng của mình khi thực hiện những điều sau:

Vui lòng thử thêm quy trình được lưu trữ Xóa nhân viên và tạo thử nghiệm đơn vị cơ sở dữ liệu mô phỏng cho Xóa nhân viên có phần phụ thuộc để xem liệu nó có thất bại trong các điều kiện nhất định không
Vui lòng thử thêm quy trình đã lưu trữ Xóa nhân viên và tạo thử nghiệm đơn vị cơ sở dữ liệu không có phần phụ thuộc để xem liệu có thể xóa nhân viên không
Vui lòng thử thêm quy trình được lưu trữ của Nhân viên tìm kiếm và tạo thử nghiệm đơn vị cơ sở dữ liệu mô phỏng với các phần phụ thuộc để xem liệu nhân viên có thể được tìm kiếm không
Vui lòng thử thêm quy trình Tìm kiếm nhân viên được lưu trữ và tạo một bài kiểm tra đơn vị cơ sở dữ liệu không có phần phụ thuộc để xem liệu có thể tìm kiếm một nhân viên không
Vui lòng thử các yêu cầu phức tạp hơn bằng cách tạo các thủ tục được lưu trữ để đáp ứng các yêu cầu và sau đó viết các bài kiểm tra đơn vị cơ sở dữ liệu không có phụ thuộc để xem liệu chúng có vượt qua bài kiểm tra hay không. Tuy nhiên, hãy đảm bảo rằng kiểm tra có thể lặp lại và tập trung vào kiểm tra đơn vị của mã

Công cụ hữu ích:

dbForge Unit Test - một GUI trực quan và thuận tiện để triển khai kiểm thử đơn vị tự động trong SQL Server Management Studio.