5

Tôi bắt đầu phát triển và tổ chức các bài kiểm tra cho một giải pháp Visual Studio rất lớn. (Có, tôi biết rằng các bài kiểm tra nên được phát triển cùng với mã thay vì khi dự án gần hoàn thành, nhưng mọi thứ là như vậy.)Đơn vị/Tổ chức kiểm tra tích hợp trong một giải pháp Visual Studio lớn

Tôi đã nhìn thấy các câu hỏi tương tự về tổ chức các bài kiểm tra đơn vị trong các giải pháp Visual Studio , nhưng tôi cũng không thấy bất kỳ bài kiểm tra tích hợp địa chỉ nào. Tôi sẽ đánh giá cao một số hướng dẫn về nơi để đặt dự án thử nghiệm để họ không lộn xộn lên cơ sở mã đã lớn.

Đây là thứ bậc cơ bản của sự vật trong giải pháp. (Tất cả các mục không kết thúc bằng .proj là thư mục bên trong một dự án hoặc giải pháp Folders.)

  • HardwareServices
    • HardwareService1
      • HardwareService1.Core.proj
      • HardwareService1.Host.proj
      • HardwareService1.Service.proj
    • HardwareService2
      • HardwareService2.Core.proj
      • HardwareService2.Host.proj
      • HardwareService2.Service.proj
  • Cơ sở hạ tầng
    • MyApp.Database.proj
    • MyApp.Infrastructure .proj
    • MyApp.ReportViewer.proj
    • MyApp.SettingsManager.proj
  • AppModules
    • AppModule1.proj
      • Common
      • Báo cáo
      • Dịch vụ
      • ViewModels
      • Lần
    • AppModule2.proj (cấu trúc tương tự như AppModules khác)
    • AppModule3.proj (cấu trúc tương tự như AppModules khác)
  • Modules
    • ComputeEngine.proj
    • Footer.proj
    • Header.proj
    • CommonServices.Proj

suy nghĩ của tôi là để tạo ra một thư mục Giải pháp gọi là "thử nghiệm" và sau đó bắt chước hệ thống phân cấp trên, làm cho một dự án thử nghiệm cho mỗi dự án mã sản xuất. Trong mỗi dự án thử nghiệm, tôi sẽ tạo các thư mục có tên là "UnitTests" và "IntegrationTests".

Mục tiêu của tôi là tạo một lược đồ đặt tên/tổ chức nhất quán để không có sự mơ hồ về nơi các thử nghiệm mới nên đi đến đâu và tìm các bài kiểm tra hiện có ở đâu. Với quy mô lớn của dự án/ứng dụng này, tôi muốn có được cấu trúc khá chắc chắn ngay ra khỏi cổng để nó không phải là một cơn đau sau này.

Cảm ơn bạn đã dành thời gian và lời khuyên.

Trả lời

2

Quy ước đặt tên mà công ty chúng tôi đã thông qua là sử dụng projectName.Tests.UnitprojectName.Tests.Integration.

Với cấu trúc hiện có của bạn, bạn sẽ có một cái gì đó như thế này:

  • HardwareService1
    • HardwareService1.Core.proj
    • HardwareService1.Host.proj
    • HardwareService1.Service.proj
    • Kiểm tra
      • HardwareService1.Core .Tests.Unit
      • HardwareService1.Core.Tests.Integration

Nếu bạn giữ thư mục kiểm tra của bạn cùng với thư mục gốc bạn không cần phải bắt chước cấu trúc hoàn chỉnh một lần nữa như kiểm tra phù hợp với dự án tương ứng.

mặt lưu ý

Bởi có tên dự án có một nhất quán Tests.Unit nó giúp hỗ trợ cho việc chạy thử nghiệm đơn vị trong xây dựng kịch bản của bạn khi bạn có thể chạy thử nghiệm với một tìm kiếm thẻ hoang dã như **\*tests.unit*.dll

Vào cuối ngày, cấu trúc dự án có thể rất chủ quan để làm những gì có ý nghĩa trong môi trường của bạn và có ý nghĩa với nhóm của bạn.

+0

Đó là cách khác mà tôi đã thấy được đề xuất (giữ các thử nghiệm với dự án). Tôi đoán sẽ có tương ứng HardwareServices1.Core.Tests.Unit.proj và HardwareServices1.Core.Tests.Integration.proj trong thư mục "Tests" trong ví dụ của bạn ở trên, phải không? – geoffmazeroff

+0

Có thể sẽ đúng nếu các dự án Host/Service đó cần các bài kiểm tra Đơn vị/Tích hợp. –

+0

Cảm ơn, @Mark. Tôi nghĩ rằng nhóm nghiên cứu rất quen thuộc với những thứ trong giải pháp, việc giữ các bài kiểm tra với chính mã đó giúp cho việc tìm kiếm dễ dàng hơn. – geoffmazeroff

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