2010-03-06 17 views
8

lớp Ví dụ trong mã giả:cách kiểm tra hoặc mô tả các khả năng vô tận?

class SumCalculator 
    method calculate(int1, int2) returns int 

một cách tốt để kiểm tra điều này là gì? Nói cách khác, tôi nên mô tả hành vi tôi cần như thế nào?

test1: canDetermineSumOfTwoIntegers 

hoặc

test2: returnsSumOfTwoIntegers 

hoặc

test3: knowsFivePlusThreeIsEight 

Test1 và Test2 vẻ mơ hồ và nó sẽ cần phải thử nghiệm một tính toán cụ thể, vì vậy nó không thực sự mô tả những gì đang được thử nghiệm. Tuy nhiên test3 rất hạn chế.

Cách tốt để kiểm tra các lớp học như vậy là gì?

Trả lời

10

tôi sẽ kiểm tra các điều kiện biên (max-int, int min-, zero, tích cực, tiêu cực) và một số trường hợp điển hình:

test1: sumOfPosAndPos 
test2: sumOfPosAndNeg 
test3: sumOfPosAndZero 
test4: sumOfNegAndZero 
test5: sumOfMaxIntAndMinInt 

, vv

+1

Có thể thêm sumOfMaxIntAndMaxInt và kiểm tra chức năng báo cáo lỗi. Đây là trường hợp ranh giới nhất mà tôi có thể nghĩ đến. – pmr

+0

sumOfMaxIntAndOne cũng sẽ gây ra ngoại lệ, phải không? Đó sẽ là một trường hợp tốt. Nếu không, tôi đồng ý. Chỉ cần nghĩ về một vài khả năng khác nhau một chút và đi với điều đó. –

+1

Đừng quên về các trường hợp kiểm tra tiêu cực test6: sumOfStringAndPositive (nên tăng ngoại lệ hoặc lỗi trả về) –

5

Có một số triết lý. Roy Osherove, tác giả của The Art of Unit Testing, dường như prefer using explicit values và chọn mức đại diện thấp nhất (hoặc đơn giản nhất) của mỗi Equivalence Class.

Nguyên tắc đó không áp dụng chính nó đặc biệt tốt cho ví dụ của bạn, nhưng hoạt động thực sự tốt trong nhiều trường hợp khác.

Nếu, ví dụ, một lớp yêu cầu đầu vào của một số nguyên dương, bạn chọn số vì đây là biểu diễn đơn giản nhất của tất cả các trình tương tác tích cực.

Cá nhân tôi thích sử dụng nguyên tắc tôi gọi Constrained Non-Determinism. Vấn đề ở đây là chúng tôi cho phép một số loại nhà máy phục vụ cho chúng tôi các biến ẩn danh cho loại đã cho, bởi vì nó buộc chúng ta thiết lập mối quan hệ trực tiếp trong thử nghiệm.

Tôi đang sử dụng AutoFixture để làm điều này (nhưng bạn cũng có thể sử dụng cái gì khác), vì vậy trong trường hợp này tôi sẽ kiểm tra SumCalculator như thế này:

var fixture = new Fixture(); 
var int1 = fixture.CreateAnonymous<int>(); 
var int2 = fixture.CreateAnonymous<int>(); 
var expectedResult = int1 + int2; 
var sut = fixture.CreateAnonymous<SumCalculator>(); 

var result = sut.Calculate(int1, int2); 

Assert.AreEqual(expectedResult, result); 

Về nguyên tắc, thử nghiệm duy nhất này cung cấp một đặc điểm kỹ thuật cho phương pháp tính toán. Chúng tôi không bao giờ biết giá trị của int1int2 là gì và điều đó rất phù hợp trong tất cả các trường hợp đó thực sự không quan trọng.

3

nếu bạn đang thử nghiệm hàm toán học, tôi khuyên bạn nên kiểm tra chức năng nghịch đảo của nó, ví dụ: đối với hàm x = a + b, bạn nên kiểm tra xem liệu ax = -b và xb = a , đây chỉ là để minh hoạ, ofcourse nó sẽ không hoạt động trên mọi trường hợp.

1

Một giải pháp thay thế khác ở đây là sử dụng Parameterized Test Case để xóa trùng lặp trong các thử nghiệm.Về cơ bản một bảng chứa tất cả dữ liệu cho các bài kiểm tra, ở dạng tuple ([term1, term2, sum]), sau đó một testcase lặp lại trên bảng khi gọi testcase được tham số hóa để kiểm tra một hàng trong bảng:

I cũng sẽ thêm thử nghiệm tiêu cực (tràn ở đây): calculate(MAXINT, 1) nghĩa vụ trả lại là gì?

1

Xem công việc của David Saff về Kiểm tra lý thuyết; here (PDF) là một ví dụ. Điều này về cơ bản là một cách xác nhận rằng một cái gì đó (giống như một hàm là nghịch đảo của hàm của nó) là đúng cho tất cả các giá trị trong một số tập hợp (bao gồm tập hợp tất cả các giá trị có thể) - và thể hiện xác nhận đó như một phép thử. Bạn có thể làm một số công cụ thú vị bằng cách chạy thử nghiệm của bạn với các giá trị được chọn ngẫu nhiên (nếu tập quá lớn để chạy hết), và tự động ghi lại các lỗi như các phép thử hồi quy cụ thể.

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