Tôi đang làm việc trên một dự án tại thời điểm tạo ra một bảng (trong số những thứ khác) dựa trên nội dung của một hệ thống tệp, và đến lượt nó thực hiện một số sửa đổi dữ liệu meta trên những thứ nó tìm thấy. Câu hỏi là: làm thế nào các bài kiểm tra nên được viết xung quanh điều này, hoặc thiết lập? Có một cách dễ dàng để chế nhạo điều này? Hay tôi nên thiết lập một "hộp cát"?
Câu trả lời:
Như bạn luôn làm trong TDD với các tài nguyên bên ngoài: bạn tạo một hoặc nhiều giao diện cho các hoạt động của hệ thống tệp của mình và "giả lập chúng ra". Bạn muốn kiểm tra "trình tạo bảng" và mã sửa đổi dữ liệu meta của mình, chứ không phải chính hoạt động của hệ thống tệp (rất có thể bạn đang sử dụng các triển khai thư viện được tạo sẵn để truy cập hệ thống tệp).
Có gì sai khi có một hệ thống tập tin "thử nghiệm"?
Tạo một cấu trúc thư mục / thư mục mẫu có đủ nội dung để kiểm tra các hoạt động của bạn.
Trong quá trình thiết lập thử nghiệm đơn vị của bạn, sao chép cấu trúc ban đầu này (sẽ khuyên bạn nên ZIP mẫu và giải nén vào khu vực thử nghiệm của bạn). Chạy thử nghiệm của bạn. Xóa toàn bộ trong khi xé xuống.
Vấn đề với việc chế nhạo trước hết là các hệ thống tệp, HĐH và cơ sở dữ liệu thuộc dự án của bạn không thực sự đủ điều kiện là tài nguyên bên ngoài và thứ hai là chế nhạo các cuộc gọi hệ thống cấp thấp vừa tốn thời gian vừa dễ bị lỗi.
Đây là loại điều bạn chắc chắn cần kiểm tra tích hợp, vì các hệ thống tệp trong thế giới thực có tất cả các loại hành vi lạ (như cách Windows sẽ không cho phép xóa tệp nếu bất kỳ quy trình nào, bao gồm cả trình duyệt, mở nó).
Vì vậy, cách tiếp cận TDD là viết thử nghiệm tích hợp trước tiên (TDD, nói đúng ra, không có khái niệm riêng biệt về 'thử nghiệm đơn vị' và 'thử nghiệm tích hợp'; chúng chỉ là thử nghiệm). Rất có khả năng đó sẽ là đủ; Thế là xong việc, dừng lại, về nhà .
Nếu không, sẽ có một số phức tạp bên trong không dễ kiểm tra đầy đủ bằng cách sắp xếp các tệp. Trong trường hợp đó, bạn chỉ cần lấy sự phức tạp đó ra, đặt nó vào một lớp và viết các bài kiểm tra đơn vị cho lớp đó . Rất có khả năng bạn sẽ thấy rằng lớp chung có thể sử dụng được trong các trường hợp cơ sở dữ liệu, tệp xml, v.v.
Trong mọi trường hợp, bạn sẽ lấy lõi cơ bản của mã bạn đang viết và 'giả' nó ra để viết các bài kiểm tra sẽ vượt qua liệu đơn vị được kiểm tra có sai hay không.
'unit test' and 'integration test'; they are just tests.tôi nghĩ thực tế, đây sẽ là giải pháp tốt nhất cho trường hợp của tôi - Tôi thực sự cần kiểm tra các thư viện hệ thống tệp tôi đang sử dụng cho các trường hợp cạnh và cách ứng dụng nên phản hồi những, cái đó. Nếu tôi chuyển sang thư viện hệ thống tệp khác, tôi không muốn phải viết lại một loạt các mã giả / mã kiểm tra để làm việc với thư viện mới, nhưng có cấu trúc thư mục kiểm tra và kiểm tra tích hợp sẽ đơn giản hơn nhiều.
Tôi hiểu câu hỏi của bạn là "Cách tốt / được chấp nhận để kiểm tra một lớp phụ thuộc vào hoạt động của hệ thống tệp". Tôi không cho rằng bạn muốn kiểm tra hệ thống tập tin của hệ điều hành của bạn.
Để duy trì nỗ lực 'giao diện cho các hoạt động của hệ thống tệp của bạn và "giả lập chúng" "như câu trả lời @Doc Brown đề xuất càng nhỏ càng tốt, nên sử dụng luồng nhị phân java hoặc trình đọc văn bản (hoặc tương đương trong c # hoặc ngôn ngữ lập trình bạn đang sử dụng) thay vì sử dụng Tệp có tên tệp trực tiếp trong lớp do bạn phát triển.
Thí dụ:
Sử dụng java Tôi đã triển khai một lớp CsvReader
public class CsvReader {
private Reader reader;
public CsvReader(Reader reader) {
this.reader = reader;
}
}
Để kiểm tra tôi đã sử dụng dữ liệu bộ nhớ như thế này
String contentOfCsv = "TestColumn1;TestColumn2\n"+
"value1;value2\n";
CsvReader sut = new CsvReader(java.io.StringReader(contentOfCsv));
hoặc đưa testdata vào tài nguyên
CsvReader sut = new CsvReader(getClass().getResourceAsStream("/data.csv"));
Trong sản xuất tôi sử dụng hệ thống tập tin
CsvReader sut = new CsvReader(new BufferedReader( new FileReader( "/import/Prices.csv" ) ));
Bằng cách này, CsvReader của tôi không phụ thuộc vào hệ thống tệp mà phụ thuộc vào "Trình đọc" trừu tượng, nơi có triển khai cho hệ thống tệp.