Ví dụ về thử nghiệm đơn vị trong C#?

Question

Kiểm tra đơn vị chính xác là gì và làm cách nào để viết một bài kiểm tra? Tôi nghe nhiều lần mọi người viết chúng trước khi ứng dụng của họ thậm chí được viết, làm thế nào điều này có thể được? Tôi cảm thấy rằng thử nghiệm đơn vị là một số mã thực hiện cuộc gọi đến phương thức ứng dụng của bạn với giá trị được đặt và dự kiến ​​giá trị cụ thể sẽ quay lại, nếu giá trị cụ thể không quay lại thử nghiệm đã thất bại. Tôi có sai hoặc lừa dối ở đây không? Tôi đọc rất nhiều về thử nghiệm đơn vị nhưng tôi biết rất ít về những gì nó thực sự trông giống như trong mã để một mẫu sẽ là tuyệt vời.

Đây có phải là bài kiểm tra đơn vị không?

mã giả

bắt đầu ...

CheckForDuplicateSubdomains(){ 
    get all users in DB with matching subdomains 
    if greater than zero, fail test 
} 

PS: Tôi đang sử dụng ASP.NET MVC trong C#

Answer 1

Tôi có ấn tượng rằng một thử nghiệm đơn vị là một số mã mà làm cho một cuộc gọi với một phương pháp của ứng dụng của bạn với một giá trị đã đặt và dự kiến ​​một giá trị cụ thể sẽ quay lại, nếu giá trị cụ thể không quay trở lại thì thử nghiệm đã không thành công. Tôi có sai hoặc lừa dối ở đây không?

Không, bạn hoàn toàn đúng.

Điều quan trọng với các bài kiểm tra đơn vị là kiểm tra một đoạn mã nhỏ nhất có thể.

Trong ví dụ của bạn, bạn lấy thứ gì đó từ db và sau đó đếm số mục ... Nếu phương pháp của bạn không thành công, bạn sẽ không bao giờ biết chính xác nơi mọi thứ đã sai vì có quá nhiều thứ có thể sai. ..

db-kết nối của bạn có thể bị mất, sql không hợp lệ, ...

Nếu bạn đang sử dụng asp.net MVC, bạn cần phải có một thời gian dễ dàng hơn viết bài kiểm tra đơn vị hơn nếu bạn đang sử dụng asp bình thường. net

Answer 2

Bài kiểm tra đơn vị là bài kiểm tra thực hiện một phần rất nhỏ mã của bạn, thường là một phương pháp đơn lẻ (đơn vị chính xác).

Trong TDD, nhà phát triển có thể viết Bài kiểm tra đơn vị trước khi mã hóa phương pháp vì họ đã biết đơn vị mã nên làm gì. Nó không quan trọng như thế nào nó làm việc ... kiểm tra chỉ đảm bảo kết quả là chính xác.

Và mã giả có thể được sử dụng như một bài kiểm tra Đơn vị (không chắc nó sẽ kiểm tra cái gì, nhưng tôi sẽ giả sử bạn đang thử một phương thức không trả về các Tên miền phụ trùng lặp).

Lý thuyết là Kiểm tra đơn vị (và Kiểm tra phát triển) nên giảm đau đầu hơn nữa xuống đường bằng cách đảm bảo mỗi đơn vị mã thực hiện chính xác những gì được mong đợi của nó.

Answer 3

Bạn đúng về thử nghiệm đơn vị. Ý tưởng là kiểm tra tất cả các chức năng của bạn, từng cái một, với các đầu vào khác nhau để đảm bảo chúng hoạt động như bạn mong đợi (trái với việc tìm ra sau khi chúng được chèn vào một ứng dụng .. và sau đó làm cho việc thử nghiệm phức tạp hơn).

Viết các bài kiểm tra đơn vị trước khi bạn viết hàm là một phần của phương pháp được gọi là "Phát triển theo hướng thử nghiệm". Trong đó bạn chỉ viết bộ khung của hàm, và tất cả các bài kiểm tra đơn vị trước tiên. Vì vậy, lúc đầu tất cả các bài kiểm tra của bạn sẽ thất bại (b/c chức năng chưa được lập trình). Sau đó bạn lập trình hàm cho đến khi tất cả các bài kiểm tra vượt qua.

Answer 4

Có, ví dụ của bạn sẽ là thử nghiệm đơn vị. Có một vài lý do để tạo thử nghiệm trước.Đầu tiên, nó hoạt động như tài liệu sống cho dự án của bạn. Nó thiết lập hành vi và kết quả mong đợi, giúp bạn thực sự triển khai mã của bạn (viết một cái gì đó dễ dàng hơn, biết phải làm gì và về cơ bản nó được bắt đầu như thế nào). Thứ hai, nếu bạn viết bài kiểm tra sau đó, bạn có nhiều khả năng viết một bài kiểm tra làm việc với mã bạn đã viết, điều này không giúp bạn. Xác định một đơn vị mã cần làm gì, viết các bài kiểm tra và viết/sửa mã để nó phản ánh các hành vi trong các bài kiểm tra. Chiến lược này chuyển thành hiểu biết và chất lượng được cải thiện khi ứng dụng của bạn phát triển.

Answer 5

Thử nghiệm đơn vị là thử nghiệm tự động ở cấp Đơn vị. Theo cấp độ đơn vị, chúng có nghĩa là đơn vị mã nguyên tử sao cho bạn không thể phá vỡ nó thêm nữa. một hàm hoặc một phần cụ thể của một đối tượng. một thử nghiệm đơn vị cho một hàm vuông sẽ giống như

assertEqual(4, square(2)); 
assertEqual(4, square(-2)); 
assertEqual(0, square(0)); 

Bây giờ bạn có thể viết này càng sớm càng bạn đã quyết định giao diện của hình vuông, cho một chức năng phức tạp hơn bạn có thể đo khoảng cách giữa để hoàn thành chức năng là bằng bao nhiêu bài kiểm tra.

Answer 6

Có các quy ước được thiết lập rất tốt để thử nghiệm đơn vị trong họ khung xUnit, ban đầu bắt nguồn từ jUnit. Trong khuôn khổ đó, xác nhận là phương tiện chính để thực hiện kiểm tra. Trong một bộ thử nghiệm, mục tiêu là để đảm bảo rằng 100% các xác nhận của bạn là đúng sự thật.

Hãy xem xét ví dụ của bạn.

CheckForDuplicateSubdomains(){ 
    get all users in DB with matching subdomains 
    if greater than zero, fail test 
} 

Thử nghiệm này thường có tên bắt đầu bằng "kiểm tra", cho phép thử nghiệm của khung công tác biết rằng chức năng này là thử nghiệm chứ không phải phương pháp thiết lập. Điều quan trọng là phải rõ ràng rằng chúng tôi đang kiểm tra hành vi của mã và không phải trạng thái của dữ liệu.

testNoDuplicateSubdomains(){ 
} 

Trong mỗi thử nghiệm, có four phases:

• thiết lập fixture,
• tập thể dục SUT, xác minh kết quả
• và
• cố teardown.

SUT là "hệ thống đang thử nghiệm", thường là một phương pháp của một lớp trong mã sản xuất của bạn.

testNoDuplicateSubdomains(){ 
    // fixture setup 
    prepareDatabaseTestData() 
    // exercise SUT, 
    SUT = new ProductionObject() 
    result = SUT.getAllUsersWithMatchingSubDomains() 
    // result verification and 
    assertEmpty(result) // or whatever makes sense 
    // fixture teardown. 
    removeDatabaseTestData() 
} 

Cũng như nhiều kỹ thuật phát triển phần mềm, phải mất một thời gian để có kinh nghiệm viết bài kiểm tra đơn vị. Một nguồn tài nguyên tốt để tìm hiểu các phương pháp hay nhất là xUnit Test Patterns bởi Gerard Meszaros.