Làm cách nào để tạo một môi trường trong đó sửa lỗi kiểm tra được coi là ưu tiên?

Tôi là một kỹ sư phần mềm tại một công ty cỡ trung bình. Chúng tôi có một nền tảng thử nghiệm khá mạnh mẽ chạy trên TeamCity. Nó thực hiện kiểm tra đơn vị trên mỗi lần đăng ký và chạy thử đơn vị hàng ngày / BVT.

Vấn đề là - chúng tôi có rất nhiều bài kiểm tra đơn vị bị hỏng.

Rất thường xuyên, tôi đưa ra sự vô nghĩa của các bài kiểm tra đơn vị nếu chúng liên tục bị phá vỡ và không rõ ràng. Không thể xem liệu một thay đổi có gây ra hồi quy sẽ loại bỏ hầu hết giá trị của nền tảng thử nghiệm đơn vị hay không.

Tôi muốn có một hạt giống được trồng sẽ tạo ra văn hóa thói quen tốt - sửa các bài kiểm tra khi chúng bị hỏng, xem chúng là có giá trị, ưu tiên sửa các bài kiểm tra cùng với các công việc khác.

Tôi đã thử hối lộ (đồ nướng!), Chỉ đơn giản là hỏi và nói chuyện với các trưởng nhóm. Mọi người đều nói rằng đó là một ý tưởng tốt, nhưng tôi thấy là người duy nhất làm bất cứ điều gì về nó.

Cách tốt nhất để bắt đầu khuyến khích người khác sửa bài kiểm tra của họ và ưu tiên sửa bài kiểm tra trong giai đoạn nước rút của họ là gì?

Nếu có một cách ít chủ quan hơn để hỏi điều này, tôi sẽ vui lòng chấp nhận bất kỳ lời khuyên nào.

— Nhân viên mật mã
nguồn

súng nerf tự động nhằm vào anh chàng phá vỡ công trình ...

— ratchet freak

Chúng tôi thực sự có một khẩu súng nerf tự động ... nhưng bản dựng không bị hỏng, chỉ là các bài kiểm tra đơn vị :)

— Codeman

Phá vỡ các bài kiểm tra đơn vị nên ngụ ý phá vỡ xây dựng. ;)

— Jeroen Vannevel

@: Mua vào rất quan trọng, nhưng bạn không thể mua để giải quyết vấn đề cho đến khi mọi người thực sự nhận thức được vấn đề. Trong trường hợp này, nhu cầu mua ban đầu chỉ đến từ các trưởng nhóm và quản lý. Việc mua vào của nhà phát triển có thể đến sau và nói chung, một cách tự nhiên, khi hệ thống xây dựng đã được thiết lập để khiến các nhà phát triển cá nhân trả tiền cho những sai lầm của chính họ.

— Aaronaught

Nếu bánh rán thất bại, bạn sẽ nướng. :-)

— Ross Patterson

Câu trả lời:

Làm cho nó không thể thực sự phát hành bất cứ điều gì mà không sửa chữa các bài kiểm tra.

Thất bại trong việc xây dựng nếu bất kỳ thử nghiệm thất bại.
Thất bại trong việc xây dựng nếu bất kỳ bài kiểm tra nào bị bỏ qua.
Thất bại trong quá trình xây dựng nếu phạm vi kiểm tra xuống dưới một mức nhất định (vì vậy mọi người không thể xóa các kiểm tra để xử lý xung quanh nó).
Sử dụng máy chủ CI để thực hiện các bản dựng phát hành của bạn và chỉ cho phép các bản dựng từ bản dựng bản dựng của máy chủ được thăng cấp lên UAT / dàn / sản xuất / bất cứ thứ gì.

Thực tế của vấn đề là, nếu bản dựng của bạn bị hỏng trong hơn 15 phút mỗi lần (và bao gồm các bài kiểm tra không thành công), thì bạn không thực hiện tích hợp liên tục .

"Tùy chọn hạt nhân" là để máy chủ kiểm soát nguồn của bạn từ chối xác nhận / đăng ký từ bất kỳ người dùng nào khác ngoài người đã phá vỡ bản dựng. Rõ ràng một quản trị viên cần có khả năng ghi đè tạm thời nếu người này nói đi nghỉ - nhưng, nếu mọi người biết rằng toàn bộ nhóm bị lừa cho đến khi họ sửa bài kiểm tra của mình, thì họ sẽ giải quyết nhanh chóng.

Một chính sách tốt (thậm chí còn tốt hơn khi được tự động hóa) là hoàn nguyên nguồn về cam kết ổn định đã biết cuối cùng sau 15 phút xây dựng không thành công. Nói cách khác, nếu bạn không thể sửa nó hoặc không biết nguyên nhân khiến bản dựng hoặc bản thử nghiệm bị hỏng, thì hãy hoàn nguyên nó và hoạt động cục bộ cho đến khi nó được giải quyết - không bao giờ khiến các nhà phát triển khác vặn ngón tay cái trong khi bạn nghiền nát vấn đề họ không quan tâm.

PS Nếu bạn đã có rất nhiều bài kiểm tra thất bại, bạn có thể sử dụng "ngưỡng theo dõi" trong CI. Thiết lập nó để bản dựng chỉ thất bại nếu có nhiều lỗi kiểm tra hơn lần trước. Điều này, cùng với quy tắc bảo hiểm, sẽ buộc các nhà phát triển cuối cùng cải thiện tình hình thử nghiệm nếu họ muốn có thể tiếp tục làm việc.

PPS Tôi nhận ra điều này có vẻ hà khắc với một số người, nhưng tất cả đều thuộc về văn hóa của bạn. Nếu bạn đến một điểm mà mọi người chỉ không làm cho bản dựng bị hỏng hoặc các bài kiểm tra thất bại (nhóm của tôi hầu như không bao giờ làm điều đó, mặc dù tôi thỉnh thoảng phải nhắc nhở họ), thì bạn không cần phải tiếp tục với bộ quy tắc nghiêm ngặt nhất. Mặc dù IMO, bạn nên luôn thất bại trong quá trình xây dựng bài kiểm tra đơn vị bị hỏng. Kiểm tra tích hợp / trình duyệt đôi khi có thể thất bại.

— Aaron
nguồn

Mặc dù tất cả các gợi ý kỹ thuật của bạn đều hữu ích, tôi nghĩ phần quan trọng nhất trong câu trả lời của bạn là đó là tất cả văn hóa của bạn. Vì hơn cả vấn đề kỷ luật, đó là vấn đề về tiện ích của bài kiểm tra. Tôi thà đặt nó lên phía trước hơn trong PPS

— dùng40989

@ user40989: Tôi nghe bạn. Văn hóa là một cái gì đó bạn phải trau dồi, mặc dù. Nếu bạn muốn mọi người hiểu các bài kiểm tra quan trọng như thế nào, đôi khi bạn phải làm cho nó để mọi người không thể bỏ qua chúng. Khi mọi người đã quen với mức độ bao phủ mã cao và các thử nghiệm xanh, họ sẽ không muốn quay lại và sau đó các nhà phát triển của riêng bạn sẽ thực thi nó cho các tân binh. Vâng, hy vọng. Một trưởng nhóm hậu môn-giữ lại và / hoặc xây dựng tổng thể và / hoặc người quản lý giúp. :)

— Aaronaught

FWIW: Toàn bộ quy trình phát hành của chúng tôi hiện đã được tự động hóa và mọi người sẽ không nghĩ đến việc thử nghiệm bị hỏng. Trưởng nhóm thực hiện hợp nhất thành chủ, sau đó bắt đầu xây dựng bản phát hành và gửi yêu cầu quảng cáo đến các sysadins, người thực sự nhấn nút để triển khai từ các tạo phẩm xây dựng và chạy thử nghiệm trình duyệt và API tự động. Không ai phàn nàn về quy trình này, bởi vì nó tiết kiệm thời gian - chúng tôi thường dành 2 tuần để loay hoay cho một bản phát hành, bây giờ về cơ bản nó là một handwave. Ý tôi là bằng cách trau dồi văn hóa - mọi người đều biết rằng thêm 2 phút để sửa bài kiểm tra sẽ tiết kiệm được 2 giờ sau đó.

— Aaronaught

Các bài kiểm tra đơn vị không thành công không phải là vấn đề. Chúng là một triệu chứng .

Vấn đề thực sự là trong văn hóa. Bạn cần bước đi nhẹ nhàng: ở đây là những con rồng . Bạn không thể tự thay đổi văn hóa và cuối cùng, việc trở thành một tay lái cừ khôi sẽ khiến bạn trở thành kẻ bị ruồng bỏ. Nghĩa đen

Tôi đề nghị rằng nếu bạn cố gắng tìm một người cao cấp để vô địch nguyên nhân và dẫn đường. Nếu thất bại, hãy thử nâng nó trong một cuộc họp của các nhà phát triển chung, mà không chỉ tay hoặc gọi tên. Một cách khác là tự chịu trách nhiệm về việc thực hiện một công việc phù hợp: chỉ cần sửa một số bài kiểm tra khác mỗi khi bạn đăng ký. Giữ một biểu đồ trên tường cho thấy có bao nhiêu bài kiểm tra thất bại theo thời gian. Những người khác sẽ thấy nó: có thể họ sẽ chọn tham gia.

Không có câu trả lời dễ dàng.

— andy256
nguồn

Là bánh xe chói tai làm cho tôi dẫn đầu nhóm. Có lẽ có điều gì đó không ổn với tiếng rít của bạn? Mặc dù vậy, trong tất cả sự nghiêm túc, điều đó nói lên một vấn đề văn hóa rất khác , không phải với đội ngũ phát triển mà là với sự quản lý của công ty. Nếu phản ứng của ban quản lý đối với một ngọn lửa đang cháy là đeo kính râm, thì hãy ra khỏi đó đi. Nhưng nếu bạn thực sự là một cửa hàng phát triển , trái ngược với bộ phận CNTT doanh nghiệp phát hành phần mềm từ trung tâm chi phí, thì rất có khả năng các nhà quản lý quan tâm đến những thứ như mức độ thường xuyên và an toàn mà bạn có thể phát hành ra thị trường.

— Aaronaught