2016-10-10 14 views
13

Tôi đang thử nghiệm một phương pháp điều khiển một bộ sưu tập. Cho một tập hợp các tham số, nó phải chứa chính xác một phần tử khớp với một điều kiện. Chỉnh sửa: Bộ sưu tập có thể có một số yếu tố khác không phù hợp với điều kiện.Việc sử dụng Đơn như là một Thực hành không tốt?

Tôi đang sử dụng Single để kiểm tra hành vi đó, hoạt động tốt, vì nó sẽ không thực hiện được thử nghiệm bằng cách ném ngoại lệ nếu không có kết quả trùng khớp hoặc nhiều hơn một kết quả phù hợp. Nhưng không có khẳng định thực tế, bằng cách nào đó vi phạm a rrange, a ct, a ssert. Vì vậy, tôi tự hỏi nếu đây là một thực hành xấu và nếu có một cách tốt hơn để làm điều này.

Tiếp theo mã giả để chứng minh câu hỏi của tôi:

[TestMethod] 
public void TestMethod() 
{ 
    List list = MethodToTest(param1, param2); 

    list.Single(s => s.Matches(condition)); 

    //No actual Assert 
} 
+3

Tôi nghĩ khẳng định là tốt hơn, ít nhất là vì bạn có thể cung cấp thêm thông tin mang tính thông tin về những gì và ở đâu không thành công. – Evk

+1

Đây là một ý kiến ​​dựa trên câu hỏi ... Theo ý kiến ​​của tôi, tôi không sử dụng 'Single' để xác nhận rằng chỉ có 1 mục trong UT ... Tôi sẽ sử dụng' Assert.Equal (1, list.Count (. ..)) ' –

+0

Tôi đang nghĩ rằng việc sử dụng' SingleOrDefault' có thể được sử dụng tại đây. Sau đó, bạn có thể khẳng định nếu mục được trả về không phải là rỗng. – Jon

Trả lời

16

Tôi đang tự hỏi nếu điều này là một thói quen xấu và nếu có một cách tốt hơn để làm điều này.

Có và có.

nó sẽ không kiểm tra bằng cách ném ngoại lệ nếu không có kết quả trùng khớp nào hoặc nhiều hơn một kết quả phù hợp.

Đừng làm bài kiểm tra bằng cách ném ngoại lệ. Thất bại khi kiểm tra bằng cách không kiểm tra. Khung kiểm thử của bạn có một cơ chế để khẳng định điều kiện đang được thử nghiệm kiểm tra. Bạn đã mua khung kiểm tra này và bây giờ bạn đang chống lại việc sử dụng các tính năng của nó. Sử dụng khung kiểm tra vì nó được thiết kế để sử dụng, hoặc, nếu bạn không thích nó, hãy từ bỏ nó và chọn một khung công tác mà bạn thích hơn. Nhưng đừng kết thúc xung quanh cơ chế của nó.

Ngoại lệ không mong muốn không nhất thiết phải là lỗi kiểm tra; họ có thể là kiểm tra lỗi. Bạn cần để có thể nói sự khác biệt. Cách bạn nói là: nếu ngoại lệ bắt nguồn trong đoạn mã đang được kiểm tra, đó là lỗi trong mã. Nếu nó bắt nguồn trong mã thử nghiệm, đó là một lỗi trong thử nghiệm. Và bây giờ bạn đi và phát hiện một lỗi trong mã đang được kiểm tra bằng cách làm cho đoạn mã thử nghiệm được ném. Và bây giờ khó có thể biết được lỗi ở đâu. Đừng làm cho tương lai của bạn tự nghĩ rằng khó khăn; không viết mã đáng ngạc nhiên cố ý tránh các quy ước của nền tảng thử nghiệm.

+0

Cảm ơn câu trả lời của bạn. Bạn nói đúng Tôi đã không nghĩ về sự khác biệt giữa một bài kiểm tra thất bại và một bài kiểm tra lỗi. – Phonolog

Các vấn đề liên quan