Làm cách nào để kiểm tra trình đọc tệp?


19

Tôi đang làm việc trên một dự án với một vài định dạng tập tin. Một số định dạng được chỉ định bởi .xsds, một số định dạng khác bằng tài liệu trên các trang web tương ứng của chúng và một số định dạng tùy chỉnh trong nhà không có tài liệu. Mwahahahaha.

Có vấn đề gì vậy?

Tôi muốn kiểm tra trình đọc tệp của mình, nhưng tôi không hoàn toàn chắc chắn về cách thực hiện việc này. Dòng chảy của ứng dụng là như vậy:

file.___  ===> read by FileReader.java ===> which creates a Model object

FileReadergiao diện ở đâu

public interface FileReader {
    public Model read(String filename);
}

Modelmột số thuộc tính được điền khi tệp được đọc. Nó trông giống như

public class Model {
    List<String> as;
    List<String> bs;
    boolean isAPain = true;
    // ...
}

Tôi đã thử những gì?

Ý tưởng duy nhất của tôi là tạo tập tin "trình tạo" cho mỗi định dạng tệp. Các trình tạo này về cơ bản là các trình xây dựng có một vài biến số (ví dụ: số lượng bình luận để tạo trong một tệp) và xuất ra một tệp mẫu mà sau đó tôi đọc và so sánh kết quả Modelvới các biến tôi đã sử dụng để tạo tệp ban đầu.

Điều này có một vài vấn đề, mặc dù:

  • Các tệp mà nó tạo ra trông không giống như các tệp thực. Các máy phát điện là không có cách nào nhận thức được bối cảnh.
  • Thật khó để nhận ra nếu trình tạo đã được tạo cho các trường hợp cạnh vì tôi là người đặt thủ công các biến. Phương pháp này hầu như không tốt hơn tôi tạo ra một tá tệp mẫu.

Có cách nào tốt hơn để làm điều này?

EDIT: Thay đổi đơn vị để tích hợp vì đó là những gì tôi thực sự có nghĩa.

EDIT2: Đây là một ví dụ về các trường hợp cạnh tôi đã đề cập.

Mỗi tệp đại diện cho một biểu đồ được tạo thành từ các đỉnh và cạnh. Các đỉnh và cạnh này có thể được gắn theo các cách khác nhau, vì vậy:

v1 -- e1 --> v2 <-- e2 -- v3

la khac nhau tư

v1 -- e1 --> v2 -- e2 --> v3

trong đó hướng của các cạnh quan trọng. Tôi không chắc đây có nằm trong phạm vi của câu hỏi không, nhưng thật khó để nghĩ ra tất cả các trường hợp cạnh thích hợp khi tôi đặt thủ công số đỉnh, số cạnh và chỉ tạo ngẫu nhiên các kết nối.


1
Kiểm tra dựa trên dữ liệu đến với tâm trí. Bạn có thể đưa ra ví dụ cụ thể về các trường hợp cạnh (dựa trên các trường hợp cạnh có thể được kích hoạt trong quá trình thực FileReaderhiện thực tế ) không? Ví dụ: được đưa ra các trường hợp cạnh được tìm thấy trong các định dạng tệp hình ảnh , cho mỗi mục nhập bảng, nếu kết hợp các thuộc tính hàng / cột được hỗ trợ, cần có ít nhất một trường hợp thử nghiệm (tệp dữ liệu) bao gồm kết hợp đó.
rwong

@rwong Tôi đã thêm một ví dụ nhưng tôi không chắc liệu nó có cho bạn ý tưởng không. Tôi đoán vấn đề của tôi là một vấn đề phổ biến với các trường hợp cạnh, tức là. Tôi đã bỏ lỡ bất kỳ? Mặc dù, thử nghiệm dựa trên dữ liệu có vẻ thú vị. Cảm ơn!
sdasdadas

7
Ngoài ra, tôi chỉ nhận thấy điều này, nhưng trường hợp cạnh của tôi theo nghĩa đen là trường hợp cạnh .
sdasdadas

1
Tại sao không kiểm tra thủ công các tệp, và sau đó luôn luôn chạy với cùng một tệp?
Bobson

@Bobson Điều đó tệ hơn một chút so với sử dụng máy phát điện. Trong trường hợp đó tôi có thể bỏ lỡ các trường hợp cạnh (vì bây giờ tôi có thể bị mất), nhưng tôi cũng có thể đưa ra lỗi trong cách gõ của mình. Và với các tệp lớn, việc tự tạo chúng sẽ mất khá nhiều thời gian.
sdasdadas

Câu trả lời:


19

Đầu tiên, hãy nói về mục tiêu của bạn là gì:

  • rõ ràng bạn không muốn kiểm tra "định dạng tệp" - bạn muốn kiểm tra các FileReadertriển khai khác nhau của mình

  • bạn muốn tìm ra càng nhiều loại lỗi khác nhau càng tốt bằng cách kiểm tra tự động

Để đạt được mục tiêu đó một cách đầy đủ, IMHO bạn phải kết hợp các chiến lược khác nhau:

  • đầu tiên, thử nghiệm đơn vị thực tế: FileReaderviệc triển khai của bạn sẽ bao gồm nhiều phần và chức năng khác nhau. Viết các bài kiểm tra nhỏ kiểm tra từng phần trong số chúng một cách cô lập; thiết kế các chức năng của bạn theo cách họ không thực sự cần đọc dữ liệu trong tệp. Những loại kiểm tra này sẽ giúp bạn kiểm tra hầu hết các trường hợp cạnh của bạn.
  • thứ hai, các tệp được tạo: đó là những gì tôi sẽ gọi là kiểm tra tích hợp. Các tệp như vậy sẽ giúp bạn theo dõi các lỗi khác với điểm 1, ví dụ: kết hợp các tham số cụ thể, lỗi truy cập tệp, v.v. Để tạo các trường hợp kiểm thử tốt, cũng sẽ hữu ích khi tìm hiểu về một số kỹ thuật cổ điển như nhóm các trường hợp kiểm tra vào các lớp tương đương hoặc kiểm tra giá trị biên. Lấy một bản sao của cuốn sách này của Glenford Myers để tìm hiểu thêm về điều đó. Các bài viết trên Wikipedia về kiểm thử phần mềm là một nguồn lực tốt, quá.
  • Thứ ba, hãy thử lấy dữ liệu trong thế giới thực: thật khó để xác minh rằng các tệp này được đánh giá chính xác bởi FileReaders của bạn , nhưng có thể đáng để làm điều này vì nó thường tìm thấy các lỗi không được tiết lộ bởi hai chiến lược đầu tiên. Một số người sẽ gọi những điều tử tế này cũng là "kiểm tra tích hợp", những người khác thích "kiểm tra chấp nhận", nhưng thực tế thuật ngữ này không thực sự quan trọng.

IMHO không có cách tiếp cận "ngắn gọn" nào mang lại cho bạn lợi ích của cả ba chiến lược "với giá của một". Nếu bạn muốn phát hiện các trường hợp cạnh cũng như thất bại trong các trường hợp tiêu chuẩn cũng như các trường hợp thực tế, bạn phải đầu tư ít nhất một số - có lẽ là rất nhiều - nỗ lực. May mắn thay, tất cả các phương pháp tiếp cận có thể được sử dụng để tạo các bài kiểm tra tự động, lặp lại.

Ngoài ra, bạn nên đảm bảo rằng bạn FileReaderkhông che giấu bất kỳ lỗi nào khi đọc dữ liệu đó - tạo các kiểm tra / xác nhận được xây dựng sẵn, đưa ra các ngoại lệ khi có lỗi xảy ra trong nội bộ, v.v. Điều này giúp mã kiểm tra của bạn có cơ hội phát hiện lỗi tốt hơn nhiều , ngay cả khi bạn không có tệp kiểm tra rõ ràng hoặc trường hợp kiểm tra cho một tình huống bất ngờ.


Câu trả lời tuyệt vời, và tôi sẽ chỉnh sửa tiêu đề câu hỏi của tôi để phản ánh tốt hơn. Cảm ơn!
sdasdadas
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.