Tôi có nên kiểm tra lớp truy cập dữ liệu đơn vị không? Đây có phải là một thực hành tốt và làm thế nào để làm điều đó?

Question

Nếu tôi đang có Lớp truy cập dữ liệu (nHibernate) ví dụ một lớp có tên là UserProvider và lớp Business Logic UserBl, tôi có nên thử nghiệm phương thức SaveUser hoặc GetUserById hoặc bất kỳ phương thức công khai nào khác trong lớp DA được gọi từ BL lớp. Đây có phải là dự phòng hay thực tiễn phổ biến để làm không?

Có phải thông thường đối với lớp DA thử nghiệm đơn vị hay thuộc lớp Kiểm tra tích hợp? Có tốt hơn để có cơ sở dữ liệu thử nghiệm hoặc tạo dữ liệu cơ sở dữ liệu trong khi thử nghiệm không?

Mọi trợ giúp đều được đánh giá cao.

Answer 1

Thực hành tốt là viết kiểm thử đơn vị cho mọi lớp, ngay cả DAL.

Tôi không nghĩ rằng chạy thử nghiệm trên db thực sự là một ý tưởng hay, bạn có thể hủy hoại dữ liệu quan trọng. Chúng tôi đã sử dụng để thiết lập một bản sao của db cho các bài kiểm tra chỉ với đủ dữ liệu để chạy thử nghiệm. Trong dự án thử nghiệm của chúng tôi, chúng tôi đã có một tệp web.config đặc biệt với các cài đặt thử nghiệm, như ConnectionString cho db kiểm tra của chúng tôi.

Answer 2

Không có câu trả lời đúng cho điều này, nó thực sự phụ thuộc. Một số người (ví dụ: Roy Osherove) nói rằng bạn chỉ nên kiểm tra mã có logic điều kiện (câu lệnh IF, v.v.), có thể có hoặc không bao gồm DAL của bạn. Một số người (thường là những người làm TDD) sẽ nói rằng bạn nên kiểm tra tất cả mọi thứ, bao gồm cả DAL, và nhằm mục đích bảo hiểm mã 100%.

Cá nhân tôi chỉ kiểm tra nếu nó có logic, do đó, kết thúc với một số phương pháp DAL được thử nghiệm và một số thì không. Hầu hết thời gian bạn vừa kết thúc kiểm tra xem BL của bạn có gọi DAL của bạn không, điều này có một số công đức nhưng tôi không thấy cần thiết. Tôi nghĩ rằng nó có ý nghĩa hơn để có các bài kiểm tra tích hợp bao gồm các ứng dụng end-to-end, bao gồm cơ sở dữ liệu, trong đó bao gồm những thứ như GetUserById.

Dù bằng cách nào, và bạn có thể đã biết điều này, nhưng hãy đảm bảo rằng các bài kiểm tra đơn vị của bạn không chạm vào cơ sở dữ liệu thực. (Không có vấn đề làm điều này, nhưng đó là một thử nghiệm tích hợp không phải là một bài kiểm tra đơn vị, vì phải mất nhiều thời gian hơn và liên quan đến thiết lập phức tạp, và nên được chạy riêng).

Answer 3

Theo kinh nghiệm của tôi, thật hữu ích khi tự mình kiểm tra từng lớp. Tích hợp nó và kiểm tra lại. Kiểm tra tích hợp thường không kiểm tra tất cả các khía cạnh. Đôi khi, nếu Lớp Truy cập Dữ liệu (Tôi không biết nHibernate) được tạo mã hoặc loại mã chung thì có vẻ như quá mức cần thiết. Nhưng tôi đã thấy nó nhiều hơn một lần mà thử nghiệm có hệ thống trả hết.

Đó có phải là dự phòng không? Theo tôi thì không.

Có thực tế phổ biến không? Khó nói. Tôi sẽ nói không. Tôi đã nhìn thấy nó trong một số dự án nhưng không phải trong tất cả các dự án tôi đã làm việc. Thường phụ thuộc vào thời gian/nguồn lực và tâm lý của nhóm/nhà phát triển cá nhân.

Có tốt hơn để có cơ sở dữ liệu thử nghiệm hoặc tạo dữ liệu cơ sở dữ liệu trong khi kiểm tra không? Đây là một câu hỏi khá khác. Không thể trả lời dễ dàng. Phụ thuộc vào dự án của bạn. Tạo một cái mới là tốt nhưng đôi khi ném lên các lỗi không thực (mặc dù lỗi). Nó phụ thuộc vào dự án của bạn (phát triển sản phẩm hoặc phát triển độc quyền). Thông thường trong một sở hữu độc quyền trên trang web phát triển một cơ sở dữ liệu được di chuyển vào từ một nơi nào đó. Vì vậy, một thử nghiệm thứ hai là chắc chắn cần thiết với các dữ liệu di chuyển. Nhưng điều này là khá ở cấp độ kiểm tra hệ thống.

Answer 4

Đơn vị kiểm tra DAL là giá trị như đã đề cập nếu có logic trong đó, ví dụ nếu sử dụng cùng một StoredProc để chèn & cập nhật giá trị của nó biết rằng chèn hoạt động, cuộc gọi tiếp theo cập nhật trước đó và chọn trả về và không phải là một danh sách.Trong trường hợp của bạn Phương thức SaveUser có thể chèn lần đầu tiên xung quanh và sau đó cập nhật, thật tuyệt khi biết rằng đây là những gì đang được thực hiện ở giai đoạn thử nghiệm đơn vị.

Nếu bạn đang sử dụng một khuôn khổ như iBatis hoặc Hibernate, nơi bạn có thể thực hiện các trình đánh máy xác nhận giá trị của nó xác nhận rằng các trình xử lý xử lý các giá trị theo cách được chấp nhận cho DB cơ sở của bạn. Đối với thử nghiệm đối với một DB thực tế nếu bạn sử dụng một khung như Spring bạn có thể tận dụng các lớp thử nghiệm đơn vị cơ sở dữ liệu được hỗ trợ với tính năng tự động quay lại giao dịch để bạn chạy thử nghiệm và DB không bị ảnh hưởng sau đó. Xem here để biết thông tin. Những người khác có thể cung cấp hỗ trợ tương tự.