Các trình tạo thử nghiệm đơn vị đã giúp bạn khi làm việc với mã kế thừa?

Tôi đang xem xét một cơ sở mã C # (.NET 4.0, một số Silverlight) được tạo ra có phạm vi kiểm tra rất thấp. Bản thân mã này hoạt động ở chỗ nó đã vượt qua thử nghiệm chấp nhận của người dùng, nhưng nó dễ vỡ và ở một số khu vực không được bao gồm nhiều. Tôi muốn thêm phạm vi kiểm tra đơn vị rắn xung quanh mã kế thừa bằng cách sử dụng các nghi phạm thông thường (NMock, NUnit, StatLight cho các bit Silverlight).

Cách tiếp cận thông thường của tôi là bắt đầu làm việc thông qua dự án, kiểm tra đơn vị & tái cấu trúc, cho đến khi tôi hài lòng với trạng thái của mã. Tôi đã làm điều này nhiều lần trong quá khứ và nó hoạt động tốt.

Tuy nhiên, lần này tôi đang nghĩ đến việc sử dụng một trình tạo thử nghiệm (cụ thể là Pex ) để tạo khung thử nghiệm, sau đó tự động tìm hiểu nó.

Câu hỏi của tôi là: bạn đã từng sử dụng các trình tạo thử nghiệm đơn vị trong quá khứ khi bắt đầu làm việc trên một cơ sở mã di sản, và nếu vậy, bạn có muốn giới thiệu chúng không?

Nỗi sợ hãi của tôi là các thử nghiệm được tạo sẽ bỏ lỡ các sắc thái ngữ nghĩa của cơ sở mã, dẫn đến tình trạng đáng sợ khi thử nghiệm vì lợi ích của số liệu bảo hiểm, thay vì các thử nghiệm thể hiện rõ hành vi dự định trong mã.

unit-testing legacy

— Duncan Bayne
nguồn

Tôi đã thử PeX một lần và kết quả là, tốt, giả sử, không thỏa mãn lắm - YMMV. Đừng mong đợi một công cụ như vậy để "hiểu" mã của bạn và các yêu cầu chức năng của nó - nó không bỏ lỡ "các sắc thái ngữ nghĩa", nó bỏ lỡ toàn bộ ngữ nghĩa. Hơn nữa, khi bạn bắt đầu với một cơ sở mã kế thừa, thông thường bạn sẽ không bắt đầu với các bài kiểm tra đơn vị trước, mà bằng các bài kiểm tra hệ thống hoặc tích hợp; đó chắc chắn không phải là những gì PeX được tạo ra.

— Doc Brown

Tôi sẽ đề nghị nhìn mọi thứ một chút khác nhau. Thêm mã kiểm tra đơn vị mới vào một ứng dụng hiện có mà không có sự cố có thể không mang lại cho bạn kết quả tốt nhất. Nếu bạn đang làm điều này để làm quen với cơ sở mã hoặc bạn thực sự có thời gian để giết và muốn thử nghiệm các trình tạo thử nghiệm thì hãy bỏ qua ý kiến của tôi.

Để thực dụng, bạn nên xem qua tất cả các danh sách lỗi. Sau đó tạo các bài kiểm tra đơn vị cho từng lỗi, dẫn đến cách xử lý. Lý tưởng nhất là bạn sẽ chỉ thêm mã mới cho mỗi lỗi khi bạn tiếp cận nó.

Thời gian để thêm mã kiểm tra đơn vị:

Thêm chức năng mới
Mã xác nhận lại
Đã sửa lỗi
Học những gì mã làm
Chứng minh lỗi tồn tại

Thật khó để định lượng giá trị của việc thêm các bài kiểm tra đơn vị sau khi thực tế.

Tôi thường không cho phép mình viết câu trả lời trái với những gì người hỏi muốn, nhưng tôi cảm thấy đây là một bài học tốt để vượt qua.

— Andrew T Finnell
nguồn

Tôi đồng ý 100% với bạn ở đó - câu hỏi này xuất phát từ tôi tự hỏi làm thế nào tốt nhất để dành thời gian xuống. Cách làm thông thường của tôi là kiểm tra & tái cấu trúc trong quá trình sửa lỗi hoặc thêm tính năng. Tôi đã hy vọng một số người có thể chia sẻ một số câu chuyện chiến tranh trong khu vực này ...

— Duncan Bayne

+1, Chụp để bảo hiểm sau khi thực tế thường không hiệu quả. Có các thử nghiệm trên các lỗi cố định ngăn chặn hồi quy là rất hiệu quả. Hồi quy một lỗi có thể rất bực bội cho mọi người liên quan. Các thử nghiệm thực sự phù hợp để giúp bạn viết mã tốt hơn. Bolting trên các bài kiểm tra thường dẫn đến các bài kiểm tra không đạt tiêu chuẩn. Tôi nghĩ rằng nỗi sợ hãi của OP đã được thiết lập và tỷ lệ tín hiệu / nhiễu từ các thử nghiệm được tạo sẽ gây cản trở. Mã không được kiểm tra có thể có một số bit rất phân nhánh trong đó. Các công cụ chỉ ra mùi mã có lẽ hữu ích hơn. Có thể FXCop và các công cụ tương tự.

— kevpie