Verification harness — це набір сенсорів
Verification harness — локальний набір повторюваних перевірок, який перетворює припущення про безпечність зміни на вимірювані сигнали. Він показує проблеми форматування, типів, компіляції, тестів, статичного аналізу або очевидних security-патернів.
Сенсор має бути детермінованим: однаковий стан коду повинен давати однаковий результат. Нестабільний тест не є надійною основою для рішення про рефакторинг.
| Сенсор | Що виявляє |
|---|---|
| Formatter | Проблеми стилю та структури оформлення |
| Linter | Типові помилки й сумнівні патерни |
| Type-check | Порушення типових контрактів і сигнатур |
| Build / assemble | Проблеми компіляції, залежностей і модулів |
| Unit / integration tests | Локальну логіку та взаємодію компонентів |
| Coverage / static analysis | Сліпі зони й глибші сигнали якості |
| Code intelligence | Оголошення, usages, call chain і масштаб впливу |
Швидкі та повні перевірки
Не потрібно запускати весь CI після кожного збереження файлу, але й не варто відкладати всі перевірки до кінця. Formatter може показати коректний стиль, але не доводить правильність поведінки.
| Група | Приклади | Коли запускати |
|---|---|---|
| Швидка | Formatter, легкий lint, type-check, targeted unit test | Після кожного малого кроку |
| Середня | Integration test, build окремого модуля | Після зміни відповідного шару |
| Повна | Повний test run, coverage, широкий static analysis | Перед PR або завершенням етапу |
Карта harness перед редагуванням
- Прочитайте CLAUDE.md і правила проєкту.
- Перевірте package.json, build.gradle, README та наявні scripts.
- Відокремте швидкі перевірки від повних.
- Не додавайте новий toolchain, якщо потрібні інструменти вже є.
- Знайдіть usages, call chain, повʼязані тести та публічні контракти.
- Зафіксуйте невідомі команди замість вигадувати їх.
Керований цикл із harness
- Внесіть одну обмежену зміну.
- Запустіть відповідний точковий сенсор.
- Перегляньте diff і список файлів.
- Перед PR запустіть ширший набір перевірок.
- Збережіть фактичні команди, результати та обмеження.
one approved change
-> targeted sensor
-> diff review
-> record command and result
-> broader harness before PRПриклад для локального рефакторингу
Перед зміною OrderService.finalizeOrder потрібно знайти всі виклики й тести. Після перенесення валідації до приватного helper-а запускається точковий тест, читається diff, а перед PR — повніша перевірка. Tester-agent і reviewer-agent мають користуватися тим самим harness, а не вигадувати власні критерії.
- Невідомий script потрібно позначити як unknown.
- Невдалий сенсор — сигнал для діагностики, а не привід одразу послабити тест.
- Після завершення зафіксуйте, що реально запускалося.
- Не називайте перевірку успішною без фактичного результату.
Канонічне джерело уроку · JavaRush
Відкрити матеріал JavaRush