Có phải là thực tế xấu để thực thi một lệnh thực hiện cho các bài kiểm tra đơn vị?

Tôi đang viết bài kiểm tra cho một dự án bao gồm nhiều mô hình con. Mỗi trường hợp thử nghiệm mà tôi đã viết chạy độc lập với nhau và tôi xóa tất cả dữ liệu giữa các thử nghiệm.

Mặc dù các bài kiểm tra chạy độc lập, tôi đang xem xét thực thi lệnh thực thi, vì một số trường hợp yêu cầu nhiều hơn một mô hình con. Ví dụ, một mô hình con đang tạo dữ liệu và một mô hình khác đang chạy truy vấn trên dữ liệu. Nếu mô hình con tạo dữ liệu có lỗi, kiểm tra mô hình con truy vấn cũng sẽ thất bại, ngay cả khi chính mô hình con hoạt động tốt.

Tôi không thể làm việc với dữ liệu giả, vì chức năng chính tôi đang kiểm tra là kết nối với máy chủ từ xa hộp đen, chỉ lấy dữ liệu từ mô hình con đầu tiên.

Trong trường hợp này, bạn có thể thi hành lệnh thi hành cho các bài kiểm tra hay không? Tôi cảm thấy như có một mùi trong thiết lập này, nhưng tôi không thể tìm thấy một cách tốt hơn xung quanh.

chỉnh sửa: câu hỏi là từ Làm thế nào để kiểm tra cấu trúc trong đó một thử nghiệm là thiết lập của thử nghiệm khác? vì kiểm tra "trước" không phải là thiết lập, nhưng kiểm tra mã thực hiện cài đặt.

Tôi không thể làm việc với dữ liệu giả, vì chức năng chính tôi đang kiểm tra là kết nối với máy chủ từ xa hộp đen, chỉ lấy dữ liệu từ mô hình con đầu tiên.

Đây là phần quan trọng đối với tôi. Bạn có thể nói về "kiểm tra đơn vị" và chúng "chạy độc lập với nhau", nhưng tất cả đều có vẻ như chúng phụ thuộc vào máy chủ từ xa này và phụ thuộc vào "mô-đun phụ đầu tiên". Vì vậy, mọi thứ âm thanh được kết hợp chặt chẽ và phụ thuộc vào trạng thái bên ngoài. Như vậy, trên thực tế bạn đang viết các bài kiểm tra tích hợp. Có những bài kiểm tra chạy theo một thứ tự cụ thể là khá bình thường vì chúng phụ thuộc nhiều vào các yếu tố bên ngoài. Một lần chạy thử đã ra lệnh, với tùy chọn thoát sớm khỏi lần chạy thử nếu xảy ra sự cố là hoàn toàn chấp nhận được đối với các thử nghiệm tích hợp.

Tuy nhiên, cũng đáng để xem xét cấu trúc ứng dụng của bạn. Có thể giả lập mô hình con đầu tiên và máy chủ bên ngoài sau đó có khả năng cho phép bạn viết các bài kiểm tra đơn vị thực sự cho tất cả các mô hình con khác.

Vâng, đó là một thực hành xấu.

Nói chung, một bài kiểm tra đơn vị nhằm kiểm tra một đơn vị mã (ví dụ: một hàm duy nhất dựa trên trạng thái đã biết).

Khi bạn muốn kiểm tra một chuỗi các sự kiện có thể xảy ra trong tự nhiên, bạn muốn có một kiểu thử nghiệm khác, chẳng hạn như thử nghiệm tích hợp. Điều này thậm chí còn đúng hơn nếu bạn phụ thuộc vào dịch vụ của bên thứ ba.

Để kiểm tra đơn vị những thứ như thế này, bạn cần tìm ra cách tiêm dữ liệu giả, ví dụ như thực hiện giao diện dịch vụ dữ liệu phản ánh yêu cầu web nhưng trả về dữ liệu đã biết từ tệp dữ liệu giả cục bộ.

Lệnh thực thi được thi hành mà bạn đề xuất chỉ có ý nghĩa nếu bạn cũng hủy bỏ quá trình chạy thử sau thất bại đầu tiên.

Hủy bỏ lần chạy thử trong lần thất bại đầu tiên có nghĩa là mỗi lần chạy thử chỉ có thể phát hiện ra một vấn đề duy nhất và nó không thể tìm thấy sự cố mới cho đến khi tất cả các sự cố trước đó đã được khắc phục. Nếu thử nghiệm đầu tiên để chạy tìm thấy sự cố mất một tháng để khắc phục, thì trong tháng đó có hiệu quả sẽ không có thử nghiệm nào được thực hiện.

Nếu bạn không hủy bỏ lần chạy thử trong lần thất bại đầu tiên, thì lệnh thực thi được thi hành sẽ không mua cho bạn bất cứ điều gì vì mỗi lần kiểm tra thất bại cần phải được điều tra. Ngay cả khi chỉ để xác nhận rằng thử nghiệm trên mô hình con truy vấn bị lỗi do lỗi cũng được xác định trên mô hình con tạo dữ liệu.

Lời khuyên tốt nhất tôi có thể đưa ra là viết các bài kiểm tra theo cách dễ xác định khi một thất bại trong sự phụ thuộc đang làm cho bài kiểm tra thất bại.

Mùi mà bạn đề cập đến là việc áp dụng sai các ràng buộc và quy tắc cho các bài kiểm tra của bạn.

Các thử nghiệm đơn vị thường bị nhầm lẫn với "thử nghiệm tự động" hoặc "thử nghiệm tự động bởi một lập trình viên".

Bài kiểm tra đơn vị phải nhỏ, độc lập và nhanh chóng.

Một số người đọc không chính xác điều này là "các bài kiểm tra tự động được viết bởi một lập trình viên phải độc lập nhỏ và nhanh" . Nhưng nó đơn giản có nghĩa là nếu các bài kiểm tra của bạn không nhỏ, độc lập và nhanh chóng, chúng không phải là Bài kiểm tra đơn vị, và do đó, một số quy tắc cho Bài kiểm tra đơn vị không nên, không thể hoặc không phải áp dụng cho bài kiểm tra của bạn. Một ví dụ tầm thường: bạn nên chạy Bài kiểm tra đơn vị của mình sau mỗi lần xây dựng, điều mà bạn không được thực hiện đối với các bài kiểm tra tự động không nhanh.

Mặc dù các bài kiểm tra của bạn không phải là Bài kiểm tra đơn vị có nghĩa là bạn có thể bỏ qua một quy tắc và được phép có một số phụ thuộc lẫn nhau giữa các bài kiểm tra, bạn cũng phát hiện ra rằng có những quy tắc khác mà bạn có thể đã bỏ qua và sẽ cần phải giới thiệu lại - một điều gì đó cho phạm vi của câu hỏi khác .

Như đã lưu ý ở trên, những gì bạn đang chạy dường như là một bài kiểm tra tích hợp, tuy nhiên bạn nói rằng:

Ví dụ, một mô hình con đang tạo dữ liệu và một mô hình khác đang chạy truy vấn trên dữ liệu. Nếu mô hình con tạo dữ liệu có lỗi, kiểm tra mô hình con truy vấn cũng sẽ thất bại, ngay cả khi chính mô hình con hoạt động tốt.

Và đây có thể là một nơi tốt để bắt đầu tái cấu trúc. Mô-đun chạy truy vấn trên dữ liệu không nên phụ thuộc vào việc triển khai cụ thể mô-đun (tạo dữ liệu) đầu tiên. Thay vào đó, tốt hơn là nên tiêm một giao diện chứa các phương thức để lấy dữ liệu đó và điều này sau đó có thể được thử nghiệm để kiểm tra các truy vấn.

ví dụ

Nếu bạn có:

class Queries {

    int GetTheNumber() {
        var dataModule = new Submodule1();
        var data = dataModule.GetData();
        return ... run some query on data
    }
}

Thay vào đó thích:

interface DataModule {
    Data GetData();
}


class Queries {

    IDataModule _dataModule;

    ctor(IDataModule dataModule) {
       _dataModule = dataModule;
    }

    int GetTheNumber() {
        var data = _dataModule.GetData();
        return ... run some query on data
    }
}

Điều này loại bỏ sự phụ thuộc khỏi các truy vấn trên nguồn dữ liệu của bạn và cho phép bạn thiết lập các thử nghiệm đơn vị dễ lặp lại cho các tình huống cụ thể.

Các câu trả lời khác đề cập đến việc kiểm tra thứ tự là xấu (hầu hết là đúng trong hầu hết thời gian), nhưng có một lý do chính đáng để thực thi lệnh khi thực hiện kiểm tra: đảm bảo các kiểm tra chậm của bạn (tức là kiểm tra tích hợp) chạy sau các kiểm tra nhanh hơn (kiểm tra không dựa vào các nguồn lực bên ngoài khác). Điều này đảm bảo rằng bạn thực hiện nhiều thử nghiệm nhanh hơn, có thể tăng tốc vòng phản hồi.