Viết bài kiểm tra mã mà mục đích tôi không hiểu

Gần đây tôi đã hoàn thành một tái cấu trúc hộp đen. Tôi không thể kiểm tra nó, vì tôi không thể tìm ra cách kiểm tra nó.

Ở mức cao, tôi có một lớp có khởi tạo liên quan đến việc lấy các giá trị từ một số lớp B. Nếu lớp B là "trống", nó tạo ra một số mặc định hợp lý. Tôi đã trích xuất phần này cho một phương thức khởi tạo lớp B cho cùng các giá trị mặc định đó.

Tôi vẫn chưa tìm ra mục đích / bối cảnh của một trong hai lớp, hoặc cách chúng sẽ được sử dụng. Vì vậy, tôi không thể khởi tạo đối tượng từ một lớp B trống và kiểm tra xem nó có đúng giá trị / thực hiện đúng không.

Ý tưởng tốt nhất của tôi là chạy mã gốc, mã cứng trong kết quả của các phương thức công khai tùy thuộc vào các thành viên được khởi tạo và kiểm tra mã mới dựa vào đó. Tôi không thể nói rõ tại sao tôi cảm thấy mơ hồ khó chịu với ý tưởng này.

Có một cuộc tấn công tốt hơn ở đây?

Bạn đang làm tốt!

Tạo các bài kiểm tra hồi quy tự động thường là điều tốt nhất bạn có thể làm để tạo thành một cấu trúc lại thành phần. Nó có thể gây ngạc nhiên, nhưng các bài kiểm tra như vậy thường có thể được viết mà không có sự hiểu biết đầy đủ về những gì thành phần thực hiện bên trong, miễn là bạn hiểu "giao diện" đầu vào và đầu ra (theo nghĩa chung của từ đó). Chúng tôi đã làm điều này nhiều lần trong quá khứ cho các ứng dụng kế thừa toàn diện, không chỉ các lớp học và nó thường giúp chúng tôi tránh phá vỡ những điều mà chúng tôi không hiểu đầy đủ.

Tuy nhiên, bạn nên có đủ dữ liệu kiểm tra và đảm bảo rằng bạn hiểu rõ phần mềm làm gì từ quan điểm của người dùng thành phần đó, nếu không bạn có nguy cơ bỏ qua các trường hợp kiểm tra quan trọng.

IMHO là một ý tưởng tốt để thực hiện các thử nghiệm tự động của bạn trước khi bạn bắt đầu tái cấu trúc, không phải sau đó, vì vậy bạn có thể thực hiện tái cấu trúc theo các bước nhỏ và xác minh từng bước. Việc tái cấu trúc chính nó sẽ làm cho mã dễ đọc hơn, vì vậy nó giúp bạn tăng sự hiểu biết của mình về các phần bên trong từng chút một. Vì vậy, các bước đặt hàng trong quá trình này là

1. hiểu mã "từ bên ngoài",
2. viết bài kiểm tra hồi quy,
3. refactor, dẫn đến sự hiểu biết tốt hơn về các phần bên trong của mã

Một lý do quan trọng để viết bài kiểm tra đơn vị là chúng bằng cách nào đó ghi lại API thành phần. Không hiểu mục đích của mã đang thử nghiệm thực sự là một vấn đề ở đây. Phạm vi bảo hiểm mã là một mục tiêu quan trọng khác, khó đạt được mà không biết nhánh thực thi nào tồn tại và chúng được kích hoạt như thế nào.

Tuy nhiên, nếu có thể thiết lập lại trạng thái sạch sẽ (hoặc xây dựng đối tượng thử nghiệm mới mỗi lần), người ta có thể viết các thử nghiệm loại "rác trong thùng rác" chỉ cung cấp chủ yếu đầu vào ngẫu nhiên cho hệ thống và quan sát đầu ra.

Các xét nghiệm như vậy rất khó để duy trì, vì khi chúng thất bại, có thể phức tạp để nói tại sao và mức độ nghiêm trọng của nó. Phạm vi bảo hiểm có thể là nghi vấn. Tuy nhiên họ vẫn tốt hơn nhiều so với không có gì. Khi thử nghiệm như vậy thất bại, nhà phát triển có thể sửa đổi các thay đổi mới nhất với sự chú ý nhiều hơn và hy vọng phát hiện ra lỗi ở đó.