Có giá trị trong thử nghiệm đơn vị tự động thực hiện các thuộc tính

Question

Có vẻ như bàn tay nặng đặc biệt nhưng đi theo quy tắc mọi thứ có sẵn công khai cần được kiểm tra nên auto-implemented properties được kiểm tra?

lớp khách hàng

public class Customer 
{ 
    public string EmailAddr { get; set; } 
} 

Tested by

[TestClass] 
public class CustomerTests : TestClassBase 
{ 
    [TestMethod] 
    public void CanSetCustomerEmailAddress() 
    { 
     //Arrange 
     Customer customer = new Customer(); 

     //Act 
     customer.EmailAddr = "foo@bar.com"; 

     //Assert 
     Assert.AreEqual("foo@bar.com", customer.EmailAddr); 
    } 
} 

Answer 1

Điều gì sẽ xảy ra nếu bạn chuyển từ thuộc tính được tự động triển khai sang một tính năng hoàn toàn khác? Bài kiểm tra chỉ có vẻ thừa vì bạn biết việc triển khai - bạn không nên cân nhắc khi viết bài kiểm tra.

Tất nhiên, điều này tùy thuộc vào khả năng bạn thực sự thay đổi triển khai bất kỳ lúc nào.

Answer 2

Nó phụ thuộc nếu bạn đang thử nghiệm mà một API phù hợp với một bộ dự kiến ​​của tài sản, hoặc nếu như bạn chứng minh , bạn chỉ đang thử nghiệm truy cập và thiết lập các thuộc tính.

Trong ví dụ bạn cho tôi muốn nói không.

Cập nhật

Phù hợp với API dự kiến; nếu bạn đang truy cập các thuộc tính gián tiếp, hãy nói trong môi trường phản chiếu/động và bạn sử dụng các cuộc gọi truy cập thuộc tính và phương thức để xác minh một API không xác định phù hợp với một API được mong đợi.

Answer 3

Tôi thường xem xét bất kỳ mã nào không thực hiện hành động không đáng để thử nghiệm. Điều này thường có nghĩa là tôi không kiểm tra các thuộc tính (tự động triển khai hay không) vì chúng chỉ là thiết lập hoặc trả về một giá trị. Điều này sẽ thay đổi nếu getter hoặc setter của một tài sản thực hiện một số loại "công việc", giống như có thể trả lại một trong hai (hoặc nhiều hơn) các giá trị dựa trên trạng thái của một số lĩnh vực khác/tài sản/bất cứ điều gì.

Nếu bạn chưa xem, tôi khuyên bạn nên Roy Osherove'sbook on Unit Testing. Nó giải quyết tất cả các loại câu hỏi "cần kiểm tra và khi nào", bao gồm câu hỏi này.

Answer 4

Kiểm tra đơn vị phải được giới hạn trong chức năng thử nghiệm mà bạn đang triển khai trong ứng dụng của mình.

Bạn không nên kiểm tra API/SDK mà ứng dụng của bạn dựa vào. Một phần bởi vì đó là một sự lãng phí thời gian (công ty của bạn có muốn trả tiền cho bạn để kiểm tra SDK/API của X-Third-Party không?), Và một phần vì nó giới thiệu "tiếng ồn" vào bộ thử nghiệm đơn vị của bạn. Ngữ cảnh của thư viện kiểm thử đơn vị của bạn nên chỉ kiểm tra mã trong ứng dụng của bạn.

Answer 5

Cài đặt thử nghiệm và nhận các thuộc tính sẽ xảy ra trong bối cảnh kiểm tra chức năng kinh doanh của đối tượng. Nếu không có chức năng kinh doanh nào kiểm tra thuộc tính thì bạn không cần tài sản hoặc bạn cần thêm thử nghiệm. Tôi khuyên bạn nên thêm các thuộc tính khi bạn thêm các bài kiểm tra cần chúng thay vì thêm chúng trước khi viết bất kỳ bài kiểm tra nào.

Bằng cách kiểm tra chức năng kinh doanh, bạn đang xử lý mã nhiều hơn một hộp đen từ phối cảnh của kiểm tra đơn vị. Điều này cho phép bạn chuyển đổi chi tiết triển khai bên dưới với tác động nhỏ hơn nhiều đối với các thử nghiệm.Khi Refactor là một giai đoạn quan trọng (và thường bị bỏ qua) của chu kỳ TDD, điều này có nghĩa là việc chỉnh sửa mã ít hơn rất nhiều. Bạn cũng có thể nhận ra rằng (ví dụ) tài sản không nên có một setter công cộng và nên được chỉ định bởi một phương thức thực hiện xác nhận hợp lệ và logic kinh doanh khác.