Testing Di phương pháp mà không một lời kêu gọi bổ sung phương thức

Question

Tôi viết thử nghiệm cho một thats lớp quản lý cây của các đối tượng Tag:

public class Tag 
{ 
    public virtual int Id { get; set; } 
    public virtual string Description{ get; set; } 
    private IList<Tag> children = new List<Tag>(); 
    public virtual IEnumerable<Tag> Children 
    { 
     get {return children .ToArray();} 
    } 
    public void AddChildTag(Tag child) 
    { 
     children.Add(child); 
    } 
    public void RemoveChildTag(Tag child) 
    { 
     children.Remove(child); 
    } 
} 

Như bạn có thể thấy phương thức duy nhất để thiết lập thuộc tính cha mẹ là thông qua phương pháp AddChildTag và điều này là chính xác những gì tôi muốn, vấn đề của tôi là trong thử nghiệm đơn vị: vì mọi thử nghiệm nên là nguyên tử, làm thế nào tôi có thể thử nghiệm phương pháp RemoveChildTag?

Chỉ cách tôi thấy là một cuộc gọi đến phương thức thêm và sau đó để loại bỏ, nhưng theo cách này nếu Thêm dưới dạng một số lỗi, ngay cả khi kiểm tra xóa sẽ không thành công, do đó nguyên tử bị mất.

Làm cách nào để thực hiện điều đó?

EDIT
Tôi đã gỡ bỏ tài sản cha mẹ từ đối tượng Tag, kể từ khi tôi không sử dụng nó Một số thử nghiệm theo giải pháp sử dụng NUnit và FluentAssertion

[Test] 
    public void AddChildTagAddsChildren() 
    { 
     //Arrange 
     Tag parent = new Tag(); 
     Tag child = new Tag(); 
     //Act 
     parent.AddChildTag(child); 
     //Assert 
     parent.Children.Should().Contain(child); 
    } 
    [Test] 
    public void RemoveChildTagRemovesAddedChildren() 
    { 
     //Arrange 
     Tag parent = new Tag(); 
     Tag child = new Tag(); 
     parent.AddChildTag(child); 
     //Act 
     parent.RemoveChildTag(child); 
     //Assert 
     parent.Children.Should().NotContain(child); 
    } 
    [Test] 
    public void RemoveChildTagThrowsNothingWhenNoChild() 
    { 
     //Arrange 
     Tag parent= new Tag(); 
     Tag child= new Tag(); 
     //Act 
     Action RemoveChild =() => parent.RemoveChildTag(child); 
     //Assert 
     RemoveChild.ShouldNotThrow(); 
    } 

Answer 1

Bài kiểm tra đơn vị của bạn phải phản ánh các trường hợp sử dụng thực tế của lớp học của bạn. Người tiêu dùng của bạn sẽ sử dụng phương pháp RemoveChildTag như thế nào? Điều gì có ý nghĩa hơn? Đó là cách bạn muốn sử dụng bộ sưu tập các đối tượng?

var parent = new Tag(); 
// later 
parent.RemoveChildTag(child); 

... hoặc

var parent = new Tag(); 
parent.AddChildTag(child); 
// later 
parent.RemoveChildTag(child); 

người tiêu dùng của bạn sẽ loại bỏ đối tượng họ trước thêm. Đây là trường hợp sử dụng của bạn, "Xóa các yếu tố xóa trước đây" (lưu ý rằng nó cũng tạo ra tên phương pháp thử nghiệm tuyệt vời).

Add và Remove các phương pháp thường bổ sung - bạn không thể kiểm tra cái này mà không có phương pháp khác.

Answer 2

Có một số cách để kiểm tra phương pháp Remove:

1. Mocking - giả lập cấu trúc dữ liệu của bạn và gọi loại bỏ, vì vậy bạn có thể thử nghiệm gọi đúng phương thức
2. Thừa kế - tạo children được bảo vệ. Lớp kiểm tra của bạn sẽ được kế thừa từ lớp Tag. Bây giờ bạn có thể init children thành viên vì vậy chúng tôi có thể kiểm tra loại bỏ
3. Sử dụng Add Phương pháp

Tôi nghĩ tùy chọn 3 là tốt nhất, nó là ok sử dụng các phương pháp khác trong kiểm tra đơn vị của bạn, nếu Add có một số lỗi, nhiều hơn thì 1 kiểm tra sẽ không thành công - bạn sẽ có thể hiểu những gì bạn cần sửa.

Ngoài ra, mỗi bài kiểm tra đơn vị nên kiểm tra một số hành vi cơ bản, ngay cả khi bạn cần chuẩn bị trước. Nếu những chuẩn bị thất bại, thất bại trong thử nghiệm với những ý kiến ​​có liên quan

Lựa chọn 1 - là tốt nhất khi bạn đang đạt đến bên thứ 3 - máy chủ khác, hệ thống tập tin hơn &. Vì bạn không muốn thực hiện các cuộc gọi đó trong thử nghiệm đơn vị - giả lập phản hồi.

Tùy chọn 2 - tốt nhất tôi có thể nói, là khi bạn muốn thử nghiệm phương pháp được bảo vệ/riêng tư, mà không cần thực hiện tất cả cuộc gọi "trên đường" mà mã của bạn thực hiện (phương pháp công khai thực hiện nhiều cuộc gọi gọi phương thức bạn muốn kiểm tra), vì bạn chỉ muốn kiểm tra một logic cụ thể. Nó cũng dễ sử dụng tùy chọn này khi lớp của bạn có một số trạng thái mà bạn muốn kiểm tra, mà không cần phải viết nhiều mã để đưa lớp của bạn đến trạng thái này.

Answer 3

Bạn có thể sử dụng một PrivateObject Class để Sắp xếp đối tượng của bạn được kiểm tra

Cho phép mã kiểm tra để gọi các phương thức và thuộc tính trên mã theo thử nghiệm rằng không thể tiếp cận, vì họ là không được công khai.

EDIT

sau đó bạn có thể nhận được quyền truy cập đầy đủ đến đối tượng bọc bởi PrivateObject.RealType và PrivateObject.Target Thuộc tính

EDIT

Dù sao, mỗi hệ thống mà phá vỡ sự phân chia và đóng gói của một lớp làm cho vô dụng cách tiếp cận hộp đen của bài kiểm tra đơn vị trong TDD và nên tránh như một chất độc :)

Answer 4

Cách tiếp cận phổ biến để thử nghiệm đơn vị là mô hình Sắp xếp-Hành động-Xác thực.

Cá nhân tôi sẽ có hai bài kiểm tra cho phương pháp xóa, một phương pháp xóa một đứa trẻ chưa bao giờ được thêm vào, điều gì sẽ xảy ra? Có nên ném ngoại lệ không?

này sẽ như thế nào:

[Test] 
public void RemoveChildTagThrowsExceptionWhenNoChildren() 
{ 
    // Arrange 
    var tag = new Tag(); 
    var tagToRemove = new Tag(); 

    // Act & Assert 
    Expect(() => tag.RemoveChildTag(tagToRemove), Throws.ArgumentException); 
} 

Sau đó, tôi sẽ có một bài kiểm tra cho những gì sẽ xảy ra khi một đứa trẻ thêm được lấy ra:

[Test] 
public void RemoveChildTagRemovesPreviouslyAddedChild() 
{ 
    // Arrange 
    var tag = new Tag(); 
    var childTag = new Tag(); 
    tag.AddChildTag(childTag); 

    // Act 
    tag.RemoveChildTag(childTag); 

    // Assert 
    Expect(tag.Children.Contains(childTag), Is.False); 
} 

Nó có thể quan tâm cần lưu ý rằng khá rất nhiều triển khai .NET Remove trả về kết quả bool cho biết liệu có thực hiện bất kỳ thao tác xóa nào thực sự không. Xem here.