Làm thế nào để bạn kiểm tra mã đã được bảo hiểm tự động?

Tôi đang trong quá trình thiết lập máy chủ Tre cho một số dự án mới để chuyển sang TDD trong quy trình làm việc CI / CD. Chắc chắn, kiểm tra đơn vị là tuyệt vời, nhưng chỉ là đăng nhập như nó có.

Bây giờ điều này có thể tốt hơn trong một hook nhận trước GIT trên một số nhánh nhất định (ví dụ: phát triển và các nhánh phát hành chính), nhưng nếu thực thi thì phạm vi bảo hiểm mã phải được thực thi như thế nào. Tôi rất vui khi tin tưởng các ủy viên để đảm bảo mã được bảo hiểm, nhưng làm thế nào những điều này được duy trì mà không có bất kỳ sự trượt nào ngoài sự siêng năng và nhất quán?

Nói tóm lại, tôi muốn xem những người khác thi hành phạm vi kiểm tra như một quy trình tự động trong các giai đoạn cam kết hoặc xây dựng.

Bạn không nên thực thi bảo hiểm mã tự động.

Điều này giống như việc thực thi các dòng mã tối đa cho mỗi phương thức: đã đồng ý, hầu hết các phương thức nên nhỏ hơn 20 LỘC, nhưng có những trường hợp hợp lệ trong đó các phương thức sẽ dài hơn thế.

Theo cùng một cách, nhắm mục tiêu một tỷ lệ bao phủ mã cho mỗi lớp có thể dẫn đến hậu quả không mong muốn. Ví dụ:

• Các lớp mã nồi hơi hoặc các lớp được tạo bởi các trình tạo mã có thể không được kiểm tra. Buộc các nhà phát triển thử nghiệm họ sẽ không có bất kỳ lợi ích nào và sẽ có chi phí đáng kể về thời gian dành cho việc đó.

• Xử lý mã đơn giản các phần không quan trọng của ứng dụng không nhất thiết phải được kiểm tra.

• Trong một số ngôn ngữ, một số mã không thể được kiểm tra. Tôi đã có trường hợp này trong C # với các phương thức ẩn danh trên một thư viện nơi tôi thực sự muốn có phạm vi bảo hiểm mã 100%. Những trường hợp đó có thể làm mất tinh thần cho các nhà phát triển.

Quan trọng hơn, phạm vi bảo hiểm mã phải tỷ lệ thuận với hai khía cạnh của mã: mức độ quan trọng và mức độ phức tạp của nó :

• Một đoạn mã với logic phức tạp là một phần của tính năng chính của ứng dụng sẽ được kiểm tra chu đáo hơn, bởi vì thất bại hoặc hồi quy có thể có hậu quả quan trọng.

• Một đoạn mã đơn giản xử lý một tính năng không ai sử dụng có thể có các bài kiểm tra cơ bản chỉ bao gồm các trường hợp cơ bản.

Tất nhiên, bạn vẫn có thể sử dụng phạm vi bảo hiểm mã làm phép đo , đặc biệt là so sánh cách các nhóm khác nhau đạt được phạm vi bảo hiểm mã: có thể có các nhóm ít kỷ luật hơn và miễn cưỡng hơn khi thử nghiệm. Trong những trường hợp đó, bạn có thể muốn kết hợp số liệu này với số liệu khác, chẳng hạn như số lỗi, thời gian giải quyết lỗi hoặc số nhận xét trong quá trình đánh giá mã.

Bạn cũng có thể muốn thực thi ít nhất một số phạm vi bảo hiểm mã, giả sử 60% ¹, đối với các dự án riêng lẻ có ý nghĩa (cẩn thận để loại trừ các nguyên mẫu, mã được tạo, CRUD, v.v.) Để các nhà phát triển có thể đánh dấu các lớp cụ thể là loại trừ từ bảo hiểm mã cũng đẹp². Trong trường hợp này, điều này có thể được thực hiện dưới hình thức kiểm tra không xây dựng nếu phạm vi bảo hiểm mã dưới mức tối thiểu bắt buộc. Tôi sẽ làm điều đó ở giai đoạn xây dựng, không phải giai đoạn cam kết , vì bạn sẽ không chạy thử nghiệm đơn vị trong quá trình cam kết .

^{Tôi sẽ coi 60% là mức tối thiểu hợp lý dựa trên cơ sở mã của mình: gần như mọi dự án hoặc lớp có phạm vi bảo hiểm mã dưới 60% thực sự chưa được kiểm tra . Điều này có thể thay đổi rất nhiều từ ngôn ngữ này sang ngôn ngữ khác và từ công ty này sang công ty khác (ở một số công ty, 0% là tiêu chuẩn). Hãy chắc chắn để thảo luận với nhóm của bạn những gì là bình thường và những gì là quá cao đối với họ. Có thể họ liên tục đạt 95% và có thể dễ dàng nhắm mục tiêu 99% hoặc có thể họ đấu tranh để tăng phạm vi bảo hiểm mã từ 70% lên 75%.}

^{² Cho rằng lạm dụng cuối cùng sẽ được phát hiện trong quá trình đánh giá mã, bạn không nên ngại đưa ra khả năng này cho các nhà phát triển. Điều này tương tự như khả năng loại trừ một số phần của mã khỏi các kiểm tra bởi các bộ kiểm tra kiểu hoặc bộ kiểm tra kiểu. JSLint, StyleCop và Phân tích mã là ba ví dụ trong đó loại trừ được hỗ trợ và thực sự hữu ích mà không khuyến khích lạm dụng.}

Hãy xem xét các mã sau đây:

rsq = a*a + b*b;
if (rsq >= 0.0) {
    r = sqrt(rsq);
}
else {
    handle_this_impossible_event();
}

Không có cách nào để tạo ra một trường hợp thử nghiệm sẽ đến được nhánh khác. Tuy nhiên, nếu đây là phần mềm bay an toàn quan trọng, mọi người sẽ lo lắng về trường hợp của tác giả nếu sự bảo vệ đó không gửi giá trị âm đến sqrtkhông có. Thông thường, việc tính toán rsq = a*a + b*bvà trích xuất căn bậc hai được phân tách bằng nhiều dòng mã. Tạm thời, một tia vũ trụ có thể lật bit dấu hiệu trên rsq.

Trong thực tế, phần mềm chuyến bay đã gọi tương đương handle_this_impossible_event(), nhiều lần. Thông thường, việc này bao gồm chuyển đổi quyền điều khiển sang máy tính dự phòng, tắt máy tính nghi ngờ, khởi động lại máy tính nghi ngờ và cuối cùng là máy tính nghi ngờ đảm nhiệm vai trò sao lưu. Điều đó tốt hơn nhiều so với máy tính bay chính đi whacko.

Ngay cả trong phần mềm máy bay, không thể đạt được phạm vi bao phủ 100% mã. Những người tuyên bố họ đã đạt được điều này hoặc có mã tầm thường hoặc họ không có đủ thử nghiệm chống lại các sự kiện không thể này.

Phạm vi kiểm tra là một số liệu hữu ích cho sức khỏe tổng thể của dự án của bạn. Phạm vi kiểm tra cao cho phép bạn đưa ra quyết định có căn cứ về việc phần mềm có hoạt động như mong đợi khi được triển khai hay không; với phạm vi kiểm tra thấp ngụ ý bạn chỉ đang đoán. Các công cụ tồn tại để đo mức độ bao phủ tự động, chúng thường hoạt động bằng cách chạy chương trình trong ngữ cảnh gỡ lỗi hoặc bằng cách đưa các hoạt động kế toán vào mã được thực thi.

Có nhiều loại thử nghiệm khác nhau và các loại số liệu bảo hiểm khác nhau. Các số liệu bảo hiểm phổ biến bao gồm bảo hiểm chức năng, bảo hiểm tuyên bố, bảo hiểm chi nhánh và bảo hiểm điều kiện, mặc dù có nhiều hơn .

• Kiểm tra đơn vị kiểm tra xem việc triển khai một đơn vị khái niệm (mô-đun, lớp, phương thức, có thể phù hợp với đặc điểm kỹ thuật của nó không (trong TDD, thử nghiệm là đặc điểm kỹ thuật). Các đơn vị không có bài kiểm tra đơn vị của riêng chúng là một lá cờ đỏ, mặc dù chúng có thể được bao phủ bởi các bài kiểm tra kiểu tích hợp.

  Các thử nghiệm đơn vị phải bao hàm phạm vi bao phủ gần như toàn bộ chức năng - vì thử nghiệm đơn vị thực hiện toàn bộ giao diện chung của đơn vị đó, nên sẽ không có chức năng nào không bị các thử nghiệm này chạm vào. Nếu bạn đang giới thiệu thử nghiệm đơn vị cho cơ sở mã hiện có, phạm vi chức năng là một chỉ báo tiến trình thô.

  Một bài kiểm tra đơn vị nên cố gắng bảo hiểm tuyên bố tốt (75% 100%). Bảo hiểm tuyên bố là một số liệu chất lượng cho một bài kiểm tra đơn vị. Tổng bảo hiểm không phải lúc nào cũng có thể, và bạn có thể sử dụng thời gian của mình tốt hơn là cải thiện phạm vi bảo hiểm vượt quá 95%.

  Chi nhánh và điều kiện bảo hiểm là khó khăn hơn. Một đoạn mã càng phức tạp hoặc quan trọng thì các số liệu này càng cao. Nhưng đối với mã không đặc trưng, ​​phạm vi bảo hiểm tuyên bố cao có xu hướng là đủ (và đã bao hàm mức độ bao phủ ít nhất 50%). Nhìn vào báo cáo bảo hiểm điều kiện của một đơn vị có thể giúp xây dựng các trường hợp thử nghiệm tốt hơn.

• Kiểm tra tích hợp kiểm tra xem nhiều đơn vị có thể làm việc chính xác với nhau. Kiểm tra tích hợp có thể rất hữu ích mà không đạt điểm cao trong bất kỳ số liệu bảo hiểm nào. Mặc dù các thử nghiệm tích hợp thường sẽ thực hiện một phần lớn các giao diện của đơn vị của họ (nghĩa là có độ bao phủ chức năng cao), các phần bên trong của các đơn vị này đã được bao phủ bởi các thử nghiệm đơn vị.

Chạy thử nghiệm trước khi mã được sáp nhập vào một nhánh chính là một ý tưởng tốt. Tuy nhiên, việc tính toán các số liệu bảo hiểm kiểm tra cho toàn bộ chương trình có xu hướng mất nhiều thời gian - đây là một công việc tốt cho việc xây dựng hàng đêm. Nếu bạn có thể tìm ra cách để làm điều này, một thỏa hiệp tốt sẽ là chỉ chạy các thử nghiệm đã thay đổi hoặc thử nghiệm đơn vị trên các đơn vị đã thay đổi trong một móc Git. Thất bại trong thử nghiệm không được chấp nhận đối với bất cứ điều gì khác ngoài công việc trong tiến trình của các thành viên. Nếu số liệu bảo hiểm được chọn giảm xuống dưới một số ngưỡng (ví dụ: phạm vi bảo hiểm tuyên bố dưới 80% hoặc giới thiệu các phương pháp mới mà không có bất kỳ thử nghiệm tương ứng nào), thì những vấn đề này sẽ được coi là một cảnh báo, với cơ hội cho nhà phát triển khắc phục các vấn đề tiềm ẩn này. Tuy nhiên, đôi khi có những lý do chính đáng để bỏ qua những cảnh báo này và các nhà phát triển sẽ có thể làm như vậy.

Kiểm tra là tốt, nhưng quá nhiều có thể gây phiền nhiễu. Phản hồi nhanh, có liên quan có thể giúp thúc đẩy sự chú ý đến chất lượng, nhưng bạn không muốn nó cản trở việc tạo ra giá trị. Cá nhân tôi thích chạy thử nghiệm bằng tay, vì nó cho phép tôi nhận được phản hồi nhanh hơn về phần tôi đang làm việc. Trước khi phát hành, tôi sẽ tập trung vào chất lượng nơi tôi sử dụng phân tích tĩnh, trình biên dịch và các công cụ bao phủ mã để tìm các vùng có vấn đề (với một số bước này là một phần của bộ kiểm tra trước khi phát hành).

Noone đã đề cập đến các xét nghiệm đột biến . Ý tưởng đằng sau chúng là khá thực tế và trực quan.

Chúng hoạt động bằng cách sửa đổi mã nguồn ngẫu nhiên (ví dụ: chuyển ">" thành "<") - do đó đột biến - và kiểm tra xem những thay đổi hỗn loạn này có phá vỡ bất kỳ thử nghiệm nào không.

Nếu họ không, thì a) mã được đề cập có thể không cần thiết hoặc b) (nhiều khả năng) đoạn mã này không được kiểm tra, vì việc phá vỡ nó không bị phát hiện.

Tất nhiên, dữ liệu bảo hiểm mã có thể được lấy tự động, nhưng không nên đưa ra quyết định tự động dựa trên chúng, vì những lý do mà người khác đã giải thích. (Quá mờ, quá nhiều chỗ cho lỗi.)

Tuy nhiên, điều tốt nhất tiếp theo là có một quy trình được thiết lập theo đó trạng thái hiện tại của dự án về phạm vi bảo hiểm mã được kiểm tra thường xuyên bởi con người, có thể với các báo cáo hàng ngày đến hộp thư đến của người quản lý dự án.

Trong môi trường doanh nghiệp, điều này đạt được với các công cụ Tích hợp liên tục như Hudson, Jenkins, v.v. Những công cụ này được cấu hình để thường xuyên kiểm tra toàn bộ dự án từ kho lưu trữ mã nguồn, xây dựng nó, chạy thử nghiệm và tạo báo cáo. Tất nhiên, chúng có thể được cấu hình để chạy thử nghiệm trong chế độ bao phủ mã và bao gồm các kết quả trong các báo cáo này.

Jetbrains cũng làm cho TeamCity, có vẻ như nhẹ hơn một chút và phù hợp với các cửa hàng phần mềm nhỏ hơn.

Vì vậy, người quản lý dự án nhận được báo cáo bảo hiểm mã thường xuyên, sử dụng phán đoán tốt của chính mình và đóng vai trò là người thi hành nếu cần.

Phạm vi bảo hiểm mã có thể được kiểm tra tự động, mặc dù có ý kiến ​​phổ biến, bộ công cụ Purify của Rational có tính năng bao phủ mã. Nó dựa vào thiết bị đo tất cả các chức năng (nó hoạt động trên các nhị phân, cập nhật từng chức năng hoặc gọi với một chút mã bổ sung) để có thể ghi ra dữ liệu được hiển thị cho người dùng. Công nghệ khá tuyệt, đặc biệt là vào thời điểm đó.

Tuy nhiên, ngay cả khi chúng tôi đã cố gắng thực sự, thực sự khó khăn để có được bảo hiểm 100%, chúng tôi chỉ quản lý được 70% hoặc hơn thế! Vì vậy, nó là một chút của một bài tập vô nghĩa.

Tuy nhiên, trong tình huống viết bài kiểm tra đơn vị, tôi nghĩ rằng phạm vi kiểm tra đơn vị 100% thậm chí còn vô nghĩa hơn. Đơn vị kiểm tra các phương thức yêu cầu kiểm tra đơn vị, không phải mọi getter hay setter! Kiểm thử đơn vị nên là về việc xác minh các chức năng khó khăn (hoặc các lớp TBH) và không cố gắng đánh dấu vào các hộp trong một số quy trình hoặc công cụ hiển thị các dấu tick màu xanh lá cây đẹp.

Tôi đã xây dựng một công cụ cho việc này

https://github.com/exussum12/coverageChecker

Sử dụng

bin/diffFilter --phpunit diff.txt clover.xml 70

Sẽ thất bại nếu dưới 70% độ lệch được bao phủ bởi các bài kiểm tra đơn vị.

Lấy khác biệt bằng.

git diff origin/master... > diff.txt

Giả sử bạn phân nhánh từ chủ và sẽ hợp nhất trở lại thành chủ

Bỏ qua cờ phpunit trong mã, nó thực sự chỉ là kiểm tra clover để bất cứ thứ gì có thể xuất ra clover đều có thể sử dụng nó.

Vì các câu trả lời khác được đề xuất đưa ra 100% không phải là ý hay