Làm cách nào để yêu cầu gcov bỏ qua các dòng mã C++ không thể chuyển nhượng được?

Question

Tôi đang sử dụng gcov để đo mức độ phù hợp trong mã C++ của mình. Tôi muốn nhận được mức độ phủ sóng 100%, nhưng bị cản trở bởi thực tế rằng có một số dòng mã không có khả năng lý thuyết (các phương thức được yêu cầu nhưng không bao giờ được gọi, các nhánh mặc định là switch) v.v.) Mỗi nhánh trong số này chứa một tuyên bố assert(false);, nhưng gcov vẫn đánh dấu chúng là un-hit.

Tôi muốn có thể yêu cầu gcov bỏ qua các chi nhánh này. Có cách nào để cung cấp cho gcov thông tin đó - bằng cách chú thích mã nguồn hoặc bằng bất kỳ cơ chế nào khác không?

Answer 1

Vui lòng sử dụng lcov.Nó ẩn phức tạp gcov của, sản xuất đầu ra tốt đẹp, cho phép đầu ra chi tiết cho mỗi thử nghiệm, tính năng lọc dễ dàng tập tin và - ta-TAA - đánh dấu dòng cho dòng đã đánh giá:

Từ geninfo (1):

Sau đây dấu hiệu được công nhận bởi geninfo:

• LCOV_EXCL_LINE
  • dòng chứa dấu này sẽ được loại trừ.
• LCOV_EXCL_START
  • đánh dấu sự khởi đầu của một phần loại trừ. Dòng hiện tại là một phần của phần này.
• LCOV_EXCL_STOP
  • đánh dấu sự kết thúc một phần loại trừ. Dòng hiện tại không phải là một phần của phần này.

Answer 2

Tôi không tin điều này là có thể. Gcov phụ thuộc vào gcc để tạo thêm mã để tạo ra mức độ phù hợp. Bản thân GCov chỉ phân tích cú pháp dữ liệu. Điều này có nghĩa là Gcov không thể phân tích mã nào tốt hơn gcc (và tôi giả sử bạn sử dụng -Wall và đã xóa mã được báo cáo là không thể truy cập được). Hãy nhớ rằng các hàm relocatable có thể được gọi từ bất cứ nơi đâu, thậm chí là các dll hay tệp thi hành bên ngoài, do đó không có cách nào trình biên dịch có thể biết chức năng relocatable sẽ không được gọi hoặc những chức năng nào có thể có.

Có thể bạn sẽ cần sử dụng một số công cụ phân tích tĩnh để nhận thông tin mà bạn muốn.

Answer 3

Bạn có thể giới thiệu các bài kiểm tra đơn vị về các chức năng liên quan, chỉ tồn tại để đóng gcov bằng cách trực tiếp tấn công các đường dẫn mã không theo luật không? Vì họ là những bài kiểm tra đơn vị, có lẽ họ có thể bỏ qua "điều không thể" của các tình huống. Họ có thể gọi các hàm không bao giờ được gọi, chuyển các giá trị enum không hợp lệ để bắt các nhánh mặc định, v.v.

Sau đó, chạy các kiểm tra đó chỉ trên phiên bản mã của bạn được biên dịch bằng NDEBUG hoặc chạy chúng trong khai thác thử nghiệm rằng khẳng định được kích hoạt - bất kể khung kiểm thử của bạn hỗ trợ.

Tôi thấy nó hơi kỳ quặc mặc dù thông số kỹ thuật cho biết mã phải ở đó, thay vì thông số chứa các yêu cầu chức năng trên mã. Đặc biệt, điều đó có nghĩa là các thử nghiệm của bạn không thử nghiệm các yêu cầu đó, đó là một lý do tốt để giữ các yêu cầu chức năng. Cá nhân tôi muốn sửa đổi các spec để nói, "nếu được gọi với một giá trị enum không hợp lệ, chức năng sẽ thất bại một assert. Người gọi sẽ không gọi hàm với một giá trị enum không hợp lệ trong chế độ phát hành". Hoặc một số như vậy.

Có lẽ những gì nó hiện đang nói, nằm dọc theo dòng "tất cả các câu lệnh chuyển đổi phải có trường hợp mặc định". Nhưng điều đó có nghĩa là các tiêu chuẩn mã hóa đang can thiệp vào hành vi quan sát (ít nhất, có thể quan sát được dưới gcov) bằng cách giới thiệu mã chết. Tiêu chuẩn mã hóa không nên thực hiện điều đó, vì vậy đặc tả chức năng cần tính đến các tiêu chuẩn mã hóa nếu có thể.

Nếu không, bạn có thể quấn mã không thể chuyển được trong #if !GCOV_BUILD và tạo một bản dựng riêng cho lợi ích của gcov. Xây dựng này sẽ thất bại một số yêu cầu, nhưng có điều kiện phân tích mã của bạn là chính xác, nó mang lại cho bạn sự tự tin mà bạn muốn rằng bộ kiểm thử kiểm tra mọi thứ khác.

Chỉnh sửa: bạn nói rằng bạn đang sử dụng trình tạo mã dodgy, nhưng bạn cũng đang yêu cầu giải pháp bằng cách chú thích mã nguồn. Nếu bạn đang thay đổi nguồn, bạn có thể loại bỏ mã chết trong nhiều trường hợp không? Không phải việc thay đổi nguồn được tạo là lý tưởng, nhưng cần phải ...