Thử nghiệm đơn vị với các đầu vào dài

Question

[TestMethod] 
public void SomeTestMethod() 
{ 
    string input = "some looooong input..."; 

    var proc = new Processor() 
    string result = proc.DoSomething(input); 

    Assert.Equals("good", result); 
} 

Nếu tôi đang viết kiểm tra đơn vị và có đầu vào quá dài (như giao dịch EDI), tôi có nên dán nó vào phương pháp thử làm chuỗi dài không?

Những người khác đã đề xuất tôi nên dán chuỗi dài đó vào một tệp và coi tệp đó là tài nguyên được nhúng trong dự án thử nghiệm của tôi. Nếu tôi làm một cái gì đó như thế và tôi cần đầu vào khác nhau cho mỗi bài kiểm tra của tôi, tôi có thể thấy rất nhiều tập tin chồng chất lên và trở nên khó khăn để duy trì.

Có bất kỳ phương pháp hay nhất nào về vấn đề này không? Tôi có nên tiếp tục dán các chuỗi dài này vào các phương pháp thử nghiệm của mình không?

Answer 1

Tôi luôn đặt chuỗi thử nghiệm dài vào tài nguyên và duy trì việc đặt tên nhất quán giữa các thử nghiệm và tài nguyên của chúng để dễ dàng lập bản đồ. Tôi sử dụng cùng tên cho tài nguyên và bài kiểm tra. Khi tôi cần một số tài nguyên để thử nghiệm, tôi thêm hậu tố 1, 2, 3, v.v.

Answer 2

Nếu điều gì đó nhanh chóng mà tôi không quan tâm, tôi thả mã đó vào mã. Vì tôi có nhiều khả năng thử nghiệm một khái niệm.

Nếu mã của mã sẽ tiếp tục như kiểm tra hoặc mã sản xuất, hãy sử dụng tệp tài nguyên dưới dạng tài nguyên được nhúng hoặc sử dụng tệp resx, bạn luôn thấy thoải mái hơn.

Answer 3

Bạn có thể sử dụng một constructor chuỗi khác nhau để tạo ra một chuỗi rất dài của ký tự lặp đi lặp lại, như thế này:

string input = new string('x', 1024 * 1024/2); 

Cách tiếp cận đó đưa ra một cách nhiều thanh lịch hơn của việc tạo ra chuỗi dài withing phải dán chuỗi dài vào các bài kiểm tra của bạn.

Answer 4

Đây chỉ là câu trả lời "được đề xuất" vì tôi chưa bao giờ thấy bất kỳ phương pháp hay nhất nào về vấn đề này;

Tôi làm việc với các tệp EDI và các trường hợp thử nghiệm của chúng tôi thường chứa dữ liệu thử nghiệm được dán giống như bạn làm, trong trường hợp của chúng tôi là hằng số được xác định bên ngoài bản thân kiểm tra để không làm lộn xộn mã kiểm tra thực tế.

Chúng tôi nhận thấy rằng việc xử lý các tệp bên ngoài dễ bị lỗi.

Answer 5

Tôi đã thử nghiệm một số regexp chống lại tệp. Những gì tôi đã làm là tôi sao chép dán nội dung của tập tin vào lớp thử nghiệm như là một tài sản bình thường nhưng tôi đã sử dụng các thẻ #region để ẩn nó. Tôi không cần phải nhìn thấy 200 dòng văn bản mỗi lần tôi mở lớp kiểm tra đó. Đây cũng là một trong số ít trường hợp tôi thấy thẻ #region hữu ích.

Answer 6

Mà không biết đang Processor 's, như tôi nhìn thấy nó, Processor nên có xét nghiệm đơn giản, nhanh chóng, đơn vị bao gồm hoạt động bên trong của nó, trong khi kiểm tra như SomeTestMethod nên được coi là Tích hợp kiểm tra.

Như vậy, tôi sẽ lưu trữ tất cả dữ liệu thử nghiệm trong một tệp XML và tải nó vào thử nghiệm, chạy cùng một thử nghiệm cho mọi đầu vào (Nếu bạn muốn kiểm tra lượng dữ liệu nghiêm trọng - bạn có thể sử dụng cơ sở dữ liệu) . Không cần viết các bài kiểm tra riêng biệt cho mỗi đầu vào.

Cách tiếp cận rất sạch sẽ và thanh lịch về cách thực hiện điều này trong MSTest được mô tả here.