Chúng tôi đang bắt đầu thúc đẩy bảo hiểm mã ở đây tại nơi làm việc của tôi và điều đó khiến tôi phải suy nghĩ .... Bao nhiêu mã là đủ?

Khi nào bạn đạt đến mức giảm lợi nhuận trên phạm vi bảo hiểm mã? Điểm ngọt ngào giữa bảo hiểm tốt và không đủ là gì? Nó có thay đổi theo loại dự án bạn đang thực hiện không (ví dụ WPF, WCF, Mobile, ASP.NET) (Đây là các lớp C # chúng tôi đang viết.)

Chúng tôi nhắm đến ít nhất 70%. Trên những thứ dễ kiểm tra hơn (ví dụ, cấu trúc dữ liệu chức năng), chúng tôi nhắm tới 90% và hầu hết các cá nhân nhắm đến gần 100% nhất có thể. Trên những thứ liên quan đến WPF và các khung công tác khác rất khó kiểm tra, chúng tôi nhận được mức độ bao phủ thấp hơn nhiều (chỉ 70%).

Tôi cho rằng chỉ riêng phạm vi bảo hiểm là một số liệu kém. Thật dễ dàng để tạo ra vô số các thử nghiệm vô dụng bao gồm mã, nhưng không kiểm tra đầy đủ đầu ra, hoặc không thử các trường hợp cạnh, chẳng hạn. Mã bao gồm chỉ có nghĩa là nó không ném ngoại lệ, không phải là nó đúng. Bạn cần kiểm tra chất lượng - số lượng không quan trọng.

"Đủ" là khi bạn có thể thay đổi mã của mình với sự tự tin rằng bạn không vi phạm bất cứ điều gì. Đối với một số dự án, có thể là 10%, đối với các dự án khác, nó có thể là 95%.

Nó gần như không bao giờ cao đến 100%. Tuy nhiên, đôi khi cố gắng để có được phạm vi bảo hiểm mã 100% có thể là một cách tuyệt vời để loại bỏ hành trình khỏi cơ sở mã. Đừng quên rằng có hai cách để tăng độ bao phủ mã - viết thêm các bài kiểm tra hoặc lấy mã ra. Nếu mã không được bảo hiểm vì khó kiểm tra, rất có thể bạn có thể đơn giản hóa hoặc cấu trúc lại để dễ kiểm tra hơn. Nếu nó quá mơ hồ để kiểm tra, thường có khả năng tốt là không có gì khác trong mã đang sử dụng nó.

Mã bảo hiểm tiếp cận 100% không có triệu chứng. Do đó, 5% cuối cùng đó có lẽ là nỗ lực nhiều hơn giá trị của nó, khi bạn bắt đầu đạt được lợi nhuận nhỏ đáng tiếc cho những nỗ lực đã bỏ ra.

Bảo hiểm là một số liệu để theo dõi, nhưng nó không phải là mục tiêu cuối cùng. Tôi đã thấy (và được thừa nhận bằng văn bản!) Rất nhiều mã bảo hiểm cao - bảo hiểm 100% (dĩ nhiên là TDD):

• lỗi vẫn xuất hiện
• thiết kế vẫn có thể kém
• bạn thực sự có thể tự giết mình để bắn cho một số mục tiêu bảo hiểm tùy ý - chọn các trận đánh của bạn: p

Có một "Con đường của Testivus" entry mà tôi nghĩ là thích hợp để tham khảo ở đây :)

Chỉ 20% phần lớn mã sẽ chạy 80% thời gian . Phân tích phạm vi bảo hiểm mã không hữu ích trừ khi được ghép nối với biểu đồ cuộc gọi để xác định những gì cần kiểm tra nhất. Điều đó cho bạn biết trường hợp cạnh của bạn có khả năng là. Bạn có thể đưa ra 100 bài kiểm tra chỉ dành cho những trường hợp cạnh đó, chiếm chưa đến 5% mã thực tế.

Vì vậy, hãy đảm bảo bao gồm 100% trong số 20% xác định các đường dẫn quan trọng và ít nhất 50% phần còn lại (theo biểu đồ cuộc gọi). Điều này sẽ giúp bạn (khoảng) 70% - 75% tổng bảo hiểm, nhưng nó khác nhau.

Đừng đốt thời gian cố gắng để có được hơn 70% tổng bảo hiểm trong khi để lại các trường hợp quan trọng mà không cần kiểm tra.

Sử dụng bảo hiểm như một hướng dẫn để chỉ ra các khu vực không được thử nghiệm. Thay vì có một nhiệm vụ bảo hiểm, sẽ khôn ngoan hơn khi hiểu lý do mã không được bảo hiểm. Ghi lại một lý do cho sự thiếu hụt là kỷ luật tốt cho phép các rủi ro được cân bằng.

Đôi khi lý do ít hơn mong muốn 'ví dụ như hết thời gian' nhưng có thể ổn khi phát hành sớm. Tốt hơn là gắn cờ các khu vực để trở lại để tăng cường bảo hiểm sau này.

Tôi làm việc trên phần mềm chuyến bay quan trọng trong đó phạm vi bảo hiểm 100% được coi là phù hợp với các hệ thống không quan trọng. Đối với các hệ thống quan trọng hơn, chúng tôi kiểm tra phạm vi bảo hiểm chi nhánh / quyết định và sử dụng kỹ thuật gọi MC / DC đôi khi không đủ nghiêm ngặt.

Chúng tôi cũng phải đảm bảo rằng chúng tôi cũng đã bao gồm mã đối tượng.

Đó là sự cân bằng giữa rủi ro, trong trường hợp của chúng tôi rất cao, so với giá trị / chi phí. Một sự lựa chọn sáng suốt là cần thiết dựa trên nguy cơ bỏ sót một lỗi.

Khi bạn bắt đầu xem xét các thay đổi sẽ ảnh hưởng đến hiệu suất thời gian chạy, bảo mật, tính linh hoạt hoặc khả năng bảo trì để cho phép bảo hiểm nhiều mã hơn, đã đến lúc kết thúc nhiệm vụ để có thêm bảo hiểm mã.

Tôi có các dự án với điểm đó là 0% vì phạm vi bảo hiểm là không thể tính toán mà không làm tổn hại đến thiết kế và các dự án khác với tỷ lệ cao tới 92%.

Số liệu bảo hiểm mã chỉ hữu ích trong việc chỉ ra rằng bạn có thể đã bỏ lỡ một số bài kiểm tra. Họ không cho bạn biết gì về chất lượng bài kiểm tra của bạn.

Không gian phần mềm quan trọng yêu cầu bảo hiểm 100% tuyên bố.

Lúc đầu nó không có ý nghĩa gì. Mọi người đều biết rằng phạm vi kiểm tra đầy đủ không có nghĩa là mã được kiểm tra đầy đủ và không khó để có được phạm vi bảo hiểm 100% mà không thực sự kiểm tra ứng dụng.

Tuy nhiên, phạm vi bảo hiểm 100% là giới hạn thấp hơn: mặc dù phạm vi bảo hiểm 100% không phải là bằng chứng của phần mềm không có lỗi, nhưng chắc chắn rằng với phạm vi bảo hiểm ít hơn, mã không được kiểm tra đầy đủ và điều này đơn giản là không thể chấp nhận được đối với phần mềm quan trọng.

Tôi thực sự thích câu trả lời của @ RevBingo vì anh ấy gợi ý rằng cuộc đấu tranh hướng tới 100% có thể khiến bạn dọn dẹp hoặc xóa mã không sử dụng. Những gì tôi chưa thấy trong các câu trả lời khác là ý thức khi bạn cần bảo hiểm cao và khi bạn không. Tôi đã đâm sau khi bắt đầu này. Tôi nghĩ rằng việc thêm chi tiết vào biểu đồ như thế này sẽ là một việc theo đuổi hữu ích hơn là tìm một số bao phủ thử nghiệm phù hợp với tất cả các mã.

100%

Đối với API công khai, như Bộ sưu tập java.util, không được kết hợp với Cơ sở dữ liệu và không trả về HTML, tôi nghĩ rằng phạm vi bảo hiểm 100% là mục tiêu bắt đầu cao cả, ngay cả khi bạn giải quyết 90-95% do thời gian hoặc khác ràng buộc. Việc tăng phạm vi kiểm tra sau khi bạn là tính năng hoàn chỉnh buộc mức độ xem xét chi tiết hơn so với các loại đánh giá mã khác. Nếu API của bạn hoàn toàn phổ biến, mọi người sẽ sử dụng nó, phân lớp nó, giải nén nó, v.v. theo những cách bạn không thể mong đợi. Bạn không muốn trải nghiệm đầu tiên của họ là tìm lỗi, hoặc giám sát thiết kế!

90%

Đối với mã cơ sở hạ tầng kinh doanh, có cấu trúc dữ liệu và trả về cấu trúc dữ liệu, 100% vẫn có thể là mục tiêu khởi đầu tốt, nhưng nếu mã này không đủ công khai để mời nhiều người sử dụng sai, có thể 85% vẫn được chấp nhận?

75%

Đối với mã nhận và trả về Chuỗi, tôi nghĩ rằng kiểm thử đơn vị dễ vỡ hơn nhiều, nhưng vẫn có thể hữu ích trong nhiều tình huống.

50% hoặc ít hơn

Tôi ghét viết bài kiểm tra cho các hàm trả về HTML vì nó quá dễ vỡ. Điều gì xảy ra nếu ai đó thay đổi CSS, JavaScript hoặc toàn bộ blob HTML và tiếng Anh mà bạn trả lại không có ý nghĩa gì với người dùng cuối? Nếu bạn có thể tìm thấy một hàm sử dụng nhiều logic nghiệp vụ để tạo ra một ít HTML, thì điều này có thể đáng để thử nghiệm. Nhưng tình huống ngược lại có thể không đáng để thử nghiệm chút nào.

Gần 0%

Đối với một số mã, định nghĩa của "chính xác" là "có ý nghĩa với người dùng cuối." Có những bài kiểm tra phi truyền thống mà bạn có thể thực hiện đối với mã này như kiểm tra ngữ pháp tự động hoặc HTML xác thực đầu ra. Tôi thậm chí đã thiết lập các câu lệnh grep cho những mâu thuẫn nhỏ mà chúng ta thường gặp phải khi làm việc, như nói "Đăng nhập" khi phần còn lại của hệ thống gọi nó là "Đăng nhập". Người đàn ông này không hoàn toàn là một bài kiểm tra đơn vị, nhưng là một cách hữu ích để nắm bắt các vấn đề mà không mong đợi đầu ra cụ thể.

Cuối cùng, chỉ có một con người có thể đánh giá những gì hợp lý với con người. Kiểm tra đơn vị không thể giúp bạn ở đó. Đôi khi phải mất vài người để đánh giá chính xác.

Tuyệt đối 0%

Đây là một thể loại buồn và tôi cảm thấy như một người ít viết nó hơn. Nhưng trong bất kỳ dự án đủ lớn nào cũng có những lỗ thỏ có thể hút người trong nhiều tuần mà không mang lại lợi ích kinh doanh nào.

Tôi đã mua một cuốn sách bởi vì nó tuyên bố sẽ cho thấy cách tự động giả dữ liệu để thử nghiệm Hibernate. Nhưng nó chỉ kiểm tra các truy vấn HQL và Hibernate Hibernate. Nếu bạn phải thực hiện nhiều HQL và SQL, bạn thực sự không nhận được lợi thế của Hibernate. Có một dạng cơ sở dữ liệu trong bộ nhớ Hibernate, nhưng tôi đã không đầu tư thời gian để tìm ra cách sử dụng nó hiệu quả trong các thử nghiệm. Nếu tôi có hoạt động đó, tôi muốn có phạm vi kiểm tra cao (50% -100%) cho bất kỳ logic nghiệp vụ nào tính toán công cụ bằng cách điều hướng một biểu đồ đối tượng khiến Hibernate chạy một số truy vấn. Khả năng kiểm tra mã này của tôi là gần 0% ngay bây giờ và đó là một vấn đề. Vì vậy, tôi cải thiện phạm vi kiểm tra trong các lĩnh vực khác của dự án và cố gắng thích các chức năng thuần túy hơn các chức năng truy cập cơ sở dữ liệu, phần lớn là do việc viết các bài kiểm tra cho các chức năng đó dễ dàng hơn. Vẫn,

Tôi nghĩ rằng nó phụ thuộc vào một phần của ứng dụng bạn đang thử nghiệm. Ví dụ, đối với logic nghiệp vụ hoặc bất kỳ thành phần nào liên quan đến chuyển đổi dữ liệu phức tạp, tôi sẽ nhắm đến mức độ bao phủ 90% (càng cao càng tốt). Tôi thường tìm thấy các lỗi nhỏ nhưng nguy hiểm bằng cách chỉ kiểm tra càng nhiều mã càng tốt. Tôi thà tìm thấy những lỗi như vậy trong quá trình thử nghiệm hơn là để chúng xảy ra tại trang web của khách hàng một năm sau đó. Ngoài ra, một lợi ích của phạm vi bảo hiểm mã cao là nó ngăn mọi người thay đổi mã làm việc quá dễ dàng, vì các thử nghiệm phải được điều chỉnh tương ứng.

Mặt khác, tôi nghĩ có những thành phần mà phạm vi bảo hiểm mã ít phù hợp hơn. Ví dụ, khi kiểm tra GUI, sẽ rất tốn thời gian để viết một bài kiểm tra bao gồm tất cả các mã được thực thi khi nhấp vào nút để gửi sự kiện đến đúng thành phần. Tôi nghĩ trong trường hợp này sẽ hiệu quả hơn nhiều khi sử dụng phương pháp truyền thống để thực hiện kiểm tra thủ công, trong đó bạn chỉ cần nhấp vào nút và quan sát hành vi của chương trình (cửa sổ hộp thoại bên phải có mở ra không? ?).

Tôi không có ý kiến ​​cao về việc sử dụng phạm vi bảo hiểm mã làm thước đo để biết khi nào bộ thử nghiệm của bạn có đủ phạm vi bảo hiểm.

Lý do chính là vì nếu bạn có một quy trình mà trước tiên bạn viết một số mã, sau đó một số thử nghiệm, sau đó xem phạm vi bảo hiểm mã để khám phá nơi bạn đã bỏ lỡ một bài kiểm tra, thì đó là quá trình bạn cần cải thiện. Nếu bạn thực hiện TDD thực sự, thì bạn có phạm vi bảo hiểm mã 100% (phải thừa nhận rằng có một số điều không quan trọng mà tôi không kiểm tra). Nhưng nếu bạn nhìn vào phạm vi bảo hiểm mã để tìm ra những gì cần kiểm tra, thì bạn có thể sẽ viết các bài kiểm tra sai.

Vì vậy, điều duy nhất bạn có thể kết luận từ phạm vi bảo hiểm mã là nếu nó quá thấp, bạn không có đủ các bài kiểm tra. Nhưng nếu nó cao, không có gì đảm bảo rằng bạn có tất cả các bài kiểm tra đúng.