Thử nghiệm động khác với thử nghiệm tham số trong JUnit 5 như thế nào?

Question

Hầu như tất cả các ví dụ về các bài kiểm tra động mà tôi đã thấy, có thể được làm lại và viết bằng các bài kiểm tra tham số. Vì vậy, đó là một kịch bản thực tế mà các bài kiểm tra động là lựa chọn duy nhất, hoặc ít nhất, phù hợp hơn so với các bài kiểm tra tham số hóa.

Ví dụ kiểm tra động "thực sự" duy nhất trong tài liệu JUnit 5 là không thực tế.

Bất kỳ ý tưởng nào?

Answer 1

Không giống như DynamicTest, ParameterizedTest không phải là một phần của lõi junit-jupiter-api nhưng là trong một vật riêng biệt có tên junit-jupiter-params (xem 3.12.1. Required Setup). Điều này là do một trong những nguyên tắc cốt lõi của JUnit 5 là "thích các điểm mở rộng hơn các tính năng" (Core Principles · junit-team/junit5 Wiki).

API JUnit Jupiter xác định cách tạo và đăng ký thử nghiệm động làm điểm mở rộng cho JUnit trong khi JUnit Jupiter Params định nghĩa API cấp cao hơn để xác định các thử nghiệm được tham số hóa.

JUnit 5.0 M5 Milestone Chủ đề của hiện tại là "vùng chứa động và thay đổi API nhỏ". Với những thay đổi dự kiến ​​này, các nhà phát triển sẽ không chỉ có thể tạo ra các bài kiểm tra động mà còn là các bài kiểm tra động (các thùng chứa động chứa các thùng chứa và/hoặc kiểm thử động khác). Như vậy sẽ chứng minh, tôi nghĩ, rất hữu ích cho việc tạo ra các bài kiểm tra giống như đặc điểm kỹ thuật. Tóm lại, ý tưởng như tôi hiểu là lần đầu tiên phát hành các điểm mở rộng lõi thông qua các API "cấp thấp" (ví dụ: các thùng chứa/kiểm tra động) và sau đó tạo và khuyến khích các bên thứ ba tạo các tiện ích mở rộng tận dụng chúng (ví dụ: được tham số hóa kiểm tra).