Tôi có thói quen luôn cố gắng phân biệt mã cấp độ ứng dụng với mã cấp khung, vì vậy tôi đã gặp phải vấn đề mà bạn đang mô tả khá thường xuyên: bạn thường muốn tất cả mã cấp độ khung được kiểm tra trước khi bất kỳ mã cấp độ ứng dụng nào bắt đầu được kiểm tra . Ngoài ra, ngay cả trong mã cấp khung, có xu hướng có một số mô-đun khung cơ bản được sử dụng bởi tất cả các mô-đun khung khác, và nếu có lỗi trong nguyên tắc cơ bản, thực sự không có điểm nào trong việc kiểm tra bất cứ điều gì khác.
Thật không may, các nhà cung cấp khung thử nghiệm có xu hướng có những ý tưởng hơi cứng nhắc về cách sử dụng sáng tạo của họ, và khá bảo vệ những ý tưởng đó, trong khi những người sử dụng khung của họ có xu hướng chấp nhận mục đích sử dụng mà không cần hỏi. Đây là vấn đề, bởi vì nó kìm hãm thử nghiệm và đổi mới. Tôi không biết về những người khác, nhưng tôi thích tự do thử làm điều gì đó một cách kỳ quặc và tự mình xem liệu kết quả tốt hơn hay xấu hơn so với cách đã được thiết lập, thay vì không có quyền tự do làm mọi thứ theo cách của tôi ở nơi đầu tiên.
Vì vậy, theo tôi, sự phụ thuộc kiểm tra sẽ là một điều tuyệt vời cần có, và thay vào đó, khả năng chỉ định thứ tự thực hiện các bài kiểm tra sẽ là điều tốt nhất tiếp theo.
Cách duy nhất tôi tìm thấy để giải quyết vấn đề đặt hàng thử nghiệm là đặt tên cẩn thận, để khai thác xu hướng của khung thử nghiệm để thực hiện thử nghiệm theo thứ tự bảng chữ cái.
Tôi không biết làm thế nào điều này hoạt động trong Visual Studio, vì tôi chưa làm gì liên quan đến thử nghiệm rộng rãi với C #, nhưng ở phía Java của thế giới, nó hoạt động như sau: Trong thư mục nguồn của dự án, chúng tôi thường có hai thư mục con, một cái gọi là "chính", chứa mã sản xuất và một cái gọi là "thử nghiệm", chứa mã thử nghiệm. Trong "chính", chúng tôi có một hệ thống phân cấp thư mục tương ứng chính xác với hệ thống phân cấp gói của mã nguồn của chúng tôi. Các gói Java gần tương ứng với các không gian tên C #. C # không yêu cầu bạn khớp phân cấp thư mục với phân cấp không gian tên, nhưng nên làm như vậy.
Bây giờ, những gì mọi người thường làm trong thế giới Java là trong thư mục "test", họ phản ánh hệ thống phân cấp thư mục được tìm thấy trong thư mục "chính", để mỗi thử nghiệm nằm trong cùng một gói chính xác như lớp mà nó kiểm tra. Lý do đằng sau điều này là khá thường xuyên lớp thử nghiệm cần truy cập các thành viên gói riêng của lớp đang thử nghiệm, vì vậy lớp thử nghiệm cần phải nằm trong cùng gói với lớp được thử. Ở phía C # của thế giới không có thứ gọi là khả năng hiển thị không gian tên cục bộ, vì vậy không có lý do gì để phản ánh hệ thống phân cấp thư mục, nhưng tôi nghĩ rằng các lập trình viên C # ít nhiều tuân theo cùng một quy tắc trong việc cấu trúc các thư mục của họ.
Trong mọi trường hợp, tôi thấy toàn bộ ý tưởng này cho phép các lớp kiểm tra có quyền truy cập vào các thành viên gói cục bộ của các lớp được kiểm tra sai, bởi vì tôi có xu hướng kiểm tra các giao diện, không phải triển khai. Vì vậy, hệ thống phân cấp thư mục của các thử nghiệm của tôi không phải phản ánh phân cấp thư mục của mã sản xuất của tôi.
Vì vậy, những gì tôi làm là tôi đặt tên cho các thư mục (nghĩa là các gói) của các thử nghiệm của tôi như sau:
t001_SomeSubsystem
t002_SomeOtherSubsystem
t003_AndYetAnotherSubsystem
...
Điều này đảm bảo rằng tất cả các thử nghiệm cho "Một số hệ thống" sẽ được thực hiện trước tất cả các thử nghiệm cho "Một số hệ thống khác", tất cả các thử nghiệm sẽ được thực hiện trước tất cả các thử nghiệm cho "AndYetAnotherSubystem", v.v.
Trong một thư mục, các tệp thử nghiệm riêng lẻ được đặt tên như sau:
T001_ThisTest.java
T002_ThatTest.java
T003_TheOtherTest.java
Tất nhiên, điều đó giúp ích rất nhiều cho các IDE hiện đại có khả năng tái cấu trúc mạnh mẽ cho phép bạn đổi tên toàn bộ các gói (và tất cả các gói phụ và tất cả các mã tham chiếu đến chúng) chỉ bằng vài cú nhấp chuột và tổ hợp phím.