Чи можна перевірити наявність примітки в одиничному тесті?

У мене є ієрархія класів java, яка формується абстрактним класом та N розширеннями. В абстрактному класі у мене є метод, який позначається анотацією @Remove. Хоча ми не отримаємо жодних винятків того, що не вийде з ладу, якщо цю анотацію буде видалено, ми можемо вийти з винятку з пам'яті, тому я хотів би бути впевнений, що ми помічаємо якомога швидше, якщо ця анотація зникне під час рефакторингу.

Я намагаюся створити GUTS (хороші одиничні тести), тому я подумав, що можу документувати цю "технічну вимогу" у своїх тестах, із тестовим випадком, який це констатує.

Але це не особливість, це як деталь реалізації, і вона не пов'язана з поведінкою методу (метод може бути порожнім, але він повинен існувати і повинен бути анотований).

Чи добре це створити тест для цього чи є якийсь інший спосіб перевірити існування цієї анотації?

Так, створіть одиничний тест. Ви говорите, що якщо анотацію буде видалено, ви можете позбутися помилок у виробництві. Це була б помилка-вбивця. Допускати це через якусь ідею, що тести слід якось обмежувати, є контрпродуктивним. Тести повинні перевірити правильність у всіх сенсах. Чим швидше ви виявите можливу проблему, тим краще, тому тест на одиницю та збій CI збірки є надійним способом запобігання помилок. Спроба винайти інший механізм, щоб запобігти впровадженню такої помилки, здається, поки не варто. Кожному новому розробнику доведеться пояснити, як поводитися з "особливим випадком" жодних тестів на функціональну коректність. Це, швидше за все, не дуже добре використовувати час розробника.

Команди редагування, які мають BDD, швидше за все, відокремлюють функціональний тест бізнесу від технічних тестів, таких як тести на ефективність. Зазвичай команди мають різні типи тестів, включаючи тести інтеграції, які виконуються рідше, ніж їх основні бізнес-логічні тести. Зазвичай це робиться з профілями збірки, щоб розробники в їх потоці часто могли запускати швидкі тести бізнес-логіки та повільніші тести на інтеграцію, перш ніж ввести код. Складання CI запустить усі тести.

Коли критична функція реалізується за допомогою такої декларативної техніки, я, як правило, віддаю перевагу використанню тесту інтеграції, який включає частину структури, яка розпізнає декларацію. Це захищає вас від зміни поведінки рам, нерозуміння ефекту декларації тощо. Просто перевірка наявності примітки не гарантує конкретної поведінки.