Mới để thử nghiệm đơn vị, làm thế nào để viết các bài kiểm tra tuyệt vời?

Question

Tôi khá mới đối với thế giới thử nghiệm đơn vị và tôi vừa quyết định thêm phạm vi kiểm tra cho ứng dụng hiện có của mình trong tuần này.

Đây là một nhiệm vụ rất lớn, chủ yếu là do số lượng các lớp học để kiểm tra nhưng cũng bởi vì các bài kiểm tra viết là tất cả mới đối với tôi.

Tôi đã viết các bài kiểm tra cho một loạt các lớp học, nhưng bây giờ tôi tự hỏi liệu tôi có làm đúng không.

Khi tôi viết bài kiểm tra cho một phương pháp, tôi có cảm giác viết lại lần thứ hai những gì tôi đã viết trong chính phương thức đó.
Các thử nghiệm của tôi dường như bị ràng buộc chặt chẽ với phương pháp (kiểm tra tất cả các mã lệnh, mong đợi một số phương thức bên trong được gọi một số lần, với các đối số nhất định), dường như nếu tôi tái cấu trúc phương pháp, nếu hành vi cuối cùng của phương pháp không thay đổi.

Đây chỉ là cảm giác và như đã nói ở trên, tôi không có kinh nghiệm kiểm tra. Nếu một số người thử nghiệm có kinh nghiệm hơn ở đó có thể cho tôi lời khuyên về cách viết các bài kiểm tra tuyệt vời cho một ứng dụng hiện có, điều đó sẽ được đánh giá cao.

Chỉnh sửa: Tôi rất muốn cảm ơn Stack Overflow, tôi đã có những yếu tố đầu vào tuyệt vời chỉ trong vòng chưa đầy 15 phút để trả lời nhiều giờ đọc trực tuyến mà tôi đã làm.

Answer 1

Bài kiểm tra của tôi dường như bị ràng buộc chặt chẽ với phương pháp (kiểm tra tất cả các mã, mong đợi một số phương thức bên trong được gọi là một số lần, với các đối số nhất định), dường như là tôi đã tái cấu trúc phương thức, kiểm tra sẽ thất bại ngay cả khi hành vi cuối cùng của phương pháp không thay đổi.

Tôi nghĩ bạn đang làm sai.

Một thử nghiệm đơn vị nên:

• thử nghiệm một phương pháp
• cung cấp một số lập luận cụ thể để phương pháp mà
• thử nghiệm mà kết quả được như mong đợi

Nó không nên nhìn vào bên trong các phương pháp để xem những gì nó đang làm, vì vậy việc thay đổi bên trong không nên làm cho thử nghiệm thất bại. Bạn không nên trực tiếp kiểm tra các phương thức riêng tư đang được gọi. Nếu bạn quan tâm đến việc tìm hiểu xem mã riêng của bạn có đang được kiểm tra hay không thì hãy sử dụng công cụ bao gồm mã. Nhưng đừng bị ám ảnh bởi điều này: bảo hiểm 100% không phải là một yêu cầu.

Nếu phương pháp của bạn gọi phương thức công khai trong các lớp khác và các cuộc gọi này được đảm bảo bởi giao diện của bạn, thì bạn có thể kiểm tra xem các cuộc gọi này có đang được thực hiện hay không bằng cách sử dụng khung làm giả.

Bạn không nên sử dụng chính phương thức đó (hoặc bất kỳ mã nội bộ nào mà nó sử dụng) để tạo kết quả mong đợi một cách linh hoạt. Kết quả dự kiến ​​sẽ được mã hóa cứng trong trường hợp kiểm tra của bạn để nó không thay đổi khi thay đổi thực hiện. Dưới đây là ví dụ đơn giản về thử nghiệm đơn vị nên làm:

testAdd() 
{ 
    int x = 5; 
    int y = -2; 
    int expectedResult = 3; 

    Calculator calculator = new Calculator(); 
    int actualResult = calculator.Add(x, y); 
    Assert.AreEqual(expectedResult, actualResult); 
} 

Lưu ý rằng kết quả được tính không được kiểm tra - chỉ kết quả là chính xác. Tiếp tục bổ sung thêm nhiều trường hợp thử nghiệm đơn giản hơn như trên cho đến khi bạn đã bao phủ nhiều kịch bản nhất có thể. Sử dụng công cụ bảo hiểm mã của bạn để xem bạn có bỏ lỡ bất kỳ đường dẫn thú vị nào không.

Answer 2

Cần lưu ý rằng các thử nghiệm đơn vị theo đơn vị retro vào mã hiện tại là đến nay khó khăn hơn so với việc tạo mã đó bằng các thử nghiệm ngay từ đầu. Đó là một trong những câu hỏi lớn trong việc đối phó với các ứng dụng cũ ... làm thế nào để kiểm tra đơn vị? Điều này đã được hỏi nhiều lần trước (do đó bạn thể được đóng lại như một câu hỏi dupe), và người ta thường kết thúc ở đây:

Moving existing code to Test Driven Development

Tôi thứ hai giới thiệu cuốn sách câu trả lời được chấp nhận, nhưng ngoài ra có nhiều thông tin được liên kết trong câu trả lời ở đó.

Answer 3

Hãy thử viết Bài kiểm tra đơn vị trước khi viết phương pháp sẽ kiểm tra.

Điều đó chắc chắn sẽ buộc bạn phải suy nghĩ một chút khác biệt về cách mọi thứ đang được thực hiện. Bạn sẽ không có ý tưởng làm thế nào phương pháp sẽ làm việc, chỉ cần những gì nó là vụ phải làm.

Bạn nên luôn kiểm tra kết quả của phương pháp, chứ không phải cách phương thức nhận được kết quả đó.

Answer 4

Không viết các bài kiểm tra để nhận được toàn bộ mã của bạn. Viết các bài kiểm tra đảm bảo yêu cầu của bạn. Bạn có thể phát hiện ra các tệp mã không cần thiết. Ngược lại, nếu chúng là cần thiết, chúng ở đó để đáp ứng một số loại yêu cầu; tìm thấy nó là gì và kiểm tra yêu cầu (không phải đường dẫn).

Giữ thử nghiệm của bạn nhỏ: một thử nghiệm cho mỗi yêu cầu.

Sau đó, khi bạn cần thực hiện thay đổi (hoặc viết mã mới), trước tiên hãy thử viết một bài kiểm tra. Chỉ một. Sau đó, bạn sẽ thực hiện bước đầu tiên trong phát triển theo hướng thử nghiệm.

Answer 5

Kiểm tra đơn vị là về đầu ra bạn nhận được từ một hàm/phương pháp/ứng dụng. Nó không quan trọng ở tất cả như thế nào kết quả được sản xuất, nó chỉ là vấn đề mà nó là chính xác. Vì vậy, cách tiếp cận của bạn để đếm các cuộc gọi đến các phương thức bên trong và như vậy là sai. Những gì tôi có xu hướng làm là ngồi xuống và viết những gì một phương thức nên trả về một số giá trị đầu vào hoặc một môi trường nhất định, sau đó viết một bài kiểm tra so sánh giá trị thực tế được trả về với những gì tôi đã đưa ra.

Answer 6

các thử nghiệm được cho là cải thiện khả năng bảo trì. Nếu bạn thay đổi phương thức và ngắt kiểm tra, có thể là một điều tốt. Mặt khác, nếu bạn nhìn vào phương pháp của bạn như một hộp đen hơn là nó không quan trọng những gì là bên trong phương pháp. Thực tế là bạn cần phải thử những thứ cho một số xét nghiệm, và trong những trường hợp đó bạn thực sự không thể coi phương pháp này là một hộp đen. Điều duy nhất bạn có thể làm là một thử nghiệm tích hợp wrte - bạn tải lên một thể hiện đầy đủ của dịch vụ đang được thử nghiệm và có nó làm việc giống như nó sẽ chạy trong ứng dụng của bạn. Sau đó, bạn có thể coi nó như một hộp đen.

When I'm writing tests for a method, I have the feeling of rewriting a second time what I   
already wrote in the method itself. 
My tests just seems so tightly bound to the method (testing all codepath, expecting some  
inner methods to be called a number of times, with certain arguments), that it seems that 
if I ever refactor the method, the tests will fail even if the final behavior of the 
method did not change. 

Điều này là do bạn đang viết bài kiểm tra sau khi viết mã. Nếu bạn đã làm nó theo cách khác xung quanh (đã viết các bài kiểm tra đầu tiên) nó sẽ không cảm thấy theo cách này.

Answer 7

Đây là cuốn sách tốt nhất để thử nghiệm đơn vị: http://www.manning.com/osherove/

Nó giải thích tất cả các thực hành tốt nhất, làm, và không cho kiểm tra đơn vị.

Answer 8

Để kiểm tra đơn vị, tôi đã tìm thấy cả Kiểm tra lái xe (kiểm tra trước, mã thứ hai) và mã đầu tiên, kiểm tra thứ hai cực kỳ hữu ích.

Thay vì viết mã, sau đó viết kiểm tra. Viết mã sau đó nhìn vào những gì bạn nghĩ rằng mã nên làm. Hãy suy nghĩ về tất cả các mục đích sử dụng của nó và sau đó viết một bài kiểm tra cho mỗi. Tôi thấy các bài kiểm tra viết nhanh hơn nhưng có liên quan nhiều hơn bản thân mã hóa. Các xét nghiệm nên kiểm tra ý định. Ngoài ra suy nghĩ về những ý định bạn gió lên tìm trường hợp góc trong giai đoạn viết thử nghiệm. Và tất nhiên trong khi viết thử nghiệm bạn có thể tìm thấy một trong số ít sử dụng gây ra lỗi (điều tôi thường thấy, và tôi rất vui vì lỗi này không làm hỏng dữ liệu và không được kiểm tra).

Tuy nhiên, thử nghiệm gần giống như mã hóa hai lần. Trong thực tế, tôi đã có các ứng dụng trong đó có nhiều mã kiểm tra (số lượng) hơn mã ứng dụng. Một ví dụ là một máy trạng thái rất phức tạp. Tôi đã phải chắc chắn rằng sau khi thêm nhiều logic hơn vào nó, toàn bộ điều luôn luôn làm việc trên tất cả các trường hợp sử dụng trước đó. Và vì những trường hợp đó khá khó theo dõi bằng cách xem mã, tôi đã có một bộ kiểm tra tốt cho máy này mà tôi tin rằng nó sẽ không bị vỡ ngay cả sau khi thực hiện thay đổi, và các bài kiểm tra đã cứu được một vài lần . Và khi người dùng hoặc người thử nghiệm tìm thấy lỗi với các trường hợp dòng chảy hoặc góc bị mất tích, hãy đoán xem điều gì đã được thêm vào kiểm tra và không bao giờ xảy ra nữa. Điều này thực sự mang lại cho người dùng sự tự tin trong công việc của tôi ngoài việc làm cho toàn bộ điều siêu ổn định. Và khi nó phải được viết lại vì lý do hiệu suất, hãy đoán xem, nó hoạt động như thế nào trên tất cả các đầu vào nhờ vào các bài kiểm tra.

Tất cả các ví dụ đơn giản như function square(number) là tuyệt vời và tất cả, và có thể là ứng cử viên xấu dành nhiều thời gian thử nghiệm. Những người làm logic kinh doanh quan trọng, đó là nơi thử nghiệm là quan trọng. Kiểm tra các yêu cầu. Đừng chỉ kiểm tra hệ thống ống nước. Nếu các yêu cầu thay đổi thì hãy đoán xem, các bài kiểm tra cũng phải như thế nào.

Kiểm tra không được kiểm tra nghĩa là hàm foo đã gọi thanh chức năng 3 lần. Điều đó là sai. Kiểm tra xem kết quả và tác dụng phụ có đúng không, không phải cơ chế bên trong.