Làm cách nào để kiểm tra di chuyển cơ sở dữ liệu?

Question

Tôi đang sử dụng Migrator.NET để viết di chuyển cơ sở dữ liệu cho ứng dụng. Marc-André Cournoyer đã viết:

Giống như bất kỳ mã trong ứng dụng của bạn, bạn phải kiểm tra di cư của bạn. Mã thăng trầm. Làm một phần của quy trình xây dựng liên tục và thử nghiệm nó trên nhiều cơ sở dữ liệu khác nhau và môi trường như bạn có thể.

Tôi làm như thế nào? Nói rằng tôi có phương thức Up() tạo ra một bảng và phương thức Down() để giảm cùng một bảng và tôi đang sử dụng SQL Server. Làm thế nào một thử nghiệm sẽ như thế nào? Tôi có nên chạy truy vấn SQL đối với các bảng hệ thống, chẳng hạn như select * from sys.columns, để kiểm tra xem bảng đã được tạo và có cấu trúc thích hợp không? Nếu chúng ta đang sử dụng NHibernate thì sao?

EDIT Ý tôi là di chuyển theo ý nghĩa Rails ActiveRecord Migration (tạo, sửa đổi và rách cơ sở dữ liệu theo các bước nhỏ dựa trên mã C#).

CHỈNH SỬA 2 Và here nơi tôi đọc về việc chúng tôi nên thử nghiệm di chuyển. Bài đăng trên blog thực sự được liên kết từ wiki của Migrator.

Answer 1

Bạn có kiểm tra DAL của mình - một số loại kiểm tra tích hợp không?

Bạn cần nhiều hơn tập lệnh di chuyển, bạn cũng cần tập lệnh cơ bản. Khi bạn muốn kiểm tra nâng cấp cơ sở dữ liệu, bạn nên chạy tất cả các tập lệnh từ đường cơ sở trên máy chủ thử nghiệm/dàn dựng để tạo phiên bản mới nhất của cơ sở dữ liệu. Sau đó kiểm tra DAL của bạn dựa vào cơ sở dữ liệu kiểm tra cập nhật. Nếu tất cả các bài kiểm tra DAL thành công thì việc di chuyển của bạn phải thành công (nếu không thì các bài kiểm tra DAL của bạn chưa đủ).

Đó là một thử nghiệm tốn kém để chạy, nhưng nó khá nhiều đá rắn. Cá nhân tôi sẽ thừa nhận làm rất nhiều điều này bằng tay vào lúc này; chúng tôi có một công cụ di chuyển trong nhà sẽ áp dụng tất cả các tập lệnh (bao gồm cả đường cơ sở), do đó, kiểm tra thiết lập cơ sở dữ liệu và kiểm tra DAL là các bước riêng biệt. Nó hoạt động mặc dù. Nếu bạn muốn chắc chắn rằng một bảng đã được tạo ra, không có phương pháp nào tốt hơn là thực sự cố gắng chèn dữ liệu vào nó!

Bạn có thể thử để kiểm tra kết quả bằng cách nhìn vào catalog hệ thống và INFORMATION_SCHEMA quan điểm và như vậy, nhưng cuối cùng là cách duy nhất để chắc chắn rằng nó thực sự làm việc là cố gắng sử dụng các đối tượng mới. Chỉ vì các đối tượng ở đó không có nghĩa là chúng hoạt động.

Answer 2

lẽ scrip này có thể giúp bạn:

http://www.benzzon.se/forum/uploads/benzzon/2006-03-27_134824_sp_CompareDB.txt

kịch bản này so sánh hai db (cấu trúc và dữ liệu)

Answer 3

kiểm soát nguồn là đã dành một bản chụp của cơ sở mã hiện tại của bạn.. Di chuyển là để di chuyển thay đổi cơ sở dữ liệu của bạn từ một phiên bản sang phiên bản tiếp theo. Vì vậy, tại một số điểm trong tương lai, bạn có thể lấy một cơ sở dữ liệu cũ, áp dụng di chuyển và làm việc với cơ sở mã mới nhất.

Tôi chưa từng thấy thử nghiệm di chuyển thực tế. Tôi đã thấy kết quả thử nghiệm, và họ đã bắt/nhắc tôi chạy những di chuyển mới nhất.

describe User do 
    it { should have_column :name, :type => :string } 
    it { should validate_presence_of :name}  
end 

Vì vậy, ai đó thay đổi mô hình. Thêm một thử nghiệm để phản ánh mô hình. Thêm di chuyển. Sau đó, cam kết nguồn.
Bạn lấy các thử nghiệm mới nhất, chạy. Kiểm tra không thành công vì cơ sở dữ liệu không tương ứng. Bạn nhớ chạy di chuyển, sau đó chạy lại kiểm tra. Sự thành công.

Answer 4

Bạn CÓ THỂ so sánh các đối tượng hệ thống cơ sở dữ liệu, nhưng bạn sẽ cần phải có mục tiêu để so sánh - nếu không, làm cách nào bạn biết nếu được chuyển hoặc không thành công?

Tôi nghĩ rằng bạn có thể nên tạo ra một tập hợp các trường hợp thử nghiệm hoạt động CRUD trường hợp cạnh mà thực hiện các thực thể hoặc hoạt động trong lớp dữ liệu. Nếu bất kỳ lỗi nào trong số này không thành công, cơ sở dữ liệu không đồng bộ với những gì được yêu cầu. tức là nếu việc chèn một trường char (20) không thành công vì nó chỉ là char (15) trong cơ sở dữ liệu. Sau đó, so sánh cấu trúc db có thể được thực hiện để xem nếu tắt.

Bạn có thể rút ngắn điều này bằng cách chỉ tập trung vào các mục đã thay đổi gần đây và giả sử các thay đổi trước đó đã được áp dụng.

Answer 5

Kiểm tra việc di chuyển thử nghiệm như là một phần của chiến lược kiểm tra tính bền vững tổng thể của bạn nếu sử dụng NHibernate, tức lànếu bạn có thể tạo và lưu tất cả các thực thể của bạn mà không có bất kỳ lỗi nào, cơ sở dữ liệu của bạn và ánh xạ của bạn phải chính xác.

Answer 6

Tôi cũng đang tìm câu trả lời cho điều này. Tôi nghĩ rằng điều này nên được thử nghiệm trong một môi trường tích hợp hơn là một thử nghiệm đơn vị một: Đối với các bài kiểm tra đơn vị (DAL) tôi thả cơ sở dữ liệu và tạo lại nó. Tuy nhiên, lý tưởng tôi muốn có một môi trường tích hợp là DB của tôi được sao chép từ quá trình sản xuất và các kịch bản di trú DB chạy theo cả hai cách: Trở lên để đảm bảo nâng cấp sản xuất trơn tru và Giảm xuống để đảm bảo có thể khôi phục.