[tradein] scraper_kit migration — Stage 0: общий parity-test harness #2304

New issue

Closed

opened 2026-07-03 20:17:02 +00:00 by lekss361 · 0 comments

lekss361 commented

2026-07-03 20:17:02 +00:00

Owner

Родительский эпик: #2277 (аудит зависимостей — comment 2026-07-03T19:59:16Z, id 19984).

Зачем

Все следующие sub-issues миграции legacy app/services/scrapers/* → scraper_kit требуют
одного и того же: сравнить вывод старой функции и kit-эквивалента на одинаковом входе. Без
общей утилиты каждая группа пишет свою — дублирование и риск разных стандартов строгости
(особенно критично для группы valuation).

Scope (S)

Написать переиспользуемую parity-test утилиту (tests/support/ или аналог по конвенции репо):

Принимает legacy-callable + kit-callable + набор входных фикстур (реальные записи из БД или
сохранённые снапшоты)
Гоняет оба, сравнивает вывод (поддержка tolerance для float-полей типа latency/timestamp)
Понятный diff-репорт при расхождении

DoD

Утилита существует, покрыта собственным unit-тестом (сравнение на заведомо идентичных/
заведомо разных входах)
Пример использования — parity-тест для ОДНОГО простого случая (например
app/api/v1/admin.py debug-эндпоинт) как smoke, доказывающий что harness работает
end-to-end
README/docstring — как следующим PR'ам (группы A-F) подключить harness к своей миграции

НЕ входит

Сама миграция importers (это группы A-F, отдельные issues)
Изменение legacy-кода (harness read-only относительно legacy)

Блокирует: все остальные sub-issues этого эпика (A, B, C, D, E, F) — они ссылаются на этот
harness в своих parity-тестах.

Родительский эпик: #2277 (аудит зависимостей — comment 2026-07-03T19:59:16Z, id 19984). ## Зачем Все следующие sub-issues миграции legacy `app/services/scrapers/*` → `scraper_kit` требуют одного и того же: сравнить вывод старой функции и kit-эквивалента на одинаковом входе. Без общей утилиты каждая группа пишет свою — дублирование и риск разных стандартов строгости (особенно критично для группы valuation). ## Scope (S) Написать переиспользуемую parity-test утилиту (`tests/support/` или аналог по конвенции репо): - Принимает legacy-callable + kit-callable + набор входных фикстур (реальные записи из БД или сохранённые снапшоты) - Гоняет оба, сравнивает вывод (поддержка tolerance для float-полей типа latency/timestamp) - Понятный diff-репорт при расхождении ## DoD - [ ] Утилита существует, покрыта собственным unit-тестом (сравнение на заведомо идентичных/ заведомо разных входах) - [ ] Пример использования — parity-тест для ОДНОГО простого случая (например `app/api/v1/admin.py` debug-эндпоинт) как smoke, доказывающий что harness работает end-to-end - [ ] README/docstring — как следующим PR'ам (группы A-F) подключить harness к своей миграции ## НЕ входит - Сама миграция importers (это группы A-F, отдельные issues) - Изменение legacy-кода (harness read-only относительно legacy) Блокирует: все остальные sub-issues этого эпика (A, B, C, D, E, F) — они ссылаются на этот harness в своих parity-тестах.