Phạm vi kiểm tra mã đơn vị - bạn có bao phủ 100% không?

Question

Các thử nghiệm đơn vị của bạn có phải là phạm vi bao trùm 100% không? Có hoặc không, và tại sao hoặc tại sao không.

Answer 1

Ít khi thực tế để nhận được mức độ bao trùm 100% trong một hệ thống không tầm thường. Hầu hết các nhà phát triển, những người viết các bài kiểm tra đơn vị đều quay cho những người từ trung đến cao 90.

Công cụ kiểm tra tự động như Pex có thể giúp tăng mức độ phù hợp của mã. Nó hoạt động bằng cách tìm kiếm các trường hợp cạnh khó tìm.

Answer 2

Không, bởi vì có một trade-off thực tế giữa đơn vị xét nghiệm hoàn hảo và thực sự hoàn thành một dự án :)

Answer 3

Không vì tôi đã dành thời gian của tôi thêm các tính năng mới giúp người sử dụng chứ không phải là khó khăn để viết bài kiểm tra khó hiểu mà cung cấp ít giá trị. Tôi nói đơn vị kiểm tra những điều lớn, những thứ tinh tế và những thứ mong manh.

Answer 4

Không vì nhiều lý do:

• Nó thực sự tốn kém để đạt độ che phủ 100%, so với 90% hoặc 95% đối với một lợi ích đó không phải là rõ ràng.
• Ngay cả với 100% mức độ phù hợp, mã của bạn là không phải là hoàn hảo. Hãy xem phương pháp này (trong thực tế nó phụ thuộc vào loại hình bảo hiểm bạn đang nói về - chi nhánh bảo hiểm, dòng bảo hiểm ...):

public static String foo(boolean someCondition) { 
    String bar = null; 
    if (someCondition) { 
     bar = "blabla"; 
    } 
    return bar.trim(); 
} 

và kiểm tra đơn vị:

assertEquals("blabla", foo(true)); 

Kiểm tra sẽ thành công và độ bao phủ mã của bạn là 100%. Tuy nhiên, nếu bạn thêm một thử nghiệm khác:

assertEquals("blabla", foo(false)); 

thì bạn sẽ nhận được NullPointerException. Và khi bạn ở 100% với bài kiểm tra đầu tiên, bạn sẽ không nhất thiết phải viết bài kiểm tra thứ hai!

Nói chung, tôi cho rằng các quan trọng mã phải được bảo hiểm tại gần 100%, trong khi các mã khác có thể được bảo hiểm tại 85-90%

Answer 5

Cá nhân tôi thấy 100% bảo hiểm thử nghiệm được vấn đề trên nhiều cấp độ. Đầu tiên và quan trọng nhất, bạn phải chắc chắn rằng bạn đang đạt được một lợi ích hữu hình, tiết kiệm chi phí từ các bài kiểm tra đơn vị bạn viết. Ngoài ra, kiểm tra đơn vị, giống như bất kỳ mã nào khác, là CODE. Điều đó có nghĩa là, giống như bất kỳ mã nào khác, phải được xác minh về tính chính xác và được duy trì. Đó là thời gian bổ sung xác minh mã bổ sung cho tính chính xác, và duy trì nó và giữ cho các xét nghiệm đó hợp lệ để đáp ứng với các thay đổi đối với mã doanh nghiệp, thêm chi phí. Đạt được 100% thử nghiệm bảo hiểm và đảm bảo bạn kiểm tra bạn đang code triệt để nhất có thể là một nỗ lực đáng khen ngợi, nhưng đạt được nó bằng mọi giá ... tốt, thường là quá tốn kém.

Có nhiều lần khi kiểm tra lỗi và kiểm tra tính hợp lệ được thực hiện để bao gồm rìa hoặc cực kỳ hiếm, nhưng chắc chắn có thể, trường hợp đặc biệt là một ví dụ về mã không nhất thiết cần phải được bảo hiểm.Lượng thời gian, nỗ lực (và cuối cùng tiền) phải được đầu tư để đạt được độ bao phủ của các trường hợp hiếm rìa như vậy thường lãng phí là trong bối cảnh nhu cầu kinh doanh khác. Các thuộc tính thường là một phần của mã, đặc biệt là với C# 3.0, không cần phải được thử nghiệm nhiều nhất, nếu không phải tất cả, các thuộc tính hoạt động giống hệt nhau và quá đơn giản (trả về một câu lệnh đơn hoặc tập hợp). kiểm tra đơn vị thời gian bao quanh hàng ngàn tài sản có thể có khả năng được đầu tư tốt hơn ở một nơi khác, nơi lợi nhuận hữu hình lớn hơn, có giá trị hơn về đầu tư đó có thể được thực hiện.

Ngoài việc đơn giản đạt được phạm vi kiểm tra 100%, có những vấn đề tương tự khi cố gắng thiết lập đơn vị "hoàn hảo". Mocking frameworks đã tiến triển đến một mức độ tuyệt vời những ngày này, và hầu như bất cứ điều gì có thể được chế giễu (nếu bạn sẵn sàng trả tiền, TypeMock thực sự có thể giả lập bất cứ điều gì và tất cả mọi thứ, nhưng nó chi phí rất nhiều.) Tuy nhiên, thường có những lúc phụ thuộc mã của bạn không được viết theo cách có thể giả lập (đây thực sự là vấn đề cốt lõi với số lượng lớn bản thân .NET framework.) Thời gian đầu tư để đạt được phạm vi thích hợp của bài kiểm tra là hữu ích, nhưng đưa vào số lượng quá nhiều thời gian để loại bỏ tất cả mọi thứ và bất cứ điều gì dưới mặt của mặt trời, thêm lớp trừu tượng và giao diện để làm cho nó có thể, một lần nữa thường là một sự lãng phí thời gian, công sức, và cuối cùng là tiền bạc.

Mục tiêu cuối cùng với thử nghiệm không thực sự là đạt được mức độ phù hợp tối đa trong mã. Mục tiêu cuối cùng phải đạt được giá trị lớn nhất trên một đơn vị thời gian đầu tư vào việc viết các bài kiểm tra đơn vị, trong khi bao gồm càng nhiều càng tốt trong thời gian đó. Cách tốt nhất để đạt được điều này là để có những cách tiếp cận BDD: (. Hành vi ... không đơn vị) Xác định mối quan tâm của bạn, xác định hoàn cảnh của bạn, và kiểm tra kết quả mong đợi xảy ra đối với bất kỳ mảnh hành vi được phát triển

Answer 6

Tôi thường viết các bài kiểm tra đơn vị giống như một phương pháp phòng ngừa hồi qui. Khi một lỗi được báo cáo rằng tôi phải sửa chữa, tôi tạo một bài kiểm tra đơn vị để đảm bảo rằng nó không tái xuất hiện trong tương lai. Tôi có thể tạo một vài thử nghiệm cho các phần chức năng mà tôi phải đảm bảo giữ nguyên (hoặc đối với các tương tác giữa các phần phức tạp), nhưng tôi thường muốn sửa lỗi để cho tôi biết một trong những điều cần thiết.

Answer 7

Có, chúng tôi làm.

Tùy thuộc vào ngôn ngữ và khuôn khổ bạn đang sử dụng để dễ dàng đạt được.

Chúng tôi đang sử dụng Ruby on Rails cho dự án hiện tại của mình. Ruby là rất "mockable" trong đó bạn có thể stub/mock ra khối lớn mã của bạn mà không cần phải xây dựng trong thành phần lớp quá phức tạp và thiết kế xây dựng mà bạn sẽ phải làm bằng các ngôn ngữ khác.

Điều đó nói rằng, chúng tôi chỉ có 100% dòng bảo hiểm (về cơ bản những gì rcov cung cấp cho bạn). Bạn vẫn phải suy nghĩ về việc kiểm tra tất cả các nhánh cần thiết. Điều này chỉ thực sự có thể nếu bạn bao gồm nó ngay từ khi bắt đầu xây dựng tích hợp liên tục và phá vỡ tòa nhà nếu mức độ phù hợp giảm xuống dưới 100% - khiến nhà phát triển khắc phục ngay lập tức.Tất nhiên bạn có thể chọn một số số khác làm mục tiêu, nhưng nếu bạn bắt đầu mới, không có nhiều khác biệt cho nỗ lực để nhận được từ 90% đến 100%

Chúng tôi cũng có một loạt các số liệu phá vỡ công trình xây dựng nếu chúng vượt qua một ngưỡng nhất định (ví dụ như độ phức tạp của chu trình, ví dụ sao chép) tất cả đều đi cùng nhau và giúp củng cố lẫn nhau.

Một lần nữa, bạn thực sự phải có công cụ này ngay từ đầu để tiếp tục làm việc ở mức độ nghiêm ngặt - hoặc là đặt mục tiêu bạn có thể nhấn, và dần dần ratchet nó cho đến khi bạn đạt đến một cấp độ hạnh phúc với.

Làm điều này làm tăng thêm giá trị? Tôi đã hoài nghi lúc đầu, nhưng tôi có thể thành thật nói rằng có nó. Không phải chủ yếu bởi vì bạn đã kiểm tra kỹ lưỡng mã (mặc dù đó chắc chắn là một lợi ích), nhưng nhiều hơn về viết mã đơn giản dễ kiểm tra và lý do. Nếu bạn biết bạn có để có phạm vi kiểm tra 100%, bạn dừng viết quá phức tạp nếu/else/while/try/catch monstrosities và Keep It Simple Stupid.

Answer 8

Tôi chỉ có mức độ phù hợp 100% đối với các đoạn mã mới đã được viết với khả năng kiểm tra. Với đóng gói thích hợp, mỗi lớp và chức năng có thể có chức năng kiểm tra đơn vị đồng thời cung cấp gần mức độ phù hợp 100%. Sau đó, chỉ cần thêm một số thử nghiệm bổ sung bao gồm một số trường hợp cạnh để giúp bạn đạt được 100%.

Bạn không nên viết các bài kiểm tra chỉ để nhận được mức độ phù hợp. Bạn nên viết các bài kiểm tra chức năng để kiểm tra tính chính xác/tuân thủ. Bằng một đặc tả chức năng tốt bao gồm tất cả các cơ sở và thiết kế phần mềm tốt, bạn có thể nhận được bảo hiểm tốt miễn phí.

Answer 9

Có, tôi đã có các dự án đã có phạm vi phủ sóng 100%. Xem câu trả lời của tôi đến một tương tự question.

Bạn thể nhận được 100% dòng vùng phủ sóng, nhưng như những người khác đã chỉ ra ở đây trên SO và các nơi khác trên internet của nó có lẽ chỉ ở mức tối thiểu. Khi bạn xem xét bảo hiểm đường dẫn và chi nhánh, có rất nhiều việc phải làm.

Cách khác để xem xét nó là cố gắng làm cho mã của bạn trở nên đơn giản đến mức dễ dàng nhận được mức độ phù hợp 100%.

Answer 10

Tôi thường quản lý để đạt 93 .. 100% với mức độ phù hợp của mình nhưng tôi không nhắm đến 100% nữa. Tôi đã từng làm điều đó và trong khi nó có thể thực hiện được, nó không đáng để nỗ lực vượt ra ngoài một điểm nhất định vì việc kiểm tra một cách mù quáng thường không cần thiết. Ví dụ tốt của việc này có thể là chi nhánh thẩm định thực sự của đoạn mã sau snipped

public void method(boolean someBoolean) { 
    if (someBoolean) { 
     return; 
    } else { 
     /* do lots of stuff */ 
    } 
} 

Tuy nhiên điều quan trọng để đạt được là càng gần với vùng phủ sóng 100% trên chức năng phần của lớp càng tốt vì đó là những nguy hiểm vùng nước của ứng dụng của bạn, các bog sương mù của lỗi rão và hành vi không xác định và tất nhiên là xiếc tiền làm xiếc.

Answer 11

Điều tôi làm khi tôi có cơ hội là chèn câu lệnh vào mỗi nhánh của mã có thể được grepped và bản ghi đó nếu chúng bị trúng, để tôi có thể so sánh để xem báo cáo nào đã không bị đánh. Đây là một công việc vặt, vì vậy tôi không phải lúc nào cũng tốt về điều đó.

Tôi vừa xây dựng một ứng dụng giao diện người dùng nhỏ để sử dụng trong đấu giá từ thiện, sử dụng MySQL làm DB của mình.Vì tôi thực sự, thực sự không muốn nó phá vỡ giữa cuộc đấu giá, tôi đã thử một cái gì đó mới.

Kể từ khi nó được trong VC6 (C++ + MFC) Tôi định nghĩa hai macro:

#define TCOV ASSERT(FALSE) 
#define _COV ASSERT(TRUE) 

và sau đó tôi rắc

TCOV; 

suốt mã, trên mỗi con đường riêng tôi có thể tìm thấy, và trong mọi thói quen. Sau đó, tôi chạy chương trình dưới trình gỡ lỗi và mỗi lần nhấn một số TCOV, nó sẽ dừng lại. Tôi sẽ xem mã cho bất kỳ vấn đề rõ ràng nào và sau đó chỉnh sửa mã này thành _COV, sau đó tiếp tục. Mã sẽ biên dịch lại khi đang di chuyển và chuyển sang TCOV tiếp theo. Bằng cách này, tôi từ từ, siêng năng, loại bỏ đủ các tuyên bố TCOV để nó chạy "bình thường".

Sau một thời gian, tôi đã grepped mã cho TCOV và cho biết mã nào tôi chưa thử nghiệm. Sau đó, tôi quay lại và chạy nó một lần nữa, đảm bảo kiểm tra nhiều chi nhánh mà tôi chưa thử trước đó. Tôi tiếp tục thực hiện việc này cho đến khi không còn các câu lệnh TCOV nào trong mã.

Quá trình này mất một vài giờ, nhưng trong quá trình tôi tìm thấy và sửa một số lỗi. Không có cách nào tôi có thể có kỷ luật để thực hiện và làm theo một kế hoạch thử nghiệm mà có thể đã được triệt để. Tôi không chỉ biết rằng mình đã bao phủ tất cả các chi nhánh, nhưng nó đã làm cho tôi xem xét mọi chi nhánh trong khi nó đang chạy - một loại đánh giá mã rất tốt.

Vì vậy, dù bạn có sử dụng công cụ phủ sóng hay không, đây là cách tốt để loại bỏ các lỗi có thể ẩn nấp trong mã cho đến khi có thêm thời gian.

Answer 12

Từ Ted Neward blog.

Đến thời điểm này, hầu hết các nhà phát triển ít nhất đã nghe nói về, nếu không được coi là chấp nhận, bản ghi nhớ Thử nghiệm Masochistic. Các thành viên của NFJS'ers Stuart Halloway và Justin Gehtland đã thành lập một công ty tư vấn, Relevance, đặt một thanh cao như là một tiêu chuẩn văn hóa doanh nghiệp: 100% kiểm tra phạm vi mã của họ. Neal Ford đã báo cáo rằng ThoughtWorks đưa ra những tuyên bố tương tự, mặc dù đó là sự hiểu biết của tôi rằng khách hàng đôi khi đặt những trở ngại ngẫu nhiên trong cách đạt được mục tiêu nói trên. Thật là vui tính, nhưng như câu tục ngữ Ấn Độ cổ của người Mỹ được nói là nhà nước, Nếu bạn nhắm mũi tên vào mặt trời, nó sẽ bay cao hơn và cha hơn nếu bạn nhắm nó xuống đất.

Answer 13

Đối với tất cả các thử nghiệm phủ sóng 90%:

Vấn đề với làm như vậy là cứng 10% để kiểm tra mã cũng là mã không tầm thường có chứa 90% số lỗi! Đây là kết luận tôi đã có kinh nghiệm sau nhiều năm TDD.

Và sau tất cả điều này là kết luận khá đơn giản. Điều này khó kiểm tra 10% mã, rất khó để kiểm tra vì nó phản ánh vấn đề kinh doanh khó khăn hoặc lỗ hổng thiết kế khéo léo hoặc cả hai. Những lý do chính xác thường dẫn đến mã lỗi.

Nhưng cũng:

• 100% mã bảo rằng giảm với thời gian ít hơn 100% bao phủ thường pinpoints một lỗi hoặc ít nhất là một lỗ hổng.
• 100% mã được bảo hiểm được sử dụng cùng với hợp đồng, là vũ khí tối thượng để dẫn đến sống gần với mã không có lỗi. Code Contracts and Automated Testing are pretty much the same thing
• Khi lỗi được phát hiện trong mã được bao phủ 100%, việc sửa lỗi sẽ dễ dàng hơn. Vì mã chịu trách nhiệm về lỗi này đã được kiểm tra, nên không khó để viết các bài kiểm tra mới để sửa lỗi.

Answer 14

Trên một dự án mới, tôi thực hành TDD và duy trì độ phủ sóng 100%. Nó chủ yếu xảy ra một cách tự nhiên thông qua TDD. Khoảng cách bảo hiểm thường đáng chú ý và dễ dàng lấp đầy. Nếu công cụ bảo hiểm tôi đang sử dụng bảo hiểm chi nhánh hoặc thứ gì đó khác, tôi sẽ chú ý đến điều đó, mặc dù tôi chưa bao giờ thấy chi nhánh nói cho tôi biết điều gì, có lẽ vì TDD đã đến đó trước.

Đối số mạnh nhất của tôi để duy trì mức độ phù hợp 100% (nếu bạn quan tâm) là dễ bảo trì hơn 100% so với quản lý ít hơn 100% mức độ phù hợp. Nếu bạn có 100% phạm vi phủ sóng và nó giảm xuống, bạn ngay lập tức biết lý do tại sao và có thể dễ dàng sửa chữa nó, bởi vì thả là trong mã bạn vừa làm việc trên. Nhưng nếu bạn giải quyết cho 95% hoặc bất cứ điều gì, thật dễ dàng để bỏ qua các hồi quy bảo hiểm và bạn mãi mãi xem xét lại những khoảng trống đã biết. Đó là lý do chính xác tại sao thực hành tốt nhất hiện nay yêu cầu một bộ thử nghiệm để vượt qua hoàn toàn. Bất cứ điều gì ít hơn là khó khăn hơn, không dễ dàng hơn, để quản lý.

Thái độ của tôi chắc chắn được củng cố bằng cách làm việc trong Ruby một thời gian, nơi có các khung kiểm tra xuất sắc và kiểm tra đôi rất dễ dàng. Phạm vi phủ sóng 100% cũng dễ dàng trong Python. Tôi có thể phải hạ thấp các tiêu chuẩn của mình trong một môi trường với các công cụ ít khắc phục hơn.

Tôi rất muốn có các tiêu chuẩn giống nhau về các dự án cũ, nhưng tôi chưa bao giờ thấy nó thực tế để mang lại một ứng dụng lớn với phạm vi phủ sóng tầm thường lên đến 100%; Tôi đã phải giải quyết cho 95-99%. Nó luôn luôn là quá nhiều công việc để quay trở lại và bao gồm tất cả các mã cũ. Điều này không mâu thuẫn với lập luận của tôi rằng rất dễ để giữ một codebase ở mức 100%; nó dễ dàng hơn nhiều khi bạn duy trì tiêu chuẩn đó ngay từ đầu.

Answer 15

Trong nhiều trường hợp, nó không đáng để nhận được 100% bảo hiểm sao kê, nhưng trong một số trường hợp, nó là giá trị nó. Trong một số trường hợp, mức độ bao trùm 100% là quá lax một yêu cầu.

Câu hỏi quan trọng cần đặt ra là, "tác động gì nếu phần mềm không thành công (tạo ra kết quả sai)?". Trong hầu hết các trường hợp, tác động của lỗi là tương đối thấp. Ví dụ: có thể bạn phải sửa mã trong vòng vài ngày và chạy lại một số thứ. Tuy nhiên, nếu tác động là "ai đó có thể chết trong 120 giây", thì đó là một tác động rất lớn và bạn phải có nhiều hơn lô phạm vi kiểm tra nhiều hơn mức độ phù hợp 100%.

Tôi dẫn số Core Infrastructure Initiative Best Practices Badge cho Quỹ Linux. Chúng tôi do có phạm vi bảo hiểm 100%, nhưng tôi không nói rằng điều đó là cần thiết. Trong một thời gian dài chúng tôi đã rất gần 100%, và chỉ quyết định làm điều đó phần trăm nhỏ cuối cùng. Tuy nhiên, chúng tôi không thể biện minh cho vài phần trăm cuối cùng về cơ sở kỹ thuật; vài phần trăm cuối cùng được thêm hoàn toàn là "niềm tự hào của tay nghề". Tôi nhận được một phần rất nhỏ của tâm trí từ có bảo hiểm 100%, nhưng thực sự nó không cần thiết. Chúng tôi đã được bảo hiểm trên 90% chỉ từ các bài kiểm tra bình thường, và đó là tốt cho các mục đích của chúng tôi.Điều đó nói rằng, chúng tôi muốn phần mềm trở nên vững chắc và có mức độ bao phủ 100% đã giúp chúng tôi đạt được điều đó. Nó cũng dễ dàng hơn để nhận được 100% tuyên bố bảo hiểm ngày hôm nay.

Sẽ hữu ích khi đo lường mức độ phù hợp, ngay cả khi bạn không cần 100%. Nếu thử nghiệm của bạn không có mức độ phù hợp tốt, bạn cần quan tâm đến . Một bộ kiểm thử xấu có thể có vùng phủ sóng báo cáo tốt, nhưng nếu bạn không có vùng phủ sóng báo cáo tốt, thì theo định nghĩa bạn có một bộ kiểm thử xấu. Bao nhiêu bạn cần là một thương mại-off: những rủi ro (xác suất và tác động) từ phần mềm đó là hoàn toàn chưa được kiểm tra là gì? Theo định nghĩa, nó có nhiều khả năng có lỗi (bạn không thử nghiệm nó!), Nhưng nếu bạn và người dùng của bạn có thể sống với những rủi ro đó (xác suất và tác động), thì không sao. Đối với nhiều dự án tác động thấp hơn, tôi nghĩ rằng 80% -90% bảo hiểm tuyên bố là okay, tốt hơn là tốt hơn.

Mặt khác, nếu mọi người có thể chết do lỗi trong phần mềm của bạn thì phạm vi báo cáo 100% không đủ. Tôi sẽ ít nhất thêm bảo hiểm chi nhánh, và có thể nhiều hơn, để kiểm tra chất lượng của các bài kiểm tra của bạn. Các tiêu chuẩn như DO-178C (đối với các hệ thống trong không khí) sử dụng phương pháp này - nếu thất bại nhỏ, không có vấn đề lớn, nhưng nếu thất bại có thể là thảm họa, thì cần phải kiểm tra nghiêm ngặt hơn nhiều. Ví dụ, DO-178C yêu cầu MC/DC coverage đối với phần mềm quan trọng nhất (phần mềm có thể nhanh chóng giết người nếu nó làm sai). MC/DC là cách vất vả hơn so với bảo hiểm tuyên bố hoặc thậm chí bảo hiểm chi nhánh.