Tôi có thể kiểm tra sự tồn tại của chú thích trong bài kiểm tra đơn vị không?

Tôi có một hệ thống phân cấp lớp java được hình thành bởi một lớp Trừu tượng và N phần mở rộng của nó. Trong lớp trừu tượng tôi có một phương thức được chú thích bằng chú thích @Remove. Mặc dù chúng tôi sẽ không nhận được bất kỳ ngoại lệ nào về việc sẽ không thất bại nhanh nếu chú thích này bị xóa, chúng tôi có thể thoát khỏi ngoại lệ bộ nhớ, vì vậy tôi muốn chắc chắn rằng chúng tôi nhận thấy càng nhanh càng tốt nếu chú thích này biến mất trong một số tái cấu trúc.

Tôi đang cố gắng tạo GUTS (bài kiểm tra đơn vị tốt), vì vậy tôi nghĩ rằng tôi có thể ghi lại "yêu cầu kỹ thuật" này trong các bài kiểm tra của mình, với một trường hợp kiểm tra nêu rõ điều đó.

Nhưng đây không phải là một tính năng, nó là một chi tiết triển khai và nó không được liên kết với hành vi của phương thức (phương thức có thể trống, nhưng nó phải tồn tại và phải được chú thích).

Có ổn không khi tạo một bài kiểm tra cho điều đó hoặc có cách nào khác để kiểm tra sự tồn tại của chú thích này không?

Có tạo ra một bài kiểm tra đơn vị. Bạn đang nói rằng nếu chú thích được loại bỏ thì bạn có thể thoát khỏi lỗi bộ nhớ trong sản xuất. Đó sẽ là một lỗi giết người. Để điều đó xảy ra do một số ý kiến ​​cho rằng các bài kiểm tra nên bằng cách nào đó bị hạn chế là phản tác dụng. Các xét nghiệm nên kiểm tra tính chính xác trong tất cả các giác quan. Bạn càng sớm phát hiện ra vấn đề có thể càng tốt thì việc kiểm tra đơn vị và không xây dựng CI là cách vững chắc để ngăn chặn lỗi. Cố gắng phát minh ra một cơ chế khác để ngăn chặn việc giới thiệu một lỗi như vậy có vẻ không đáng. Mỗi nhà phát triển mới sẽ phải được giải thích về cách xử lý "trường hợp đặc biệt" không có kiểm tra tính chính xác chức năng. Đó rất có thể không phải là một cách sử dụng tốt thời gian của nhà phát triển.

Các nhóm chỉnh sửa làm BDD có khả năng tách biệt kiểm tra chức năng kinh doanh khỏi các kiểm tra kỹ thuật, chẳng hạn như kiểm tra hiệu suất. Thông thường, các nhóm có các loại kiểm tra khác nhau bao gồm các kiểm tra tích hợp được chạy ít thường xuyên hơn các kiểm tra logic nghiệp vụ cốt lõi của họ. Điều này thường được thực hiện với các cấu hình xây dựng để các nhà phát triển trong luồng của họ có thể chạy các kiểm tra logic kinh doanh nhanh thường xuyên và các kiểm tra tích hợp chậm hơn trước khi họ cam kết mã. Bản dựng CI sẽ chạy tất cả các bài kiểm tra.

Khi một chức năng quan trọng được triển khai bằng cách sử dụng một kỹ thuật khai báo như thế này, tôi có xu hướng thích sử dụng một bài kiểm tra tích hợp bao gồm một phần của khung công nhận khai báo. Điều này bảo vệ bạn khỏi những thay đổi trong hành vi của khung, hiểu sai về ảnh hưởng của tuyên bố, v.v. Đơn giản chỉ cần kiểm tra sự hiện diện của chú thích không đảm bảo bất kỳ hành vi cụ thể nào.