Làm cách nào để tổ chức kiểm tra tính toàn vẹn dữ liệu trực tiếp và kiểm tra đơn vị mã?

Question

Tôi có một số tệp có mã kiểm tra mã (sử dụng một lớp "không phân biệt").

Sau đó tôi thấy nó sẽ là tốt đẹp để kiểm tra tính toàn vẹn cơ sở dữ liệu cũng. Tôi đặt nó vào một cây thư mục riêng biệt. (Những thứ như các phím có định dạng chính xác, nút cha và con đang trỏ chính xác và như vậy. Chỉnh sửa: đây là một dự án nosql, nơi tôi không thể dựa vào kiểm tra mức cơ sở dữ liệu liek toàn vẹn tham chiếu và như vậy.)

Tôi sử dụng cùng một lớp học không nhất quán cho các bài kiểm tra tính toàn vẹn.

Bây giờ tôi tự hỏi nếu nó thực sự có ý nghĩa để giữ riêng biệt này. Để kiểm tra tính toàn vẹn của dữ liệu, tôi thường sao chép các phần mã mà tôi sử dụng để kiểm tra mã xử lý dữ liệu.

Nhưng nó không giống nhau. Các bài kiểm tra mã sử dụng cơ sở dữ liệu thử nghiệm (được xóa sau mỗi lần kiểm tra) và kiểm tra tính toàn vẹn kết nối với dữ liệu trực tiếp và phân tích nó. Kiểm tra tính toàn vẹn tôi muốn gọi từ cron và gửi báo thức nếu có điều gì đó xảy ra trong cơ sở dữ liệu trực tiếp.

Bạn xử lý như thế nào? Có các tiêu chuẩn cho việc thiết lập như vậy không? Kinh nghiệm của bạn là gì?

Xu hướng của tôi là đặt mọi thứ vào cùng một tệp, điều này sẽ dẫn đến việc kiểm tra mã cũng được thực hiện bởi cron trên môi trường sản xuất.

Chỉnh sửa: Điều gì cũng thúc đẩy tôi là cố gắng giữ cho dự án đơn giản và không có quá nhiều tệp được chạm vào bởi một tác vụ hoặc luồng công việc. Nếu không có tất cả các thử nghiệm tôi đã có một tập tin lớp học, một phân lớp, một lớp học liên quan, một số thư viện (helper) tập tin và mã chính. Thử nghiệm thêm một tệp. Nó giúp tôi giữ sự chú ý của mình tập trung trong khi mã hóa, nó ít căng thẳng hơn và tôi tin rằng tôi thực hiện ít lỗi hơn, và tôi có thể nhớ nhanh hơn và tìm một phần mã nhất định với ít tệp bị ảnh hưởng hơn. Chỉ một tệp thử nghiệm trên mỗi luồng công việc mới có thể trợ giúp ở đây. Nếu tôi giữ nó riêng biệt có 2 tập tin (kiểm tra tính toàn vẹn dữ liệu và kiểm tra mã) và có thể 3 (một thư viện chung cho cả hai). Trừu tượng sẽ thêm phức tạp.

Chỉnh sửa2: Bây giờ tôi đang tái cấu trúc một chút và chỉ di chuyển các tệp kiểm tra dữ liệu đến cùng một cây thư mục, nơi cũng kiểm tra mã, nhưng vẫn giữ các tệp khác nhau với tên "toàn vẹn" hoặc "thử nghiệm". Tôi sẽ không (chưa) hợp nhất các tập tin, bởi vì 2 người được đề nghị chống lại nó, và tôi tin vào kinh nghiệm và lời khuyên của họ cho đến bây giờ. Tôi sẽ sống với bản sao mã cho thời điểm này.

Edit3: Tôi quên đề cập đến việc lựa chọn các thử nghiệm trên mỗi lần chạy không được xác định bởi cấu trúc cây trong trường hợp này. Các bài kiểm tra được liệt kê trong một tệp chính, vì vậy tôi có 2 tệp chính "toàn vẹn" và "kiểm tra mã" hiện tại và thử nghiệm có thể sống trong cùng một cấu trúc directury.

Có thể nhiều người sẽ trả lời. Cảm ơn bạn cho đến nay cho các đầu vào có giá trị, mà đã giúp tôi phát triển cấu trúc cuối cùng!

Chỉnh sửa4: Tôi đã thực hiện tái cấu trúc lại nhiều hơn bây giờ. Có vẻ như tôi nên giữ 2 tệp, nhưng với mục đích được sửa đổi đôi chút. Một mục tiêu được giám sát theo lịch trình trên máy chủ sản xuất. Và một cái khác để phát triển. Nhưng trong cả hai tập tin có thể được kiểm tra tính toàn vẹn hoặc kiểm tra mã. Và trong cả hai tác vụ tệp có thể được thực hiện trên cơ sở dữ liệu thử nghiệm (được xóa sau khi thử nghiệm) và trên cơ sở dữ liệu cố định (mỗi cơ sở dữ liệu vĩnh viễn, máy chủ sản xuất và máy chủ develpment). Và một điều quan trọng: tôi thấy mình đang di chuyển rất nhiều mã phổ biến từ các tệp thử nghiệm đến các tệp lớp. Vì vậy, các lớp học cũng có được khả năng chỉ để thử nghiệm.Tôi thích điều này cho đến nay, cảm thấy sạch sẽ. Tôi chưa (chưa) tạo một thư viện để thử nghiệm được chia sẻ giữa 2 phần đầu thử nghiệm, mã này đã chuyển đến tệp lớp của obejct đang bị xóa bây giờ.

Xin lưu ý rằng nhận xét của tôi dưới đây được ký với "user89021" nhưng đó là tôi, karlthorwald. Tôi không thể làm bất cứ điều gì về nó.

Answer 1

Bạn nên tách các cơ sở dữ liệu thử nghiệm liên quan từ các bài kiểm tra đơn vị "tinh khiết".
Chi phí của việc có hai hội đồng khác nhau rất thấp xem xét các lợi ích - bạn có một bộ nhanh chóng, không cần thiết lập các bài kiểm tra yêu cầu mà bạn có thể chạy trên bất kỳ máy nào và bộ chậm hơn để kiểm tra tính toàn vẹn của cơ sở dữ liệu. địa điểm (ví dụ: xây dựng máy chủ).

Một lợi ích khác là bạn có thể có hai quy trình xây dựng (nhanh và hàng đêm) chạy các bộ thử nghiệm khác nhau.

Để tránh trùng lặp mã, bạn có thể tạo một assembly khác với các phương thức/hành động phổ biến mà cả hai bộ kiểm thử đều cần. Đừng lo lắng quá nhiều về việc kiểm tra thực tế bởi vì bạn đang thử nghiệm những thứ khác nhau (logic hoặc cơ sở dữ liệu) vì vậy sớm hay muộn các bài kiểm tra của bạn sẽ trở nên khá khác nhau tùy thuộc vào những gì bạn đang cố gắng kiểm tra.

Answer 2

Cách tiếp cận của bạn để tách chúng là tốt.

Mối quan tâm của bạn về sao chép mã là 100% hợp lệ.

Giải pháp khá thẳng - trừu tượng hóa chức năng chung giữa các thử nghiệm - ví dụ: "RunTest", "AnalyzeResult", "ConnectToDB" - vào một thư viện chung (bạn không chỉ định ngôn ngữ nào nhưng tôi cho rằng nó có khái niệm về một thư viện) có thể được thông qua các chi tiết cấu hình như cơ sở dữ liệu nào để kết nối. Sau đó, sử dụng thư viện đó một cách độc lập với trình điều khiển kiểm tra đơn vị và trình điều khiển kiểm tra tính toàn vẹn - nếu bạn có đủ kỹ năng/may mắn, có thể có rất ít mã riêng của nó ngoài cấu hình (ví dụ: cơ sở dữ liệu nào để kết nối, làm thế nào để báo cáo kết quả và thử nghiệm nào để chạy).

Tương tự, nếu cần thiết, đầu vào chung/tập hợp dữ liệu có thể được đặt trong thư mục chung

Answer 3

Một câu trả lời khác. Bạn có hai loại kiểm tra. Những gì tôi muốn làm là giải quyết các bài kiểm tra tính toàn vẹn. Những gì bạn có thể muốn làm là bao gồm các bài kiểm tra tính toàn vẹn làm chức năng của mã sản xuất . IOW, có tính toàn vẹn như là một phần của hệ thống.

Bạn đã đề cập rằng trùng lặp là một vấn đề và bạn đang tái cấu trúc để loại bỏ trùng lặp. Mã tái cấu trúc của khóa học có các bài kiểm tra phát triển?

Giám sát hệ thống có thể là mã sản xuất. Vì vậy, những gì bao giờ mã bạn viết trở thành một phần của hệ thống.

Điều tuyệt vời về điều này là bạn phát triển mã của bạn thông qua các bài kiểm tra phát triển của bạn.