Thực tiễn tốt nhất để trang bị thêm mã kế thừa với các bài kiểm tra tự động

Tôi sắp nhận nhiệm vụ thực hiện lại một giao diện đã được xác định (một tập hợp các tệp tiêu đề C ++) trong một cơ sở mã tương đối lớn và cũ. Trước khi làm điều này, tôi muốn có phạm vi kiểm tra đầy đủ nhất có thể, vì vậy tôi có thể phát hiện các lỗi thực hiện càng sớm và dễ dàng càng tốt. Vấn đề là cơ sở mã đã tồn tại không được thiết kế để có thể dễ dàng kiểm tra, với (rất) các lớp và hàm lớn, mức độ khớp nối cao, các hàm có (nhiều) tác dụng phụ, v.v.

Sẽ thật tuyệt khi nghe về bất kỳ kinh nghiệm nào trước đây với các nhiệm vụ tương tự và một số mẹo hay và cụ thể về cách bạn tiến hành trang bị thêm các bài kiểm tra tự động (đơn vị, tích hợp, hồi quy, v.v.) cho mã kế thừa của bạn.

Trước hết, hãy nhận và đọc Làm việc hiệu quả với Bộ luật kế thừa của Michael Feathers - đó là một trợ giúp không thể thiếu cho các nhiệm vụ như vậy.

Sau đó, một vài lưu ý:

• Bạn có một đặc tả / hợp đồng chính xác cho giao diện không, hay thực tế bạn chỉ có triển khai hiện có là "đặc tả"? Trong trường hợp trước, việc viết lại hoàn toàn từ đầu sẽ dễ dàng hơn, trong trường hợp sau thì khó có thể thực hiện được.
• nếu bạn muốn thực hiện lại giao diện, cách hữu ích nhất để sử dụng tài nguyên thử nghiệm của bạn là chỉ viết thử nghiệm đối với giao diện. Tất nhiên, điều này không đủ điều kiện là thử nghiệm đơn vị theo nghĩa nghiêm ngặt, thay vì thử nghiệm chức năng / chấp nhận, nhưng tôi không phải là người theo chủ nghĩa thuần túy :-) Tuy nhiên, các thử nghiệm này có thể sử dụng lại và cho phép bạn so sánh trực tiếp kết quả từ hai triển khai .
• Nhìn chung, tôi sẽ ưu tiên tái cấu trúc mã hiện có hơn là viết lại từ đầu, trừ khi nó hoàn toàn không thể xác định được. (Nhưng trong trường hợp này, bạn sẽ viết bài kiểm tra đơn vị như thế nào?) Hãy xem bài đăng này từ Joel để thảo luận chi tiết hơn về chủ đề này. Việc tạo ra một tập các thử nghiệm chấp nhận đối với giao diện mang lại cho bạn một mạng lưới an toàn mỏng nhưng hữu ích, dựa vào đó bạn có thể bắt đầu tái cấu trúc một cách thận trọng mã hiện có để làm cho nó có thể kiểm tra được (sử dụng các ý tưởng từ cuốn sách của Feathers).

Phương pháp tốt nhất được biết là Phương pháp Mikado. http://mikadomethod.wordpress.com/2010/08/04/the-mikado-method-book/ Đây chỉ là khái quát của một kỹ thuật đơn giản nhưng đó là cách duy nhất tôi biết để bắt đầu cải thiện chất lượng mã trong cơ sở mã lớn mà không chấp nhận rủi ro không cần thiết.

WEWLC cũng là một cuốn sách rất hay về nó nhưng được viết bằng C ++ không phải lúc nào cũng hữu ích với mã Java hoặc Ruby.

Các thử nghiệm phù hợp retro trên một cơ sở mã cũ có thể khá khó khăn nếu nó là nguyên khối trong thiết kế.

Nếu có thể (bạn có thời gian / tiền bạc không), một cách để tiến về phía trước sẽ là tái cấu trúc mã thành các đơn vị dễ kiểm tra hơn.

Tôi muốn thêm một liên kết . Có một vài ví dụ về việc triển khai thử nghiệm không dễ dàng như vậy được tái hiện thành mã thân thiện hơn xUnit. Đối với cách tiếp cận chung, hãy thử các liên kết đã được đề cập (bài Joel, Làm việc với mã Legacy