Chúng ta có nên loại trừ mã cho phân tích bảo hiểm mã?

Tôi đang làm việc trên một số ứng dụng, chủ yếu là những ứng dụng cũ. Hiện tại, phạm vi bảo hiểm mã của họ khá thấp: thường từ 10 đến 50%.

Kể từ vài tuần, chúng tôi đã thảo luận thường xuyên với các nhóm ở Bangalore (phần chính của sự phát triển được thực hiện ở nước ngoài) về việc loại trừ các gói hoặc lớp cho Cobertura (công cụ bảo hiểm mã của chúng tôi, ngay cả khi chúng tôi hiện đang di chuyển sang JaCoCo).

Quan điểm của họ là như sau: vì họ sẽ không viết bất kỳ bài kiểm tra đơn vị nào trên một số lớp của ứng dụng (1) , các lớp này nên được loại trừ khỏi biện pháp bao phủ mã. Nói cách khác, họ muốn giới hạn biện pháp bao phủ mã đối với mã được kiểm tra hoặc nên được kiểm tra .

Ngoài ra, khi họ làm việc trong bài kiểm tra đơn vị cho một lớp phức tạp, các lợi ích - hoàn toàn về mặt bảo hiểm mã - sẽ không được chú ý do trong một ứng dụng lớn. Giảm phạm vi bảo hiểm mã sẽ làm cho loại nỗ lực này rõ ràng hơn ...

Sự quan tâm của phương pháp này là chúng tôi sẽ có một biện pháp bảo hiểm mã cho biết trạng thái hiện tại của một phần của ứng dụng mà chúng tôi coi là có thể kiểm tra được .

Tuy nhiên, quan điểm của tôi là bằng cách nào đó chúng ta đang giả mạo các số liệu. Giải pháp này là một cách dễ dàng để đạt được mức độ bao phủ mã cao hơn mà không cần bất kỳ nỗ lực nào. Một điểm khác làm phiền tôi là như sau: nếu chúng tôi hiển thị mức tăng bảo hiểm từ tuần này sang tuần khác, làm thế nào để biết tin tốt này là do công việc tốt của các nhà phát triển hay đơn giản là do loại trừ mới?

Ngoài ra, chúng tôi sẽ không thể biết chính xác những gì được xem xét trong biện pháp bảo hiểm mã. Ví dụ: nếu tôi có 10.000 dòng ứng dụng mã với 40% phạm vi bảo hiểm mã, tôi có thể khấu trừ 40% cơ sở mã của mình đã được kiểm tra (2) . Nhưng điều gì xảy ra nếu chúng ta đặt loại trừ? Nếu phạm vi bảo hiểm mã bây giờ là 60%, tôi có thể khấu trừ chính xác những gì? 60% cơ sở mã "quan trọng" của tôi đã được kiểm tra? Làm thế nào tôi có thể

Theo như tôi biết, tôi thích giữ giá trị bảo hiểm mã "thực", ngay cả khi chúng tôi không thể vui vẻ về điều đó. Ngoài ra, nhờ có Sonar, chúng tôi có thể dễ dàng điều hướng trong cơ sở mã của mình và biết, đối với bất kỳ mô-đun / gói / lớp nào, phạm vi bảo hiểm mã riêng của nó. Nhưng tất nhiên, phạm vi bảo hiểm mã toàn cầu vẫn sẽ thấp.

Ý kiến ​​của bạn về chủ đề đó là gì? Làm thế nào để bạn làm trên các dự án của bạn?

Cảm ơn.

(1) Các lớp này thường liên quan đến các hạt UI / Java, v.v.

(2) Tôi biết điều đó không đúng. Trên thực tế, điều đó chỉ có nghĩa là 40% cơ sở mã của tôi

Tôi thường loại trừ mã được tạo tự động, chẳng hạn như các máy khách WCF mà Visual Studio tạo. Thường có rất nhiều dòng mã ở đó và chúng tôi sẽ không bao giờ kiểm tra chúng. Điều này làm cho nó rất mất tinh thần để tăng thử nghiệm trên một đoạn mã lớn ở nơi khác và chỉ tăng độ bao phủ mã lên 0,1%.

Tôi cũng sẽ loại trừ các tương tác của lớp dữ liệu, miễn là nhóm có thể nói chắc chắn rằng lớp này mỏng nhất có thể. Mặc dù bạn có thể lập luận rằng, nếu lớp mỏng, nó sẽ không có hiệu ứng lớn, nó sẽ để lại rất nhiều thành phần trong báo cáo bảo hiểm với 0% chống lại chúng, vì vậy chúng tôi không nhất thiết phải chú ý đến những thứ chúng ta cần để thực sự lo lắng về. Lớp UI có thể được lập luận theo cách tương tự, tùy thuộc vào khung được sử dụng.

Nhưng, như một điểm phản biện, tôi cũng sẽ loại trừ các bài kiểm tra đơn vị. Họ phải luôn có phạm vi bảo hiểm ~ 100% và họ chiếm một tỷ lệ lớn trong cơ sở mã, các số liệu xiên lên một cách nguy hiểm.

Câu hỏi hay. Nói chung, tôi có xu hướng loại trừ mã khỏi phạm vi bảo hiểm mã vì một số lý do, ví dụ:

• tạo ra
• di sản (không cập nhật nữa)
• Nó đến đây: một số lớp nhất định, tôi không có ý định thử nghiệm

Tại sao điểm cuối cùng? Tôi nghĩ rằng đó là một thực hành tốt để tập trung vào những điều tôi quan tâm, trong khi ngăn chặn phiền nhiễu. Nếu bạn không có ý định kiểm tra Lớp UI, tại sao phải xem xét nó - nó sẽ chỉ thu hút sự chú ý khỏi phần quan trọng của phần mềm của bạn - logic nghiệp vụ.

NHƯNG:

1. Bạn nên có một lý do chính đáng, tại sao loại trừ một lớp nhất định khỏi kiểm tra đơn vị (có thể có câu hỏi - từ sếp, đồng đội của bạn, báo chí ;-)
2. Nếu bạn muốn họ kiểm tra các lớp này, bạn nên đưa chúng vào phần thống kê để hiển thị cho cả nhóm, mỗi ngày điều đó rất quan trọng và cần phải được thực hiện.

Cuối cùng: đừng quá coi trọng con số. Bảo hiểm 30% có thể chứng minh một phần mềm vững chắc, khi đó là phần thiết yếu của nó.

Tôi có xu hướng đồng ý với bạn và bao gồm tất cả các mã có liên quan trong các số liệu bảo hiểm mã (và Sonar nói chung). Ngay cả khi bạn không có kế hoạch kiểm tra một số phần của mã (trong tương lai gần), số liệu sẽ phản ánh trạng thái thực tế. Điều này buộc bạn phải có một lý do thuyết phục để không viết các bài kiểm tra cho một phần quan trọng của cơ sở mã. Cuối cùng (một khi khác, các phần quan trọng hơn của mã đã được trình bày) bạn có thể xem xét lại hoặc chọn một cách khác để loại bỏ sự bất đồng này - ví dụ: bằng cách tái cấu trúc mã trong câu hỏi để có thể kiểm tra được hoặc chuyển tất cả logic từ nó sang khác nhau, một phần có thể kiểm tra của cơ sở mã, hoặc thậm chí để loại bỏ toàn bộ lớp (nếu một lớp không đáng để kiểm tra, liệu nó có đủ lý do để tồn tại không?)

Trong các dự án hiện tại của tôi, chúng tôi cũng bao gồm tất cả các mã theo số liệu, với một ngoại lệ: mã được tạo, tạo ra vô số cảnh báo phân tích tĩnh. Vì mã này thường bao gồm các lớp POD hài hước mà không có logic nào, nên không có gì để kiểm tra cả.

Bây giờ tôi không quen thuộc nhiều với các công cụ bao phủ mã mà bạn đang sử dụng cũng như tôi không quen thuộc với các hạt Java, nhưng từ những gì bạn nói chúng có liên quan đến UI.

Với kiến ​​thức hạn hẹp của mình, tôi có điều này để nói:

1. Đừng để con số bởi bất kỳ loại công cụ kiểm tra nào cản trở bài kiểm tra của bạn.
2. Nếu các lớp là phức tạp và không phải là đơn vị kiểm tra được, thì luôn luôn nên tính lại chúng thành các lớp nhỏ gọn hơn và có thể kiểm tra được. Nó sẽ đòi hỏi rất nhiều nỗ lực và cống hiến nhưng nó sẽ trả tiền trong thời gian dài.
3. Việc kiểm tra các thành phần UI có thể khó khăn, nhưng bạn vẫn có thể kiểm tra chức năng đang được thực hiện bởi các thành phần đó.
4. Nếu bạn đang làm một dự án dựa trên web thì bạn có thể sử dụng QUnit để kiểm tra đơn vị tất cả các mã phía máy khách.

Nói chung, bạn nên nhớ rằng phạm vi bảo hiểm mã chỉ là một con số và phạm vi bảo hiểm mã cao không cho thấy các thử nghiệm tốt. Tập trung vào việc làm cho các thư viện cốt lõi mạnh mẽ hơn và có thể kiểm tra hơn là nhắm đến tỷ lệ phần trăm cao hơn.

Một số loại trừ có ý nghĩa (mã tấm nồi hơi không có tác động thực sự hoặc tiềm năng tác động đến dự án của bạn hoạt động chính xác). Ngay cả việc vẫn thu thập bảo hiểm mã dưới dạng số liệu là vô nghĩa vì dù sao nó cũng không cho bạn biết bất cứ điều gì hữu ích. Bảo hiểm mã 100% không phải là mục tiêu thực sự và số lượng bảo hiểm thấp cũng có thể không tệ tùy thuộc vào dự án, có thể bảo hiểm mã 20-30% bao gồm mọi thứ đáng để thử nghiệm. bảo hiểm mã chỉ cho bạn biết X% mã của bạn có khả năng bao phủ thực sự là bằng một số loại thử nghiệm không rõ chất lượng.

Tôi đề nghị báo cáo một bộ số liệu cho từng lớp mã của bạn. Các số liệu này phải bao gồm thông tin kích thước (ví dụ: LoC, số thư viện, số lớp hoặc phương thức, v.v.), thông tin kiểm tra (ví dụ: phạm vi bảo hiểm) và thông tin lỗi (ví dụ: tìm và sửa tỷ lệ).

Các lớp bị loại trừ của bạn sẽ có phạm vi bảo hiểm 0% và các khu vực được thử nghiệm của bạn sẽ có phạm vi bảo hiểm 60% mà bạn đã đề cập. Thông tin kích thước sẽ cho mọi người hiểu bao nhiêu chưa được kiểm tra hoặc thử nghiệm. Thông tin lỗi sẽ thông báo cho bạn nếu bạn có thể nên tạo các thử nghiệm cho các lớp bị loại trừ và nếu các thử nghiệm hiện tại của bạn đang hoạt động.

Rất dễ để các tổ chức phần mềm trở nên quá tập trung vào độ tinh khiết của các số liệu. Chúng tôi không tạo ra số liệu, chúng tôi tạo ra phần mềm tốt. Một số liệu giúp bạn cung cấp phần mềm chất lượng cao một cách kịp thời là số liệu trung thực nhất, thuần túy nhất có.