Đơn vị kiểm tra chèn/cập nhật/xóa

Question

Tôi đã googled này một chút và không thực sự tìm thấy câu trả lời tôi cần.

Tôi đang làm việc trên trang web trong C# với SQL Server và LINQ cho khách hàng. Tôi muốn người dùng có thể gửi tin nhắn cho nhau. Vì vậy, những gì tôi làm là tôi đơn vị kiểm tra này với dữ liệu mà thực sự đi vào cơ sở dữ liệu.

Vấn đề là bây giờ tôi phụ thuộc vào việc có ít nhất 2 người dùng mà tôi biết ID của. Hơn nữa tôi phải dọn dẹp sau cái tôi. Điều này dẫn đến các bài kiểm tra đơn vị khá lớn để kiểm tra rất nhiều trong một bài kiểm tra.

Cho phép nói rằng tôi muốn cập nhật người dùng. Điều đó có nghĩa là tôi sẽ phải ceate người dùng, cập nhật nó, và sau đó xóa nó. Điều này rất nhiều xác nhận trong một bài kiểm tra đơn vị và nếu nó không thành công với việc cập nhật, tôi phải xóa nó theo cách thủ công.

Nếu tôi sẽ làm điều đó bất kỳ cách nào khác, mà không lưu dữ liệu vào DB, tôi sẽ không chắc chắn có thể biết rằng các dữ liệu đã có mặt trong cơ sở dữ liệu sau khi cập nhật, vv

cách đúng đắn là gì để làm điều này mà không cần thử nghiệm kiểm tra nhiều chức năng trong một thử nghiệm?

Answer 1

Do tất cả các thử nghiệm bên trong một khối System.Transactions.TransactionScope, và đơn giản là không gọi Scope.Complete() ... Tất cả các thay đổi sẽ được khôi phục khi bạn thoát và những người dùng khác sẽ không thể xem dữ liệu tạm thời bạn tạo trong cơ sở dữ liệu, do đó quá trình thử nghiệm sẽ chỉ ảnh hưởng đến máy thử nghiệm ..

Bạn có thể nhập một người dùng mới, đọc cơ sở dữ liệu để xác minh rằng nó đã được nhập chính xác, và bất cứ điều gì khác mà bạn cần phải kiểm tra, trong khối của TransactionScope ...

Có phương pháp thử nghiệm đơn vị riêng biệt mạo danh hai người dùng khác nhau, tất cả trong một giao dịch ...

ví dụ: mã

using (var scop = new System.Transactions.TransactionScope()) 
    { 
     // all your test code and Asserts that access the database, 
     // writes and reads, from any class, ... 
     // to commit at the very end of this block, 
     // you would call 
     // scop.Complete(); // ..... but don't and all will be rolled back 
    } 

Answer 2

Có tệp đồ đạc (trong XML, SQL, YAML, bất kỳ thứ gì) mà bạn có thể tải vào cơ sở dữ liệu thử nghiệm cục bộ chỉ bằng một lệnh.

Ví dụ: nộp đồ đạc cho hai người dùng cần phải nhắn tin cho nhau có thể trông giống như (điều này là của tôi):

Member: 

    Member_WibWobble: 
    username:  Wibble_Wobble 
    email_address: michael+dev_wibwob@[removed].com 
    password:  pw 
    is_super_admin: true 
    last_login:  "2010-01-06 12:12:57" 
    Country:  country_AU 
    UploadImage: 
     type:   <?php echo UploadImage::TYPE_MEMBER_AVATAR."\n"; ?> 
     upload:  "http://localhost/[removed]/images/wibwobble.jpg" 

    Member_BunnyHugs: 
    username:  BunnyHugs 
    email_address: michael+dev_bunny@[removed].com 
    password:  pw 
    is_super_admin: true 
    last_login:  "2009-12-01 14:11:11" 
    Country:  country_UK 
    UploadImage: 
     type:   <?php echo UploadImage::TYPE_MEMBER_AVATAR."\n"; ?> 
     upload:  "http://localhost/[removed]/images/bunnyhugs.jpg" 

PrivateMessage: 

    PrivateMessage_1: 
    subject:   "Yo" 
    body:   | 
     hi 

     <b>escape this html please</b> 

     bye 
    is_read:   false 
    Sender:   Member_WibWobble 
    Recipient:  Member_BunnyHugs 

Answer 3

Cơ sở dữ liệu thử nghiệm đơn vị có thể là PITA do bản chất của chúng (lưu trữ lâu dài).

Để làm điều này đúng, bạn nên luôn bắt đầu bằng lược đồ trống. Sau đó, tải mã thử nghiệm của bạn điền vào các giá trị dữ liệu phải có ở đó. Điều này có thể đơn giản như việc thực thi một tập lệnh sql chứa lược đồ và dữ liệu mặc định.

Khi đã xong, sau đó bắt đầu chạy thử nghiệm của bạn. Các thử nghiệm phải bao gồm tất cả các hoạt động của ứng dụng mà bạn thường làm.

Nếu có bất kỳ sự cố nào xảy ra, đó không phải là một thỏa thuận lớn bởi vì, một lần nữa, bạn nên bắt đầu làm mới mọi lúc.

Ngoài ra, bạn muốn giữ dữ liệu đó xung quanh trong trường hợp lỗi kiểm tra để bạn có thể kiểm tra trạng thái cơ sở dữ liệu tại thời điểm xảy ra lỗi. Vì vậy, đây là cả một điều tốt và xấu.

Cùng với các dòng này, các kiểm tra db phải được chạy trên cá thể cơ sở dữ liệu thử nghiệm riêng của nó. Bằng cách này bạn không phải lo lắng về các vấn đề thoáng qua như ai đó đang thay đổi cấu trúc db bên dưới bạn khi các thử nghiệm đang tiến triển.

Cuối cùng, kiểm tra cơ sở dữ liệu là một dự án trong và của chính nó.