Khi thử nghiệm đơn vị, phải sử dụng cơ sở dữ liệu khi kiểm tra các hoạt động CRUD? sql có thể giúp đỡ với điều này? Bạn có phải tạo ra db bằng cách nào đó trong bộ nhớ?Khi thử nghiệm đơn vị, bạn có phải sử dụng cơ sở dữ liệu để kiểm tra các hoạt động CRUD không?
Tôi đang sử dụng mbunit.
No. Việc tích hợp DB thực tế sẽ là kiểm tra tích hợp. Không phải thử nghiệm đơn vị.
Có bạn có thể sử dụng bất kỳ DB trong bộ nhớ như SQLite hoặc MS SQL Compact cho điều này nếu bạn không thể trừu tượng (giả) Dal của bạn/DAO trong bất kỳ cách nào khác.
Với điều này trong tâm trí tôi phải chỉ ra rằng, kiểm tra đơn vị là có thể tất cả các cách để DAL, nhưng không DAL chính nó. DAL sẽ phải được thử nghiệm với một số loại DB thực tế trong thử nghiệm tích hợp.
Thực sự, nếu bạn đang viết một bài kiểm tra kết nối với cơ sở dữ liệu, bạn đang thực hiện thử nghiệm tích hợp , không phải thử nghiệm đơn vị.
Đối với đơn vị kiểm tra các hoạt động như vậy, hãy xem xét sử dụng một số loại đối tượng cơ sở dữ liệu giả. Ví dụ, nếu bạn có một lớp đóng gói tương tác cơ sở dữ liệu của bạn, trích xuất một giao diện từ nó và sau đó tạo ra một lớp kế thừa sử dụng các đối tượng trong bộ nhớ đơn giản thay vì thực sự kết nối với cơ sở dữ liệu.
nhưng làm cách nào bạn có thể thử nghiệm chèn hoặc xóa sau đó? Tôi chỉ không nhận được nó! – mrblah
@homestead: thử nghiệm đơn vị chỉ nên kiểm tra một UNIT nhất định của mã không phải là một quy trình kinh doanh hoàn chỉnh. –
@homestead: Bạn viết một bài kiểm tra tích hợp cho nó. – JoshJordan
Như với tất cả các câu hỏi phức tạp, câu trả lời là: Nó phụ thuộc :)
Nói chung bạn nên ẩn truy cập lớp dữ liệu của bạn đằng sau một giao diện để bạn có thể kiểm tra phần còn lại của ứng dụng mà không cần sử dụng một cơ sở dữ liệu, nhưng nếu bạn muốn thử nghiệm việc thực hiện truy cập dữ liệu thì sao?
Trong một số trường hợp, một số người coi việc này thừa vì họ chủ yếu sử dụng các công nghệ truy cập dữ liệu khai báo như ORM.
Trong các trường hợp khác, chính thành phần truy cập dữ liệu có thể chứa một số logic mà bạn có thể muốn kiểm tra. Đó có thể là một điều hoàn toàn phù hợp để làm, nhưng bạn sẽ cần cơ sở dữ liệu để làm điều đó. Một số người coi đây là Kiểm thử Tích hợp thay vì Kiểm tra Đơn vị, nhưng trong cuốn sách của tôi, nó không quan trọng quá nhiều thứ bạn gọi - điều quan trọng nhất là bạn nhận được giá trị từ các thử nghiệm hoàn toàn tự động của mình, và bạn chắc chắn có thể sử dụng một khung kiểm thử đơn vị để điều khiển các thử nghiệm đó.
Trong khi quay lại, tôi đã viết về how to do this on SQL Server. Điều quan trọng nhất cần nhớ là tránh sự cám dỗ để tạo ra một Lịch thi đấu chung với một số 'dữ liệu đại diện' và cố gắng sử dụng lại điều này trong tất cả các bài kiểm tra. Thay vào đó, bạn nên điền dữ liệu như một phần của mỗi bài kiểm tra và làm sạch nó sau.
+1. Tôi nghĩ bạn đóng đinh nó :) – si618
Khi kiểm tra đơn vị, phải sử dụng cơ sở dữ liệu khi thử nghiệm các hoạt động CRUD?
Giả sử một lúc bạn đã trích xuất các giao diện tròn cho biết các hoạt động CRUD và đã kiểm tra mọi thứ sử dụng giao diện được nói thông qua mocks hoặc sơ khai. Bây giờ bạn còn lại với một đoạn mã là một phương thức lưu chứa một chút mã để ràng buộc các đối tượng và một số SQL.
Nếu vậy thì tôi sẽ tuyên bố rằng một "Đơn vị" và nói rằng bạn cần một cơ sở dữ liệu, và lý tưởng một trong đó là ít nhất một đại diện tốt cho cơ sở dữ liệu của bạn, kẻo bạn bị bắt ra với SQL cụ thể vender.
Tôi cũng sẽ sử dụng ánh sáng các mocks để điều chỉnh các điều kiện lỗi, nhưng tôi sẽ không tự kiểm tra phương pháp lưu chỉ với mocks. Vì vậy, trong khi kỹ thuật này có thể là một thử nghiệm tích hợp tôi vẫn sẽ làm điều đó như là một phần của bài kiểm tra đơn vị của tôi.
Chỉnh sửa: Đã bỏ lỡ 2/3 câu hỏi của bạn. Lấy làm tiếc.
Trợ giúp có thể giúp bạn thực hiện điều này?
Tôi đã từng sử dụng trong cơ sở dữ liệu bộ nhớ và đã bị cắn hoặc là cơ sở dữ liệu tôi đã sử dụng và hệ thống trực tiếp đã làm một việc khác hoặc mất một thời gian để khởi động. Tôi sẽ khuyên mọi nhà phát triển đều có cơ sở dữ liệu cục bộ của nhà phát triển.
Bạn có phải tạo lại db bằng cách nào đó trong bộ nhớ không?
Trong cơ sở dữ liệu có. Tôi sử dụng DbUnit để chia nhỏ dữ liệu và theo cách thủ công giữ lược đồ cập nhật với các tập lệnh SQL nhưng bạn có thể chỉ sử dụng các tập lệnh SQL. Có một cơ sở dữ liệu cục bộ phát triển thêm một số bảo trì bổ sung khi bạn có cả lược đồ và bộ dữ liệu để theo kịp dữ liệu nhưng cá nhân tôi thấy có giá trị trong khi bạn có thể chắc chắn rằng lớp cơ sở dữ liệu đang hoạt động như mong đợi.
Như những người khác đã chỉ ra, những gì bạn đang cố gắng đạt được không phải là thử nghiệm đơn vị nhưng thử nghiệm tích hợp.
Có điều đó nói, và thậm chí nếu tôi thích thử nghiệm đơn vị trong sự cô lập với mocks, không có gì thực sự sai với thử nghiệm tích hợp. Vì vậy, nếu bạn cho rằng điều đó có ý nghĩa trong ngữ cảnh của bạn, chỉ cần bao gồm thử nghiệm tích hợp trong chiến lược thử nghiệm của bạn.
Bây giờ, liên quan đến câu hỏi của bạn, tôi muốn xem DbUnit.NET. Tôi không biết phiên bản .NET của công cụ này nhưng tôi có thể nói với bạn rằng phiên bản Java là rất tốt cho các bài kiểm tra tương tác với một cơ sở dữ liệu. Trong một vài từ, DbUnit cho phép bạn đặt cơ sở dữ liệu ở trạng thái đã biết trước khi chạy thử nghiệm và thực hiện xác nhận về nội dung của bảng. Thực sự tiện dụng. BTW, tôi khuyên bạn nên đọc trang Best Practices, ngay cả khi bạn quyết định không sử dụng công cụ này.
Như đã đề cập ở trên, khóa ở đây là để có cơ sở dữ liệu thử nghiệm của bạn ở trạng thái đã biết trước khi chạy thử nghiệm. Trong một ví dụ thực tế, tôi có một vài kịch bản lệnh SQL được chạy trước các thử nghiệm tạo lại một tập dữ liệu thử nghiệm đã biết. Từ đây, tôi có thể kiểm tra các hoạt động CRUD và xác minh rằng (các) hàng mới được chèn/cập nhật/xóa.
Tôi đã viết một tiện ích gọi là DBSnapshot để giúp kiểm tra tích hợp cơ sở dữ liệu sqlserver.
Nếu giản đồ cơ sở dữ liệu của bạn thay đổi thường xuyên, sẽ rất hữu ích nếu bạn thực sự kiểm tra mã của mình dựa trên phiên bản db thực. Mọi người sử dụng SqlLite để kiểm tra nhanh chóng (vì cơ sở dữ liệu chạy trong bộ nhớ), nhưng điều này không hữu ích khi bạn muốn xác minh rằng mã của bạn hoạt động dựa trên cơ sở dữ liệu thực sự của bạn.
Khi kiểm tra cơ sở dữ liệu bạn muốn theo một mẫu tương tự như: sao lưu cơ sở dữ liệu, thiết lập cơ sở dữ liệu để kiểm tra, thực hiện mã, xác minh kết quả, khôi phục cơ sở dữ liệu về trạng thái bắt đầu.
Ở trên sẽ đảm bảo rằng bạn có thể chạy từng thử nghiệm một cách riêng biệt. Tiện ích DBSnapshot của tôi sẽ đơn giản hóa mã của bạn nếu bạn viết nó .net. Tôi nghĩ rằng nó dễ sử dụng hơn DbUnit.NET.
Hãy thừa nhận rằng nó thực sự là một thử nghiệm tích hợp, có một số giá trị trong việc giả mạo một cơ sở dữ liệu để thực hiện các bài kiểm tra đơn vị không? –
Vâng. Nó sẽ giúp bạn đơn vị kiểm tra kho dữ liệu của bạn, sử dụng DAL (trong trường hợp này là những người giả mạo). –
-1. Tôi nghĩ rằng câu trả lời của Mark chính xác hơn: Nó phụ thuộc vì nếu bạn đang viết mã mà vẫn tồn tại dữ liệu thay mặt cho mã khác (n-tier, thư viện khung, v.v.), thì kiểm thử đơn vị chính xác là, thử nghiệm một đơn vị cụ thể mã hoạt động như mong đợi. Ví dụ: giả sử bạn sử dụng cột IDENTITY trong DB của mình và trả lại ID đã tạo dưới dạng truy vấn SELECT sau INSERT, mã này phải được kiểm tra đơn vị tức là xác nhận giá trị trả về là ID dự kiến. Đồng ý rằng việc tạo kho lưu trữ giả là tốt, nhưng có một số điều bạn không thể bỏ qua. – si618