2013-01-03 34 views
8

Tôi muốn tìm hiểu cách viết các trường hợp thử nghiệm trước khi viết mã. Tôi đã đọc một bài viết về phát triển theo hướng thử nghiệm. Tôi tự hỏi làm thế nào các nhà phát triển viết các trường hợp thử nghiệm? Ví dụ: phương pháp này:Cách viết các trường hợp kiểm tra?

public int divideNumbers(int num1, int num2) 
    { 
     return num1/num2; 
    } 
+1

bạn biết rằng bạn đã viết mã trước khi kiểm tra? :) – Rafal

Trả lời

3

Bây giờ chúng tôi bắt đầu với một dự án trống. Bạn muốn làm một cái gì đó, nói chia hai số. Vì vậy, bạn viết một bài kiểm tra mô tả những gì bạn muốn làm:

Assert.That(divide(10,2), Eq(5)) 

thử nghiệm này mang đến cho bạn một điểm mấu chốt: nó mô tả giao diện chấp nhận được của phương pháp divide. Vì vậy, bạn tiến hành thực hiện nó như là int divide(int x, int y) ví dụ.

Viết các bài kiểm tra mô tả những gì bạn mong đợi nhận được từ mã của bạn. Bạn không cần phải suy nghĩ nhiều về nó. Cách viết bình thường nhất của bạn có lẽ là cách tốt nhất để thiết kế mã của bạn, và sau đó bạn có thể thực hiện nó để thỏa mãn kiểm thử của bạn.

1

Có một vài bước để thử nghiệm. Từ MSDN;

Trong trường hợp của bạn;

Assert.AreEqual(divideNumbers(8, 4), 2); 

Assert lớp xác minh điều kiện kiểm tra đơn vị sử dụng true/false mệnh đề. Bạn nên viết các trường hợp thử nghiệm của bạn những gì bạn mong đợi kết quả của họ. Bạn có thể sử dụng thuộc tính TestMethod cho các phương pháp thử nghiệm của mình. Có một bài đăng thú vị về số Creating Unit tests for your c# code. Phân tích nó rất tốt.

+0

Thực ra những gì tôi muốn hỏi có một câu trả lời là liên kết mà bạn đã chia sẻ từ codeproject. Cảm ơn. – cihata87

0

Bắt đầu bằng cách nhận ra sự khác biệt giữa lý thuyết và thực hành.

Bất kỳ hệ thống thực tế nào đều có thể dễ dàng tạo thông qua TDD và một số khác thì không.

Nhóm cuối cùng là mọi thứ phụ thuộc vào môi trường, khi làm việc trên một hệ thống không tìm cách trừu tượng hóa các giả định về môi trường, nhưng thực tế chấp nhận chúng.

Nhóm này có thể được phát triển theo kiểu TDD, nhưng nó sẽ yêu cầu thêm công cụ và tiện ích mở rộng cho nhà máy phần mềm.

Đối với .Net, đây là công cụ và tiện ích mở rộng như MS virtual Test Lab và SpecFlow.

Điều tôi đang cố gắng giao tiếp là tùy thuộc vào.

Để thử nghiệm thành phần/đơn vị rất đơn giản, ý tưởng sẽ là viết testcase không thành công, trước khi viết mã để kiểm tra và kết thúc phát triển khi chạy thử thành công.

Để thử nghiệm tích hợp và hơn thế nữa (thử nghiệm hệ thống), bạn cần xem xét, trong số những thứ khác, cách mang môi trường thử nghiệm vào một số trạng thái đã biết ngoài việc xem xét những gì cần kiểm tra.

1

Bắt đầu với một nhánh của hàm/lớp/thành phần mà bạn muốn phát triển. Nó nên biên dịch, nhưng cố tình không (chưa) làm những gì nó được cho là phải làm.

Ví dụ:

public int divideNumbers(int num1, int num2) 
{ 
    throw new NotImplementedException(); 
} 

hoặc

return -42; 

Hãy suy nghĩ về những hành vi dự định, điều trị các stub như một giao diện để một hộp đen. Đừng quan tâm đến việc thực hiện (chưa). Hãy suy nghĩ về "hợp đồng" của giao diện: X đi vào, Y đi ra ngoài.

Xác định các trường hợp chuẩn và các trường hợp egde quan trọng. Viết các bài kiểm tra cho họ.

Để phân chia số nguyên (giả sử chúng tôi viết từ đầu), có một số trường hợp cần xem xét: Có và không còn lại, n/1, n/0, 0/n, 0/0, số âm , v.v.

Assert.IsTrue(divideNumbers(4,4) == 1); 
Assert.IsTrue(divideNumbers(4,3) == 1); 
Assert.IsTrue(divideNumbers(4,2) == 2); 
Assert.IsTrue(divideNumbers(4,1) == 4); 
Assert.Throws<ArgumentException>(() => divideNumbers(4,0)); 

Assert.IsTrue(divideNumbers(0,4) == 0); 
Assert.Throws<ArgumentException>(() => divideNumbers(0,0)); 

Assert.IsTrue(divideNumbers(4,-2) == -2); 
Assert.IsTrue(divideNumbers(-4, 2) == -2); 
Assert.IsTrue(divideNumbers(-4,-2) == 2); 

Assert.IsTrue(divideNumbers(4,-3) == -1); 
Assert.IsTrue(divideNumbers(-4, 3) == -1); 
Assert.IsTrue(divideNumbers(-4,-3) == 1); 

Biên dịch và chạy thử nghiệm đơn vị. Tất cả đều thất bại? Nếu không, tại sao? Có lẽ một trong các bài kiểm tra không hoạt động như dự định (các bài kiểm tra cũng có thể bị lỗi!).

Bây giờ, hãy bắt đầu triển khai cho đến khi thử nghiệm không thành công nữa.

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