Cách sử dụng của Assert.Inconclusive

Question

Tôi tự hỏi làm thế nào ai đó nên sử dụng Assert.Inconclusive().

Tôi đang sử dụng nếu thử nghiệm đơn vị của tôi sắp thất bại vì lý do khác với lý do thử nghiệm.

Ví dụ, tôi có một phương thức trên một lớp tính tổng của một mảng int. Trên cùng một lớp, cũng có một phương pháp để tính trung bình của phần tử. Nó được thực hiện bằng cách gọi tổng và chia nó theo chiều dài của mảng.

Viết một bài kiểm tra Đơn vị cho Tổng() rất đơn giản. Tuy nhiên, khi tôi viết một bài kiểm tra cho Average(), và Sum() không thành công, thì Average() cũng có khả năng thất bại.

Thất bại của Trung bình không rõ ràng về lý do không thành công; nó không thành công vì lý do nào khác ngoài lý do nó nên thử nghiệm. Đó là lý do tại sao tôi sẽ kiểm tra xem Sum() trả về kết quả chính xác, nếu không tôi Assert.Inconclusive().

Đây có phải là thực tiễn tốt không? Assert.Inconclusive dành cho mục đích gì? Hay tôi nên giải thích ví dụ trước bằng phương pháp Khung cách ly?

Answer 1

Khi tôi sử dụng VS để tạo các bài kiểm tra đơn vị, tôi đã nhận Assert.Đối với các phương pháp thử được tạo và thường tôi thay đổi xác nhận để một điều gì đó khác khi tôi làm việc. Tôi sử dụng các dấu hỏi của Assert.Inconclusive trong kết quả kiểm tra như là dấu hiệu để nhanh chóng cho tôi biết những thử nghiệm mà tôi chưa hoàn thành.

Vâng, đó chỉ là cách tôi sử dụng nó. Từ tên của nó "Không kết luận", tôi đoán bạn có thể sử dụng để cho biết trạng thái không xác định của bạn miễn là bạn ghi lại ý nghĩa của nó. Tuy nhiên, từ mô tả phương pháp Average() của bạn, tôi nghĩ rằng có lẽ thử nghiệm đơn vị của bạn không đủ nguyên tử để chỉ bao gồm một "đơn vị", một trường hợp cụ thể. Đôi khi, tôi viết 2 hoặc 3 phương pháp thử nghiệm đơn vị cho một phương pháp duy nhất. Hoặc bạn có thể phá vỡ phương pháp Average() của bạn để các phương pháp nhỏ hơn bao gồm các trách nhiệm duy nhất. Bằng cách đó, bạn có thể kiểm tra đơn vị những phương pháp nhỏ hơn trước khi kiểm tra đơn vị bạn Average() một.

---

Johannes,

Đây là cách tôi sẽ thực hiện các phương pháp Sum() và Average().

public static class MyMath 
{ 
    private static void ValidateInput(ICollection<int> numbers) 
    { 
     if (numbers == null) 
      throw new ArgumentNullException("numbers", "Null input. Nothing to compute!"); 
     if (numbers.Count == 0) 
      throw new ArgumentException("Input is empty. Nothing to compute!"); 
    } 

    public static int Sum(int[] numbers) 
    { 
     ValidateInput(numbers); 

     var total = 0; 
     foreach (var number in numbers) 
      total += number; 

     return total; 
    } 

    public static double Average(int[] numbers) 
    { 
     ValidateInput(numbers); 
     return Sum(numbers)/numbers.Length; 
    } 
} 

Để đơn giản, tôi chỉ ném ArgumentException ngoại lệ từ phương pháp ValidateInput(ICollection<int>). Bạn cũng có thể kiểm tra khả năng tràn và ném OverflowException theo phương pháp ValidateInput(ICollection<int>).

Với điều đó đã nói, đây là cách tôi sẽ kiểm tra chức năng Average(int[]).

[TestMethod] 
public void AverageTest_GoodInput() 
{ 
    int[] numbers = {1, 2, 3}; 
    const double expected = 2.0; 
    var actual = MyMath.Average(numbers); 
    Assert.AreEqual(expected, actual); 
} 

[TestMethod] 
[ExpectedException(typeof(ArgumentNullException))] 
public void AverageTest_NullInput() 
{ 
    int[] numbers = null; 
    MyMath.Average(numbers); 
} 

[TestMethod] 
[ExpectedException(typeof(ArgumentException))] 
public void AverageTest_EmptyInput() 
{ 
    var numbers = new int[0]; 
    MyMath.Average(numbers); 
} 

Với các bài kiểm tra này, tôi có thể chắc chắn rằng khi tất cả các bài kiểm tra vượt qua, chức năng của tôi là chính xác. Vâng, ngoại trừ trường hợp tràn. Bây giờ tôi có thể quay trở lại phương pháp ValidateInput(ICollection<int>) để thêm logic để kiểm tra tràn, sau đó thêm một thử nghiệm khác để mong đợi các OverflowException được ném cho loại đầu vào gây ra tràn. Hoặc làm theo thứ tự ngược lại nếu bạn muốn tiếp cận bằng TDD.

Tôi hy vọng điều này sẽ giúp làm sáng tỏ ý tưởng.

Answer 2

Tôi chỉ Khẳng định.Kết quả về các bài kiểm tra đơn vị mà tôi chưa viết. Đôi khi khi viết một cái gì đó tôi nhận ra một số trường hợp góc mà tôi không muốn bỏ lỡ. Vì vậy, tôi nhanh chóng nhảy qua, viết phương pháp thử nghiệm với một tên mô tả và thêm một dòng duy nhất của Assert.Inconclusive.

Lý do để làm điều này là nó cung cấp tài liệu về những thứ tôi cần kiểm tra mà không làm gián đoạn luồng công việc của mình quá nhiều. Nó cũng làm cho nó có thể lọc ra thất bại kiểm tra một cách nhanh chóng trong danh sách kết quả. Có một thất bại không xác định có nghĩa là tôi đã không bị hỏng bất cứ điều gì tôi chỉ cần thử nghiệm nhiều hơn để viết.

Answer 3

Kiểm tra không kết thúc là một thử nghiệm mà bạn không thể xác định kết quả. Ví dụ: nếu bạn có thử nghiệm sử dụng một loại tài nguyên bên ngoài nào đó (ví dụ: kết nối Internet). Nếu kết nối hiện không có sẵn, điều này không thực sự có nghĩa là thử nghiệm là một thất bại. Mặt khác, bạn không nên chỉ đánh dấu nó là thành công mà không thực sự chạy nó thông qua. Vì vậy, bạn đánh dấu nó là không thuyết phục và điều này có thể được nhìn thấy trong báo cáo thử nghiệm.

LƯU Ý: Nói chung, bạn không nên sử dụng các tài nguyên bên ngoài như vậy trong các bài kiểm tra của mình, vì điều này có thể làm cho các bài kiểm tra trở nên mong manh.

Đối với các thử nghiệm chưa hoàn thành, tôi sử dụng thuộc tính Explicit của MbUnit.

Answer 4

Assert.Inconclusive chỉ ra rằng một trong hai:

tôi chưa viết bài kiểm tra, tôi đã chỉ tạo ra các phương pháp thử nghiệm

-hoặc-

thử nghiệm của tôi có một sự phụ thuộc và sự phụ thuộc đó không có sẵn. Ví dụ:

List<Customer> custs = o.GetAllCustomers(); 
if (custs.Count == 0) 
{ 
    Assert.Inconclusive("No customers to test"); 
    return; 
}