Làm thế nào để tổ chức kiểm tra đơn vị và không thực hiện tái cấu trúc một cơn ác mộng?

Question

Cách kiểm tra đơn vị tổ chức hiện tại của tôi tóm tắt như sau:

• Mỗi dự án có dự án riêng của mình với các bài kiểm tra đơn vị. Đối với một dự án BusinessLayer, có một dự án thử nghiệm BusinessLayer.UnitTests.
• Đối với mỗi lớp tôi muốn kiểm tra, có một lớp kiểm tra riêng biệt trong dự án thử nghiệm được đặt chính xác cùng cấu trúc thư mục và trong cùng một không gian tên giống như lớp đang được kiểm tra. Đối với một lớp học CustomerRepository từ một không gian tên BusinessLayer.Repositories, có một lớp thử nghiệm CustomerRepositoryTests trong một không gian tên BusinessLayerUnitTests.Repositories.

Phương pháp trong mỗi lớp thử theo quy ước đặt tên đơn giản MethodName_Condition_ExpectedOutcome. Vì vậy, các lớp CustomerRepositoryTests chứa thử nghiệm cho một lớp CustomerRepository với một phương pháp Get định nghĩa trông giống như sau:

[TestFixture] 
public class CustomerRepositoryTests 
{ 
    [Test] 
    public void Get_WhenX_ThenRecordIsReturned() 
    { 
     // ... 
    } 

    [Test] 
    public void Get_WhenY_ThenExceptionIsThrown() 
    { 
     // ... 
    } 
} 

Cách tiếp cận này đã phục vụ tôi khá tốt, bởi vì nó làm cho việc định vị các bài kiểm tra đối với một số đoạn mã thực sự đơn giản. Trên trang đối diện, nó làm cho việc tái cấu trúc mã thực sự khó khăn hơn sau đó nó phải là:

• Khi tôi quyết định chia dự án thành nhiều dự án nhỏ hơn, tôi cũng cần chia dự án thử nghiệm của mình.
• Khi tôi muốn thay đổi không gian tên của một lớp, tôi phải nhớ thay đổi không gian tên (và cấu trúc thư mục) của một lớp thử nghiệm.
• Khi tôi thay đổi tên của một phương pháp, tôi phải trải qua tất cả các bài kiểm tra và thay đổi tên ở đó. Chắc chắn, tôi có thể sử dụng Tìm kiếm & Thay thế, nhưng điều đó không đáng tin cậy lắm. Cuối cùng, tôi vẫn cần kiểm tra các thay đổi theo cách thủ công.

Có một số cách thông minh của tổ chức kiểm tra đơn vị đó vẫn sẽ cho phép tôi để xác định vị trí thử nghiệm cho một mã cụ thể một cách nhanh chóng và đồng thời bản thân cho vay nhiều hơn đối với refactoring?

Ngoài ra, có một số người, uh, có lẽ Studio mở rộng Visual, mà sẽ cho phép tôi để bằng cách nào đó nói rằng "hey, những xét nghiệm này cho rằng phương pháp, vì vậy khi tên của những thay đổi phương pháp, hãy nên loại và thay đổi các bài kiểm tra là tốt "? Thành thật mà nói, tôi đang nghiêm túc xem xét để viết một cái gì đó như thế bản thân mình :)

Answer 1

Sau khi làm việc rất nhiều với các bài kiểm tra, tôi đã nhận ra rằng (ít nhất là đối với tôi) có tất cả những hạn chế mang lại rất nhiều vấn đề trong thời gian dài, chứ không phải là những điều tốt đẹp. Vì vậy, thay vì sử dụng "Tên" và các quy ước để xác định điều đó, chúng tôi đã bắt đầu sử dụng mã. Mỗi dự án và mỗi lớp có thể có bất kỳ số lượng các dự án thử nghiệm và các lớp kiểm tra. Tất cả các mã thử nghiệm được tổ chức dựa trên những gì đang được thử nghiệm từ một quan điểm chức năng (hoặc yêu cầu nó thực hiện, hoặc lỗi mà nó sao chép, vv ...). Sau đó cho việc tìm kiếm các bài kiểm tra cho một đoạn mã chúng ta làm điều này:

[TestFixture] 
public class MyFunctionalityTests 
{ 
    public IEnumerable<Type> TestedClasses() 
    { 
     // We can find the tests for a class, because the test cases references in some special method. 
     return new []{typeof(SomeTestedType), typeof(OtherTestedType)}; 
    } 

    [Test] 
    public void TestRequirement23423432() 
    { 
     // ... test code. 
     this.TestingMethod(someObject.methodBeingTested); //We do something similar for methods if we want to track which methods are being tested (we usually don't) 
     // ... 
    } 
} 

Chúng ta có thể sử dụng các công cụ như resharper "tập quán" để tìm các trường hợp kiểm tra, vv ... Và khi điều đó là chưa đủ, chúng ta làm một số ma thuật bằng cách phản ánh và LINQ bằng cách tải tất cả các lớp thử nghiệm, và chạy một cái gì đó như allTestClasses.where(testClass => testClass.TestedClasses().FindSomeTestClasses()); Bạn cũng có thể sử dụng TearDown để thu thập thông tin về phương pháp nào được thử nghiệm theo từng phương pháp/lớp và thực hiện tương tự.

Answer 2

Một dự án thử nghiệm đơn vị cho mỗi dự án là con đường để đi. Chúng tôi đã thử với một dự án thử nghiệm đơn vị lớn nhưng điều này làm tăng thời gian biên dịch.

Để giúp bạn tái cấu trúc sử dụng sản phẩm như resharper hoặc code rush.

Answer 3

Có một số cách thông minh của tổ chức kiểm tra đơn vị mà vẫn sẽ cho phép tôi để xác định vị trí thử nghiệm cho một mã cụ thể một cách nhanh chóng

Resharper có một số vết cắt ngắn tốt cho phép bạn tập tin hoặc mã tìm kiếm

Như bạn đã nói cho lớp CustomerRepository là bài kiểm tra CustomerRepositoryTests

Phím tắt R # hiển thị hộp inpput cho những gì bạn tìm thấy trong trường hợp bạn chỉ có thể nhập CRT và nó sẽ s làm thế nào bạn tất cả các file bắt đầu với tên có đầu tiên như Capital C sau đó R và sau đó T

Nó cũng cho phép bạn tìm kiếm theo thẻ hoang dã như CR * sẽ cho bạn thấy danh sách các tập tin CustomerRepository và CustomerRepositoryTests

Answer 4

Một cách để giữ địa điểm lớp và kiểm tra đồng bộ khi di chuyển mã:

• Move mã để một không gian tên tạm đặt tên duy nhất
• Tìm kiếm tài liệu tham khảo để có không gian tên trong các thử nghiệm của bạn để xác định các xét nghiệm cần phải được di chuyển
• Di chuyển các bài kiểm tra đến vị trí mới phù hợp
• Khi tất cả các tài liệu tham khảo để không gian tên tạm thời từ các bài kiểm tra là ở đúng nơi, sau đó di chuyển mã gốc để mục tiêu dự định của nó

Một sức mạnh của end-to- kết thúc hoặc kiểm tra hành vi là các bài kiểm tra được nhóm theo yêu cầu và không mã, do đó bạn tránh được vấn đề giữ vị trí thử nghiệm đồng bộ với mã tương ứng.

Answer 5

Về các tiện ích mở rộng VS liên kết mã với các kiểm tra, hãy xem Tác động thử nghiệm của Visual Studio. Nó chạy các bài kiểm tra theo một profiler và tạo ra một cơ sở dữ liệu nhỏ gọn để ánh xạ các điểm chuỗi IL tới các bài kiểm tra đơn vị. Vì vậy, nói cách khác, khi bạn thay đổi mã Visual Studio biết cần phải chạy thử nghiệm nào.