Việc thêm các bài kiểm tra đơn vị có ý nghĩa đối với mã kế thừa nổi tiếng?

• Tôi đang nói về các bài kiểm tra đơn vị theo nghĩa TDD. (Không tự động "tích hợp" hoặc những gì bạn muốn gọi là kiểm tra.)
• Mã kế thừa như trong: (C ++) mã mà không cần kiểm tra. (xem: Hoạt động hiệu quả của Michael Feathers với Bộ luật kế thừa )
• Nhưng cũng có mã kế thừa như trong: Mã mà nhóm chúng tôi đã làm việc trong 10-5 năm qua, vì vậy chúng tôi thường có một ý tưởng khá hay về nơi đặt mọi thứ để thay đổi điều gì đó.
• Chúng tôi có các bài kiểm tra đơn vị tại chỗ (thông qua Boost.Test) cho một số mô-đun đến sau hoặc đã phù hợp "tự nhiên" cho các bài kiểm tra đơn vị (bộ chứa ứng dụng cụ thể, công cụ chuỗi, trình trợ giúp mạng, v.v.)
• Chúng tôi chưa có thử nghiệm chấp nhận tự động thích hợp.

Bây giờ, gần đây tôi đã có "niềm vui" để thực hiện 3 tính năng mới đối mặt với người dùng.

Mỗi người trong số đó mất khoảng 1-2 giờ để tăng tốc với các phần mã tôi cần thay đổi, 1-2 giờ để triển khai mã (nhỏ) mà tôi cần thay đổi và 1-2 giờ nữa để đảm bảo ứng dụng chạy chính xác sau đó và đã làm nó là phải làm.

Bây giờ, tôi thực sự thêm ít mã. (Tôi nghĩ rằng một phương thức và một vài dòng gọi cho mỗi tính năng.)

Bao gồm mã này (thông qua bất kỳ phương pháp nào được đề xuất trong WEwLC ), do đó, một bài kiểm tra đơn vị sẽ có ý nghĩa (và không phải là một tautology hoàn chỉnh) sẽ dễ dàng mất thêm 2-4 giờ, nếu không muốn nói là nhiều hơn. Điều này sẽ tăng thêm 50% -100% thời gian cho mỗi tính năng, không có lợi ích ngay lập tức, như

1. Tôi không cần kiểm tra đơn vị để hiểu bất cứ điều gì về mã
2. Kiểm tra thủ công là cùng một lượng công việc, vì tôi vẫn cần kiểm tra xem mã có được tích hợp chính xác vào phần còn lại của ứng dụng hay không.

Cấp, nếu , sau này, "ai đó" đã đến và chạm vào mã đó, về mặt lý thuyết anh ta có thể có một số lợi ích từ bài kiểm tra đơn vị đó. (Chỉ về mặt lý thuyết, vì hòn đảo mã được thử nghiệm đó sẽ sống trong một đại dương mã chưa được kiểm tra.)

Vì vậy, "lần này" tôi đã chọn không thực hiện công việc khó khăn khi thêm kiểm tra đơn vị: Mã thay đổi để kiểm tra nội dung đó sẽ phức tạp hơn đáng kể so với thay đổi mã để thực hiện chính xác tính năng (và sạch sẽ).

Đây có phải là một cái gì đó điển hình cho mã di sản được kết hợp mạnh mẽ? Tôi có lười biếng không / chúng ta có đặt các ưu tiên sai làm đội không? Hay tôi là người thận trọng, chỉ thử nghiệm những thứ mà chi phí không quá cao?

Bạn phải thực dụng về những tình huống này. Mọi thứ đều phải có giá trị kinh doanh, nhưng doanh nghiệp phải tin tưởng bạn để đánh giá giá trị của công việc kỹ thuật là gì. Vâng, luôn có một lợi ích khi có các bài kiểm tra đơn vị, nhưng liệu lợi ích đó có đủ lớn để biện minh cho thời gian sử dụng không?

Tôi sẽ luôn tranh luận về mã mới, nhưng về mã kế thừa, bạn phải thực hiện một cuộc gọi phán xét.

Bạn có trong lĩnh vực mã này thường xuyên? Sau đó, có một trường hợp để cải tiến liên tục. Bạn đang thực hiện một thay đổi đáng kể? Sau đó, có một trường hợp đó là mã mới. Nhưng nếu bạn đang tạo mã một dòng trong một khu vực phức tạp có thể sẽ không được chạm lại trong một năm, thì tất nhiên chi phí (chưa kể rủi ro) của việc tái cấu trúc là quá lớn. Chỉ cần tát một dòng mã của bạn vào đó và đi tắm nhanh.

Nguyên tắc nhỏ: Luôn tự nghĩ: " Tôi có tin rằng việc kinh doanh được hưởng lợi nhiều hơn từ công việc kỹ thuật này mà tôi cảm thấy tôi nên làm hơn là công việc họ yêu cầu sẽ bị trì hoãn do đó không? "

Việc đạt được các bài kiểm tra đơn vị theo nghĩa TDD là để có được thứ gì đó tự đứng vững, mà không cần truyền thống truyền miệng được xây dựng qua nhiều năm bởi một nhóm ổn định.

Đó là một may mắn lớn khi cùng một đội đã ở cùng một dự án trong rất nhiều thời gian. Nhưng điều này cuối cùng sẽ thay đổi. Người bị bệnh, buồn chán hoặc thăng chức. Họ di chuyển, nghỉ hưu hoặc chết. Những cái mới đến với những ý tưởng mới và sự thôi thúc tái cấu trúc mọi thứ theo cách chúng học ở trường. Các công ty được bán và mua. Chính sách quản lý thay đổi.

Nếu bạn muốn dự án của bạn tồn tại, bạn phải chuẩn bị cho những thay đổi.

Viết bài kiểm tra đơn vị là bằng chứng trong tương lai mã của bạn. Nếu cơ sở mã không có các thử nghiệm, thì bạn nên thêm các thử nghiệm mới cho tất cả các tính năng mới bởi vì nó làm cho đoạn mã đó mạnh mẽ hơn một chút.

Tôi thấy rằng việc thêm các bài kiểm tra, ngay cả trong mã kế thừa, có lợi trong trung hạn đến dài hạn. Nếu công ty của bạn không quan tâm đến trung dài hạn, tôi sẽ tìm một công ty khác. Ngoài ra, tôi không nghĩ rằng sẽ mất nhiều thời gian để kiểm tra thủ công hơn là để viết một bài kiểm tra đơn vị đã đặt. Nếu vậy, bạn cần thực hành mã kata tập trung vào viết bài kiểm tra.

Chắc chắn các cách thực hành tốt nhất chỉ ra bạn nên kiểm tra bất kỳ mã nào bạn thay đổi. Tuy nhiên, tiền mã hóa trong thế giới thực bao gồm rất nhiều thỏa hiệp, thời gian và vật liệu là hữu hạn.

Những gì bạn cần làm là đánh giá chi phí theo cách thực sự để sửa lỗi và thực hiện sửa đổi mà không cần kiểm tra đơn vị. Sau đó, bạn có thể hỗ trợ chống lại đầu tư trong việc tạo ra các thử nghiệm. Các bài kiểm tra đơn vị làm giảm đáng kể chi phí của công việc trong tương lai nhưng bây giờ có giá.

Điểm mấu chốt là nếu hệ thống của bạn hiếm khi thay đổi thì có thể không đáng để viết bài kiểm tra đơn vị nhưng nếu nó chịu sự thay đổi thường xuyên thì nó sẽ có giá trị.

Tất cả những quyết định hợp lý nhỏ này để không tạo ra các bài kiểm tra đang tạo ra một khoản nợ kỹ thuật tê liệt sẽ quay trở lại ám ảnh bạn khi ai đó rời đi và một người thuê mới phải đến và tăng tốc.

Có, có thể mất thêm 2-3 giờ để viết bài kiểm tra đơn vị nhưng nếu mã được gửi lại từ kiểm tra, bạn sẽ phải kiểm tra lại mọi thứ một cách thủ công và lập lại tài liệu kiểm tra của mình - bạn có làm vậy không? Nếu không, làm thế nào có ai biết những gì bạn đã thử nghiệm và những giá trị bạn đã sử dụng?

Các thử nghiệm đơn vị ghi lại hành vi dự kiến ​​của mã mà dữ liệu thử nghiệm được sử dụng để kiểm tra chức năng và cung cấp cho các lập trình viên mới sự tin tưởng hợp lý rằng họ đã không phá vỡ thứ gì đó khi thực hiện các thay đổi.

Nó tốn một vài giờ ngày hôm nay nhiều hơn so với kiểm tra thủ công nhưng sau đó bạn đang kiểm tra mỗi khi bạn thực hiện bất kỳ thay đổi nào tiết kiệm hàng giờ trong vòng đời của mã.

Tuy nhiên, nếu bạn biết rằng mã sẽ bị loại bỏ trong một vài năm, tất cả những gì tôi đã nói thay đổi vì bạn sẽ không hoàn thành việc kiểm tra mã và nó sẽ không bao giờ trả lại.

Giá trị của các bài kiểm tra đơn vị không chỉ nằm ở việc kiểm tra một tính năng mới khi được phát triển. Lợi ích của các bài kiểm tra đơn vị đạt được chủ yếu trong tương lai.

Có, bạn có thể phải dành những gì có vẻ như là một lượng thời gian không phù hợp để làm cho mã kế thừa của bạn có thể kiểm tra được.

Nhưng nếu bạn không, bạn sẽ, hoặc chắc chắn nên , chi tiêu nhiều, nhiều, nhiều giờ hơn thử nghiệm tính năng này. Không chỉ trên sự phát triển ban đầu của nó, mà với mọi phiên bản mới của phần mềm của bạn. Nếu không có đơn vị kiểm tra bạn và các hình thức kiểm tra tự động khác, bạn không có lựa chọn nào khác ngoài việc dành nhiều giờ kiểm tra thủ công để đảm bảo rằng tính năng của bạn không vô tình bị hỏng, ngay cả khi chính tính năng đó không bị thay đổi.