Thêm các bài kiểm tra đơn vị vào mã kế thừa [đã đóng]

Bạn đã bao giờ thêm các bài kiểm tra đơn vị vào mã kế thừa chưa? Làm thế nào phức tạp là mã và làm thế nào khó khăn để khai thác và mô phỏng mọi thứ? Kết quả cuối cùng có đáng giá không?

Cách tốt nhất, tôi đã tìm thấy, là thêm dần các bài kiểm tra đơn vị, không chỉ nhảy vào và nói rằng bây giờ chúng tôi sẽ kiểm tra đơn vị ứng dụng.

Vì vậy, nếu bạn định chạm vào mã, để sửa lỗi hoặc tái cấu trúc, thì trước tiên hãy viết các bài kiểm tra đơn vị. Đối với các bài kiểm tra đơn vị lỗi sẽ giúp chứng minh vấn đề nằm ở đâu, vì bạn có thể sao chép nó.

Nếu tái cấu trúc, bạn sẽ muốn viết các bài kiểm tra đơn vị, nhưng bạn có thể thấy rằng bài kiểm tra đó không thể viết được, vì vậy bạn có thể cần tìm một cấp độ cao, gọi hàm sẽ được cấu trúc lại và kiểm tra đơn vị phần đó. Sau đó, khi bạn cấu trúc lại chức năng tấn công, hãy viết các bài kiểm tra của bạn để bạn có thể đảm bảo rằng nó đang hoạt động như bình thường.

Không có cách nào dễ dàng để làm điều này.

Câu hỏi này có thể giúp đưa ra nhiều gợi ý hơn. Làm cách nào để bạn đưa kiểm thử đơn vị vào một cơ sở mã kế thừa (C / C ++)?

Cuốn sách của Michael Feathers "Làm việc hiệu quả với Mã di sản" là toàn bộ cuốn sách đề cập đến chủ đề này. Michael nói rằng thường quá khó để giới thiệu các bài kiểm tra cho mã kế thừa vì nó không được cấu trúc để có thể kiểm tra được. Điều tôi nhận ra từ cuốn sách nhiều nhất là một vài mẫu có tên "Hàm mầm" và "Lớp mầm". Hàm nảy mầm là một hàm đóng gói thay đổi mà bạn cần thực hiện trong mã. Sau đó, bạn chỉ kiểm tra các chức năng này. Lớp mầm là cùng một ý tưởng ngoại trừ chức năng mới được chứa trong một lớp.

Có, và nói chung là rất đau. Thay vào đó, tôi thường phải viết các bài kiểm tra tích hợp.

Cuốn sách The Art of Unit Testing có một số lời khuyên hữu ích về điều này. Nó cũng giới thiệu cuốn sách Làm việc hiệu quả với Mã kế thừa ; Tôi chưa đọc phần thứ hai, nhưng nó nằm trong ngăn xếp của tôi.

CHỈNH SỬA: Nhưng có, ngay cả độ phủ mã tối thiểu cũng đáng giá. Nó đã mang lại cho tôi sự tự tin và một mạng lưới an toàn để cấu trúc lại mã.

CHỈNH SỬA: Tôi đã đọc Làm việc hiệu quả với Mã kế thừa và nó rất xuất sắc.

Cũng hãy nhìn vào cách tiếp cận mới trong lĩnh vực kiểm thử đơn vị mã kế thừa - dự án Asis , nó được lấy cảm hứng từ dự án ApprovalTests và chia sẻ các khái niệm chính của nó.

Như đã đề cập về phương pháp ApprovalTests trong bài viết này :

Thường thì bạn có một dự án mã kế thừa khổng lồ mà bạn không có thử nghiệm nào cả, nhưng bạn phải thay đổi mã để triển khai một tính năng mới hoặc trình cấu trúc lại. Điều thú vị về mã kế thừa là - Nó hoạt động! Nó hoạt động trong nhiều năm, bất kể nó được viết như thế nào. Và đây là một ưu điểm rất lớn của mã đó. Với việc phê duyệt, chỉ với một lần kiểm tra, bạn có thể nhận được tất cả các đầu ra có thể có (HTML, XML, JSON, SQL hoặc bất kỳ đầu ra nào có thể là) và chấp thuận, bởi vì bạn biết đấy - nó hoạt động! Sau khi bạn đã hoàn thành bài kiểm tra như vậy và được chấp thuận kết quả, bạn thực sự an toàn hơn nhiều với việc tái cấu trúc, vì bây giờ bạn đã "khóa" tất cả các hành vi hiện có.

Công cụ Asis chính xác là về việc ghi nhớ mã kế thừa thông qua việc tạo và chạy các bài kiểm tra mô tả đặc tính một cách tự động.

Để biết thêm thông tin, hãy xem tại

• README chi tiết trong github repo của dự án
• thảo luận về tin tức hacker
• thảo luận trên reddit.com/r/php
• thảo luận trên reddit.com/r/programming

Một thay thế cho các bài kiểm tra đơn vị, cũng được giới thiệu trong Làm việc hiệu quả với mã kế thừa là các bài kiểm tra đặc tính . Tôi đã có kết quả thú vị với các bài kiểm tra như vậy. Chúng dễ thiết lập hơn các bài kiểm tra đơn vị khi bạn kiểm tra từ điểm hơn có thể được kiểm tra (được gọi là đường may). Hạn chế là khi kiểm tra không thành công, bạn có ít gợi ý hơn về vị trí của vấn đề vì khu vực được kiểm tra có thể lớn hơn nhiều so với kiểm tra đơn vị. Ghi nhật ký giúp ở đây.

Một khung kiểm thử đơn vị như họ xUnit có thể được sử dụng để viết các bài kiểm tra đặc tính.

Trong các bài kiểm tra như vậy, được viết sau các dữ kiện, xác nhận xác minh hành vi hiện tại của mã. Không giống như các bài kiểm tra đơn vị, chúng không chứng minh rằng mã là đúng, chúng chỉ ghim lại (mô tả đặc điểm) hành vi hiện tại của mã.

Quá trình này tương tự như TDD,:

• viết một bài kiểm tra cho một phần mã
• thực thi nó - thất bại
• sửa lỗi kiểm tra từ hành vi quan sát được của mã
• thực hiện nó - vượt qua
• nói lại

Các bài kiểm tra sẽ không thành công nếu bạn sửa đổi hành vi bên ngoài của mã. Hành vi bên ngoài của mã? âm thanh quen thuộc ? Vâng, đúng rồi, chúng tôi đây. Bây giờ bạn có thể cấu trúc lại mã.

Rõ ràng rủi ro phụ thuộc vào phạm vi của các thử nghiệm mô tả đặc tính.

Hãy xem thư viện tiện ích kiểm tra đơn vị mã nguồn mở miễn phí, ApprovalTests . Nếu bạn là nhà phát triển .NET, người sáng tạo, Llewellyn Falco, đã thực hiện một loạt video cho thấy cách anh ấy sử dụng ApprovalTests để cải thiện kiểm tra đơn vị cho cả mã mới và mã cũ.

Nếu bạn đang lên kế hoạch cấu trúc lại mã kế thừa thì việc tạo các bài kiểm tra đơn vị đó là điều bắt buộc. Đừng lo lắng về việc chế nhạo hoặc khai báo - hãy lo lắng về việc kiểm tra các đầu vào và đầu ra của hệ thống để các thay đổi hoặc nỗ lực tái cấu trúc của bạn không phá vỡ chức năng hiện tại.

Tôi sẽ không nói dối bạn, việc trang bị thêm các bài kiểm tra đơn vị cho mã kế thừa là rất khó - nhưng nó rất đáng giá.

Tôi đã nói một thời gian trước về ý tưởng về Kim tự tháp kiểm tra đảo ngược trong mã kế thừa tại XPDays http://xpdays.com.ua/archive/xp-days-ukraine-2012/materials/legacy-code/

Phần trình bày này sẽ trả lời câu hỏi tại sao đôi khi việc bắt đầu với tích hợp / chức năng hoặc thậm chí kiểm tra chấp nhận cấp cao lại quan trọng khi làm việc với mã kế thừa. Và sau đó từ từ, từng bước giới thiệu các bài kiểm tra đơn vị. Không có ví dụ về mã - xin lỗi, nhưng bạn có thể tìm thấy một loạt chúng trong cuốn sách Michaels Feathers "Làm việc hiệu quả với Legacy Code".

Ngoài ra, bạn có thể kiểm tra Legacy Code Retreat http://www.jbrains.ca/legacy-code-retreat và tìm cuộc họp đó trong khu vực của bạn.