Cơ sở dữ liệu và Kiểm tra đơn vị / Tích hợp

Tôi đã có một cuộc thảo luận với ai đó về thử nghiệm đơn vị / tích hợp với các ứng dụng web và tôi có một sự bất đồng về ý tưởng cốt lõi. Vấn đề là người mà tôi đang nói nghĩ rằng cơ sở dữ liệu mà bài kiểm tra đơn vị không hoạt động nên có dữ liệu được điền trước trong đó và tôi nghĩ rằng nó nên hoàn toàn trống trước và sau khi các bài kiểm tra được thực thi.

Mối quan tâm của tôi với dữ liệu được điền trước trong cơ sở dữ liệu là không có cách nào để đảm bảo dữ liệu được duy trì ở trạng thái tốt. Bản thân các bài kiểm tra sẽ tạo, xóa và sửa đổi dữ liệu trong cơ sở dữ liệu để tôi thực sự không thấy việc có dữ liệu trong cơ sở dữ liệu trước khi bạn bắt đầu kiểm tra là một điều tốt.

Có vẻ như cách tốt nhất để kiểm tra chức năng cơ sở dữ liệu sẽ có các thiết lập sau:

1. Trong giai đoạn "thiết lập" trước khi thử nghiệm thực sự chạy, trước tiên bạn cắt ngắn tất cả các bảng trong cơ sở dữ liệu
2. Sau đó, bạn chèn tất cả dữ liệu cần thiết cho các trường hợp thử nghiệm mà bạn sắp chạy
3. Sau đó, bạn chạy và xác nhận các trường hợp thử nghiệm
4. Sau đó, trong giai đoạn "phá vỡ", bạn lại cắt tất cả các bảng trong cơ sở dữ liệu

Tôi không thấy cách nào khác tốt hơn để đảm bảo rằng dữ liệu bạn đang kiểm tra là một thử nghiệm tốt.

Am i thiếu cái gì ở đây? Đây không phải là cách tốt nhất để kiểm tra chức năng liên quan đến cơ sở dữ liệu? Có một số lợi ích khi có cơ sở dữ liệu được điền trước luôn tồn tại trong cơ sở dữ liệu (ngay cả trước khi bạn bắt đầu kiểm tra hoặc sau khi kiểm tra xong)? Bất kỳ trợ giúp nào trong các ý tưởng để giải thích quá trình của tôi khác nhau để có được quan điểm của tôi tốt hơn cũng sẽ rất tuyệt (đó là nếu quan điểm của tôi có giá trị).

Đối với tôi kiểm tra đơn vị không nên đối phó với cơ sở dữ liệu, kiểm tra tích hợp đối phó với cơ sở dữ liệu.

Các thử nghiệm tích hợp liên quan đến cơ sở dữ liệu trong thực tế nên có một cơ sở dữ liệu trống rỗng với cách tiếp cận xé nát, sử dụng cách tiếp cận dựa trên giao dịch là một cách khá tốt (nghĩa là tạo một giao dịch khi thiết lập và khôi phục lại xé nát).

Những gì bạn của bạn nghe có vẻ như họ muốn làm là kiểm tra theo quan điểm 'hồi quy', tức là có dữ liệu thực ở đó và xem hệ thống phản ứng như thế nào, sau tất cả không có hệ thống nào là hoàn hảo và thường có thể có dữ liệu xấu nằm ở đâu đó cung cấp một số quirks cho mô hình miền của bạn.

Thực tiễn tốt nhất của bạn là con đường để đi, và những gì tôi có xu hướng làm, là nếu tôi tìm thấy một kịch bản cho dữ liệu xấu, hãy viết một bài kiểm tra tích hợp với một thiết lập lên và phá bỏ với kịch bản chính xác đó.

Nếu các thử nghiệm của bạn phụ thuộc vào cơ sở dữ liệu, thì tôi nghĩ điều quan trọng hơn là dữ liệu bạn quan tâm ở trạng thái đã biết đối với thử nghiệm của bạn, thay vì cơ sở dữ liệu trống. Một trong những biện pháp của các bài kiểm tra tốt là mỗi bài kiểm tra nên thất bại vì một lý do và không có bài kiểm tra nào khác thất bại vì lý do tương tự.

Vì vậy, nếu thử nghiệm của bạn quan tâm đến trạng thái của dữ liệu thì hãy đưa dữ liệu vào trạng thái đã biết đó và đưa dữ liệu về trạng thái đó sau khi thử nghiệm của bạn đã chạy, để các thử nghiệm của bạn có thể được sao chép.

Nếu bạn có thể tách các bài kiểm tra của mình khỏi trạng thái dữ liệu bằng cách chế nhạo thì đó cũng là một điều tốt. Bạn đề cập đến việc bạn đang thực hiện kiểm tra đơn vị / tích hợp, nhưng tất nhiên hai điều đó nên được xem xét riêng. Các bài kiểm tra đơn vị của bạn nên được tách khỏi cơ sở dữ liệu nếu có thể và các bài kiểm tra tích hợp của bạn sẽ được kiểm tra với cơ sở dữ liệu ở trạng thái đã biết.

Chà, tôi thấy một lợi ích khi có một cơ sở dữ liệu được chuẩn bị trước: bạn không phải viết mã sẽ chèn dữ liệu bạn cần, vì nó có ở đó. Nếu không thì chỉ có nhược điểm. Có lẽ ai đó đã sửa đổi dữ liệu thử nghiệm trên cơ sở dữ liệu? Có lẽ ai đó đã cố gắng làm mới dữ liệu? Nhưng điều tồi tệ hơn là có một trường hợp thử nghiệm làm xáo trộn cơ sở dữ liệu ... Bạn cuối cùng sẽ tạo lại toàn bộ cơ sở dữ liệu một cách thủ công nhiều lần.

Bạn đúng trong cách viết bài kiểm tra, ngoại trừ việc tôi sẽ không cắt ngắn bất cứ điều gì:

• giai đoạn thiết lập: nhận kết nối tới cơ sở dữ liệu và chèn dữ liệu
• giai đoạn chạy
• xé pha: xóa dữ liệu đã chèn (cắt ngắn)

Bây giờ, kịch bản đó là tuyệt vời cho các bài kiểm tra đơn vị. Khi một người cần dữ liệu cho cả thử nghiệm đơn vị và tích hợp, tôi thấy rằng một giai đoạn thiết lập lớn phổ biến cho tất cả các trường hợp thử nghiệm (chúng tôi tập hợp lại tất cả "chèn" vào một phương thức tĩnh) cũng có thể hoạt động rất tốt. Nó giống như một nền tảng giữa ý tưởng của bạn và ý tưởng của bạn bè. Hạn chế duy nhất là bạn phải rất cẩn thận khi thêm một số dữ liệu mới để không phá vỡ các trường hợp kiểm tra hiện có (nhưng nếu bạn thêm như hai ba hàng trên mỗi bảng như chúng tôi đã làm thì đó không phải là vấn đề)

Tôi nghĩ rằng bạn cần thu hẹp một ví dụ với đồng nghiệp của bạn và tìm hiểu chính xác ý nghĩa của chúng. Cả hai bạn có thể ở trên cùng một trang.

Ví dụ: Kiểm tra bảng giao dịch tài khoản

1. Bạn có muốn kiểm tra xem bảng này cho người dùng / tài khoản không có giao dịch không?
2. Kiểm tra thêm bản ghi đầu tiên và xem nếu bạn có thể tạo số dư.
3. Tạo hồ sơ khi đã có hồ sơ hiện có và kiểm tra số dư hoạt động và bất kỳ quy tắc kinh doanh nào khác.
4. Xem bảng với các hồ sơ hiện có và tất cả các CRUD khác.

Cho dù bạn đạt được điều này bằng cách thực hiện các bước 1 & 2 hoặc bắt đầu với cơ sở dữ liệu đã ở trạng thái này (khôi phục bản sao lưu?) Tôi không chắc nó có vấn đề gì không. Ý tưởng của bạn về việc viết kịch bản cho tôi giúp bạn dễ dàng quản lý mọi thay đổi bạn cần (Giống như nếu bạn quên tạo tài khoản quản trị viên và cần nó cho người dùng mới.). Tập tin script dễ dàng được đưa vào kiểm soát nguồn hơn một số tập tin sao lưu. Điều này cũng bị ảnh hưởng bởi việc bạn có phân phối ứng dụng này hay không.

Để vẽ các khía cạnh của một vài câu trả lời với nhau và thêm 2p của tôi ...

Lưu ý: nhận xét của tôi liên quan đến kiểm tra cơ sở dữ liệu cụ thể và không kiểm tra giao diện người dùng (mặc dù rõ ràng áp dụng tương tự).

Cơ sở dữ liệu chỉ cần thử nghiệm nhiều như các ứng dụng giao diện người dùng nhưng có xu hướng được kiểm tra trên cơ sở 'nó có hoạt động với giao diện người dùng không?' hoặc 'các báo cáo có tạo ra kết quả chính xác không?', mà theo tôi là thử nghiệm rất muộn trong quá trình phát triển cơ sở dữ liệu và không mạnh mẽ lắm.

Chúng tôi có một số khách hàng sử dụng thử nghiệm đơn vị / tích hợp / hệ thống cho cơ sở dữ liệu kho dữ liệu của họ ngoài UAT / Performance / et al thông thường. xét nghiệm. Họ thấy rằng với sự tích hợp liên tục và thử nghiệm tự động, họ đã nhận được nhiều vấn đề trước khi đến với UAT truyền thống, do đó tiết kiệm thời gian trong UAT và tăng cơ hội thành công cho UAT.

Tôi chắc chắn rằng hầu hết sẽ đồng ý rằng một sự nghiêm ngặt tương tự nên được áp dụng cho kiểm tra cơ sở dữ liệu như kiểm tra báo cáo hoặc kết thúc trước.

Điều quan trọng với thử nghiệm là kiểm tra các thực thể đơn giản nhỏ, đảm bảo tính chính xác của chúng, trước khi tiến hành kết hợp các thực thể phức tạp, đảm bảo tính chính xác của chúng trước khi mở rộng sang hệ thống rộng hơn.

Vì vậy, đưa ra một số bối cảnh cho câu trả lời của tôi ...

Kiểm tra đơn vị

• có trọng tâm kiểm tra để chứng minh rằng đơn vị hoạt động, ví dụ: bảng, dạng xem, hàm, thủ tục được lưu trữ
• nên 'sơ khai' các giao diện để loại bỏ các phụ thuộc bên ngoài
• sẽ cung cấp dữ liệu riêng của mình. Bạn cần một trạng thái bắt đầu đã biết của dữ liệu, vì vậy nếu có cơ hội dữ liệu trước khi thử nghiệm, thì việc cắt / xóa sẽ xảy ra trước khi dân số
• sẽ chạy lý tưởng trong bối cảnh thực hiện riêng của nó
• sẽ tự xóa sau khi xóa dữ liệu đã sử dụng; Điều này chỉ quan trọng khi sơ khai không được sử dụng.

Ưu điểm của việc này là bạn loại bỏ tất cả các phụ thuộc bên ngoài vào bài kiểm tra và thực hiện số lượng kiểm tra nhỏ nhất để chứng minh tính đúng đắn. Rõ ràng, các thử nghiệm này không thể chạy trên cơ sở dữ liệu sản xuất. Có thể có một số loại bài kiểm tra bạn sẽ làm, tùy thuộc vào loại đơn vị, bao gồm:

• kiểm tra lược đồ, một số có thể gọi đây là kiểm tra 'hợp đồng dữ liệu'
• giá trị cột đi qua
• việc thực hiện các đường dẫn logic với các giá trị dữ liệu khác nhau cho các hàm, thủ tục, khung nhìn, các cột được tính toán
• kiểm tra trường hợp cạnh - NULL, dữ liệu xấu, số âm, giá trị quá lớn

(Đơn vị) Kiểm thử tích hợp

Tôi thấy bài SE này hữu ích khi nói về các loại thử nghiệm khác nhau.

• có trọng tâm thử nghiệm để chứng minh rằng các đơn vị tích hợp với nhau
• thực hiện trên một số đơn vị với nhau
• nên 'sơ khai' các giao diện để loại bỏ các phụ thuộc bên ngoài
• sẽ cung cấp dữ liệu của riêng mình, để loại bỏ ảnh hưởng của ảnh hưởng dữ liệu bên ngoài
• sẽ chạy lý tưởng trong bối cảnh thực hiện riêng của nó
• sẽ tự xóa sau khi xóa dữ liệu đã tạo; Điều này chỉ quan trọng khi sơ khai không được sử dụng.

Khi chuyển từ các bài kiểm tra đơn vị sang các bài kiểm tra tích hợp này, thường sẽ có nhiều dữ liệu hơn một chút, để kiểm tra nhiều trường hợp kiểm thử khác nhau. Rõ ràng, các thử nghiệm này không thể chạy trên cơ sở dữ liệu sản xuất.

Điều này sau đó tiến hành Kiểm tra hệ thống , Kiểm tra tích hợp hệ thống (còn gọi là kiểm tra đầu cuối 2), với việc tăng khối lượng dữ liệu và tăng phạm vi. Tất cả các thử nghiệm này sẽ trở thành một phần của khung kiểm tra hồi quy. Một số thử nghiệm này có thể được người dùng chọn để thực hiện như một phần của UAT, nhưng UAT là các thử nghiệm được xác định bởi người dùng , không được xác định bởi CNTT - một vấn đề phổ biến!

Vì vậy, bây giờ tôi đã đưa ra một số bối cảnh, để trả lời các câu hỏi thực tế của bạn

• chuẩn bị dữ liệu cho kiểm tra đơn vị và tích hợp có thể gây ra lỗi kiểm tra giả và nên tránh.
• Cách duy nhất để đảm bảo các kiểm tra nhất quán là không đưa ra các giả định về dữ liệu nguồn và kiểm soát nó chặt chẽ.
• bối cảnh thực hiện kiểm tra riêng biệt rất quan trọng, để đảm bảo rằng một người kiểm tra không xung đột với người kiểm tra khác thực hiện các kiểm tra tương tự trên một nhánh khác của mã cơ sở dữ liệu được kiểm soát nguồn.

Thành thật mà nói tôi nghĩ rằng nếu bạn thực hiện kiểm thử đơn vị mà không có cơ sở dữ liệu có kích thước tương đương với cơ sở dữ liệu sản xuất hiện có, bạn sẽ có nhiều thứ vượt qua các thử nghiệm và thất bại trong sản xuất để thực hiện. Tất nhiên tôi cũng chống lại việc phát triển một cơ sở dữ liệu địa phương nhỏ vì lý do này.

Và nếu mã là dữ liệu cụ thể, làm thế nào bạn có thể kiểm tra nó một cách hiệu quả mà không cần dữ liệu? Bạn sẽ bỏ lỡ xem nếu các truy vấn trả về kết quả chính xác. Tại sao bạn thậm chí muốn xem xét thử nghiệm đối với cơ sở dữ liệu trống, tất cả những gì cho bạn biết là nếu cú ​​pháp đúng không nếu truy vấn đúng. Điều đó có vẻ thiển cận với tôi. Tôi đã thấy quá nhiều thứ chạy và vượt qua các bài kiểm tra sai về mặt phân loại. Bạn không muốn tìm thấy điều đó trong thử nghiệm đơn vị? Tôi làm.