Quy tắc thử nghiệm đơn vị

Question

Câu hỏi của tôi có thể xuất hiện thực sự ngu ngốc đối với một số bạn nhưng tôi phải hỏi .. Xin lỗi ..

Tôi không thực sự hiểu nguyên tắc kiểm tra đơn vị .. Làm thế nào bạn có thể kiểm tra các lớp học của doanh nghiệp lớp hoặc lớp truy cập dữ liệu mà không sửa đổi cơ sở dữ liệu của bạn? Tôi giải thích, tôi có một chức năng cập nhật một trường trong cơ sở dữ liệu .. Không có gì tuyệt vời .. Lớp lớp doanh nghiệp được khởi tạo và phương thức BLL.Update() thực hiện một số điều khiển và cuối cùng khởi tạo một lớp DAL. thủ tục trong cơ sở dữ liệu với các tham số chính xác.

công trình của nó nhưng câu hỏi của tôi là ..

Để làm kiểm tra đơn vị có kết quả lớp DALayer tôi phải tác động đến cơ sở dữ liệu trong các bài kiểm tra! Để kiểm tra ví dụ nếu giá trị 5 được truyền cho DataBase tôi phải làm điều đó và trường của cơ sở dữ liệu sẽ là 5 sau khi thử nghiệm!

Vì vậy, tôi biết thông thường hệ thống không bị ảnh hưởng bởi các xét nghiệm vì vậy tôi không hiểu làm thế nào bạn có thể làm các bài kiểm tra mà không cần mà không cần thực hiện các phương pháp ..

Tx cho câu trả lời và xin lỗi tiếng Anh nghèo của tôi ..

Answer 1

Tôi sẽ chia câu hỏi của bạn thành một số câu hỏi phụ vì khó trả lời chúng lại với nhau.

Đơn vị kiểm tra x Tích hợp thử nghiệm

Khi bạn viết bài kiểm tra đơn vị bạn đang thử nghiệm đơn vị đơn giản. Điều đó có nghĩa là bạn đang thử nghiệm đường dẫn thực thi duy nhất trong phương pháp thử nghiệm. Bạn cần phải tránh kiểm tra các phụ thuộc của nó như cơ sở dữ liệu đã đề cập. Bạn thường viết kiểm tra đơn vị đơn giản cho mỗi đường dẫn thực hiện để bạn có được mã vùng phủ sóng tốt bằng các thử nghiệm của bạn.

Khi bạn viết kiểm tra tích hợp, bạn đang kiểm tra tất cả các lớp để xem tính năng tích hợp và cấu hình có hoạt động hay không. Bạn thường không viết thử nghiệm tích hợp cho mỗi đường dẫn thực hiện vì có nhiều kết hợp trên tất cả các lớp.

lớp kinh doanh kiểm tra - kiểm tra đơn vị

Bạn cần phải kiểm tra các lớp học kinh doanh của bạn mà không phụ thuộc vào Dal và DB. Để làm điều đó bạn phải thiết kế lớp BL của bạn để những phụ thuộc đó được tiêm từ bên ngoài. Trước tiên, bạn cần định nghĩa lớp trừu tượng hoặc giao diện cho DAL và truyền giao diện DAL đó làm tham số cho hàm tạo (một cách khác là để trưng ra thuộc tính có thể đặt trên lớp BL). Khi bạn kiểm tra lớp BL của mình, bạn sẽ sử dụng một giao diện DAL khác không phụ thuộc vào DB. Có các mẫu thử nghiệm nổi tiếng Mock, Stub và Fake xác định cách tạo và sử dụng các triển khai giả đó. Mocking cũng được hỗ trợ bởi nhiều khung kiểm thử.

kiểm tra lớp truy cập dữ liệu - Tích hợp kiểm tra

Bạn cần phải kiểm tra Dal của bạn chống lại DB thực sự. Bạn sẽ chuẩn bị kiểm tra DB với bộ dữ liệu thử nghiệm và bạn sẽ viết các bài kiểm tra của mình để làm việc với dữ liệu đó.Mỗi thử nghiệm sẽ chạy trong giao dịch riêng của nó sẽ được cuộn lại ở cuối để nó sẽ không sửa đổi tập dữ liệu ban đầu.

Trân trọng, Ladislav

Answer 2

Đối với kịch bản mà bạn mô tả dưới dạng tương tác db, việc nhạo báng rất hữu ích. Nếu bạn có cơ hội, hãy xem Rhino Mocks

Answer 3

Bạn sử dụng Inversion of Control cùng với khuôn khổ chế nhạo, ví dụ: Rhino Mocks như ai đó đã đề cập đến

Answer 4

Nếu bạn không phải dùng đến chế giễu và sử dụng thực tế DB trong thử nghiệm sau đó nó sẽ được thử nghiệm tích hợp trong điều kiện của giáo và nó không phải là một bài kiểm tra đơn vị nữa. Tôi đã làm việc trên một dự án mà một sql .mdf chuyên dụng đã được kiểm soát nguồn được gắn vào máy chủ cơ sở dữ liệu bằng cách sử dụng NUnit trong [Setup] một phần của [SetupFixture], similary tách ra trong [TearDown]. Điều này đã được thực hiện mỗi khi kiểm tra NUnit được thực hiện và có thể rất tốn thời gian tùy thuộc vào mã SQL bạn có cũng như kích thước dữ liệu có thể làm tồi tệ hơn.

Bây giờ bắt là phí bảo trì, bạn có thể thay đổi DB scehma trong chu kỳ chạy nước rút và lúc relaease, kịch bản DB thay đổi phải được chạy trên tất cả các cơ sở dữ liệu được sử dụng trong quá trình phát triển và thử nghiệm của bạn. Như được đề cập ở trên. Không chỉ vậy, dữ liệu thử nghiệm mới (như ai đó đã đề cập ở trên) phải được popoulated cho bảng/cột mới được tạo ra và tương tự như vậy, dữ liệu exisitng có thể cần phải được làm sạch cũng như yêu cầu thay đổi hoặc sửa lỗi.

Điều này có vẻ là một nhiệm vụ và ai đó có thẩm quyền trong nhóm có thể nắm quyền sở hữu hoặc nếu thời gian cho phép bạn có thể tích hợp thực thi các kịch bản thay đổi như một phần của Tích hợp liên tục nếu bạn đã triển khai. Tuy nhiên việc bổ sung và làm sạch dữ liệu kiểm tra cần được thực hiện một cách thủ công.