Kiểm tra một danh sách Tất cả trong cùng một bài kiểm tra hoặc một bài kiểm tra cho từng điều kiện?

Tôi đang kiểm tra rằng một hàm thực hiện những gì mong đợi trong danh sách. Vì vậy tôi muốn kiểm tra

f(null) -> null
f(empty) -> empty
f(list with one element) -> list with one element
f(list with 2+ elements) -> list with the same number of elements, doing what expected

Để làm như vậy, cách tiếp cận tốt nhất là gì?

• Kiểm tra tất cả các trường hợp trong cùng một thử nghiệm (phương thức), dưới tên "WorksAsExpected"
• Đặt một thử nghiệm cho mỗi trường hợp, do đó có
  • "WorksAsExpectedWhenNull"
  • "WorksAsExpectedWhenEmpty"
  • "WorksAsExpectedWhenSingleEuity"
  • "WorksAsExpectedWhenMoreElements"
• Một lựa chọn khác tôi không nghĩ tới :-)

Quy tắc đơn giản mà tôi sử dụng để thực hiện một tập các thử nghiệm trong một trường hợp thử nghiệm hay nhiều trường hợp là: nó có liên quan đến chỉ một thiết lập không?

Vì vậy, nếu tôi đang kiểm tra rằng, đối với nhiều yếu tố, cả hai đều xử lý tất cả chúng và đưa ra kết quả chính xác, tôi có thể có hai hoặc nhiều xác nhận, nhưng tôi chỉ phải thiết lập danh sách một lần. Vì vậy, một trường hợp thử nghiệm là tốt.

Trong trường hợp của bạn, tôi phải thiết lập một danh sách rỗng, một danh sách trống, v.v. Đó là nhiều thiết lập. Vì vậy, tôi chắc chắn sẽ tạo ra nhiều thử nghiệm trong trường hợp này.

Như những người khác đã đề cập, những "nhiều thử nghiệm" đó có thể tồn tại như một trường hợp thử nghiệm được tham số hóa duy nhất; tức là trường hợp thử nghiệm tương tự được chạy với nhiều loại dữ liệu thiết lập. Chìa khóa để biết thời tiết này là một giải pháp khả thi nằm trong các phần khác của bài kiểm tra: "hành động" và "khẳng định". Nếu bạn có thể thực hiện các hành động và khẳng định tương tự trên mỗi bộ dữ liệu, thì hãy sử dụng phương pháp này. Nếu bạn thấy mình thêm ifví dụ để chạy các mã khác nhau đối với các phần khác nhau của dữ liệu đó, thì đây không phải là giải pháp. Sử dụng các trường hợp thử nghiệm riêng lẻ trong trường hợp sau.

Có một sự đánh đổi. Bạn càng đóng gói trong một thử nghiệm, càng có nhiều khả năng bạn sẽ có hiệu ứng hành tây cố gắng vượt qua. Nói cách khác, thất bại đầu tiên dừng bài kiểm tra đó. Bạn sẽ không biết về các xác nhận khác cho đến khi bạn khắc phục thất bại đầu tiên. Điều đó nói rằng, có một loạt các bài kiểm tra đơn vị gần như tương tự ngoại trừ mã thiết lập là rất nhiều công việc bận rộn chỉ để tìm ra rằng một số công việc như được viết và những công việc khác thì không.

Các công cụ có thể, dựa trên khung của bạn:

• Lý thuyết . Một lý thuyết cho phép bạn kiểm tra một loạt các sự kiện về một tập hợp dữ liệu. Sau đó, khung công tác sẽ cung cấp các thử nghiệm của bạn với nhiều kịch bản dữ liệu thử nghiệm - theo trường hoặc theo phương thức tĩnh tạo dữ liệu. Nếu một số sự kiện của bạn áp dụng dựa trên một số điều kiện tiên quyết và những điều khác thì các khung này không đưa ra khái niệm về một giả định . Bạn Assume.that()chỉ cần bỏ qua bài kiểm tra dữ liệu nếu nó không thành công. Điều này cho phép bạn xác định "Hoạt động như mong đợi" và sau đó chỉ cần cung cấp cho nó rất nhiều dữ liệu. Khi bạn xem kết quả, bạn có một mục nhập cho các bài kiểm tra chính và sau đó là mục nhập phụ cho từng phần dữ liệu.
• Các xét nghiệm tham số . Các bài kiểm tra tham số là tiền thân của các lý thuyết, vì vậy có thể không có kiểm tra điều kiện tiên quyết mà bạn có thể có với các lý thuyết. Kết quả cuối cùng là như nhau. Bạn xem kết quả, bạn có một mục nhập chính cho bài kiểm tra và sau đó là một mục cụ thể cho từng điểm dữ liệu.
• Một thử nghiệm với nhiều khẳng định . Sẽ mất ít thời gian hơn để thiết lập, nhưng cuối cùng bạn cũng phát hiện ra vấn đề một chút. Nếu bài kiểm tra quá dài và có quá nhiều kịch bản khác nhau được thử nghiệm, có hai rủi ro lớn: sẽ mất nhiều thời gian để chạy và nhóm của bạn sẽ chán ngấy với nó và tắt bài kiểm tra.
• Nhiều bài kiểm tra với thực hiện tương tự . Điều quan trọng cần lưu ý là nếu các xác nhận khác nhau, chúng sẽ kiểm tra không trùng lặp. Tuy nhiên, đây sẽ là sự khôn ngoan thông thường của một nhóm tập trung TDD.

Tôi không có suy nghĩ nghiêm ngặt rằng chỉ có thể có một asserttuyên bố trong bài kiểm tra của bạn, nhưng tôi đưa ra các hạn chế rằng tất cả các khẳng định nên kiểm tra các điều kiện hậu của một hành động. Nếu sự khác biệt duy nhất giữa các bài kiểm tra là dữ liệu, thì tôi sẽ nghĩ đến việc sử dụng các tính năng kiểm tra hướng dữ liệu nâng cao hơn như kiểm tra tham số hoặc lý thuyết.

Cân nhắc các lựa chọn của bạn để quyết định kết quả tốt nhất là gì. Tôi sẽ nói rằng "WorksAsExpectedWhenNull" về cơ bản khác với bất kỳ trường hợp nào bạn đang xử lý một bộ sưu tập có số lượng phần tử khác nhau.

Đó là những trường hợp thử nghiệm khác nhau, nhưng mã cho thử nghiệm là như nhau. Do đó sử dụng các bài kiểm tra tham số là giải pháp tốt nhất. Nếu khung thử nghiệm của bạn không hỗ trợ tham số hóa, hãy trích xuất mã được chia sẻ thành hàm trợ giúp và gọi nó từ các trường hợp thử nghiệm riêng lẻ.

Cố gắng tránh tham số hóa thông qua một vòng lặp trong một trường hợp thử nghiệm, vì điều đó gây khó khăn cho việc xác định tập dữ liệu nào gây ra lỗi.

Trong chu trình tái cấu trúc xanh của TDD red kèm theo, bạn nên thêm một dữ liệu mẫu vào một thời điểm. Kết hợp nhiều trường hợp thử nghiệm vào một thử nghiệm tham số sẽ là một phần của bước tái cấu trúc.

Một cách tiếp cận khá khác nhau là thử nghiệm tài sản . Bạn sẽ tạo các thử nghiệm khác nhau (tham số hóa) để xác nhận các thuộc tính khác nhau của chức năng của bạn, mà không chỉ định dữ liệu đầu vào cụ thể. Ví dụ: một thuộc tính có thể là: cho tất cả các danh sách xs, danh sách ys = f(xs)có cùng độ dài như xs. Khung kiểm tra sau đó sẽ tạo ra các danh sách thú vị và danh sách ngẫu nhiên và khẳng định rằng các thuộc tính của bạn giữ cho tất cả chúng. Điều này tránh xa các ví dụ chỉ định thủ công, vì các ví dụ chọn thủ công có thể bỏ lỡ các trường hợp cạnh thú vị.

Có một bài kiểm tra cho mỗi trường hợp là phù hợp bởi vì kiểm tra một khái niệm duy nhất trong mỗi bài kiểm tra là một hướng dẫn tốt thường được đề xuất.

Xem bài đăng này: Có ổn không khi có nhiều khẳng định trong một bài kiểm tra đơn vị? . Có một cuộc thảo luận chi tiết và có liên quan ở đó:

Hướng dẫn của tôi thường là bạn kiểm tra một Ý TƯỞNG logic cho mỗi bài kiểm tra. bạn có thể có nhiều khẳng định trên cùng một đối tượng. chúng thường sẽ là cùng một khái niệm đang được thử nghiệm. Nguồn - Roy Osherove

[...]

Các thử nghiệm chỉ thất bại vì một lý do duy nhất, nhưng điều đó không phải lúc nào cũng có nghĩa là chỉ nên có một tuyên bố Khẳng định. IMHO điều quan trọng hơn là phải giữ mẫu "Sắp xếp, Hành động, Khẳng định".

Điều quan trọng là bạn chỉ có một hành động, và sau đó bạn kiểm tra kết quả của hành động đó bằng cách sử dụng các xác nhận. Nhưng đó là "Sắp xếp, Hành động, Khẳng định, Kết thúc thử nghiệm". Nếu bạn muốn tiếp tục thử nghiệm bằng cách thực hiện một hành động khác và nhiều xác nhận sau đó, hãy thực hiện thử nghiệm riêng thay thế. Nguồn

Theo tôi nghĩ, nó phụ thuộc vào điều kiện thử nghiệm.

• Nếu thử nghiệm của bạn chỉ có 1 điều kiện để thiết lập thử nghiệm, nhưng nhiều tác dụng phụ. đa khẳng định là chấp nhận được.
• Nhưng khi bạn có nhiều điều kiện, có nghĩa là bạn có nhiều trường hợp kiểm tra, mỗi trường hợp chỉ được bao phủ bởi 1 bài kiểm tra đơn vị.